画像やリンクが無効になっている可能性もあるのでご了承下さい。
はじめに
Simplicity2 から Cocoon にテーマを変更した事と WordPress Popular Posts の使用を取りやめた関係で全ての画像のサムネイルを再生成した。
Cocoon に移行した直後はトップページのインデックスにある「記事のアイキャッチ画像」が古いサムネイルの場合、適応するアスペクト比に出来ずに記事のカードがズレて表示されたりちう悪影響が見受けられた。
ちょっとこれは格好悪いなという事でサムネイルを再生成させることで解消させる事とした。
サムネイル再生成を行う理由
使用するテーマによって生成するサムネイルのサイズが異なるので、使用中のテーマが必要とするサイズのサムネイルが存在しないときは近い解像度のサムネイルか若しくは大元の大きな画像の表示サイズを変えるだけで埋め込む場合も見受けられる。
この場合、画像のクロップなどでアスペクト比を調整までしてくれないのでインデックスに表示されるアイキャッチ画像のアスペクト比が 16:9 や 4:3 とか 3:2 はたまた 1:1 等と混在してしまうことになる。故に表示がズレたりカードサイズに統一感が無くなると。
こう言った表示上の問題を解決する事と、不要なサイズのサムネイルは削除して整理するという意味も込めてサムネイルを再生成する事に。
WP-CLI の導入
WordPress にはプラグインでもサムネイルを再生成してくれる物は存在する。
しかしこのプラグインの説明を読んでいると
If you have command line access to your server, I highly recommend using WP-CLI instead of this plugin as it’s faster (no HTTP requests overhead) and can be run inside of a screen for those with many thumbnails. For details, see the documentation of its media regenerate command.
なんて書いてある。要は HTTP のオーバーヘッドが無いから高速だよって事に。
確かに大量の画像が存在する場合、ブラウザを開いたままにしておかなければならないし間違ってページを閉じでもしたら目も当てられない状態になってしまう。
ならばということでこの際 WP-CLI の導入を行うこととした。これは非常に簡単な作業だった。
WP-CLI オフィシャルページに手順が書かれているのでそのまんまやるだけ。
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5241k 100 5241k 0 0 2368k 0 0:00:02 0:00:02 --:--:-- 2368k
php wp-cli.phar --info
OS: Linux 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64
Shell: /bin/zsh
PHP binary: /usr/bin/php
PHP version: 7.2.12
php.ini used: /etc/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /home/hoge/tmp
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.0.1
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp流れとしては wp-cli.phar をダウンロードしたあと、動作確認をする。実行権を与えて /usr/local/bin 以下に wp という名前で移動することでインストールという事になる。
WP-CLI を用いた全画像のサムネイル再生成
WP-CLI を用いればコマンド一つで再生成が可能だが、先ずは画像のバックアップを行っておく必要がある。
もし途中で何かしらのトラブルが発生して処理が止まった場合、正常に画像が読み込めなくなってかなり大変な事になる。これは検証環境でテスト中に敢えて途中で止めてみたらアイキャッチ画像が歯抜け状態になってしまった事で実体験済み。
バックアップを行うには WordPress をインストールしたドキュメントルート以下 wp-content/uploads を全てを別の場所にコピーするなり tar で固めておいても良いだろう。
筆者の場合は検証環境としている仮想マシンに rsync で全部飛ばしておいた。
確実にバックアップを取ったらあとは WP-CLI を用いてコマンドを打ち込んでおく。
WordPress のインストール先は /path/to/wordpress と表す事にした。
WP-CLI を実行する時に WordPress の設定状況などを読み込んでよろしくやってくれる関係上、WordPress のインストール先をカレントディレクトリとしておく必要がある。若しくは --path オプションでインストール先を指定しても良い。
cd /path/to/wordpress
wp media regenerate --yes このコマンドはサムネイル再生成を何かあってもユーザの確認無しに処理すると言う物。
注意点としては画像数が多い場合にはもの凄い時間がかかるので、ターミナル上でそのまま実行すると開いたままにしておかなければいけなくなる。
予め時間が掛かると分かっている場合は nohup コマンドを用いるか screen を使ってターミナルを閉じてもジョブが死なない様な手を一つ入れておくと良いだろう。
筆者はサブマシンが基本 24 時間稼働な為、そちらでターミナル開いて ssh でホストに接続し WP-CLI を実行したまま放置しておいた。
サムネイル再生成に掛かった時間
このブログの画像は全部で 6,907 個。
再生成の処理を開始したのが 2018/12/04 23:30 頃。
終了した時間が大体 2018/12/05 08:30 だったので大体 9 時間掛かったことになる。
平均すると 1 枚の画像あたり 4.7 秒程度必要だったと言う事になる。勿論これは元画像のサイズによって大きく左右されてくる所とは思う。
参考までに言うと、ホストの CPU は Intel Core i3-550 にメモリ 12GB、ストレージには適当な SSD となっている。
再生成した結果
トップページの記事インデックスに表示されているアイキャッチ画像のアスペクト比が全てテーマ Cocoon で設定した 16:9 に統一され、ズレなども無く綺麗に揃ってくれた。
既に使われていないサイズのサムネイルも消えたので無駄なディスク使用も減ったかなと思ったけど、新たなサイズのサムネイルが増えていたので逆に少しディスク使用量が増えたかなと。
おわりに
テーマの変更もそうだし WordPress の画像設定で生成させるサムネイルサイズを変更した場合は整合性をとるためにサムネイルの再生成を行っておくと良いだろう。
コメント