カテゴリーで言えば、この部分ですよね。
https://github.com/yhira/cocoon/blob/24a428b1988a0126f60c3d7b547f3216061bed20/lib/content-category.php#L18
https://github.com/yhira/cocoon/blob/24a428b1988a0126f60c3d7b547f3216061bed20/lib/content-category.php#L31
https://github.com/yhira/cocoon/blob/24a428b1988a0126f60c3d7b547f3216061bed20/lib/content-category.php#L235

wp_postmetaのmeta_key'the_page_noindex'で例えるとすると、キーがthe_page_noindex_{post_id}になっているということですね。
だとしたら、意味のないID指定ですよね。

うーん、どうしよう…。
とりあえず、category_metaをキーにして保存もしておいて、読み込み時category_metaキーで読み込めない場合は、category_meta_{term_id}も取得して値を読み込むようにしたほうが良いのだろうか。
余計な処理は増えるけど、その方が後々分かりやすいような気がする。

はい、挙げられたコードの部分です。

wp_termmetaには、単体のデータとしてterm_id・meta_key・meta_valueがセットで保存されており、get_term_meta関数はひとつのterm_idとmeta_keyから特定のmeta_valueを取得してくる一方、WP_Term_Queryクラスのmeta_queryは指定したmeta_key（とmeta_value）にマッチするterm群を取得してくるよう実装されています。
meta_keyがterm_id毎に独立してしまっていることにより、共通条件のクエリでは取得できません。

typeパラメータやcompareパラメータでmeta_valueを条件指定できることまで考慮すると、個別のメタ情報におけるmeta_valueはなるべく整理してシンプルにしておくのがよさそうなので、私がカスタマイズで新たに加えた箇所は取得データが1対1となるように切り分けて保存する形にしました。
Cocoonの例で言うと、カテゴリ色でひとつ、タイトルでひとつ…といった感じです。

現在のデータに修正を加えるのであれば、保存する際（save_extra_category_fileds関数）は新たに整理した形のタームメタに保存するようにし、取得する際（get_category_meta関数）は新タームメタ⇒（データがセットされていない場合のみ）旧タームメタになりそうですね。
メタ情報を切り分ける場合は、save_extra_category_fileds関数での保存時に$_POST['cat_meta']を要素ごとに繰り返しupdate_term_metaすることで対応可能です。

今回、IDごとにキーを指定しているのと、配列で保存しているという2つの問題点がありますね…。
なんでこんな仕様にしてしまったんだか…。結構昔なので全部覚えてないです。
多分、あまり深く考えないでやってしまったんだと思います。

私がカスタマイズで新たに加えた箇所は取得データが1対1となるように切り分けて保存する形にしました。

よろしければ、content-category.phpコードをnotepad.pw等で、見せていただいて、命名とコードなどを参考にさせていただくことは可能でしょうか。

追記：とりあえずブランチ側で修正しました。

wp_postmetaに命名を合わせて、色だったらthe_category_color, the_category_text_colorとかにした方が良いのかもしれませんね。

とりあえずは、こちら側でブランチを切って修正してみようと思います。

とりあえず、こんな感じで修正してみました。
https://github.com/yhira/cocoon/commits/save_extra_category_fileds
https://github.com/yhira/cocoon/commit/324bda0dec5aff26f986869caf457f064403307c
これで、以前の保存情報取得できつつも、新しいwp_termmetaに保存できるようになったのではないかと思います。
もう少し、動作確認してみてタグの方も修正しようと思います。

ぱっと見た感じでは問題なさそうなので、とりあえずテストして詳しく確認してみようと思います。

問題が起こらない限りは修正の必要はありませんが、

私がカスタマイズで新たに加えた箇所は取得データが1対1となるように切り分けて保存する形にしました。

について、一応私の命名やコードを書いておきます。

命名については、私は主なカスタマイズはアップデートしやすいようにプラグインにまとめているため、meta_keyは[プラグイン名]_[キー名]といった感じで命名しており、基本的にCocoonの仕様が変更されても問題ありません。

save_extra_category_fileds関数での保存時に$_POST['cat_meta']を要素ごとに繰り返しupdate_term_metaする

コードについては、上記の説明をコードにしておけばよかったのですが、name="example[meta_key]"と配列のままで送信し、$_POST['example']をもとにforeach内で繰り返しupdate_term_metaする形にしました。

以前のCocoonからだと、

