カスタムブロックのAttributesにはobjectタイプが存在しないらしい。

著者 Nora

日付 2019年4月1日

カテゴリーコラム

カスタムブロックを作成する際、値を保存する時に気を付ける点についてです。

タイトルにもあるように、カスタムブロックの作成に関する話ですので、カスタムブロックの作成方法をご存知でない場合は先にそちらの記事をご参照ください。

最近はテーマ「Ace」用にSwiperのスライダーブロック（+投稿タイプ+ショートコード+ウィジェット…）セットを作成しているのですが、オプションを属性値として登録して保存しているんですが、結構な量ですので項目毎に分類しています。

今回はそれでふと思い出した備忘録です。

カスタムブロック作成時のハマった事例集でも作ろうかと思ってしまうくらいにこの手のネタは尽きません。

Attributesが保存できる値

Gutenbergでカスタムブロックを登録する際のパラメータに、使用するデータの型を予め登録するのですが、以下の型が登録できるデータタイプです。

他にもあるかもしれませんが、とりあえず「object」は無理でした。

object型では、保存メソッド「setAttributes」がコールされると、一時的にattributesとして保存されたように見える（コンソール系メソッドで値を確認する限り）んですが、ページをリフレッシュすると結局うまく保存されていませんし、フォーム系DOMのビューに変化が起こりません。

選択しているブロックを切り替えると値が反映されていますが、ページをリフレッシュするとやはり保存されていないことが分かります。

つまりオブジェクト形式では保存されていなかったという話です。

第一候補として似たようなことをしたい場合、arrayを使用することが考えられます。

具体的には配列にキーとなる値も合わせて保存させ、更新用メソッドがコールされる度に古いデータと入れ替える形で保存することです。

ですが、設定項目が多かったり、グループ毎に設定を分けて管理したい場合など、データをひとまとめにしておきたかったのですが、PHPの連想配列的な形で保存しておきたい場合もあるかと思いますので、データの基本的な形としてJSONを使います。

データを使用する際は「JSON.parse( string )」、保存する際は「JSON.stringify( Obj )」です。

GutenbergではワードプレスのRestAPIを使用しているそうで、そちらの都合で受け渡しするデータの型に幾らかの制限があるのでしょう。

もしかしたらJSONと指定すればオブジェクトのまま使えた、或いは将来的に使えるのかも知れませんね。

Gutenbergだけでなく多くのオプション値をフォーム送信する際にはかなりJSONは役に立ちます。

ShapeShifterでウィジェットエリアにオプショナルでサブコンテンツを出力するようなメタデータを実装した際は、ユーザーが任意で保存するデータの数を増減させることができるものでしたので、保存する際に全てのデータを一旦JSON化して纏めてから送信するようにしていました。

送信する数が多くなり過ぎると、送信可能な上限を越えてしまう場合もありますし、他のプラグインとも一緒に使う場合を考慮すると、リソースをなるべく節約しておきたいですから。

まぁそんなに大量にinputタグなどを使用する機会は殆ど無いと思いますけどね。