[Hatsuki]

@アクツさん

gutenbergの駄目なところで、再編集時に保存されてるhtmlとsaveの記述されてるフォーマットを比較して差があるとフォーマットと違うからって壊れたブロック…ゴルァ状態(な感じ)
なので、自動的にメディアから取得したデータを出すようにすると、メデイアの情報を変えると保存されてるhtmlのaltの値と異なるのでそのままだと「ゴルァ」な感じになります。
他の要因で保存されたhtmlが変わってしまう場合の処理が思ってるより結構面倒なんす…

調べてみたら、殆どのブロック(他の開発されたもの含む)ってalt付いてないっすね…
もしかして: gutenbergはaltに弱い？

♥ 0

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

[Hatsuki]

@キタジマさん

media.titleかmedia.descriptionとか何かで、メディアのファイル名かタイトル取得とか出来たと思います。
後はattributesにselecter、alt属性から取得の形に変えれば、「アレ」を書かなくても済むはず。(空で書いてる以上、空文字で代入されます。後、alt部分をコードエディタで書き直しても問題無く動作する)

ただ、今までの分はメディア選択からやり直しなので、少し手間があります。
なので、save時にmediaIDからmedia情報を取得し、自動でaltなどを入れるようにする…って手も試しましたが、これだと記事を保存し直すだけで、その時のメディア画像とかタイトルが適用されると思いきや、メディアの情報を変えると再編集時に壊れるので推奨出来ません…。

しかし、alt情報がエディタ時に目に見えない分、ブロックの設定部分にinputを置くことで取得したaltを表示で見える+編集と言う形なのでUIとしてはこの方が良いのかなーとか考えたり。
どうっすか？

♥ 0

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

[Hatsuki]

> 下記でGutenbergの表示をカスタマイズ出来るようなのですが、MyBlocksのプラグインに貼り付ければ使えるようになりますでしょうか。

記載されている通りにやったとしても無理です。
また、registerBlockTypeはPHPに存在する命令ではなく、記載のコードについてはPHPと書いていますが、実は誤記でReactのjsとなるようです。
（※ 別のページでもghostkit作者自身がReact記述だからPHPではないと言っていました…）
なのでReactで少し試しましたが、拡張するのはSnow Monkey Blocksにある１ブロックでもかなり大変だったのと問題が多いです。

以下、試した事に対する事を書いておきます。

MyBlocksと言う新規のブロックを作ると言う意味では、この通りregisterBlockTypeを挟み、ghostkitのsupportsの環境を上手く配置して取り込むようにすれば使えます。
Snow Monkey Blocksのファイルだけではghost kitのこのsupportsの設定は存在しないのでエラーとなります。その為、取り込むようにしなければなりませんでした。
（取り込み方はghostkitのgithubのコードから調べてみてください…一応取り込みは出来たんですが、正しい取り込み方は不明ですので）

Snow Monkey Blocksの既存のブロックにghostkitと同じようにDisplay設定をカスタマイズしたいと言う事であれば、smb/xxxxxxxのブロックに対してaddFilterを上手く追加させ、フィルター処理するようにしなければ動作しないようです。
（ただ、それでも編集時にブロックが壊れるのも多かったり色々問題が起きます）

…また、それらを拡張した場合でもSnow Monkey Blocksのアップデートなどに合わせて都度対応が必要となると思います。

これらの設定は色々と便利な所もあるので、Snow Monkey Blocksでも使えたら良いのですが結構難しい部分もある事と、ghostkitと言う別のプラグインの独自仕様を使う為、こう言った複雑な事をしたとしても十分に動作は出来ないようです…。

一応、ghostkitとは違いますが、似たような事をしたいのであれば

Gutenbergで既存のブロックにカスタム設定を追加する方法

Gutenbergはサイドバーに「高度な設定」というクラス名を入力できる欄があるのですが、これだとクラス名を覚えていなくてはいけなくて、制作者以外の人に入力してもらうの…

www.webopixel.net

とかが参考になると思います。
これもaddFilterでやってるようです。

なお、既存のブロックにスタイルを増やしたり拡張するのは

Block Styles in Gutenberg – Bill Erickson

Every block type in the WordPress editor can have multiple style options. I'll show you how to add and remove style options from blocks.

www.billerickson.net

が、参考になりますので、そちらも追記しておきます。

♥ 0

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

[Hatsuki]

ではルートディレクトリの変更機能もつける方向でちょっとみてみます。

お手数ですが、時間ある時にでもお願いします。
（一応、上記のisfileで分けての実装はしてますので、急がなくても大丈夫です）

どのタイミング（フックポイント）で実行されてます？

plugin_loadedの所にsnow_monkey_member_post_template_pathを実行する形で、そこだけmy-snow-monkeyにそれだけ書く形で再度試してみました…。
何故かそっちだと上手くいったので、調べてみました。
snow_monkey_member_post_template_pathの優先度と、テーマ側のフックでのroot設定を同時にやっていた事、優先度などの処理問題だったっぽいです。（多分、複数使うと正しくパスが見られなくなるか何かが起こったのかと）
完全に、こちらのミスです。すみません……。

はっきりと覚えてない…

それは…（泣）Snow Monkeyだけは…制作者も解らない状態化しないよう、願いますorz

♥ 0

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

[Hatsuki]

「そのテンプレート自体のパス」を差し替えるもの

ありゃ、また使い方を誤ってたようで…orz
ゴソッと変えると言うより、わざわざslugで判定するよりもファイルが有ればそれを使う、無ければプラグインの本来のファイルを読むって言うテーマのrootの感覚の方が楽だなと。
rootディレクトリにファイルを入れるだけなんで、やっぱりこのslugのも上書きしたいって言う時に後から追加してもコード弄らなくて良いなと。

\Framework\Helper::get_template_part は基本テーマディレクトリ内のファイルを読み込むためのもの

なるほど。基本テーマ外のマッチはやると大変そうなんで１の方法で上書きする形で使います。
しかし、shortcodeディレクトリの中のテンプレートの指定だけsnow_monkey_member_post_template_pathでどうも上手くいかないみたいなので、
それだけ何とか出来たらなと思います。

Member Post は、メインの用途は「コンテンツの閲覧をログインユーザーに制限する」

あー、なるほど。
制限した上でユーザー登録の導線も作ってユーザーを増やそう！ってことまで考えてしまってました…。
そして、オマケがオマケじゃないくらい便利なんですけど（笑）

一応 title 属性で指定はしてて、svg に変換後は svg の title 属性としてタイトルが保持されるみたいです。

あ、そんな所に指定されてたとは…。これならCSSかjs使えばタイトルを別枠に出せそうなんで、それでやります。

5分たつと自動的に編集不可

そんな仕様が…。また一つ勉強になりました。有難うございます。

商品ページ（https://snow-monkey.2inc.org/product/snow-monkey-member-post/）のスクリーンショットだと「表示は制限されています…ログイン」のログインってリンクっぽいですが、これ今のバージョンだとリンクになっていない感じなので、それも不具合で有れば修正頼みますー。
（多分、redirect先をどうするのか問題とかで、リンクやめた気もしましたが）

♥ 0

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

[Hatsuki]

あれ？トピックの編集機能が無くなってる…？？

編集がないので、返信の形にて。
snow_monkey_member_post_template_pathを使えば
contentディレクトリ内のmessage.phpなどはファイルを別に読ませる事で書き換えられてはいるんですが、
shortcodeディレクトリのlogin-formとかは、上手く切り替わらないので、
フックを掛けるタイミングが、ショートコードって言う仕様から違うのか調べてます。
上書きがうまく出来てない問題もあって、ログインフォームとかってこの際どうやってデザイン変えるんだろうって言う質問が出ましたが、とりあえず、こちらのトピックにて。

プラグインのphpを直接変えれば全て色々変更とか出来ますが、それだとアップデートのたびに戻ってしまう問題もあるので、プラグインでテーマみたいに上書きとか出来ないかと。

ちょっとこちらの使い方の問題がありそうなので、もう少し調べてみます。
すんません。

♥ 0

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

[Hatsuki]

＠キタジマさん

マージありがとうございました。
後、さりげなく他のブロックのリファクタリングも参考になりました（笑）

> BlockAlignmentToolbar でやると後でわかりにくくなるようなきもしますね…。

確かに。標準がsupportsの方なので後でわかりにくくなる問題リスクは高い…。
うーん、CSSだけのカスタマイズの場合、この部分の反映がそのままエディタ内ではされないのがちょっと悩ましい。ただ、標準のことも考えたら、キタジマさんの二重管理って方針が面倒だけど後々良さそうな気も…。ここはまた今後考えていく所かもしれませぬ。（エディター内のHTML仕様も変わる可能性あるし）

＠アクツさん

アクツさんが想定されているCSSも、見れるならそれをベースにブロックの仕様上の問題をどうするかとか考えたいですし、よかったら問題ない範囲で今後でもCSSを晒しちゃってください（笑）色々そう言う所からもエディタに反映されない”だろう問題”とか解るので助かります。

スタイルがサポートされているとスタイルの拡張自体は別プラグインで安全に出来るっぽいんで、Snow Monkey Blocksとは別のプラグイン作ってボタンブロックのスタイルくらいなら増やせると思います。

…やり方は…またいつか書きたい（切実…

♥ 0

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

[Hatsuki]

後１つだけ、葉月さんの方で気になったらしいので、それも記載します。

登録フォームには、登録していない人が使用されることを想定されるので
「パスワードをお忘れですか?」のリンクは不要ではないでしょうか？
パスワードの入力ボックスがない事もあり「パスワード？」と言う誤解を招くかもしれないのも１つの理由です。

って事です。ご検討お願いしま。

♥ 0

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

[Hatsuki]

＠キタジマさん

あ、先に出された（笑）
こっちでもボタンに対して色々検証やってたので、ちょっとそれだけ直したのをプルリクしておきました。

どーも、supportsでalignすると色々と標準のクラス名で付いちゃうし、エディタだけの反映に問題があるんで、この際それを、BlockAlignmentToolbarを使ってクラス名を正しく当てようか考えてたのを、きちんと伝えれなかったorz
すみません。そうしないとスタイル増やす際にちょっと問題が今後出てくるかもなんでそこだけ共有出来れば良いなと…。今度またそれだけ直そうかなと思います。
よろしくお願いします。

♥ 0

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

[Hatsuki]

@キタジマさん

…タイプと言う独自……なんたる…問題！！

と思いましたが、全然問題と認識してなくて、スタイルで大丈夫かと思ってます。

だって、これ…フルサイズにするだけじゃないですか？
smb-btn–fullクラスが付くだけやん…って感じな認識で、それなら、アウトラインのボタンでもタイプと言う項目をそのまま使って、フルにするかノーマルにするか…大きさを変更する項目に使って良いんじゃないかなと。

タイプ　→ 大きさ
と項目名を変えれば、解決だよねーと。（項目変更は、葉月さん案

なので、そこまで影響はないかと。

実際、BlockAlignmentToolbarを使って、テキストの位置とかも右寄せとか左寄せとかにするとかの方が変にそれをスタイルでやっちゃうと後から変になるので、タイプは残すままで良いと思います。

どうでしょう？

♥ 0

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

[Hatsuki]

> それはもうその人のデザイン上の趣味なので…ということで16px以上に矯正するようにはしてません。

仕様、了解です。
デフォルトが１６であれば、確かにデザイン上の趣味…。
クローズします。

♥ 0

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

[Hatsuki]

> 引数をフックでいじると、値と画面上の見た目に差異がでそうな気がするのですがどうでしょうね。

あ、そうか…。確かにタイミング次第では差異の問題が起こりそうな気がします。

Framework::control(
  'select',
  'post-entries-layout',
  apply_filter(.....)
);

とかで出来ないかと思ったんですが、そういう単純な問題でもなく。
下手に間違うとカスタマイザーがぶっ壊れますし、フックでするべきじゃないって事で理解しました。

> remove は結構めんどくさいはずです。

やっぱり面倒なところですか。白紙で上書きする形でします。
となると、既存のカスタマイザー項目の削除なら、デザインスキンのjsと同じような事をするって感じで可能として
ゴリゴリ変更するって言うのは、基本的に出来ないと思った方が良さそうと。

> CSS 的な意味でいうと、形自体は rich-media ですが、more 表示とかのエフェクトは無かったりします。

なるほど。その違いですか。基本は定義しなければ形はrich-mediaの形が適用される…って感じですな。

大体、解りました。

そもそも、そこまで変更しようとするなって話ではありますが…
デザインスキン ＝ 全体的に変わる　なので、もっと自由な 部分だけのスタイル ってのをカスタマイザーで気軽に追加して、実際の反映表示を見ながら変更して行けないかなーと。
ちょっと試している所で、記事一覧とかヘッダースタイルとかなら用意されてるのに追加すれば出来そうだなと。
そう言う感じです。（まだ、実験段階ですが…）

♥ 0

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

[Hatsuki]

ちょっと試したんですが、カスタマイザーの「デザイン」「基本デザイン設定」「基本のフォントサイズ(px)」が16未満だと
なぜか拡大されてしまって駄目っぽいです。

16以上であれば、問題ない事を確認しました。（テーマのデフォルトって、１６でしたっけ？）

♥ 0

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

[Hatsuki]

いや、bbpressのテキストボックスとかmember postのログイン等もinputがあるんで、
それも入れないと駄目かもです。
（そっちも、何故か拡大が発生している？うちの問題かと思いましたが公式でも発生してました）

これ多分basisの調整で全部可能かなーと思ったんで、可能なら全体的に調整していただいた方が良いかも知れません。

♥ 0

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

[Hatsuki]

> カスタマイザーのセクション or コントロールを定義するときに、 active_callback で表示条件を指定できます。

active_callbackで指定って、そう言う事だったのかと。（使い方がイマイチ理解してなかったw
WP Customizer Frameworkの方のコードももう少し調べてみます。

……WP Customizer FrameworkのReadMe、追加で書いていただいても構いませんよ？w

♥ 0

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

[投稿者]

投稿