フォーラムへの返信
-
もし、XO Securityを使用せず、さきほど示した独自の方法の場合だと（コア側の変更は別として）、「変更があった場合の正しい動作不安」もなく使い続けられる可能性が高まる、ということでしょうか。
あるいは、XO Securityの設定値を読み込み、URL書き換えの処理を行う方法が現時点では最適解、といった背景があってのことでしょうか。
うーんそうですね、人によって考えは違うかもしれませんが、「XO Securityの設定値を読み込み、URL書き換えの処理を行う方法」は（XO Security のアップデートで互換性が崩れることがある可能性を除けば）利用者側は難しいことを特に考えなくて良いというのがメリットです。
独自の方法だと好きに書き換えができるわけですが、XO Security や Login rebuilder が同じような条件下でのみ書き換えを許可していることを考えると、なんでもかんでもフックで書き換えるのが良くない、という可能性もあるのかなと（ちょっとこの辺は僕は詳しくないです）。もし本当にそうだったとしたら、フックでかきかえるのはあまり良くない方法なのかもしれません。
今↓のように
site_url( 'wp-login.php', 'login_post' )と URL を書いているところを、$action = site_url( 'wp-login.php', 'login_post' ); if ( class_exists( '\XO Security' ) ) { // XO Security で URL 書き換え設定が有効化されている場合は $action を書き換え $action = str_replace( ... ); } ?> <form action="<?php echo esc_url( $action ); ?>" ...>のようにすれば、フックで書き換えているわけではないので、影響が及ぶ範囲を Member Post のフォームだけに限定でき、大問題には発展しないのかなという感じです。
Who liked:すみません、ちょっと無理そうな気がしてきました…。コードを追っていくと下記の部分があるのですが、
/** * Get the login URL. * * @param string $url URL. * @param string $loginfile Login filename. */ private function get_login_url( $url, $loginfile ) { if ( is_user_logged_in() ) { return str_replace( 'wp-login.php', $loginfile, $url ); } if ( empty( $_SERVER['REQUEST_URI'] ) ) { return $url; } if ( false !== strpos( $_SERVER['REQUEST_URI'], $loginfile ) ) { // phpcs:ignore WordPress.Security.ValidatedSanitizedInput $url = str_replace( 'wp-login.php', $loginfile, $url );既にログイン済みの場合か、変更後のログインページを開いているときにログイン URL の書き換えがおこなわれるようです。つまり、ログイン済みか今からログインしようとログイン画面を開いているときのみ書き換えが行われるということで、Member Post のフォームは非ログイン時しか表示されないので書き換えがおこなわれないということになります…。なぜこの条件指定になっているのかがよくわからなかったのですが、何か理由があるのかもしれませんね…。
Who liked:コードありがとうございます！ XO Security のものとほぼ同じ実装のようでした。
ちょっと試してみたいたのですが、どうも WordPress コアのログイン・ログアウトブロックの場合でも送信先の URL が
wp-login.phpのままになってしまうようでした。
なのでこのログイン URL を変更するコード自体に何らかの問題があるのでは？という気がしました。Member Post のほうを、このコードに合わせる形で何らかの変更を入れることができないか、もう少し調査してみます。
Who liked:
