[Hatsuki]

スマホのドロワーメニューのことですよね

それです。
何故ならないのかは謎なんですが、アニメーションの前に要素の不透明化（display:noneとかopacityとか）が働いてしまってるのかもーと思ってます。アニメーションのキーが100%になる前にそう言う効果が発火するとアニメーションを実行する前に透明になるからパッと消えるんすかね？
ちょっとどうにか調整したい部分っすねー、これ

♥ 0

いいねをした人: 居ません

[Hatsuki]

確認できました。閉じますー

♥ 0

いいねをした人: 居ません

[Hatsuki]

確認後に閉じ忘れてましたのもありますが、検索条件系のクエリーをガリガリと調べてパターンで叩いてみました。（念の為）
テストした感じでも問題ないので、閉じます。

♥ 0

いいねをした人: 居ません

[Hatsuki]

強制的に続きを読むのリンクは消すようにするのが良いですかねー。

ですね。強制的にmoreコメントを消して続きを見せると言うのも良いかもですが、メンバー限定と併用した場合どうなるのかとかをきちんと試さないとですね（試せてない）

うーん、あまり設定項目は増やしたくないんですよね。

確かにゴチャゴチャするのは良くないのですが、説明文は差し替え時はメモとして使ってませんが、差し替え前は説明として使っていたので…、差し替え止めるって時には消した場合は再入力しないといけないんですよね…。それが何か「うーん」な感じなもので。良い感じになれば良いと思います。

♥ 0

いいねをした人: 居ません

[Hatsuki]

template-parts/common/search-form-xxx.php が僕の環境にはなかったので、試しに下記のコードを試してみたのですが、

んーと、ちょっとやりたい事が上手く出来ないと言うか何と言うか…
単純に検索フォームの位置を判別して置換を適用したいなと思ってます。

ちょっとコードが適当ですが…

add_filter( 'snow_monkey_template_part_render', [ $this, '_template_part_render' ], 10, 4 );

public function _template_part_render( $html, $slug, $name, $vars ) {
	if ( 'template-parts/common/search-form' !== $slug ) {
		return $html;
	}
	echo $name;
	ob_start();
	View::render( 'form/index' );
	$form_html = ob_get_clean();
	$html = mb_ereg_replace(
		'</form>',
		$form_html . '</form>',
		$html
	);
	return $html;
}

とした場合には、オーバーレイ時（overlay-search-box）、見つからない時(no-match)、404時（404）は$nameにも代入されて正しく反映されますが、
サイドバー等のウィジェットで出している検索フォームに関してはフックが掛からないっぽいです。
これをどうにかする場合、検索フォームの場合はget_search_formを使えばいけるっぽいんですが…そうした場合、全検索フォームに対して引っかかるが、フォームの位置判断が出来ない。

フックが1つまでしかかけれない（2個目以降は無視される）

ありゃ…それは気づかなかった…。と言うことは、自作してるアドオン系プラグインでは思い切り使ってるので他のプラグインで掛からなくなってたっぽいのもあったのかも。一度整理し直さないとですね…。ちょっと何か考えるとして、snow_monkey_get_template_part_template-は、なるべく使わないようにとりあえずの修正をすればって感じですか。
renderフックなら問題なさそうなので、そっち使います。

> 追伸：

oh……適当に書いてしまってました。
まあ、開発中はfilterで書いて後から直すって事の方が多いです…（actionフックはfilterって書いても動くし）

♥ 0

いいねをした人: 居ません

[Hatsuki]

あーなるほど、 is_search() かつ is_tag() みたいなパターンがあり得るということですね。 is_search() のときは is_search() にしかならないと思い込んでいました…。

is_search()は必ずtrueになるんですが、ANDなパターンがあるんですよね。
ただ、技術書籍とかでは is_tag() = タグページと書かれてたり、英語リファレンスでもそう書かれているっぽいんですよね…。
WP4系の時からANDになるパターンは変わってないし、何となく仕様って気もしますが、実際はコアのバグなのか…正直なところは悩ましい（笑）

is_searchで弾くのは確実に検索ページって判定になるので、is_search判定でしとけば良いと思います！

♥ 0

いいねをした人: 居ません

[Hatsuki]

追加CSSに

.c-hamburger-btn__bar {
background: #fff;
}

でどうでしょうか？
また、MENUのラベル色を変更する場合は

.c-hamburger-btn__label {
color: #fff;
}

となります。

♥ 0