function save_extra_category_fileds( $cat_id ) {
  if ( isset( $_POST['cat_meta'] ) ) {
    $keys = array_keys( $_POST['cat_meta'] );
    foreach ( $keys as $key ) {
      update_term_meta( $cat_id, $key, $_POST['cat_meta'][$key] );
    }
  }
}

のような形と言えます。
その他は修正版のコードとおよそ同じ形になっています。

ご確認と、コードありがとうございます。
今のところ、僕の環境でいろいろ動作確認しても問題ないので、タグ部分も変更してみようと思います。

修正したらまた書き込みます。

一応、タグも修正しておきました。
https://github.com/yhira/cocoon/commits/save_extra_category_fileds
https://github.com/yhira/cocoon/commit/a18b4a369ee6f1645b61eb54200390469f51a92d
これも、とりあえず動作確認した限りでは、大丈夫そう。

カテゴリー・タグそれぞれの動作をざっと確認した限りでは問題なさそうです。

アプデ後の利用者向けに書き加えておくと、各フィールドの値を取得するのにget_term_meta関数から各々のメタ情報を取得する関数に置き換えたことで、タイトルを設定するフィールドの初期値にカテゴリー名が入るようになったのが変更点といったところでしょうか。
実際の動作に影響はありません。

最終的に不要になった旧メタ情報については、delete_term_metaなどで削除処理を加える予定はありますでしょうか？
なさそうであれば、本件の実装に合わせて自分で処理を加えようと思いますが。

タイトルを設定するフィールドの初期値にカテゴリー名が入るようになったのが変更点といったところでしょうか。

これは、意図しないものでした。未入力の場合はカテゴリー名が入らないように修正しました。
あと、新しい値に空欄を入力したときに、反映されない不具合があったので修正しておきました（今のところカテゴリーのみ）。
https://github.com/yhira/cocoon/commit/85fab2937953591dc68103c921c0fb08ae2aa027
加えて、一応、古い配列の値も設定を保存するようにも変更しました。新しい値と、古い値が別々だと、ややこしいような気もして。

最終的に不要になった旧メタ情報については、delete_term_metaなどで削除処理を加える予定はありますでしょうか？

今のところ新しいキーにデータが保存してない場合は、旧データ（get_the_category_metaで読み込んでいる配列）を読み込む必要があるのと、あっても負荷はそこまで変わらないと思うので、今のところ削除は考えていません。

すいません。上記のものは、旧データを読み込まない不具合がありました。

現在修正中です。

一応修正はしてみたものの、これだとget_term_metaを読み込んだ後、空欄だったらget_the_category_metaをもう一度読み込む必要があるのが、ちょっと気持ち悪い。
https://github.com/yhira/cocoon/commit/847a5b1db405e12c28f8b00b8770194d529e2830
とりあえずの修正。

よく見たら、get_metadata→get_metadataで失敗したときの返り値がflaseに限定されていたわけではないっぽいのが原因だったかも。
https://developer.wordpress.org/reference/functions/get_term_meta/
https://developer.wordpress.org/reference/functions/get_metadata/

これじゃ、このように書くとダメな場合もあるのかも。

