All in One Migration後にMW WP Formが停止→デバッグ追加で復活

🚨 問題の概要

環境:

• WordPress移行: All in One Migration使用
• PHP環境変更: 8.1.29 → 7.4.33
• プラグイン: MW WP Form (フォームID: 123)
• 症状: フォーム送信後にメールが届かない

🔍 診断過程

1. 基本的なメール機能テスト

// PHPのmail()関数テスト
$result = mail('test@example.com', 'PHP Mail Test', 'Test');
// → SUCCESS ✅

// WordPressのwp_mail()テスト  
$result = wp_mail('test@example.com', 'WP Mail Test', 'Test');
// → SUCCESS ✅

2. MW WP Form専用デバッグ

// MW WP Formのフック監視
add_action('mwform_before_send_admin_mail_mw-wp-form-123', function($Mail_admin, $Data) {
    error_log('Form 123: Before send admin mail triggered');
}, 10, 2);

結果: フォーム送信時に一切ログが出力されない = MW WP Formが動作していない

🎯 謎の解決

デバッグコードを追加した直後、突然メールが正常に送信されるようになりました。 解決後のログ（完璧な動作）:

=== MW WP FORM DEBUG START ===
Form 123: Before send admin mail triggered
File attached to admin mail: .../dummy.pdf.zip
wp_mail called with subject: 管理者宛メール件名
Auto reply mail object type: object
Adding filename to auto reply: dummy.pdf.zip
Form 123: Before send reply mail triggered
wp_mail called with subject: 自動返信メール件名
Temporary file deleted: .../dummy.pdf.zip
Form 123: After send triggered
=== MW WP FORM DEBUG END ===

💡 原因の推測

All in One Migration後の内部状態不安定

1. フック登録の不完全な初期化
2. WordPressキャッシュの問題
3. プラグイン読み込み順序の問題

デバッグコードが「治療薬」の役割

• functions.phpの再読み込み
• フック登録の再実行
• WordPress内部状態のリセット効果

🛡️ 予防策と対処法

1. All in One Migration後の必須対応

// プラグイン依存のフック登録を安全化
add_action('plugins_loaded', function() {
    if (class_exists('MW_WP_Form')) {
        // フック登録処理
    }
});

2. フック登録の優先度調整

add_action('mwform_before_send_admin_mail_mw-wp-form-123', $callback, 5, 2);
// 優先度を下げて早めに実行

3. 緊急時の診断コード

// MW WP Form状態確認
add_action('init', function() {
    if (isset($_GET['debug_mwform'])) {
        echo class_exists('MW_WP_Form') ? "ACTIVE" : "INACTIVE";
        exit;
    }
});

📋 学んだこと

1. All in One Migration後は必ずWordPressの内部状態を疑う
2. 診断目的のコードが意図せず問題を解決することがある
3. PHP版数の逆転（新→旧）でも問題が発生する
4. フック登録のタイミングが重要

🙋‍♀️ 質問

同様の問題を経験された方はいらっしゃいますか？
また、All in One Migration後の安定化についてベストプラクティスがあれば教えてください。