前提

hogehoge.comのサイト移管
- 旧サイトはA社のホスティング
- 新サイトはB社のホスティングサービスを使う(IPアドレスが変わる）
dnsは切り替え前で旧サイト側を指してる
開発者はhostsを使用して新サイト側を見てる

scrapeチェックってなんぞや。

wp-admin/includes/file.php

/**
 * Attempts to edit a file for a theme or plugin.
 *
 * When editing a PHP file, loopback requests will be made to the admin and the homepage
 * to attempt to see if there is a fatal error introduced. If so, the PHP change will be
 * reverted.
 *
 * @since 4.9.0
 */
function wp_edit_theme_plugin_file( $args ) {

要約:phpはエラーがあるとwordpress全体が死ぬから自身にループバックして死なないかチェックするぜ。エラーになったらやべーから更新はロールバックするぜ。

どういうこと

ざっくりこんなかんじ。

とりあえず実ファイルを更新
チェック用の一時キーとしてscrape_keyとscrape_nonceを作る
DB一時保存用領域(transient)にscrape_keyとscrape_nonceのペアを更新する
wordpressのadmin_url()なりにscrape_keyとscrape_nonceのペアのパラメータ付きでwp_remote_get()
- ここでやべーphpだとエラーで死ぬので望んだ答えが帰ってこないので失敗と判断する
1. ここから遷移先
2. 受け取ったadmin_url()のwordpressはscrape_keyからtransientを検索してnonceを取得する
3. パラメータのscrape_nonceとtransientから取得したnonceが一致したら正しく動作したと返答する
4. ここまで遷移先
返答にscrape_nonceが含まれていたらOK、そうでなければ一律NG
NGなら実ファイルをロールバックする
(transientを削除もしとく)

なにがおきてる

新サーバー内からadmin_url()にwp_remote_get()すると旧サイト側のwordpressが呼び出され、transientに当然scrape_keyは無いので死ぬ。必ず死ぬ。

じゃどうする。

新サーバーがvpsなんかで管理者権限があるなら/etc/hostsを設定するなりして、新サーバーでhogehoge.comが自身を指すように設定する
管理者権限が無いなら ftpなりで直接ファイルを更新する。
(非推奨) file.phpのチェックを迂回させちゃう(*1)

このケースってDNSが切り替わる前特有の問題とも言えるので、開き直って直接phpファイルを修正しちゃうのが正しい気がする。

*1 非推奨:file.phpを書き換える方法

wp-admin/includes/file.php

	if ( $is_active && 'php' === $extension ) {
    // ↓ 「false &&」を入れて強制迂回
	if ( false && $is_active && 'php' === $extension ) {

これやるとアップデートが失敗するかもしれんので、忘れずに戻しておかないと後々やべーことになるかも

ちなみに

エラーメッセージで Scrape nonce check failed.と返ってくるのはドチャクソ古いwordpress。
今は「Scrape key check failed.」と返ってくる。

旧サイト。どんだけアップデートさぼってんねん。