早速ありがとうございます。
カスタマイズは何もしていません。
Ver118ではこの画像が左右いっぱいになっていました。
下記、「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
}
);
}
);
キタジマさん！ありがとうございます！
サブディレクトリの際と、加えてXO SecurityでログインURL変更した際に、問題なくログインと登録ができるようになっていることを確認しました。
早々のご対応、本当にありがとうございます！非常に助かりました。
Login rebuilderは2つめのログインURLを設置したい場合に限っていて、基本的にはXO Securityで変更することが多いので運用面でもメリットが大きいと感じています。
それでは本トピックは閉じておきます。ありがとうございました！
お手間おかけして申し訳ないです…。さらに変えてみました！
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 );
}
解決できたようで何よりです。
この方法ですとメニューテキストにも反映されるため、念のため不要な部分に反映させないようにクエリで指定いただくとよりよいと思います。
@media not all and (min-width:1024px) {
.l-container>.l-header {
mix-blend-mode: difference;
}
}
効かせるのには詳細度が関係していると思います。私もまだまだ勉強中でございます。^^
うがーまじですか…。
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 末尾のスラッシュはありなしどちらでしょうか？
es：エス様
有難うございます！
できました！！
後学のため、一番上のヘッダーに書かないとmix-blend-modeが効かない理由が分かれば教えて頂けないでしょうか？
hoshiimo.runさん
おそらくこれでいけると思います。お試しくださいませ。
.l-container>.l-header {
mix-blend-mode: difference;
}
キタジマ様
ご回答有難うございます。
すみません、コードは打ち間違いです…。
以下のように|を除いても色が変化しません。
.c-hamburger-btn__bar, .c-hamburger-btn__label {
mix-blend-mode: difference
; }
サブディレクトリの対応、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 );
}
に書き換えてみるとどうでしょうか！？
なるほど、そういうことですね。お考えのベースがよくわかりました。
たしかに多くの利用者さんのことを考えると、XO Securityなどのプラグインの使用を想定した方が汎用性は高そうですし、そもそも大きく仕様変更されそうな部分でもないでしょうから、安全面でもよさそうですね。
ご教示いただき、ありがとうございました。
それでは引き続きまして、よろしくお願いいたします。
もし、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 のフォームだけに限定でき、大問題には発展しないのかなという感じです。
キタジマさん
早々に調査やご対応検討などいただき、ありがとうございます。
XO Securityを使用した際の対策について、承知しました。
ひとつ教えてください。
もし、XO Securityを使用せず、さきほど示した独自の方法の場合だと（コア側の変更は別として）、「変更があった場合の正しい動作不安」もなく使い続けられる可能性が高まる、ということでしょうか。
あるいは、XO Securityの設定値を読み込み、URL書き換えの処理を行う方法が現時点では最適解、といった背景があってのことでしょうか。
そのあたり理解が追いついておらず申し訳ないのですが、ご教示いただけますと幸いです。
サブディレクトリ対応につきましても、承知しました。
お手数ですが、よろしくお願いいたします！
書き換え側で対処してもらわないと完全な対応は難しいので、とりあえず XO Security が有効化されている場合は Member Post 側で XO Security の設定値を読み込み、フォームのログイン URL を書き換えるようにします（XO Security の変更を追っているわけではないので、XO Security 側で変更があった場合は正しく動作しなくなる可能性はあります）。
サブディレクトリの対応についてはもうしばしお待ちを…。
