こんにちは
テーマを改変していて動かなくなったのなら、別のテーマにしたらうごくのではないでしょうか?
もしそうなら、改変した部分がもんだいだと思いますので、もとに戻されてはどうでしょうか。
@munyagu
ありがとうございます。
テンプレートを変えてみたのですが、相変わらずエラーになるようです・・・
サーバーのエラーログを確認するか、デバッグモードにしてエラーが出ていないか確認してください。
@munyagu
デバッグモードにしてみたのですが、メール送信に関するエラーは出ておらず、debug.logにもメール送信に関する文字列も確認できませんでした。
サーバーのエラーログも同様にメール送信にかかわるものは確認できていません。
wpxサーバーのサポートにも問い合わせをしているんですが、なかなか話が進まない状況です。
状況を改めて書きます。
・現状サイトが2つあり、
Aという非公開テストサイトとBという本番環境は両方ともwpxサーバー上にあり、両サイトで使用しているphpファイルなどは同じ。
・Aテストサイトでテンプレートの大幅改造をし、B本番サイトのバックアップzipを作成したうえで上書き。
この時点では両方とも正常に動いている。
・B本番環境側でfunctions.phpとpage.phpなどにいくつか変更箇所を追加。サーバーキャッシュONへの設定変更。
この後気づいたらメール機能が使えなくなる。
サーバーキャッシュをOFFに戻しても状況改善せず。
・メールが使えるAテストサイトにB本番サイトのfunctions.phpを上書き(この時点のBのバックアップば取り忘れました)
Aテストサイトもメール機能が使えなくなる。Aサイトはブラウザを開いたまましばらく更新をしていなく、そのままテンプレートの更新をしたので本当にその時点でメールが使用できていたのかの確認はしていません。
Aテストサイト側ではサーバーキャッシュは最初からOFFのままです。
・大規模変更をかける前のBのバックアップからfunctions.phpを持ってきてBテストサイトに上書きするも、Bサイトのメール機能は復活せず。
Aサイトは実験的に動かして壊すわけにはいかないので、メール送信できなくなった時点で操作をやめています。
という流れです。
functions.phpの記述ミスかと思ったのですが、昔のファイルを上書きしても直らないので全く問題個所が理解できていないです。
一応念のためなのですが、$aaa
を初期化してtrueであるか否かでお試しいただけませんでしょうか。
記述的には問題ないかと思うのですが、理論的には初期値のないものをフラグとして取得して、判断する間に実数値を対象にする echo
があることは実意的でないかなと思いますので。
<?php
$aaa = false;
$aaa = wp_mail(...);
if($aaa){
echo "成功";
}else{
echo "失敗";
}
?>
のような形や
<?php
if(wp_mail(...)){
echo "成功";
}else{
echo "失敗";
}
?>
のような形で。あと動作結果の受領動作にかかわらず、実際に送信はなされていないのでしょうか。
@msio
<?php
$aaa = false;
$aaa = wp_mail(...);
if($aaa){
echo "成功";
}else{
echo "失敗";
}
?>
の記述にしてみました。
表示は「失敗」で、実際にメールも受信できていません。
送信先はgmailに設定しています。
@munyagu さんへの返信は審査待ちになってしまったので表示までもう少しかかりそうです・・・
デバッグモードにしてみたのですが、メール送信に関するエラーは出ておらず、debug.logにもメール送信に関する文字列も確認できませんでした。
という内容のものですよね?
承認依頼していますので、間もなく承認されるものと思います。
このdebug.logですが、WordPressの設定によって出力されるものですよね?
それではなく、wpxのコントロールパネルからダウンロードできる(多分)ものです。
なるほどです。それでは実際に動いていないようですね。
準備関数の一部が機能しなくなることについて調査をしていくととても手間がかかると思うのですが、サーバーキャッシュONをOFFにしてみてはいかがでしょうか。
高速化の種類によっては呼び出しページアドレスを直接キャッシュで読み込むことで基幹プロセスが無視されていることはないでしょうか。
@munyagu
サーバー側のエラーログは毎日深夜に削除されるらしいのですが、状況発覚直後に見たログにはメールに関するものはなかったかと思います。
本日もサーバーのサポートに言われて確認しましたが、出ているエラーはこれだけです。
[Wed Oct 11 10:32:27.352231 2017] [fcgid:warn] [pid 29076] [client 157.112.145.2:46682] mod_fcgid: stderr: PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0, referer: https://サイトURL/wp-admin/admin-ajax.php?action=wp_ewwwio_media_optimize&nonce=6e24fd67bd
@msio
サーバーキャッシュはその後すぐにOFFに戻し、ブラウザのキャッシュクリアなどもしましたが、改善は見られませんでした。
関数の一部が機能しない原因を調べる方法というのは、どこかにやり方を書いたサイトなどはありますでしょうか?
wp_mailがエラーを起こすことについて書いているものを調べているとエラー部分の詳細を調べているようなのですが、どのようにすればそこまでたどり着けるのかがわからないもので・・・
このワーニングが原因なのかはちょっと分かりませんが・・・phpのバージョンを5.6に変更しませんでしたか?
私はこHTTP_RAW_POST_DATAについてあまり詳しくないので説明しかねますが、phpを5.4に変更するか、php.iniでalways_populate_raw_post_dataを-1に設定してください。
参考:https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11139510356
原因がはっきり分からないので、他のプラグインを停止したり、デフォルトテーマで該当の記述を試してみるなどで原因を特定してみてください。
以下も参考にしてみてください。
問題解決のためのチェックリスト
wp_mailのエラーの詳細の調べ方については知らないです。
すいません。
ワードプレスの準備関数自体となると、ワードプレスの内部設定によるものなのでおおよそ外堀を埋めていくデバッグ作業くらいになると思います。
ページが表示されているということは他のワードプレス準備関数のモジュールは機能しているので、主にサーバー側のメール送信まわりだけ確認できればと思いますが、サーバー調整以外での異常となると細かい設定の釣り合いを確認していく作業になるのではと思います。
メールまわりで思いつく問題を列挙いたします。
・メールサービスが死んでる
何等かの送信エラーなどがたまって死んでる。プロセスを再起動でなおります。当該ドメインのメール動作がないので発見は早いと思います。
・へんなキューがたまってる
同じく異常なメールが滞留していて当該ドメインメール受信を阻害している。送信はできる場合があるので発見が遅くなる時があります。
今回おためしのメールアドレスが当該サーバー管轄下のドメインでなければ送達はされている可能性があり着信も確認できる可能性があります。
・リバースプロキシ型キャッシュ動作時に自己更新動作型ページのモジュールが機能していない・動作条件がメール―サーバーに違反する
これはOFFでキャッシュクリアすれば解決するので、今回は違うかもです。
新しいバージョンのワードプレスを使っていればサーバーのメール発送・転送問題について調査調整で片が付くことがとても望ましいのですがメール関連の問題解決についてとっさに思いつくことが他にございませんでした。
せめてなにかの参考になりましたら幸いです。
こんにちは、
実際にトラブルシューティングをしたことはないのですが、
wp_mail('xxxxx@gmail.com','hello nibita','mail test');
//https://developer.wordpress.org/reference/hooks/wp_mail_failed/
add_action( 'wp_mail_failed', 'onMailError', 10, 1 );
function onMailError( $wp_error ) {
echo "<pre>";
print_r($wp_error);
echo "</pre>";
}
のようにフィルターを使う方法があるみたいなので、試してみてはいかがでしょうか
@munyagu
@msio
@nobita
お恥ずかしい限りなのですが、超初歩的なケアレスミスが発覚し、解決しました。
wp_mailで送信されるメールの経由情報を受信先に出さないようにWP-Mail-SMTP
プラグインを入れていたことを忘れており、
なおかつそこで設定していたSMTP設定のパスワードがサーバー側だけで書き換え、こちらのほうに変更をかけていなかったために不具合が発生していたようでした。
メールパスワードの変更がfunctions.phpの変更やサーバーキャッシュ周りをいじったのと同じタイミングだったため、そちらのほうに意識が向かっていて完全に失念していました。
いろいろと考えていただき、アドバイスもありがとうございました。
メールの動作設定をプラグインで形成することがない当方によい事例がいただけました。
可能性を完全無視していた「メールの宛先などは正しいですよね?」の質問があればもっと早かったかもしれないですよね。基本を無視していた私にも落ち度がありました。
送信状況をコントロールしたい設定事案との競合でトラブルが発生する可能性と注意点が学びになりました。
なにより設定変更だけで回復することはよかったと思います。
ありがとうございます。