フォーラムへの返信
-
投稿者投稿
-
メッセージ、「更新に失敗しました。 返答が正しい JSON レスポンスではありません。」と出ます。
このメッセージがでるときは、なんらかのプラグインが裏でエラーを出力していることが多いです。下記確認してみてください!
– 最近インストールしたりアップデートしたプラグインがああれば停止してみる
– ブラウザのデベロッパーツールのコンソールになにかエラーがでていないか確認してみる
– Snow Monkey Editor の段落のブロックスタイル「アラート」を適用していると思いますが、他のページでも使っているところがあればそこでもエラーがでるかどうか確認してみる♥ 0Who liked: No user.p-breadcrumbs-wrapper, .l-contents__inner { margin: 0 auto; max-width: 999px; }↑これめちゃめちゃ怪しいのですが、消したらどうなりますか?
♥ 0Who liked: No userSnow Monkey v19 でレイアウト周りに大きな変更があったのでその影響かもしれません(v18 以下からのアップデートでしょうか?)。
なにもカスタマイズしていなければ、基本的には問題が起きてもそのページの編集画面を開けば自動で修正されますが(再保存は必要)、カスタマイズが影響している場合は何らかの修正が必要になる可能性があります。どのようなカスタマイズをしているかで対処内容が変わってくると思うので、じっさいの画面かスクショを見ない詳しくはわからないと思います…。
♥ 0Who liked: No user下記、「news」というカスタム投稿タイプの場合の例です。My Snow Monkey プラグインか子テーマの
functions.phpにコードを追加してみてください。// カスタム投稿タイプ用のウィジェットエリアを登録 add_action( 'widgets_init', function() { register_sidebar( array( 'id' => 'my-news-sidebar', 'name' => 'ニュース用', 'before_widget' => '<div id="%1$s" class="c-widget %2$s">', 'after_widget' => '</div>', 'before_title' => '<h2 class="c-widget__title">', 'after_title' => '</h2>', ) ); } ); add_action( 'wp_body_open', function() { // 「カスタム投稿タイプ詳細かつカスタム投稿アーカイブページではないとき」は何もしない if ( ! is_singular( 'news' ) && ! is_post_type_archive( 'news' ) ) { return; } // サイドバーからデフォルトのウィジェットエリアを外す remove_action( 'snow_monkey_sidebar', 'snow_monkey_sidebar_add_sidebar_widget_area', 20 ); // カスタム投稿タイプ用のウィジェットエリアをサイドバーに追加 add_action( 'snow_monkey_sidebar', function() { ?> <div class="l-sidebar-widget-area" data-is-slim-widget-area="true" data-is-content-widget-area="false" > <?php dynamic_sidebar( 'my-news-sidebar' ); ?> </div> <?php } ); } );お手間おかけして申し訳ないです…。さらに変えてみました!
protected function _get_current_url() { $site_url = site_url(); // WordPress Core URL. $home_url = home_url(); // Home page URL. $own_directory = untrailingslashit( str_replace( $home_url, '', $site_url ) ); preg_match( '|https?://[^/]+?(/.+?)$|', $home_url, $match ); $sub_directory = $match ? $match[1] : ''; $path = filter_input( INPUT_SERVER, 'REQUEST_URI' ); $path = preg_replace( '|^' . $sub_directory . $own_directory . '|', '', $path ); $path = remove_query_arg( 'login_error_codes', $path ); $path = remove_query_arg( 'register_error_codes', $path ); return home_url( $path ); }♥ 0Who liked: No userうがーまじですか…。
CASE-B 専用ディレクトリ→そのまま表示
専用ディレクトリ : https://example.com/wp
トップページ URL : https://example.com/wp■CASE-Bのみ不具合あり
・ログインフォーム:ログインはできているが、https://example.com/wp/wp/と、専用ディレクトリの部分がもう一度付与されるURLにリダイレクトされるため、404になる。
・登録フォーム:登録はできているが、https://example.com/wp/wp/?checkemail=registeredと、上記同様に付与されたURLにリダイレクトされるため、404になってしまう。ですよね?
一応今僕は、WordPress は https://inc2734.xxx.xxx/snow-monkey/ に設置、トップページの URL も https://inc2734.xxx.xxx/snow-monkey/ という状態のサイトに適当な投稿をつくり、そこにログインフォームを設置してログイン情報を送信したところ、正しくログインできました。
ダッシュボード → 設定 → 一般設定の「WordPress アドレス (URL)」「サイトアドレス (URL)」はどちらも同じでしょうか? また、それら URL 末尾のスラッシュはありなしどちらでしょうか?
♥ 0Who liked: No userbar|となっているからではないですかね?barだと思います。♥ 0Who liked: No userサブディレクトリの対応、
snow-monkey-member-post/App/Shortcode/LoginForm.phpとmember-post/App/Shortcode/RegisterForm.phpの中にあるprotected function _get_current_url() { ... }を
protected function _get_current_url() { $site_url = site_url(); // WordPress Core URL. $home_url = home_url(); // Home page URL. $own_directory = untrailingslashit( str_replace( $home_url, '', $site_url ) ); $path = filter_input( INPUT_SERVER, 'REQUEST_URI' ); $path = preg_replace( '|^' . $own_directory . '|ms', '', $path ); $path = remove_query_arg( 'login_error_codes', $path ); $path = remove_query_arg( 'register_error_codes', $path ); return home_url( $path ); }に書き換えてみるとどうでしょうか!?
♥ 0Who liked: No userもし、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 のフォームだけに限定でき、大問題には発展しないのかなという感じです。
-
投稿者投稿
