プラグインの有無は分からないので、実装について考えてみます。
まず、リビジョンが保存されているwp_postsテーブルには、タクソノミーやカスタムフィールドの情報は保存されていません。もちろん、リビジョンではなく実体のある投稿データについても同様です。投稿にはpost_idが割り振られますが、リビジョンに付いても同様にpost_idが存在します。
投稿に関連づけられたタームが保存されているのはwp_term_relationshipsテーブルですが、object_idのカラムが投稿IDに該当します。また、カスタムフィールドが保存されているのはwp_postmetaテーブルですが、こちらのpost_idのカラムが投稿IDに該当します。
したがって、リビジョンの保存時にリビジョンのpost_idを使ってwp_term_relationshipsテーブルやwp_postmetaテーブルのデータを複製すれば、リビジョンにもタクソノミーやカスタムフィールドのデータは保存可能なはずです。
と、ここまではいつも考えていることです。concrete5ではページに関連するあらゆるデータのバージョン管理が可能なのに、なぜWordPressではできないのか…とずっと思っていましたので。
ただし、問題もいくつかあります。
１）リビジョンの画面ではタクソノミーやカスタムフィールドについて確認することができませんし、この画面はカスタマイズができない。
２）タームの利用数のカウントがおかしくなる可能性がある。リビジョンのpost_statusはinheritなので、問題ない気もするが…。
カスタムフィールドだけに限れば、Custom Field Suiteのアドオンで、このプラグインで作ったカスタムフィールドのデータをリビジョンに保存し、リビジョンから復旧した際にカスタムフィールドのデータも復旧する機能を持ったものがあります。
https://github.com/mgibbs189/cfs-revisions
これは、Custom Field Suiteプラグインが作成する独自テーブルにデータを保存するもので、コアとの機能の衝突を避けるには、別テーブルしかないのかなぁ〜と思っているところです。
コアトラックを見てみましたが、カスタムフィールドをリビジョンに含める件は開発が進んでるみたいです。
“Framework for storing revisions of Post Meta” https://core.trac.wordpress.org/ticket/20564
２年かかってまだやってるということは、なかなかハードルが高そうですね。タクソノミーについてはチケットは見つかりませんでした。
> Takuro Hishikawaさま
保存方法、問題点、それぞれ詳細に教えて頂いてありがとうございます！
コアへの実装も含め、なかなかハードルが高そうですね。
プラグインがリビジョン削除であったり、コントロール系が多いのもなんとなく頷けました。
カスタムフィールドの追加、はプラグインが多少検索で引っかかりますが、
別テーブルへ保存しているのですね・・・。なかなかそこまで読み込めず。
ともあれ、頂いた方法で実装方法を検討してみます！
本当にありがとうございました。トピックは解決済みとさせていただきます。