いいねをした人: 居ません

[Hatsuki]

私のブログは ログインするログインしないという設定はありません

失礼しました。

閲覧者のログイン機能がない場合、閲覧者は必ずログインしていない状態 = Cookieで保存と必ずなりますね。

こちらのテスト環境でFavoritesプラグインを試して確認してみましたが、
ログインしていない際のCookie保存とお気に入り削除などは上手くいきました。
（Snow Monkey v7 + Snow Monkey各種プラグイン全て + ブロックエディターの環境で確認しています）

ただ、プラグインの影響なのかキャッシュ系のプラグインやjQuery系のプラグインと併用をするなどした際に、Cookie管理（お気に入りが追加されない or お気に入りが削除されない）などが上手くいかない時がありました。
Snow Monkeyではページ最適化機能があるので、そう言った最適化機能を使用している場合はもしかすれば影響が出るのかもしれません。
（そこの影響などについては、キタジマさんに回答をお願いいたします…）

そう言ったプラグインを使用されていない場合は、おそらくショートコード側の問題の可能性もあると思います。

WordPressにお気に入り機能を追加できるプラグイン：Favorites

WordPressにお気に入り機能を追加できる「wp favorite posts」を使っているWEBサイトでエラーが出るようになりました。原因はphpのバージョンでphp7.1.xからエラーが出る…

usortblog.com

では、ブロックエディターで直接ショートコードを書いていますが、
ブロックエディターの「ウィジェット」より「ショートコード」ブロックで正しく記述してください。
（直接ショートコードを入れた場合に、こちらのテスト環境では正しく動作せず何も表示されない状態となっていた為、もしかしたら同一の症状かもしれません）

お気に入りが表示されないなどの場合は、ショートコードが正しく記述されているか再度確認していただけますか？
また、ボタン表示などをショートコードでされている場合も同様にそのショートコードを見直していただければと思います。

♥ 0

いいねをした人: 居ません

[Hatsuki]

補足で説明しますー。

私が WordPress にログインしているか 否か で、ユーザー側の お気に入り登録の表示も 変わってしまう

そうでは無いです。

まず、

ログインをしている ＝ サーバはユーザーを特定できる（IDで誰か解る）
ログインをしていない = サーバはユーザーを特定できない（誰か解らない）

状態になります。

ログインをしている人には、サーバが誰か分かっているので、そのユーザー専用の情報として、サーバ側（データベース）にユーザー情報としての保持をします。

一方、ログインをしていない人にはサーバは誰か解らないので、仮にサーバ側に保存したとしても誰にその情報を渡せば良いのか解りません。
その為、サーバ側に保存する訳では無く、ユーザーのブラウザ側に保持をお願いする事になります。
Cookieと呼ばれるもので、ユーザーのブラウザ側に保持をする…と言う事です。

お気に入り情報を表示する場合でも、

ログインしていない場合は、そもそもサーバ側はそのユーザーが誰か解らないので、データベースにあるユーザー情報をサーバは見ません。
ユーザーが保存したCookieの情報から、ユーザーにお気に入り情報を表示させるようにします。

ログイン時は、データベース側に保存されたお気に入りを表示しますが、
Cookieの情報を見ない事には、ログインをしていない時の保存データ（Cookie)を見ない為に、ログインをしていない時のお気に入り情報が表示されなくなります。

Favoritesプラグインは、多分ですがログインしている時にデータベースの情報しか見ていないと言う事なんだと思います。

ちょっと設定があるか不明なので…申し訳ないですが、
ログインしている際に両方見る…と言うのは、出来るかは解りません。
ただ…設定でそれらしき設定（Cookieとか色々書いてある設定等？）があればONにしてみると出来るかもしれません（未確認です…

♥ 0

いいねをした人: 居ません

[Hatsuki]

blockの表示数はBlockのjsで範囲を制限してるので、ブロック側でHookを作って数の制御を変更する仕様にすればできると思います。
しかし、Hookを仕掛ける場合でもjsになるのでPHPのように簡単には行かないかもです…。

現状で出来るやり方として、一度コードエディタに変え、postsPerPageの部分を表示したい最大数で直接入力した場合はその数が出るはずです。

<!-- wp:snow-monkey-blocks/recent-posts {"postsPerPage":120} /-->

のように変えると最大数が120などに変わると思いますがどうでしょうか？

♥ 0

いいねをした人: 居ません

[Hatsuki]

