WordPress3.5.1から4.7.3に更新して144%スピードアップした話。



どうも ぼくです。

このHPの運営を引き継いで5年ぐらいになりました。

ド素人がHPのサーバーの引っ越しから、ブログっぽい機能がついた誰でも無料で使えるwordpressというアプリのようなソフトのようなものを使ってデザインしたりと、どうにかなるものです。

今日はそんな5年前のカオスなソースコードを紐解いくとともに、肥大化したプラグイン群や設定を整理しながらwordpress3.5.1から4.7.3と最新版にするとともに、実行環境はphp5からphp7、mysql5.0からmysql5.5へ更新・移行作業を行っていきます。

かなり面倒そうなので、蓋をしてきましたが、php5からphp7になると処理速度が2倍!という誘惑に負けて更新処理行いました。

あとは、サーバー側が提供する高速化機能がそろそろ使えないものが出てきたためです。


スポンサーリンク

更新手順

今回は更新作業ということで、同じサーバー内でテスト環境を作り、問題なければmvして本番環境とそっくり変える方法を取りました。

DNSの向き先を変更して移行するのがふつうなのかなって思ったのですが、今回の方法は浸透するまで待たなくていいし、何かあればすぐに切り替えができる。

ただし、SSHしてコマンドを打つので、しくじると終わります。rmは使わないけどmvとか、強力なコマンドだからね。

それではザックリ説明していきます。

・mysql5.0のデータをエクスポート、mysql5.5にインポート。元のDBの接頭値が「wp1_」とする。

・サーバー内で新しいwordpress4.7.3をダウンロードして展開。DBの接頭値は「wp2_」としてmysql5.5にデータを作成。wp2_options以外のデータはwp1のそのまま利用できたのでwp1_→wp2_にリネームする。

どうやってリネームするのかはphpmyadminから出来ます。テーブル選んで操作。ロリポやxserverなど有名ドコのサーバーならどこでもあるはず。

usermetaテーブルなどにはDB名が入っているのでカラムの値 wp1をwp2とかに変更しないとユーザーの権限などが紐づかない。ログインできないなどの問題もでる。

ここで写真などは写らなくても記事などが移行できているか確認をする。

・新しいほうのPHPは既に7にしておくとよい。利用できないプラグインなどのチェックを先に行うため。

・元のwordpressと新しいwordpressのテーマ名は揃えたほうがいい。揃っていなければ、FTPで新しいwordpressのwp-content/theme/以下のテーマ名を直接変更で揃う。

・テラタームを使ってSSHして古いほうからpublic_html以下の画像フォルダなどをcp -r 元のパス コピー先パス で移行する。

・同様にプラグインをcp -r でコピーする。 wp-content/theme/twelevetwenty/plugins  注意することは管理画面でプラグインを見ると更新できるものがあるが、不用意に更新はオススメしない。不具合がでる可能性がある。また、30個以上プラグインを入れていたが、現役で使っているプラグインは5年たっても使えるものがほとんどだった。

エラーが発生したら、同様のプラグインを入れ直そう。exec-phpなどが使えなかったので「PHP Code For Posts」を入れた。

・ウィジェット、ダイナミックウィジェットの移行方法がどうしても分からなかった。いろいろ試してみたがうまく出来るものがなかった。具体的には wedget import&exportのプラグインや、ウィジェット情報がURLに情報に紐づくからシリアライズ、デシリアライズうんぬんでphpをつかってDB書き換えなど・・・

今まだ動いている元の管理画面を開いて手動でコピーしたほうが早い。

・元のwordpressで個別カスタマイズしているソースコードをコピーしていく。

主にテーマフォルダ直下のindex.phpやsingle.php style.cssなど。function.php以外はそのまま上書き保存した。function.phpは追記している部分だけを切り抜いて新しいfunction.phpに書き足した。

・最後は新しいwordpressのフォルダごと、mvしてpublic_htmlごと変える。もちろん元のフォルダはリネームしてバックアップしておく。

・自動更新されてHPが表示されないと困るので、wp-config.php に「
define( 'AUTOMATIC_UPDATER_DISABLED', true );」を足した。

これを更新作業ごとに毎回やれと言われると無理だが、5年や10年単位の見直しぐらいならちょうどいいのではないかと思う。

ハマったところ

5年ぶりの変更ということで結構ハマるポイントがありました。

・the_post_thumbnail() を使っていたところは、前の3.5.x系では小さいサイズのサムネイルを持ってきていましたが、4.7.3ではfullサイズをもってくるようで、見た目は変わらないのですが、ページサイズがかなり大きいものになっていました。the_post_thumbnail('thumnail')に変更しました。

・jQueryで「$」をつかったコードが、「Uncaught ReferenceError: $ is not defined.」というエラーになって動かない。prottype.jsなど同じく$を使うものがあるらしく、競合しないようにwordpressでは「jQuery("html,body").animate({scrollTop:0},"fast");」のように$をjQueryに置き換える必要があった。

