I have a custom post type which needs to be in sync between two different websites housed in different servers. If either site edits, inserts, or deletes, the other database will also have to update its database for the change. The issue I see is, the ID’s will be offset between the two databases.
So my rationale is, why can’t I create a custom post type to be housed in a different database table and just sync that one table between the two installations?
The issue I see is I need to take into consideration the conflicts such as URL’s. Page slug “hello-world” and custom post type slug “hello-world” when accessing the URL site.com/hello-world .
Anyone point me in a direction?
Edit : Looking into it more and thinking about it. How about on save_post, check if it’s THE custom post type, connecting to the other database, and doing a last insert ID, store it locally, and then update the external database with the internal ID of the post?
Based on the details above, I can think of the following suggestions:
-
Create a setup in which you have two servers using the same database. This can work if both your setups are identical to each other
-
Sync the data (option 1). Write a plugin that you install on both servers, and this plugin will periodically read data from the other database and update its own records
-
Sync the data (option 2). Write functionality that, when you update a record in database 1, it will trigger a REST API call that is sent to the second installation. Then that second installation will receive the updated data from the first installation via that call, and update its own records.
-
Create a central database that both installation have access to, and this central database will contain shared data for both installations
-
Have you thought of WordPress network setup (not sure if this works in this environment, you have to decide if this fits your requirements)
Personally, I like options 3, and 4 based on my understanding of the problem, but again, I do not have the full picture as you do.
