WordPress 7.0では、新しいリビジョン画面である「ビジュアルリビジョン」が導入されました。従来のテキスト中心のリビジョン画面とは異なり、実際の投稿に近い見た目で変更点を確認できる機能として期待されています。
しかし、開発中に見つかったある不具合により、一部の環境ではビジュアルリビジョンが自動的に無効化される仕様となりました。一見すると「新機能を制限しただけ」のようにも見えますが、実際にはユーザーのデータを守るための重要な設計判断でした。
この記事では、実際のGitHub上のやり取りをもとに、WordPress開発者が知っておきたいポイントを整理します。
- 1. 「ビジュアルリビジョン」とは（おさらい）
- 2. 本題：バグ報告と対策の顛末
- 2.1. GitHub上の記録
- 2.2. Issue #78130 で見つかった問題
- 2.3. PR #78249 で行われた対応
- 2.4. 開発チームが優先したもの
- 3. なぜ「修正」ではなく「無効化」だったのか
- 3.1. 投稿本文とメタデータは別管理
- 3.2. 保存処理がプラグインごとに異なる
- 3.3. 補足：なぜ従来のリビジョン画面なら動くのか
- 4. 今後の開発における影響など
- 4.1. プラグイン開発への影響
- 4.2. テーマ開発への影響
- 4.3. 将来的にはどうなるのか
- 4.4. このPRから学べること
- 5. おわりに
- 6. 参考情報：事象が起こるプラグイン・テーマ（一例）
- 6.1. プラグインの一例
- 6.2. テーマの一例
「ビジュアルリビジョン」とは（おさらい）
WordPressにおいてはリビジョン機能がありますが、従来はテキスト中心の比較でした。クラシックエディター時代はそれでも十分だった時期もあったようです。
ブロックエディター（Gutenberg）時代になると、画像やブロック構造等の視覚的変更の度合いが圧倒的に増えていきました。一方で、従来のリビジョン比較では、コードばかりが表示され、変更点が分かりにくいことがありました。
7.0では「ビジュアルリビジョン」の仕組みが導入され、視覚的な差分確認がしやすくなり、誤編集の発見が容易になりました。
本題：バグ報告と対策の顛末
GitHub上の記録
- Visual Revisions fail to restore meta controlled by Classic Meta Boxes · Issue #78130 · WordPress/gutenberg
- Editor: Disable Visual Revisions when classic meta boxes are present by ellatrix · Pull Request #78249 · WordPress/gutenberg
Issue #78130 で見つかった問題
問題となったのは、ビジュアルリビジョンから投稿を復元した際の挙動です。
例えば、投稿に次のような情報が保存されていたとします。
- 投稿本文
- ブロックの内容
- ブロックエディターのサイドバーで管理しているメタデータ
- 旧仕様のメタボックスで管理しているカスタムフィールド
ビジュアルリビジョン経由で過去のリビジョンへ戻すと、以下のような結果になっていました。
| 項目 | 復元結果 |
|---|---|
| 投稿本文 | ○ |
| ブロック | ○ |
| ブロックエディター側のメタ情報 | ○ |
| 旧仕様のメタボックスのメタ情報 | × |
つまり、「投稿本文は昔の状態なのに、カスタムフィールドだけ最新のまま」という、一部だけ復元されない状態になってしまいます。これはユーザーから見ると非常に分かりにくく、データの整合性を損なう恐れがあります。
PR #78249 で行われた対応
この問題に対し、今回のPRでは復元処理そのものを修正するのではなく、ビジュアルリビジョンを無効化するという対応が採られました。
具体的には以下のようなフローになっています。
旧仕様のメタボックスが存在するか確認
│
├─ ない
│ ↓
│ ビジュアルリビジョンを使用
│
└─ ある
↓
従来のRevision画面へ切り替えるつまり、旧仕様のメタボックスが一つでも登録されている投稿では、新しいビジュアルリビジョンは利用されません。
開発チームが優先したもの
今回のPRでは、開発チームが最優先したのは「新機能」ではなく「データの安全性」でした。
もしビジュアルリビジョンをそのまま公開すると、利用者は「リビジョンを復元した」と思っていても、実際には「SEO設定」「カスタムフィールド」「独自プラグインの設定」などが最新値のまま残る可能性があります。これは非常に危険です。
そこで、「完全に対応できるまでビジュアルリビジョンは使わせない」という方向性で進められることとなりました。品質を重視した決断と言えるでしょう。
なぜ「修正」ではなく「無効化」だったのか
一見すると「そのままバグを修正すればよいのでは？」と思うかもしれません。
しかし、この問題は見た目以上に難しいものです。
投稿本文とメタデータは別管理
WordPressでは、投稿本文とpost_metaは別々に保存されています。さらに、旧仕様のメタボックスは、save_postなどPHP側の処理で自由に保存できます。
一方、ブロックエディター側のメタは「REST API」を通して管理されています。
つまり、旧仕様のメタボックスは「PHP」ベース、ビジュアルリビジョンは「REST API」ベース、という異なる仕組みの上で動いています。
保存処理がプラグインごとに異なる
さらに難しいのは、旧仕様のメタボックスでは、以下のような様々な処理が実現できるという点です。
- 独自バリデーション
- 独自保存処理
- 独自の権限チェック
- 独自フック
つまり、旧仕様のメタボックスと一言で言っても、実際には何千通りもの保存方法があります。あまりに複雑すぎるため、ビジュアルリビジョン側ですべて再現するのは容易ではありません。
補足：なぜ従来のリビジョン画面なら動くのか
従来のリビジョン画面では、WordPressコアが以前から提供している「メタデータの復元処理」「リビジョン管理API」が利用されています。
長年運用されてきた仕組みであり、旧仕様のメタボックスとの互換性も考慮されています。そのため、従来のリビジョンでは問題なく復元できます。
今後の開発における影響など
プラグイン開発への影響
今回の変更で影響を受ける可能性があるのは、1つには、旧仕様のメタボックスを利用しているプラグインです。
例えば、「SEOプラグイン」「カスタムフィールド系プラグイン」「独自管理画面を持つプラグイン」などを有効化している場合、ビジュアルリビジョンではなく従来のリビジョン画面が表示される場合があります。
これは不具合ではなく、安全のための仕様です。
テーマ開発への影響
テーマでも、functions.phpなどでadd_meta_box()を利用している場合は同様です。
例えば、「SEO入力欄」「OGP設定」「サムネイル補助設定」「ランディングページ用設定」などを旧仕様のメタボックスとして実装している場合、ビジュアルリビジョンは利用できません。
将来的にはどうなるのか
WordPressは現在、REST APIを中心としたデータ管理へ少しずつ移行しています。
カスタムフィールドもregister_post_meta()で登録し、show_in_rest => trueを設定することで、ブロックエディターとの親和性が高まります。
もちろん、旧仕様のメタボックスがすぐに廃止されるわけではありません。しかし、今後の新機能はREST APIを前提に設計されるケースが増えると考えられます。
そのため、特に新規の開発においては、「REST API」「ブロックエディター（Gutenberg）」「Entity API」などを意識した設計が望ましいでしょう。
このPRから学べること
「PR #78249」は単なるバグ修正ではありません。WordPressコア開発チームが「新機能よりもデータの正確性を優先する」という姿勢を示した事例と言えます。
開発者としては、次のような点を意識するとよいでしょう。
- ビジュアルリビジョンは、旧仕様のメタボックスとの完全な互換性が保証されるまでは利用が制限される場合がある。
- 旧仕様のメタボックスを使用している場合、従来のリビジョン画面へ自動的に切り替わるのは正常な挙動である。
- 新規開発では、
register_post_meta()やshow_in_restを活用し、REST APIを前提とした設計を検討すると将来の互換性を高めやすい。 - 新しいエディター機能を利用する際は、「投稿本文だけでなくメタデータも正しく保存・復元されるか」という観点でテストを行うことが重要である。
おわりに
WordPressは後方互換性を非常に重視するCMSですが、新しいブロックエディター関連機能の開発では、従来の仕組みとの橋渡しが大きな課題となっています。
「PR #78249」は、その橋渡しが完全に実現するまでの「安全策」として実装されたものです。新機能を無理に提供するのではなく、データの信頼性を最優先に考えるというWordPressコアチームの設計思想を理解するうえで、非常に参考になる事例と言えるでしょう。