・wp-dtreeというプラグインをいれているんだけども。それが生成するリンクが変で、「www.403.co.jp/shop/area/ootsuki」のように店のエリアの大月のようなパーマリンクを設定するんだけども、生成されるのが「www.403.co.jp/topics/shop/area/ootsuki」と余計なものがはいってくる。カスタムパーマリンクで設定しているからそれが生きちゃうんだろうけど、もちろんnot found でページが見つからないので、 foreach ($taxonomyresults as $term){
$nodelist[$idcount] = array(
'id' => -$term->term_id,
'pid' => -$term->parent,
'url' => str_replace('/topics/', '/', get_term_link($term, $taxonomy)),
'name' => ($showcount) ? strip_tags($term->name ." ({$term->count})") : strip_tags($term->name),
'title' => strip_tags($term->description)

とプラグインの「wp-dtree-tax.php」を変更していた。なんてこと絶対忘れているから、ハマッテさがしたらそうしていた件。

・「Uncaught ReferenceError: jQuery is not defined.」が出てハマった。キャッシュ系プラグインを入れ直した際、wp-dtree というツリー形式でアーカイブなどを表示するプラグインが起動しなかった。その際に「Uncaught ReferenceError: jQuery is not defined.」が出てた。原因は「WP Fastest Cache」「Autoptimize」と「script to footer」だった。WP Fastest Cache と Autoptimizeのjavascriptを結合するというのがNG。結合するとjqueryとその他プラグインのjsの読み込み順序が崩れて後にjqueryが読み込まれるから最初にプラグインのjsが読み込まれたらjquery知らんよって言われる。Autoptimizeの設定にjqueryを弾く設定があったがうまく動かなかったので今回はパスした。「script to footer」はそのままでフッターで読み込むってのはさっきと同じ理由でNG.

「WP Fastest Cache」などのキャッシュ系が移行時には有効にしないほうがいい。タイムラグが発生して修正箇所の特定に時間がかかった。最低移行1か月はノーマル状態で運用して問題がなければキャッシュ系を有効にしていくことが得策。そこまで体感速度も変わらなかったのでこの際、キャッシュ系プラグインを削除した。

・パーマネントリンクのカスタム構造で、「%post_id%」を設定していたため、404エラーページが見つからないエラーが多発。「%postname%」に戻した。Movable Typeから移行したときのポストIDがあったため。

・そして、その状態で新規投稿すると 日本語URLになるので、

wp-admin/includes/meta-boxes.php の post_slug_meta_box関数を編集し忘れ。

function post_slug_meta_box($post) { ?> <label class="screen-reader-text" for="post_name"><?php _e('Slug') ?></label><input name="post_name" type="text" size="13" id="post_name" value="<?php echo esc_attr( $post->post_name ); ?>" /> <?php }

function post_slug_meta_box($post) { ?> <label class="screen-reader-text" for="post_name"><?php _e('Slug') ?></label><input name="post_name" type="text" size="13" id="post_name" value="<?php if(get_post_status() == 'publish' || get_post_status() == 'future' || get_post_status() == 'draft' ){ echo esc_attr( $post->post_name ); } else { echo $post->ID;} ?>" /> <?php }

・custom field template の設定が移行できなかった。wp_option の option_nameがcustom_field_template_dataの値をそのまま引っ越してもうまく移行できず。移行前に管理画面からカスタムフィールドテンプレートのエキスポートを使えばうまくいくかもしれません。移行後に私は気づいたので、しかたなく。直接データをいじったりしましたがうまく動かず。一度カスタムフィールドテンプレートの設定のオプション削除でデータを初期化した後、移行前のDBのcustom_field_template_dataの値をテキストエディタにコピーして

[Tel]
type = text
size = 35
label = 電話番号

[Time]
type = text
size = 35
label = 営業時間

[Holiday]
type = text
size = 35
label = 定休日

[Service]
type = text
size = 35
label = サービス

のところを探して、地道に設定し直しました。

・画像のexif情報(画像が縦横なのか)がアップロードすると抜けてしまって、画像が縦横逆さまになる。Image Rotation Repairというプラグインをいれてexif情報を保持するようにした。なぜ削れたのかは不明。

・include/function.php も移行する。というのもそこのソースも追記していて、

タグとか、phpとか記事内にあるものを変換しないようにする処理が書かれている。add_filter( 'run_wptexturize', '__return_false' );

パフォーマンスはどうなったのか?

pingdom website speed testを使って計測。

WS000000

まずは更新前。

5.49秒

WS000001

 

更新後、3.86sと144%パフォーマンスが上がりました。

WS000000

今後の高速化機能や使いたいプラグインはこれで当面は使えるだろうという安心感は大きいです。

No. 2214

スポンサーリンク



最高級 宅配クリーニングのネットで洗濯.com
クリーニング403が安心・高品質な本物のクリーニングをお届けします。

キャンプ場からそのまま送れるテントクリーニング.com
テント・タープなどのクリーニングと合わせて撥水加工、UV加工がオススメ!