Scribble at 2022-04-16 01:13:43 Last modified: unmodified

さきほどクライアントの公開サーバにて WordPress の実装を終えた。既存の静的なコンテンツを置き換えるため、一時的に表示に問題が起きる可能性もある。なので、あまりアクセスがない時間帯に実施した方がいいだろうから23時から作業を始めた。WordPress をアップロードすると共に、ステージングのサーバにあるテスト・サイトからデータをインポートしたり、一致したパスにメディア・ファイルをアップロードしたりで、なんやかんやとして2時間ほどかかってしまった。

いつも思うのだが、WordPress のエクスポートやインポートは、はっきり言って使わない方がいい。たいてい移設先の既に動き始めている WordPress のデータに影響を受けてしまうからだ。特に Advanced Custom Fields はサブのフィールドが消失して一部のフィールドしかインポートできなかったり、酷い結果になることが多い。したがって、最も手堅い手順は、移設先のコンテンツにかかわるテーブル、つまり PRE_postmeta, PRE_posts, PRE_terms, PRE_term_relationships, PRE_term_taxonomy の五つのテーブルを truncate してから移設元にて SQL ファイルとしてエクスポートしたテーブルを入れなおすことである。ただし、WordPress 管理画面上で登録したメディア・ファイルのパスは絶対 URL となってしまうので、異なる FQDN のサーバへ移設するときは FQDN を置換しなくてはならない。

それでも、設定項目の確認をしていないと、静的なコンテンツ(index.html)から WordPress(index.php)へと置き換えた際に、例の真っ白なページとなってしまうことがある。しかも、レンタル・サーバなんかだと .htaccess にエラー出力の php_values が書けなかったり、あるいは wp-config.php でデバッグ・モードを有効にしても何も表示されなかったりする場合があるので、色々な可能性を調べておくのが望ましい。たとえば、すぐに気が付いて修正したが、表示設定で front.php というテンプレートをトップ・ページとして固定していたのだが、「ホームページ」も「投稿ページ」も同じテンプレートの WordPress ページ(固定ページ)を指定してしまい、これが真っ白なページになるエラーの原因だった。というか、なんでそんな設定になってしまい、しかも同じテンプレートを指定してもエラーが出ないのかという問題もあるが。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook