補足です。

この不具合を修正すると、おそらくGutenbergを使用しているほとんどのCocoonユーザーに影響してくると思うので、カラーパレットの設定値を入れる属性には修正前後で互換性を持たせるために、

#[...color code...]

「先に設定値を確認し、先頭に"#"がある場合には適切な形に変換する（スラッグに設定値を置き換える）」といったような処理を加えた方がよいかと思います。

そうすれば、少なくともカラー指定にある色と一致する場合に、すでにエディタ内に配置されているブロックでも展開された時点で正しく設定が反映され、再度ブロックごとに設定を更新し直す必要がなくなります。

ちょっと上の返信のようなものではないのですが、とりあえず、機能の時点で書いていた対策案的なものを貼っておきます。
手段としては、本文内のカラーコードを含めたクラスを取得してCSSを出力するというものにしてみました。
https://github.com/yhira/cocoon/commit/75da34371d95ff65ca92a0d607b4a42e35615028
ブロックエディターにCSSを読み込めば、CSSも反映されると思います（まだ未実装）。
ただ、よくよく考えたら、編集中のブロックには、スタイルがリアルタイム反映に気づいてしまいました。
たとえ保存したとしても、非同期だから、CSSが読み込まれずリロードをしないと、スタイルが反映しない的な。
ここら辺をうまく解決する方法が思いつかないので、ブロックエディターへのリアルタイム適用には、インラインスタイルでスタイリングするしか内のかも。

あ、でも書いた直後にでいい方法を思いついたので、やってみます。うまくいくかは分からないけど。

カラーパレットでは属性の設定をスラッグベースに、カラーコードをブロックのインラインスタイル指定に...とするのが一般的な実装方法（#post-22699）

Gutenbergではなぜこのような形で実装されているのかについては、attributesを基準にしてレンダリング等を行うよう設計されているからだと思います。

従って、attributesの設計が本来の実装方法と異なっている場合、または誤った形で実装されている場合、

編集中のブロックには、スタイルがリアルタイム反映に気づいてしまいました。
たとえ保存したとしても、非同期だから、CSSが読み込まれずリロードをしないと、スタイルが反映しない的な。（#post-22742）

といった点を含め、様々な問題が生じることになります。

（例えば、PanelColorSettingsコンポーネントを使用しているブロックにフックでそのまま共通カスタマイズを加えても、Cocoonブロックにだけは正しく反映されないなど。）

今回の問題に戻って考えてみると、少なくとも

1. 他の同コンポーネントにおけるattributeの扱われ方と異なる
2. 同色のカラーコードを変更すると既存のattributeと一致しなくなる

点を修正する必要があり、

https://github.com/yhira/cocoon/commit/75da34371d95ff65ca92a0d607b4a42e35615028

のような方向性では、1.が考慮されていないと思います。

Gutenbergにはまだ今のところ実装されているフックも限られているので、本体の実装例に倣うのが確実で分かりやすいのではないかと。

修正されたコードは確認していませんが、エディタ上などの私の方ですぐに確認できる部分だけで見てみました。

まず、

1. デフォルトの状態でカラーパレットを用いているCocoonブロックを追加し、色を設定する。（＝本番環境の既存ブロック）
2. 修正版のCocoon本体を有効化する。
3. フックを通してカラーコードを変更する。
4. 1でブロックを追加した記事の編集画面を開く。

という手順で試したところ、フックで変更した色が反映されていません。
同様にプレビュー画面を開く、更新してから投稿記事を表示する場合も色（クラス名）は反映されていません。

また、4で開いた編集画面上で1の追加ブロックを選択（isSelected）したところ、カラーパレットに設定が反映されていません。

赤色を選択した上で赤のカラーコードをカスタマイズした場合でも、ブロックの色設定は赤色が選択されているはずで、テキストエディタで見たときの属性も変わっていないので、上の内容が私の環境のみでなければ、このあたりに問題がありそうです。

次に、フック（editor.BlockEdit）を通してブロックのeditでのattributesを取得してみました。
こちらにもカスタマイズの内容は反映されていないようです。

cocoon_editor_color_palette_setup関数で指定するカラーはエディタ用なので、カスタマイズ内容に則った設定値が取り出せるよう、少なくともこのカラー指定とGutenbergエディタ上でのカラーパレット設定周りの挙動を一致させる必要があります。

「インラインスタイルを使用しないAMP」で利用できるようにとそういった仕様にした結果、attributeの動作とは違うものになりました

この内容がよく分からなかったのですが、PanelColorSettingsコンポーネントでのインラインスタイル指定のことをおっしゃっているのであれば、エディタ上なのでAMPは関係ないように思います。
サイト表示上では、attributeに設定されているスラッグをもとにしたクラス名が反映されているはずです。

これらを全部修正するとしても、かなり大掛かりになるので、ちょっと今すぐには出来ないと思います。

分かりました。
環境の問題でなければ、別の対応方法を考えます。

エディタ上なのでAMPは関係ないように思います。
サイト表示上では、attributeに設定されているスラッグをもとにしたクラス名が反映されているはずです。

僕が当時参考にしていたプラグインが、公開ページ上でもインラインスタイルでスタイリングしていたので、そういうもんなんだと思い込んでいました…。あーこれはやっちゃった…。

WordPressデフォルトのボタン的に言えば、以下のようなCSSのことですね。

has-text-color has-pale-cyan-blue-color has-background has-pale-pink-background-color

明日にでも、ボタンの公式のソースコードを見てみようと思います。

また今後変更にも挑戦してみようと思います。
ただ、例えば「以前のクラス名」から「上記引用部分」のようなクラス名の変更が起こった場合、「このブロックには、想定されていないか無効なコンテンツが含まれています。」みたいなエラーが出ますよね。
こうならない、良い方法ってないんですかね…。
これはもうどうしようもないんでしょうか。

補足しておきますと、今回の主な問題は以下の点です。

倣って実装した場合にはCSSで指定されたカラー（サイト側）とカラーパレットの指定カラー（エディタ側）を変更するだけで対応でき、カスタマイズ後のカラーが反映されます。（#post-22699）

それがつまり、

WordPressデフォルトのボタン的に言えば、以下のようなCSSのことですね。

ということになってきます。

少し修正コードを読んだ上で、上記の挙動について参考になるかもしれないサンプルを置いておきます。

まず、スタイルのstyle.css#L4847-L4966を削除してください。

<?php
  $colors = cocoon_editor_color_palette_setup();
  foreach ($colors as $color) { ?>
    div .has-<?php echo $color['slug']; ?>-color {
      color: <?php echo $color['color']; ?>;
    }
    div .has-<?php echo $color['slug']; ?>-background-color {
      background-color: <?php echo $color['color']; ?>;
    }
  <?php }
?>

削除したスタイルを変更可能な形でcss-custom.phpにインライン化します。

公式ブロックではボタンや段落ブロック等にカラーパレットが用いられているので、公式のカラーパレットを適当に設定します。

add_filter('block_editor_color_palette_colors', 'cocoon_color_palette_custom');
function cocoon_color_palette_custom($colors) {
    $key = array_search('red', array_column($colors, 'slug'));
    if ($key !== false) {
        $colors[$key]['color'] = '#ff0000';
    }
    return $colors;
}

カラーパレットの指定カラーを変更してみると、その変更色がエディタ上、そしてサイト表示上全てで反映されるのが確認できると思います。

なので、カラーパレットのスタイルをインライン化して、指定カラーに合わせる方法は間違いではないのですが、それ以外の部分でも一律で反映されるよう修正しないといけない感じです。

公開ページ上でもインラインスタイルでスタイリングしていた

オプション的な設定としてカラーパレットを用いるのであれば、インラインに埋め込む形も見かけますが、基本は

{ attribute: color-slug } ⇒ color-slug-classname

の形式が保守管理はしやすいです。

「以前のクラス名」から「上記引用部分」のようなクラス名の変更が起こった場合、「このブロックには、想定されていないか無効なコンテンツが含まれています。」みたいなエラーが出ますよね。

deprecatedとして旧バージョンみたいな形で対応する方法はありますが、通常の方法だとリカバリーで対応してもらうしかないような気がします。

または、classNameに旧クラス名も追加してそのまま残しておく選択肢もあるにはあります。
今後を考えると、あまり良い方法ではありませんが。

deprecatedとして旧バージョンみたいな形で対応する方法はありますが、通常の方法だとリカバリーで対応してもらうしかないような気がします。

やっぱそうなんですね。だとしたら、そのようにするしかないですね。

ご提示いただいた、デフォルトのカラークラスの修正をしておきました。
https://github.com/yhira/cocoon/commit/080b421f2692cfb694b507b207a1dbb93ec6366a

その他のブロックについても時間がある時に一つ一つ修正していければと思います。

1つ疑問に思ったので、質問させてください。
例えばGutenbergデフォルトのボタンで色を変更するとブロックエディター上では、添付画像のようにインラインスタイルを用いて画面上の表示が切り替わります。

style="background-color: rgb(230, 0, 51); color: rgb(255, 255, 255);"

ただこういった、インラインスタイルの場合::beforeや::afterのような疑似要素を変更したい場合、どうするんでしょう。
やっぱ、ブロックエディターは、「ビジュアルエディターのスタイル挿入」とは違って、HTML要素を自由に書けるんだから、HTML要素を使えということなんでしょうか。

デフォルトカラースタイルの対応ありがとうございます。

インラインスタイルの場合::beforeや::afterのような疑似要素を変更したい場合、どうするんでしょう。

Gutenberg公式ブロックのカラーパレットについて、エディタ側でカラーをインラインスタイル指定する理由は、カラーパレットの指定カラーを優先させるためです。

サイト側で用いるスタイルをエディタ側にも読み込ませ、スタイルのカラーがカラーパレットのカラーと一致していない場合、そのままだと異なるカラーが表示されてしまいます。
そこで、インラインスタイルによってカラーパレットのカラーに上書きしているということです。

なので今回のように、テーマ側でカラーパレットの指定カラーに従ったスタイルを動的に生成するようにした場合には、インラインスタイルの指定が絶対に必要というわけではありません。

ただ、確かにGutenbergのカラーパレットによるクラスで::beforeや::after等を用いたスタイル指定は見たことがないので、Gutenbergに合わせた構造の方がよいのかもしれません。

なるほど、そういうことなんですね。
今回は、スタイルの統一のため、擬似要素を使ったまま修正しようと思いますが、次回新しいブロックを作るときは、全てHTML要素で作るようにしようと思います。

とりあえず、「ボタン」と「囲みボタン」はスラッグを用いたクラス名に変更してみました。
------------------------------------------------
https://github.com/yhira/cocoon
最新ファイルをダウンロードする場合は、上記ページのダウンロードボタンからzipファイルをダウンロードしてください。

FTPでのアップデート方法はこちら。
https://wp-cocoon.com/ftp-update/
------------------------------------------------
今回のこの修正で、問題なさそうであれば、他のも修正していこうと思います。

とりあえず、「ボタン」と「囲みボタン」はスラッグを用いたクラス名に変更してみました。

masterで変更を行っているのでしょうか？
またはpushかmergeのし忘れ等はありませんか？

すいません…。
プッシュしわすれてました；

確認しました。
まだ色々と問題点が残っているようでエラー等が生じるため、確認できた範囲で報告させていただきます。

1. デフォルトの状態でカラーパレットを用いているCocoonブロックを追加し、色を設定する。（＝本番環境の既存ブロック）
2. 修正版のCocoon本体を有効化する。
3. フックを通してカラーコードを変更する。
4. 1でブロックを追加した記事の編集画面を開く。

最初に#post-22765で示した方法でチェックしたところ、旧ボタンブロックが非推奨のままになってしまっています。

おそらくですが、修正版のdeprecated上で旧ボタンブロックを適切に新ボタンブロックに移行できていないことが問題ではないでしょうか。
この方法については、現状では以降の設定確認ができません。

次に、修正版で追加したブロックに対してカラー変更する場合を見るために、以下の方法でチェックを行いました。

1. 修正版の状態でボタンブロックを追加し、カラーパレットの設定を行ったあとに保存する。（＝今後追加していくブロック）
2. フックを用いて、カラーパレットに指定されているカラーコードを変更する。
3. 再度、ブロックを追加した編集画面を開く。

すると、3の時点で編集画面を開くことができず、エラーが出てしまっています。

エラー内容は'slug'がundefinedとなっているので、正しい方法でカラーパレットのカラーに対するスラッグ情報を取得できていないのではないでしょうか。
ブロックのフィルターフックから確認しても、少なくともedit時の該当するattributeはスラッグではなく、カラーコードになっているようなので。

軽くチェックしただけなので報告は以上ですが、これらの問題点からは

• 修正以前の旧ブロックを新ブロックに適切に移行させる。
• 旧→新の移行時にattributeもスラッグ形式へ統一させる。
• 修正後の新ブロックではattribute用にスラッグ情報を取得する。

といった修正が必要かと思います。

最初に#post-22765で示した方法でチェックしたところ、旧ボタンブロックが非推奨のままになってしまっています。

これはどういう状態でしょう？ よろしければお手数ですがキャプチャ画像もいただければ、幸いです。

すいません。
何度も読み返してようやく意味がわかりつつあります。
修正してみます。

とりあえず、ボタンのみから修正していきます。

次に、修正版で追加したブロックに対してカラー変更する場合を見るために、以下の方法でチェックを行いました。

1. 修正版の状態でボタンブロックを追加し、カラーパレットの設定を行ったあとに保存する。（＝今後追加していくブロック）
2. フックを用いて、カラーパレットに指定されているカラーコードを変更する。
3. 再度、ブロックを追加した編集画面を開く。

すると、3の時点で編集画面を開くことができず、エラーが出てしまっています。

こちらは、以下で修正できたかと思います。
https://github.com/yhira/cocoon

①はスラッグがredになるものを選択。

②は、redのカラーコードが変わるように、以下を使用。

add_filter('block_editor_color_palette_colors', 'cocoon_color_palette_custom');
function cocoon_color_palette_custom($colors) {
    $key = array_search('red', array_column($colors, 'slug'));
    if ($key !== false) {
        $colors[$key]['color'] = '#ff0000';
    }
    return $colors;
} 

③で以前では画面が真っ白になっていましたが、エラーが出ないように修正できたかと思います。

その他の不具合については、書き込みを熟読して一つ一つ修正していこうと思います。とりあえず、今日は遅いので明日から。

また、不明な点があれば、質問させていただくかもしれません。

まず、#post-23078と#post-23079についてですが、「フックを用いて…カラーコードを変更する」は今のところ提示しているサンプルをそのまま使用し、確認しています。
ただ、サンプルではCocoonの'block_editor_color_palette_colors'で一色のみ変更を行っていますが、ここでのフックの使用自体はあまり重要ではないと思います。

カラーパレットではカラーバリエーションを減らしても、減らしたカラーが反映されなくなるだけでエラーは出ないよう設計されているので、公式の実装方法に従うのであれば、カラーコードの変更のみを考えればいいはずです。
そして、#post-22699で説明した通り、問題はカラーコードの変更に対応できていない点です。

先ほどの返信にある2点の確認方法では、前者も後者もカラーコード変更時の挙動をチェックしています。

「旧ブロックが非推奨のまま」については添付画像が旧ボタンブロックです。
どのような実装の仕方をしているのかは確認していませんが、本来ならボタンブロックのアイコンが反映され、新ボタンブロックとしてそのまま操作できるのが正しい挙動かと思います。

新ボタンブロックを確認したところ、ブロック名がbutton-2となっているので、新旧2種類のブロックが混在してしまっているのが問題のようです。

そして、#post-22699で説明した通り、問題はカラーコードの変更に対応できていない点です。

この、「カラーコードの変更に対応できていない」というのは、どのように確認されているのでしょうか。
カラーコードがどこに反映されているの確認して、問題ない/問題ありと判断されているのでしょうか。

「旧ブロックが非推奨のまま」については添付画像が旧ボタンブロックです。
どのような実装の仕方をしているのかは確認していませんが、本来ならボタンブロックのアイコンが反映され、新ボタンブロックとしてそのまま操作できるのが正しい挙動かと思います。

新ボタンブロックを確認したところ、ブロック名がbutton-2となっているので、新旧2種類のブロックが混在してしまっているのが問題のようです。

これなんですが、button-2を新たに作成せずに、button-1のままクラス名が変わるような動作変更してしまうと、添付画像のように以前の投稿内で使用していたbutton-1には「このブロックには、想定されていないか無効なコンテンツが含まれています。」と出てしまって、編集できなくなってしまいませんか。

#post-23084の修正版について確認しました。
エラーの修正が確認でき、該当のattributeにもスラッグ情報が反映できていますが、attributeとカラーパレットの間に問題があるようでattributeの設定情報に基づいたカラーパレット側の設定が正しく反映されていません。…※

「カラーコードの変更に対応できていない」というのは、どのように確認されているのでしょうか。

Gutenbergエディタ上に表示されているカラーが変更したカラーになるかどうかです。
修正によってattributeがスラッグ情報となる場合、そのスラッグに対応するカラーが正しく反映されているかどうかを見ることになります。

カラーパレットに受け渡すカラー指定の配列ではスラッグとカラーコードが1対1の関係なので、カラーコードを変更してもスラッグとの関係は1対1なのが継続される形が正しい挙動です。

また、カラーパレットコンポーネント利用時には対となるカラーコードとスラッグ双方をedit上で扱うことになるため、※のように設定情報とコンポーネントの関係性にも注意する必要があるかと思います。

button-1のままクラス名が変わるような動作変更してしまうと、添付画像のように以前の投稿内で使用していたbutton-1には「このブロックには、想定されていないか無効なコンテンツが含まれています。」と出てしまって、編集できなくなってしまいませんか。

同ブロック内で旧ブロックのソースに対応する非推奨ブロックを作成し、新ブロックのソースに移行させる形が一般的かと思います。

推測ですが、ブロックが無効になってしまうということは移行用のコードが正しくないとか、旧ブロック用のsaveが抜けてしまっているとかではないでしょうか？

非推奨ブロックというものも初めて知りました…。
おそらく、現在の僕の理解力では、ソースコードなしではらちが明かないと思い、非常につたないコードで恥ずかしいのですが、ブロック部分のコードを全部公開しておきます。
https://github.com/yhira/Cocoon-Blocks-embed
もしよろしければ、これを元にダメ出ししていただければ幸いです。
今回の、ボタンコードは、こんな感じになっちゃっています。
https://github.com/yhira/Cocoon-Blocks-embed/blob/master/src/block/button/block.js
ほんとに、お手数をかけて申しわけないです。

動作確認しつつコードを書くほどの余裕はないので、とりあえず上の返信で書いた問題点と
https://github.com/yhira/Cocoon-Blocks-embed/blob/master/src/block/button/block.js
のコード上の目視だけで比較した回答になります。

まず、ブロックのsaveやattributesなどを変更する場合、そのまま変更内容を実装するだけだと既存のエディタ上にある同ブロックではエラーが出たり、正しい値が反映されなかったりします。

しかし、ブロックの中身を変更するだけのために新たなブロックを用意するのは、変更以前のブロックを引き継ぐことができず、解決方法にはなりません。
公式ドキュメントにもアンチパターンとして記述があったと思います。

そこで、第一段階として#L32は旧ブロック（cocoon-blocks/button-1）に揃え、変更後の実装も同ブロックのものとします。

同ブロック内で旧ブロックのソースに対応する非推奨ブロックを作成し、新ブロックのソースに移行させる形が一般的かと思います。

次に変更以前のブロックからの引き継ぎですが、旧ブロックを非推奨として維持するためにdeprecatedプロパティのsaveで定義します。
同時にmigrateを合わせて記述すれば、旧ブロックから新ブロックへと引き継ぐことができます。

非推奨ブロックの記述については公式の各ブロックでも実装されており、豊富な実装例を確認した方が手っ取り早いと思うので、詳細は省きます。

ただ一点だけ、新ブロックではカラーパレットのattributeがカラーコードからスラッグへと変更されているので、migrateを記述する際に注意が必要です。

attributeをカラーコードのまま引き継いでしまうと、別の部分で帳尻を合わせるためのコードを記述しなければいけなくなります。
そうなると余計に複雑化するので、migrate時に調整します。（#post-22726で説明した内容への対応）

attributeとカラーパレットの間に問題があるようでattributeの設定情報に基づいたカラーパレット側の設定が正しく反映されていません。

カラーパレットに設定が反映されていないのは、設定値がカラーコード⇒スラッグとなったにも関わらず、#L149でそのまま値を入れているのが問題かと思います。

お忙しい中、ご教示いただきありがとうございます。
そのように移行していくんですね。誠に恥ずかしながら知りませんでした。

いただいてヒントを元に、これから調べて、とりあえず通常ボタンブロックだけを正しく実装させてみようと思います。
他のブロックは、その後そのノウハウを元に変更しようと思います。

ヒントを参考にボタンだけ修正してみました。

修正ブロックファイル。
https://github.com/yhira/Cocoon-Blocks-embed/blob/deprecated-blocks/src/block/button/block.js

deprecated部分の記述。
https://github.com/yhira/Cocoon-Blocks-embed/blob/deprecated-blocks/src/block/button/_deprecated.js

属性値。
https://github.com/yhira/Cocoon-Blocks-embed/blob/deprecated-blocks/src/block/button/_attrs.js

Cocoonにdeprecatedブロックを適用したブランチ。
https://github.com/yhira/cocoon/tree/deprecated-blocks

参考
https://developer.wordpress.org/block-editor/developers/block-api/block-deprecation/

※リンクをdeprecated-blocksのものに変更。

確認しました。

カラーパレットに設定が反映されていないのは、設定値がカラーコード⇒スラッグとなったにも関わらず、#L149でそのまま値を入れているのが問題

こちらについてはまだ対応されていないようです。
新ブロック側のattributesにも'color'が残ってしまっており、旧'color'⇒新'slug'に揃える必要があります。

'color'に入るカラーコードはカラーパレットの指定カラー変更で意味をなさなくなるものであり、これを残したまま用いていると正しく動作しない箇所が出てきます。
deprecatedの migrate時に'color'は削除し、新ブロックでは用いない形が一番分かりやすいと思います。

その他の点について

_deprecated.js#L25で既存の旧ブロックが新ブロックに移行されるまでは、colorValueToSlugと同様に修正以前のデフォルト値を用いるべきかと思います。

理由は、投稿が更新されるまでは旧ブロックの状態で維持されるためで、旧ブロックが残ったままカラーパレットの指定カラーに変更があると、正しい設定で移行できない場合が出てきます。

それから、getCurrentColorSlugでカラーコードをスラッグ化する際に、Cocoon側で出力する指定カラー（helpers.js#L75）を用いていますが、これだと'block_editor_color_palette_colors'フックで変更されるカラーにしか対応できないので、Gutenberg側でカラーパレットが受け取る指定カラーを用いる必要があります。

改善点ありがとうございます！

すいません。
deprecatedがうまくいくまでは、 deprecated-blocksのブランチで編集することにしました。
https://github.com/yhira/Cocoon-Blocks-embed/tree/deprecated-blocks
お手数をおかけして申しわけないです。

_deprecated.js#L25で既存の旧ブロックが新ブロックに移行されるまでは、colorValueToSlugと同様に修正以前のデフォルト値を用いるべきかと思います。

とりあえず、こちらはcolorValueToSlugを用いるものに変更しておきました。
https://github.com/yhira/Cocoon-Blocks-embed/blob/bc40359c8ae4d8c932fdac0494c86050252fef4c/src/block/button/_deprecated.js#L25

その他の修正点は、この後取りかかろうと思います。

'color'に入るカラーコードはカラーパレットの指定カラー変更で意味をなさなくなるものであり、これを残したまま用いていると正しく動作しない箇所が出てきます。
deprecatedの migrate時に'color'は削除し、新ブロックでは用いない形が一番分かりやすいと思います。

attributesから、colorを削除するということは、colorの値を直接PanelColorSettingsのcolorSettingsのvalueに指定するということはできません。
ということは、slugの値からカラーコードに変換する処理を施してして、Settingsのvalueに割り当てるということでしょうか。
https://github.com/yhira/Cocoon-Blocks-embed/blob/c1763a9bb42ab3320fa94c3088b3c012bf6a2a7d/src/block/button/block.js#L117

attributesから、colorを削除するということは、colorの値を直接PanelColorSettingsのcolorSettingsのvalueに指定するということはできません。

については一番最初の問題提起（#post-22699）から説明してあるように、そもそもattributeにカラーコードを保持していても、直接PanelColorSettings内のvalueに入れるだけでは対応できません。
カラーコードに変更が入った場合、attributeに保持されるカラーコードとマッチしなくなるからであり、カラーパレットの表示上に反映されません。

今のままで反映させるためには、手動で既存ブロックのカラーパレットを再度ひとつひとつ選択し直し、attributeに新しいカラーコードを入れなければいけません。

カラーコードベースでattributeと表示上のカラーパレットを揃えるなら、ぱっと思いつく限りでは例えば、

1. カラーパレットに受け渡す指定カラーの配列を受け渡し直前でデータベースに保存。
2. 保存された配列と次回以降受け渡される配列の差分をチェック。
3. 差分が抽出された場合は新たな配列を2世代目として保存し、保持されている全ブロックのカラーパレット用attributeを書き換え。

といった形で実装する必要があると思います。

slugの値からカラーコードに変換する処理を施してして、Settingsのvalueに割り当てるということでしょうか。

公式ブロックではそうなっています。
クラス名の選択に用いられるカラーパレットで保持されるattributeはスラッグのみとなっています。

ここまでの返信にある要点をコードに沿ってまとめておきますと、

まずカラーパレットに受け渡す配列は、add_theme_support→get_theme_support→エディターへの設定値受け渡し用配列内に格納→エディター側へ受け渡し...という流れになっていますが、ここまでにグローバル変数やフック等いくつかの変更ポイントがあります。

add_theme_support関数は基本的にテーマで用いられるものなので、カラーパレットの色をカスタマイズするプラグインなどで変更が行われるのはadd_theme_support関数以外のポイントが一般的です。

なので、

getCurrentColorSlugでカラーコードをスラッグ化する際に、Cocoon側で出力する指定カラー（helpers.js#L75）を用いていますが、これだと'block_editor_color_palette_colors'フックで変更されるカラーにしか対応できない

#post-23226とあるように、Cocoonユーザーによる自作カスタマイズ以外でそういったプラグイン等を用いると、今のコードでは「色を設定したのにCocoonブロックのカラーパレットには反映されていない」不具合が出てきます。

カラーパレットに受け渡すカラー指定の配列ではスラッグとカラーコードが1対1の関係なので、カラーコードを変更してもスラッグとの関係は1対1なのが継続される形が正しい挙動です。

#post-23090とあるように、次にカラーパレットが配列を受け取った後を追う必要があります。

get_cocoon_editor_color_palette_colors関数でも記述している通り、配列にはname,slug,colorの3つがひとまとめの配列として格納されており、個々のカラー設定に用いられます。
そのうちのnameは別の表示用コンポーネントに入れるためだけに用いられているので、実質slugとcolorを1対1で見るだけでいいと言えるかと思います。

カラーパレットではカラーバリエーションを減らしても、減らしたカラーが反映されなくなるだけでエラーは出ないよう設計されている

#post-23085とあるように、スラッグベースのattributeに対応するクラス名を入れる形に修正しておけば、後はそのクラス名にスタイルが指定されている限り表示上反映され続けることができます。
（attribute: slug⇔classNameの関係については今の修正時点で問題なく動作しているようです。）

となると、残るはslugに対するcolorになるわけですが、ここまでまとめた要点からやはり公式と同様にカラーパレットのattributeはスラッグに揃えるのがシンプルな修正方法と考え、公式でもカラーパレット周りの各種コンポーネントや関数が整備されていることもあって、公式ブロックの実装方法に倣うことを提案した次第です。（#post-22747）

新ブロック側のattributesにも'color'が残ってしまっており、旧'color'⇒新'slug'に揃える必要があります。

'color'に入るカラーコードはカラーパレットの指定カラー変更で意味をなさなくなるものであり、これを残したまま用いていると正しく動作しない箇所が出てきます。
deprecatedの migrate時に'color'は削除し、新ブロックでは用いない形が一番分かりやすいと思います。

は残る問題点と公式ブロックの実装とを比較した内容なので、他に解決できる書きやすい方法があれば、それでも構いません。

#post-23226とあるように、Cocoonユーザーによる自作カスタマイズ以外でそういったプラグイン等を用いると、今のコードでは「色を設定したのにCocoonブロックのカラーパレットには反映されていない」不具合が出てきます

これは、スルーしているわけではないんです。
それについては現在重々承知しています。返信せず申しわけないです。
ただ僕の現在の理解力で、複数進行するとこんがらがってしまいそうだったので、とりあえず1つずつと思っていました。
とりあえずは、こちらを修正してからそちらに取りかかろうと思っています。

>slugの値からカラーコードに変換する処理を施してして、Settingsのvalueに割り当てるということでしょうか。
公式ブロックではそうなっています。
クラス名の選択に用いられるカラーパレットで保持されるattributeはスラッグのみとなっています。

>slugの値からカラーコードに変換する処理を施してして、Settingsのvalueに割り当てるということでしょうか。
公式ブロックではそうなっています。
クラス名の選択に用いられるカラーパレットで保持されるattributeはスラッグのみとなっています。

これについては、以下のようにgetCurrentColorCode関数を作成して対応してみました。
https://github.com/yhira/Cocoon-Blocks-embed/blob/a6bb5a2083ec949df00e93e62845029a7c56cc3d/src/block/button/block.js#L117

次は、カラーパレット取得方法の部分に取り掛かります。

カラーパレットの取得方法をこちらを用いたものに変更しました。

// 設定したカラーパレーットを読み込む
const colors = select('core/editor').getEditorSettings().colors;

https://github.com/yhira/Cocoon-Blocks-embed/blob/b8a14e621fa25d5b63c3190b9b4905924dbabf20/src/block/button/block.js#L52

https://github.com/yhira/Cocoon-Blocks-embed/tree/deprecated-blocks

確認しました。

block.js#L58、helpers.js#L77、helpers.js#L87などでデフォルト値を固定していることで問題が生じています。

1. attributeに保持中のスラッグに該当する指定カラーが見つからない場合、保持されたスラッグを無視してデフォルト値を返してしまうこと。
2. 'key-color'がない状態で新たにカラーパレットを設定しようとした場合、存在しないデフォルト値を返してしまうこと。

スタイルで事前にデフォルト（カラー設定がない状態）でのカラーを用意しておき、ブロック上ではデフォルト値を用いないなどの修正が必要かと思います。

その他に、

今回は、スタイルの統一のため、擬似要素を使ったまま修正しようと思いますが、次回新しいブロックを作るときは、全てHTML要素で作るようにしようと思います。

#post-22848とのことから、インラインスタイルを当てはめない既存のCocoonブロックのみなら独自の部分が含まれていてもよいかと思っていたのですが、今後新たにカラーパレットを用いるブロックの作成を視野に入れて考えた場合、公式ブロック通りに統一した方が整合性を保ちやすいのではないかと、色々と独自の関数が増えてきたので思いました。

text-color,background-color,border-color...と各種カラー用スタイルを用意し、スタイルに合わせたクラス名を当てはめていった方が管理しやすく、スタイルも統一できます。
また、カラーパレットコンポーネント周りに仕様変更や機能拡張等があったとしても、1通りの変更で済みます。

もちろん、

他に解決できる書きやすい方法があれば、それでも構いません。

と申した通り、テーマを管理するのはわいひら様であり、一番はバグが出ない形でご自身が読みやすい・理解しやすいコードだとは思うので、最終的な判断はお任せします。

ただ、

僕の現在の理解力で、複数進行するとこんがらがってしまいそうだったので、とりあえず1つずつと思っていました。

とおっしゃっていることから、バグの解決が困難な場合は公式の実装例に従って、用意されているコンポーネント等をそのまま用いた方がよいのではないかとも思っております。

また、個人的な意見になってしまいますが、独自実装が増えれば増えるほどチェックする負担も増します。

チェック作業は前回の返信でまとめた流れで最初から一貫しており、指定カラーの配列に対応するGutenbergエディタ上でのカラーパレットの挙動を見るだけですが、不具合が出る場合はコードにある不具合要素を洗い出さなければならず、独自実装が増えるほど公式のコードと二重で確認する箇所が増えるからです。

バグのない実装やチェック作業等が難しいようでしたら、公式の実装に従っていただけると助かります。

用意されているコンポーネント等をそのまま用いた方がよいのではないかとも思っております。

これは、setBackgroundColor的なものを利用して実装するということでしょうか。
https://github.com/WordPress/gutenberg/blob/5774046c216a96d95fcbcfd2903b74f5f69a0611/packages/block-library/src/paragraph/edit.js#L138

そうですね、attributeにはスラッグのみを保持しつつ、カラーパレットの設定をHOCで制御する形です。
ContrastCheckerやインラインスタイル指定は後からでも付け足せるので、カラーパレット部分は共通の仕様に揃えておいた方が結果的には楽ができそうな気がします。

現状で公式とは別の仕様の実装をした場合、後から不具合が見つかるとまたカラーパレットがある全ブロックの実装方法を見直さないといけなくなります。

また、スタイルについても修正以前（＝旧エディタ）に統一するか、修正後（＝Gutenberg）に統一するかを考えたときに、サポート期限があと2年程度の旧エディタに統一した方がメリットがあるのかは少し疑問に感じています。
例えば、Gutenberg有効化の設定値から後方互換性を持たせた形で旧エディタ用コードはまとめ、サポート終了時点で切り離せるようにしていった方が長期的には管理しやすいのではないかと。

HOCという言葉も初めて知ったぐらいなので、とりあえず検索してみて、とにかく手軽に使えそうなサンプルコードがないかあさってみました。

この手法で良いのかもわかっておらず、完全ではないですがとりあえず（エラーが出ず）動くものをと、composeでwithColorsを利用するサンプルコードを書いてみました。
https://gist.github.com/yhira/a740a1db00e7d5b1224c1994b648149d

とにかく、とりあえずカラーパレットから色を選択（変更）したらsetBackgroundColorによって、backgroundColor.colorとbackgroundColor.classが取得出来ればと試してみました。

ただ、カラーパレットで色を選択すると、backgroundColor.colorはセットされるのですが、backgroundColor.classがセットされない…。

console.log(backgroundColor);で出力させてみても、添付画像のようにcolorはセットされても、classはundefinedになってしまいます。

これは、何か書かなければならないコードが足りないのでしょうか。

また、スタイルについても修正以前（＝旧エディタ）に統一するか、修正後（＝Gutenberg）に統一するかを考えたときに、サポート期限があと2年程度の旧エディタに統一した方がメリットがあるのかは少し疑問に感じています。

スタイルについては、どちらの手法になるとしても、has-text-color, has-slug-colorとかhas-background, has-slug-background-colorにブロックは統一して使おうと思っています。

ぱっとコードを見ただけで動作確認はしていませんが、カラーオブジェクト以外の部分はきちんと動作しているのであれば、#file-onecolumnblock-js-L119や#file-onecolumnblock-js-L126でカスタムカラーを指定しているからだと思います。

withColorsはカラーパレットにデフォルトで受け渡している指定カラー配列と比較を行うため、マッチしないカスタムカラーでは正しいオブジェクトが取得できません。

カスタムカラーを削除し、他のブロックと同じようにデフォルトのカラーにするとオブジェクトを取得できるかと。

https://notepad.pw/code/ev6twtd2y

確認してみてください。

カスタムカラーパレットをコメントアウトして動作確認してみました。
すると、しっかりとすべての情報がオブジェクトに反映されました。
僕だと、原因に気づけなかったです。ありがとうございます！
自分用のメモがてら修正版を載せておこうと思います。
https://gist.github.com/yhira/048af61215f2c0d2df66238fad724ff8

そしたら、Cocoonのブロック群もこの要領で変更していこうと思います。
とりあえず、ボタンから修正してみます。

遅くなりましたが、ボタンブロックを実装してみました。
https://github.com/yhira/Cocoon-Blocks-embed/blob/deprecated-blocks/src/block/button/block.js
できるだけ、Gutenbergの仕様に合わせて書いてみたつもりです。

ただ、deprecatedの動作確認をしていて、1つだけ僕にはどうしてもわからない問題が出てきました。
それは、migrateでボタン配置情報を引き継ぐ方法です。
これまでは、attributesには、配置情報を入れずとも設定は保存されていたので特に何もしていませんでしたが、今回deprecated部分で、どうしても引き継ぐ方法がわかりませんでした。
https://github.com/yhira/Cocoon-Blocks-embed/blob/8b8002ee6a2c9f5b159aa8b725cbdb5314fbafc4/src/block/button/deprecated.js#L54
なにか、配置情報をmigrateする良い方法をご存知でしたら、お知恵を貸していただければ幸いです。

deprecatedが実行される前の旧ボタンブロックではこのように表示されます。

けれど、deprecated後では、配置が元に戻ってしまいます。
この情報を引き継ぐ方法が、いろいろ調べてみたのですが、ちょっとわかりませんでした。

実際に動作を確認したわけではないので、deprecatedにあるコードに沿って確認します。

まずボタンブロックの配置設定をした場合にdeprecated上のsaveは動作していますか？
具体的には、旧ブロックで記述されているマークアップがdeprecatedのsaveとして処理され、consoleにdeprecated時のエラーが表示されているか確認してください。

もし、エラーが吐き出されているのであれば、deprecatedのsave部分についてはおそらく問題ないかと思われます。
（deprecatedでもalignがsupportされているので、saveに関する問題点は今のところ思い当たりません。）

そして、問題はおそらくmigrate部分です。

Gutenbergでは、alignがsupportされているかどうかを判定し、されていればフックを通してalignの処理を行う仕組みになっています。
saveにはフックがありますが、migrateにはないと思うので、migrateでの引き継ぎにalignを加える必要があるかと。

なので、deprecatedのattributesにalignの定義（type: 'string'）を加え、migrateの返り値に含める形で実装すれば引き継がれるのではないでしょうか。

ちょっと体調不良で返信が遅れ申しわけないです。

もし、エラーが吐き出されているのであれば、deprecatedのsave部分についてはおそらく問題ないかと思われます。

こちらに関しては、添付画像のようにエラーメッセージが表示されているようです。

なので、deprecatedのattributesにalignの定義（type: 'string'）を加え、migrateの返り値に含める形で実装すれば引き継がれるのではないでしょうか。

ありがとうございます！
こちら、これからやってみようと思います。

おお！ありがとうございます！
引き継がれました！

一応、メモ的な意味も含めて修正点も貼り付けておきます。
https://github.com/yhira/Cocoon-Blocks-embed/commit/95edf250d68ac94bedd49c92535dd616b624fc66

これで、おそらく不明部分がなくなったので他のブロックにも適用していこうかと思います。
こんな引き継ぎ方法があるとは…、僕だとGutenbergから読み取れませんでした。
教えていただき、ありがとうございます！

一応、以下のブロックは対応させてみました。

1. 吹き出し
2. 白抜き
3. ボタン
4. 囲みボタン
5. アイコンリスト
6. タブボックス
7. タイムライン
8. トグルボックス
9. 見出しボックス
10. ラベルボックス
11. タブ見出しボックス
12. マイクロバルーン
13. マイクロテキスト

https://github.com/yhira/Cocoon-Blocks-embed/tree/deprecated-blocks