やはり、ちょっとややこしい感じでしたか。
> その下に紐づく entry-summary-post.php に設定値を引き継ぐ方法がないので。

これなんですよね…。
適当な感じで条件をゴニョゴニョしまくってうちのサイトにカスタマイズして入れてるんですが、
微妙に上手く動いてないっぽいんですよね。（上書きとかすればいけるっぽいですが…）

> v7 でオフィシャルに「関連記事レイアウト」の設定を追加しましょうか。

そうして頂いた方が助かります。
そもそも、何故一覧と設定が一緒なのかって言うのも疑問だったり…。

♥ 0

いいねをした人: 居ません

[Hatsuki]

@キタジマさん
お、クラス追加！助かります。
もしよろしければ、フックも追加していただければ…（笑
って、そこをフック追加しても何か無駄とか難しい感じもしますね…

例えば、「最初のページへ」「＜」「１」「２」「＞」「最後のページへ」
「 xxxx / yyyy ページ」
とか、最初、最後、何ページあるのかを表示したいとかそう言う場合って、フックがあれば出来るのかなーと。
今だと結構変更するのが面倒な手順を挟んでやらないとダメだったような…。
（例えがやっぱり無駄な機能になっているのは、さておき…）

WordPressって、ページャーに自由度があまり無い感じなので、Snow Monkeyで、そこを上手い感じでもっと簡単に自由にカスタマイズ出来たらなーと思いまして…。ただフックがあるだけじゃ難しいかもしれませんが。

♥ 0

いいねをした人: 居ません

[Hatsuki]

これ、矢印がFont Awesomeだから、結局classを変えたりしてCSSでゴニョゴニョするよりは、

is_archive か何かで表示しているページの判定をして、
template-parts/content/prev-next-nav.php
の出力に対して、フックを掛けるか、ファイル上書きをするかで、
ゴニョゴニョした方が早そうな気がします。

ただ、どうするのがベストなんだろう…。

♥ 0

いいねをした人: 居ません

[Hatsuki]

> 「多くの問題」というのは例えばどういうものでしょう？
> remove_filter できないとかテンプレートが読み込まれないとかですかね？

remove_filterは全部出来たのを確認済みです。
（思い切りほとんどのテンプレートに対してフック掛けて調べた結果問題なさそう）

さっき調べてみたんですが、めっちゃ勘違いしていました。
多分、こちらでレイアウト追加を無理矢理していたのが原因です…。

レイアウトにoriginalを追加……みたいなのとか色々追加をしていた所が、
entry-summaryの構造がv6から変更と言う事で、
各要素のmeta-post.phpとかが、v6のテーマ元を読んでしまうようになってしまってたようです。
（その形で、適切にoriginalのレイアウト構造が当たらなくなっていた、または一部が当たっていたりCSSが掛かって、デザインがおかしくなってしまったとか色々）
って感じのようでした。
（また、多分、get_template_partに$nameとか与えないと、entry-summary内で各要素を取るようになったので、その処理をするget_post_typeなどが取れなくなる為か、何か動作に違いを出してしまうか、何かが起こったのかも）

「多くの問題」と言って、すみません。そんなに問題なかったようです。

また、レイアウトのオリジナル追加とかやってるのは私だけと思うので、気にしないでください。レイアウトのオリジナル追加自体が結構無理矢理な部分もあるので、この辺はもう…サポート外で良いかもです。
（いつか、簡単にレイアウト追加できる仕組み考えたいですが…）

♥ 0

いいねをした人: 居ません

[Hatsuki]

すみません、やり方が悪かったようで、フック処理されていました。
ちょっと構成を合わせると処理されたのですが、何が原因なのかちょっと不明で調べると…

\Framework\Helper::get_template_part( ‘テンプレート名’, $name, $vars );
を省略して書いてもv5の時は意外と行けていたのが$nameと$varsを渡さないとかなり多くの問題が起こるようになっている…って感じですね。
もし、カスタマイズで$nameと$varsを省略して使っているならv６では入れるようにした方が良いと思われます。

また、entry-summaryのtitleなどを分けた形で修正もしないと駄目だった様子。
そう考えると、オリジナルレイアウトとかも、v６とv５での互換が無いと思えます。

と言う感じがします。
とりあえず問題は解決したのでクローズしますが、これまでのget_template_part部分を略してた場合には、カスタマイズに結構影響が及ぶ…って解りました。（結構、辛い

♥ 0

いいねをした人: 居ません

[投稿者]

投稿