同期用の個別のデータベーステーブルにカスタム投稿タイプ
私は、異なるサーバーに収容されている2つの異なるWebサイト間で同期をとる必要があるカスタム投稿タイプを持っています。どちらかのサイトが編集、挿入、または削除した場合、他のデータベースもその変更に合わせてデータベースを更新する必要があります。私が見ている問題は、IDが2つのデータベース間で相殺されるということです。
だから私の理論的根拠は、なぜ私は別のデータベーステーブルに格納するカスタム投稿タイプを作成して、2つのインストール間でその1つのテーブルを同期させることができないのですか？
私が見ている問題は、URLのような衝突を考慮に入れる必要があるということです。 URL site.com/hello-worldにアクセスすると、ページスラッグ "hello-world"とカスタム投稿タイプのスラッグ "hello-world"が表示されます。
誰かが私をある方向に向ける？
編集：もっと詳しく調べて考えてみましょう。 save_postで、それがTHEカスタム投稿タイプかどうかを確認し、他のデータベースに接続し、最後の挿入IDを作成し、それをローカルに保存してから、投稿の内部IDで外部データベースを更新しますか？
上記の詳細に基づいて、次のような提案が考えられます。
同じデータベースを使用している2つのサーバーがあるセットアップを作成します。両方の設定が互いに同一の場合、これは機能します。
データを同期します（オプション1）。両方のサーバーにインストールするプラグインを書くと、このプラグインは他のデータベースから定期的にデータを読み取り、それ自身のレコードを更新します。
データを同期します（オプション2）。データベース1のレコードを更新すると、2番目のインストールに送信されるREST API呼び出しをトリガーする機能を作成します。その後、その2番目のインストールはその呼び出しを介して最初のインストールから更新されたデータを受け取り、それ自身のレコードを更新します。
両方のインストールがアクセスできる中央データベースを作成します。この中央データベースには、両方のインストール用の共有データが含まれます。
WordPressのネットワーク設定を考えましたか（これがこの環境で機能するかどうかわからない場合は、これが要件に合うかどうかを判断する必要があります）。
個人的には、私は問題の私の理解に基づいてオプション3と4が好きですが、繰り返しますが、私はあなたがするように全体像を持っていません。
両方のWordPressインストールを接続するための別のテーブルを作成する場合は、データが正しいデータベースに送信されるように、カスタムの削除、編集、および追加機能を追加する必要があります。
これらのカスタム機能を作成する必要がある場合（カスタム投稿タイプの投稿、編集、削除などを行うためのさまざまな方法）、一方のサイトに 'master DB'を、もう一方のサイトにwpdbを使用して接続しないその他のDBとそれを取得、編集、投稿。一貫性はすべて1つのテーブルにまとめられているため、複雑な一貫性チェックは必要ありません。