WordPressの不要画像を削除したらアイキャッチ画像も消えてあわや大惨事

先日、ブログのバックアップを取っていたところ、ファイルサイズが1.3GBと巨大になっていたのでスリム化をはかりました。
プラグインを信用して安易に作業したら大変なことになったので、注意点を含めてまとめてみます。

バックアップファイルサイズが肥大した原因

ブログのバックアップファイルの中で最も容量を食うのが画像ファイルです。

それは分かっていたので、アップロードした画像はWordPress上でリサイズして保存していたのですが、よくよく調べてみると、WordPressにファイルをアップロードした際には複数のファイルが作成されていることがわかりました。

・オリジナルファイル
・リサイズしたファイル
・大サイズ
・中サイズ
・サムネイルサイズ(100×100,150×150)
・medium_large_size_w(横幅が768pxのファイル)
・テーマが作成している(と思われる)ファイル(320×180,320×240)

そして、アップロードしたファイルのサイズを変更するとその変更したサイズの画像が作成されます。
さらに、画像を回転させた場合、生成されていた全ファイルに対して、回転したファイルを生成するようです。

つまり、ファイルをアップロード→縮尺変更→画像回転の手順で画像を登録すると1枚の写真をアップロードしただけで9ファイルが作成されることになります。
縮尺変更したファイルやサムネイルファイルは大したサイズではありませんが、蓄積されて行くと膨大な量になってしまいます。

このままではサーバ容量を圧迫してしまうので、対策をとることにしました。

作業前バックアップ

この手の作業を行う場合は、必ずバックアップを取ってから行いましょう

私はバックアップを取ってから実施したので事なきを得ましたが、バックアップを取っていなければ大変なことになっていました。。。

プラグインのバックアップでも良いですができれば手動バックアップも取った方が良いと思います。
私は以下の2点のバックアップを取りました。
 ・WordPressのインストール先(/var/www/html/wordpress/)
 ・mysqlのダンプファイル

アップロード済みファイルの削除

まず、最初に行う対策はすでにアップロードしている写真で、不要な解像度のファイルを削除します。

こちらは、DNUIというプラグインを使用します。
プラグインの新規検索から「DNUI」で検索すると出て来ます。

※Web上では「DNUI Delete not used image」と紹介されているサイトをいくつか見かけましたが、プラグインの名前が変わっているようです。

こちらのプラグインを使用すると、WordPressにアップロードした画像を検索して未使用のものを削除することができるようです。

使用方法

インストール後、サイドメニューから「ツール」→「DNUI Delete not used image」と選択します。

プラグインのページが表示されますので、「images」のタブを選択します。
タブが表示されると時間差でファイルの一覧が表示されます。
基本的に未使用のファイルのみが表示されます。

右上の「Delete All」をクリックすると一覧に表示されている未使用画像を削除することができます。
複数ページに分かれている場合は、各ページを開いて削除する必要があります。
何ページも開くのが面倒な場合は「Options」のタブを開いて1ページに表示される件数を調節することができます。
ただし、1ページの表示件数を増やすとうまくページが表示されなかったりする場合があるようです。

「Options」タブの設定では、特定のサイズは削除対象外にするという設定も可能です。
これは「Ignore size list」の項目から指定できます。

注意事項

DNUIは未使用ファイルを削除してくれる便利なプラグインですが、致命的な欠点があります。
それはアイキャッチ画像にしか設定していないファイルは未使用として扱われてしまうようです。

記事内から参照しているファイルは大丈夫ですが、アイキャッチのみという使われ方をしている場合は削除されてしまいますので、注意が必要です。

私はこれに見事引っかかり、アイキャッチ画像が消滅しました。

慌ててバックアップからファイルを差し戻しましたが、どうやらDNUIで削除されたものは(直接か間接的にかは不明ですが)DB上のデータにも影響を与えるようで、復旧できませんでした。
DBのダンプファイルからリストアしてようやく復旧できました。

バックアップをミスっていたら一大事でした。

2つ目の注意点として、オリジナルファイルは消してはいけないようです。
これはWordPressの振る舞いかと思いますが、直接リンクしていないとはいえ、オリジナルを消すと他の解像度のファイルも消えてしまうようです。

作業内容

プラグインの特性はわかりましたが、影響度が不明でしたので、取り敢えず当ブログではほとんど使用していない中サイズ、大サイズで未使用のものを削除しました。

サムネイル系はサイズも小さいので今回はそのままにしました。

ファイルの量は減りましたが、合計サイズとしては100MB程度しか減りませんでした。

オリジナルファイルの削減

アップロード済みのオリジナルファイルですが、一眼レフで撮影した写真は10MB近くあり、iPhoneで撮った写真でも2〜3MBはあります。
こちらのファイルをどうにかしなければなりません。

私が取った対応は、サーバ上の画像をかき集めてMacBookProへ転送し、Mac上でリサイズ後にサーバ上のファイルを上書きするという方法を取りました。

この方法であれば、オリジナルファイルは削除せずにファイルサイズを小さくすることができます。
 →本来であれば、リサイズした上でアップロードする方が良いのですが、iPhoneから直接アップしたりもするので。。。

Th-MakerX

Mac上でのリサイズは「Th-MakerX」というアプリを使用しました。
 こちらからDLできます→Th-MakerX

リサイズ自体はMacの標準のビューワーでもできますが、利便性を考えてこちらのツールを使用しました。

以前は「iMage Tools」というツールを使っていたのですが、縦長と横長の画像をまとめて処理できなかったので今回から使うのをやめました。

また、Th-MakerXではウォーターマークを入れることができますので、今回まとめて「takuminchi.blog」と右下に入れてあります。

作業結果

作業前のフォルダで容量を取得してみたところこんな感じでした。
— before —
324M ./2017/06
192M ./2017/03
163M ./2017/05
150M ./2017/07
3.0M ./2017/01
167M ./2017/04
209M ./2017/02
1.2G ./2017
1.2G .

作業後はこんな感じです。
— after —
71M ./2017/06
66M ./2017/03
44M ./2017/05
47M ./2017/07
260K ./2017/01
51M ./2017/04
42M ./2017/02
320M ./2017
320M .

だいたい1/4ぐらいになりました。
半年分の記事で320MBであれば許容範囲内かなっと思います。

設定変更

今アップロードされているファイルについて対策を取りましたが、そのままだと今後も増えて行くことが予想されます。
なので、WordPressの設定を変更して、余計なファイルの生成を抑制しました。

大サイズ、中サイズに関しては、WordPressのダッシュボードで「設定」→「メディア」を選択し、中サイズと大サイズのサイズ入力欄に全て「0」を設定しました。

medium_large_size_wのサイズに関しては、「http://ドメイン名/wp-admin/options.php」に直接飛び、そこからmedium_large_size_wの設定を「0」にしました。

これで、3つの不要ファイルの作成は抑制されました。

サムネイルはサイズが小さいので、特に対策は取っていません。
テーマ側で作っていると思われるファイルに関しては、抑制方法がわからなかったので保留にしました。こちらもサイズが小さいので今今は懸念していません。

WordPress上でリサイズや回転したファイルに関してもそれほどサイズが大きくないので対処はしていません。
これらのファイルは定期的に「Th-MakerX」でオリジナルと一緒にリサイズすれば良いかなと思ってます。

まとめ

WordPress上で編集すればオリジナルファイルもなくなるという思い込みで、いつの間にかサーバ容量を圧迫していました。
ちゃんとメンテナンスしておかないと大変ですね。ディスクフルになる前で良かったです。

WordPressをお使いの方は今一度設定を見直してみてはいかがでしょうか?

スポンサーリンク
記事用

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

関連コンテンツ



スポンサーリンク
記事用