私は、STINGER PLUS を2016年くらいから使ってました。
↓
2019年3月に WING（ AFFINGER5 ）に変更しました。
画像が大目なのか、データベースと画像などを、Updraft Plusでバックアップを取ると、１ギガをちょっと超えてしまいました。
画像のサイズは、当初はいろいろなサイズを試してましたが、ブログをスタートしてから１年後には
- 記事中の画像サイズ：640 x 400
- アイキャッチ画像：150 x 150
に固定してました。特に記事中の画像は大きくても150KBくらい。飛び出て250KB。
アイキャッチ画像は、15KB以下です。
で、バックアップを取ったら１ギガを超えてしまったと。
「 でも、容量を小さくして画像をアップしているのに１ギガも超えるのかなぁ？ 」
使用しているサーバーはさくら。
さくらのコントロールパネルには、ファイルマネージャー機能があります。FFFTPみたいなヤツです。
ファイルの中を調べました。
↓
[ wp-content ] フォルダ
↓
[ uploads ] フォルダ
↓
[ 2016 ] フォルダ （ 他には 2017 / 2018 / 2019 )
↓
[ 06 ] 6月フォルダを開くと、
2016年6月にアップロードした画像が出てくるわけですが、
001.jpg のほかに、
001-100x100.jpg
001-150x150.jpg
と、○○○×○○○ という複製画像が。
ワードプレスは画像をアップロードすると、トリミングしたりして自動で勝手に他サイズを生成してしまう機能に気づいて、
途中から、
ダッシュボード
↓
設定
↓
メディア にて、
- サムネイルのサイズ
- 中サイズ
- 大サイズ
の全て値を「 ゼロ 」にしてました。
が、それまでの残骸が軽く見積もっても 3,000個以上・・・。
-----------------------------
で、ついでに気付いたのは、
AFFINGER5にしてから、
変なサイズが複製されている。
根っこから自動生成をナシにしようと、
AFFINGER5の親ファイルのfunctions.phpで、
2512行 ～ 2524行の命令文の先頭に // をつけてコメントアウトさせました。
-----------------------------
さくらのファイルマネージャーには「 検索機能 」が付いており、
- *60x60*
- *100x100*
- *150x150*
- *300x300*
と、検索するとその画像だけを抽出してくれて削除することが可能です。
抽出して 2016年分をコツコツ削除しました。
その後、使っている画像がたまたま 150x150 の名前が使われていたら表示されないことになるので、
ダッシュボード
↓
設定
↓
Broken Link Checker （ リンクチェッカー ）
↓
高度な設定タブ
↓
再確認 → すべてのページを再確認 をクリック。
とりあえず、画像のリンクエラーは発生していないことを確認できました。が、
リンク切れ発生。
私が使っているパソコンのブラウザソフトは、Google Chrome です。
液晶モニターのサイズが23インチと微妙なため、ブラウザのズーム設定を普段は80%で利用してます。
AFFINGER5はトップページにずらっとサムネイルがタテに並びます。そのサムネイルを一気に確認したいと思い、ズーム設定を33%にしたところ、
2016年の記事の７割ぐらいが、画像のリンク切れ状態に・・・。
え～、なんで！？
と、思いましたが冷静になってズーム設定を100%にしてみたところ、
普通に表示されている。戻ってる。
？？？
リンク切れ画像の、リンク先アドレスの末尾には、-60x60と自動生成の証が付いてました。
2017年・2018年・2019年の記事のアイキャッチ画像を100%でリンクアドレスを調べるとオリジナルのままなのですが、33%で見てみると-60x60がアドレスの末尾に付いてました。
ただし、自動生成の命令文をコメントアウトした以降で、150px × 150px のアイキャッチ画像をアップロードした記事については、
33%に小さくして再読み込みしても、150のオリジナルサイズが適用していてリンク切れになりません。アドレスの末尾もオリジナルのままです。
うーん、wpの昔からあるようなデフォルトのテーマなら、
メディア設定でサイズをゼロにすれば自動生成のすべてが防げるけど、
スティンガープラスや、AFFINGER5などの特殊なテーマの場合、
デフォルトでゼロにするだけでは足りなくて、テーマのphpから削除するなり、コメントアウトするなりをしなければいけない、と思う。
結局、functions.php で自動生成を停止してなかった500記事では、
60x60を関連付け、ヒモ付けされてしまっており、
画像をただ削除してしまうと、33%サイズで見ているユーザーには画像リンク切れの嵐になっている。
回避したい場合は、
functions.php で自動生成を停止しているのを確認してから、
１ページづつ編集に入って、アイキャッチをいったん削除して、再度指定する
という必要があるんでしょうな。
うーん、面倒だ。
で、気をつけたいのが、画像削除プラグインである
DNUI - Delete not used image 。
使われていない画像を検索・検知・抽出して削除できるおりこうさんプラグイン。
ただし、
そもそも更新が３年前なので、ワードプレスのブロックという概念である新エディター「Gutenberg（グーテンベルク）」との愛称ってどうなの？と。
で、小さいサイトでAFFINGER5テーマを使ってDNUIを使ってみました。
結果は、余計な生成サイズを軒並みキレイに削除できました。結果、AFFINGER5でも使えます。
が、
検索してくれるプログラムは、果たして33%まで対応しているか？
100%で見ている状況のみをベースとして、削除するのではないだろうか？
33%の画像（60x60）は普段は絶対に使われることは無い。だけど残してくれないと、画像リンク切れとなってしまう。
DNUIには、オリジナル画像は絶対に消さないという条件を付け加えることが可能なのですが。うーむ。
とりあえず、
今からブログを開始する人は、ダッシュボードからサイズをゼロにして、テーマのファンクションPHPにて自動生成をコメントアウトしてしまいましょう。
すでにブログを執筆している人で、コメントアウトしていない人はテーマによっては自動生成されており、60x60など普段使わないサイズが生成されて、しかもヒモ付け・関連付けされている可能性がありますので、画像削除する前に、コメントアウト設定を行ってから、各ページのアイキャッチ画像をいったん削除してから、再アップロードして、更新しましょう。その後、DNUIで一括削除、というコースをオススメします。
また、
オリジナルが640ｘ400のサイズで、
ユーザーが見ている液晶サイズによって、
- パソコンの液晶モニター
- ノートパソコン
- タブレット
- スマホ
それぞれにあったサイズ
- 640ｘ400
- 320ｘ200
- 100ｘ66
でサーバーからダウンロードされるとすれば、100％で表示しきれない＝無駄に大きいデーターをダウンロードせずに済むので、
画像サイズの自動生成は理にかなったシステムかとは思います。
ただし、現在では遅延読み込みプラグインであるa3 Lazy Loadなどがあるので、（ googleのPageSpeed Insightsテストでもそれ系のプラグインを使いましょうと言ってます。）
オリジナルの画像が500KBだったり、1MBと巨大サイズであれば論外ですが、
100 ～ 200KB程度の画像であれば、遅延読み込みプラグインでリカバーできてしまう。
自動生成・画像サイズのレスポンシブ対応は否定しません。スマートです。
が、普段見ることがないサイズまでどんどん自動生成されてしまう現状は果たして健全と言えるのか？
いかにデータ容量が1KBと小さくても、それが年別に、月別に1,000個も10,000個も存在する場合、Updraft Plusなどでバックアップする際に余計な時間がかかってしまうことは間違いない。
私はすべての自動生成をOFFにします。
各端末サイズでぴったりのサイズをダウンロードすることで稼げるタイムは、すぐそこに来ている5G時代に突入すれば、そのアドバンテージを体感することができなくなるはずですし。
※ ちなみに、アイキャッチ画像だけではなく記事中の画像も33％にするとリンク切れになってます・・・。