function get_the_category_color($cat_id = null){
  $res = get_term_meta( $cat_id, 'the_category_color', true );
  if ($res !== false) {
    return $res;
  } else {//旧バージョン対応 

get_term_metaは実際にはget_metadataが処理しているので、meta_keyの有無にかかわらずsingleパラメータがtrue→空文字、false→空配列を返す形になっています。
その代わりに、meta_keyの有無を確認する方法としてmetadata_existsが存在します。

最終的に不要になった旧メタ情報については、delete_term_metaなどで削除処理を加える予定はありますでしょうか？

私が上記の確認を行ったのは「不要なデータは削除してデータベースを見やすく整理すべき」との考えもありましたが、term_meta関数の仕様も考えてのことでした。

空欄で更新を行った際の不具合については見落としていましたが、旧データと新データを混在したままで取り扱おうとすると、やはり少し複雑になってしまいます。

最初の修正版での動作から、

1. 既存のカテゴリー編集画面を開く
2. 旧データから各フィールドの設定が読み込まれる
3. 適宜編集したあとに更新を行う
4. 編集内容が新メタデータとして格納される

となっているので、4のedited_term時点で該当するterm_idに紐づく旧データは少なくとも必要なくなります。
よって、更新に合わせてこの旧データのみdelete_term_metaを使用しても問題なさそうと思いました。

旧データから新データに移行するためにupdate_term_metaとdelete_term_metaを使用するタイミングはedited_termでなくてもよいですが、新旧両方のデータが混在し続ける形で考えるのではなく、何らかの動作を区切りに新データのみを扱う形に切り替える方向で考えた方が各コードの動作を複雑化しなくて済むのではないでしょうか？

1. get_the_category_metaで旧データを取得する
2. 旧データ配列内の各要素を新データのmeta_keyに対するmeta_valueに入れる
3. 新データについてupdate_term_metaを行う
4. 旧データについてdelete_term_metaを行う

この一連が動作するポイントは、各ターム編集画面の更新時に個別だろうとアプデ後のテーマ読み込み時に一括だろうと、動作する箇所であればどこでもOKだと思います。

この動作を区切りとして、区切りより前は

• 旧データのmeta_keyは存在する
• 新データのmeta_keyは存在しない

区切りより後は

• 旧データのmeta_keyは存在しない
• 新データのmeta_keyは存在する

といった感じで判断材料にできます。

すると、旧データに対するコードと新データに対するコードを切り分けることができ、最終的に不要なデータが残ることもありません。

metadata_existsの存在を知りませんでした。
それを使用して、判定するように変更しました。
https://github.com/yhira/cocoon/commit/d81bdcb3eb0e8ddcbd487ec1ff12085bb9cf39f2

何らかの動作を区切りに新データのみを扱う形に切り替える方向で考えた方が各コードの動作を複雑化しなくて済むのではないでしょうか？

よくよく考えたら、edited_term時、新しい値を保存したのであれば、古い配列の値をわざわざ新しくして保存する必要もなく、削除してしまえば良いですよね。
削除するように変更しておきました。
https://github.com/yhira/cocoon/commit/39dfea27246419daa1d19ec900d13fe813ceaaa7

タブを開いたままだったので上の書き込みは、こちらの書き込みに気づかないまま記入しました。
ただ、おそらく同様のことはできたのではないかと思います。

改めて修正後のテーマをインストールし、チェックしてみました。

function get_the_category_title($cat_id = null, $is_cat_name = true){
if (term_metadata_exists($cat_id, 'the_category_title')) {
return get_term_meta( $cat_id, 'the_category_title', true );
} else {//旧バージョン対応
$meta = get_the_category_meta($cat_id);
if (!empty($meta['title'])){
return $meta['title'];
} else {
//タイトルが存在しない場合はカテゴリ名を利用する
if ($is_cat_name) {
return get_category($cat_id)->name;
}
}
}
}

カテゴリータイトルの取得について、'the_category_title'に移行後のタイトルは無条件でreturnしてしまっているため、空の場合に一部カテゴリー名が表示されません。

function get_the_category_content($cat_id = null){
if (term_metadata_exists($cat_id, 'the_category_content')) {
return get_term_meta( $cat_id, 'the_category_content', true );
} else {//旧バージョン対応
if (!$cat_id) {
$cat_id = get_query_var('cat');
}
$meta = get_the_category_meta($cat_id);
if (!empty($meta['content']))
$content = $meta['content'];
else
$content = category_description($cat_id);
}
$content = wpautop($content);
$content = apply_filters( 'the_category_tag_content', $content );//カテゴリー・タグ本文共通
$content = apply_filters( 'the_category_content', $content );
return $content;
}

同様に、カテゴリー本文についても無条件でのreturnによりコンテンツの整形が行われません。

ありがとうございます。

カテゴリータイトルの取得について、'the_category_title'に移行後のタイトルは無条件でreturnしてしまっているため、空の場合に一部カテゴリー名が表示されません。

タイトルが空欄の場合、公開ページで通常のカテゴリ名が必要な場合に、空文字になる恐れがありますね。
双方とも、修正しておきました。
https://github.com/yhira/cocoon/commit/7fc3a167c8cc6071e83237b098b2ae7c72c94e1d

タグ部分も修正しておきました。
https://github.com/yhira/cocoon/commit/adb1ccfaa027566a6de8c592a8785acac8207141
https://github.com/yhira/cocoon/commit/32344b041ccef74a98e4359094959f337916840f

確認した限りでは、今のところその他に大きな問題は確認されません。
特に問題なさそうでしたら、アップデート内容に加えても大丈夫なのではないでしょうか。

修正ありがとうございました。

僕もいろいろ確認してみた限りでは大丈夫そう。
とりあえずmasterにはマージしてプシュしておきました。
ご確認と、ご助言ありがとうございます！