とあるサイトの公開にともなって、テスト環境から本番環境にWordPressを引越しすることがあったのですが、いつも使っている「Search replace DB」でDBのパスを書き換えたのです。
すると!なぜか、あちこちに文字化けの嵐。「?」マークがそこらじゅうに発生。もともと、かなり古いWordPressで書かれていたブログを2サイト分、統合してインポートしていたのですが、その中の投稿がおかしくなっていました。今回新しく作った固定ページは大丈夫。
Search replace DBはここ2年ぐらいよく使っているんですが、実行したら文字化け発生というのは初めてのことだったので驚きました。
「?」マークを一括置換するわけにもいかないので、地道に手作業で直すことに。
とはいえ、また同じことが起こっても困ってしまうので、このトラブルを回避する方法をFacebookでつながっているみなさんに聞いてみました。
WordPressの引越しにおいてDBを直接操作してURLの置換をするのは非推奨だとCodexにかいてある
コアコントリビューターの宮内さんに教えていただいたのですが
それほど記事が多くないのであれば、wp-config.phpに
define(‘WP_HOME’,’http://example.com’);
define(‘WP_SITEURL’,’http://example.com’);
と書いて、記事内の画像等へのリンクを手作業で直すとかの方が安全かもですね。
ちなみにGUIDっていうところに含まれているシリアライズかされたドメイン名は変わらなかったからと言って特に実害はなくて、ケースによってはむしろ変えることで不具合があるので、WordPressとしてはGUIDを変えないことを推奨しています。たとえば http から https に変えちゃう時とかはメディア系のサイトでは悪影響が考えられるんですよね。既読のはずの記事が一斉に復活するとか。それを識別するために GUID は変えちゃダメなんです。
開発環境から本番に移行するときは変えた方がいいと言う考え方もあって、それは確かにそうなんですが、一律で変えてしまうと言うノウハウが広まると不具合があるので、変えない方がぶなんという趣旨で変えないことを推奨しているんじゃないかと。
とのことでした。
この方法は初耳だったのですが、Codexにも確かにこのように書いてあるのです。
When doing the above and changing the URLs directly in the database, you will come across instances of the URL being located in the “guid” column in the wp_posts tables.
It is critical that you do NOT change the contents of this field.
The term “GUID” stands for “Globally Unique Identifier”. It is a field that is intended to hold an identifier for the post which a) is unique across the whole of space and time and b) never, ever changes. The GUID field is primarily used to create the WordPress feeds.
訳)
データベースを直接さわって操作することでURLを変更してしまうと、wp_postsテーブルの「GUID」カラムにあるURLに影響があります。
このフィールドを変更しないことが重要です。
「GUID」という用語は「グローバル(Globally)に独自の(Unique)識別子(Identifier)」の意味です。これは、投稿の識別子を保持することを目的としたフィールドであり、a)スペースと時間の全体にわたって独自なものであり、b)決して変化することはありません。 GUIDフィールドは主にWordPressフィードの作成に使用されます。
とはいえ、置換作業はやっぱり必要な場合も。そんなときは「search replace」を使おう
とはいえ、今回のように何年も運用されている古いWordPressサイトの引越しだと、記事が何百件と存在することも多いので、その時にどうするかは悩ましいところです。
同じくコアコントリビューターの占部さんにコメントもらったのですが
wp cli serch-replace が一番安定なきがします
とのこと。
先述の「Search replace DB」と同様の技術で、これをWordPressをコマンドラインから操作するためのツールである「WP-CLI」を使ってやる方法とのことです。
WP-CLIって何度か耳にしたことがあるのですが、何なのかよくわかっていませんでした。なんだか便利そう・・・!「wp cli serch-replace」で検索したら、方法がたくさん出てきました。
こういったコマンドを使えたら早いのでしょうけど、どうしても敷居が高くて手が出せず、GUIツールに頼ってしまいます。。「WP-CLI」のデザイナー向けハンズオンをどなたかやっていただけないでしょうか(他力本願)
コマンドラインが使えないデザイナーならGUIで操作できる「Search replace DB」を使えば大丈夫。ただし「GUID」を除外しよう
こんどはコアコントリビューターのkiteさんがコメントをくれたのですが
これ使って大丈夫ですよ。Ver 2 までは自動削除機能がなかったので、このツールをサーバ上に残してるととても危険でしたが、今は置換完了後に自分自身を削除する機能がついてます。GUID カラムの除外もできますし、`wp search-replace` も元々このツールからできてます。WP-CLI 使えるならそれに越したことはないんですが。
シリアライズはこのツールもしくは WP-CLI を使っていれば気にする必要はないです。GUID は除外する場合はどちらも指定すれば可能です。
なんと!WP-CLIもSearch replace DBも同じものだったのですね。コマンドラインで実行するか、GUIでやるかの違いだけだったようです。
きになるGUIDに影響させないという点でも、除外項目に指定してあげたら大丈夫なんですね。
ためしにインストールしてみたら、たしかにその項目ありました。次回から必ずチェックしてやろうと思います。
エディタの一括置換はダメ、ぜったい
ちなみに、エディタでURLの一括置換をしてはダメなのですが、その理由は、シリアライズ化されたデータを変えてしまうからなのです。
シリアライズ化が何なのかよくわかっていない私ですが、たとえば、エディタを使ってURLを置換してしまうと、ウィジェットに入力していたデータがなくなってしまいます。
これは、シリアライズによって紐づいていた情報がなくなってしまうからですね。
どうしても置換が必要な場合は、上記の「Search replace DB」や「wp cli serch-replace」を使って、シリアライズ化されたデータに影響を及ぼさないような方法でやる必要があります。
わたしがいつもやり方を参考にさせていただいているブログはこちらです
WordPressでサーバ移行時にデータベース上のドメインを書き換える方法
この方法を参考に作ったわたしのスライドがこちら。かなり前のWordBenchで話をしたときの資料です。
WordPressの引越し作業はよくやっていることなので、事故らないベストな方法を今後も追求していきたいと思います。
今回はたくさんの方に具体的なアドバイスをいただいて助かりました、ありがとうございます!