Open bobbingwide opened 7 years ago
Well, it’s a long time since I raised this. The WordPress Block Editor ( Gutenberg) provides all the REST API methods we need to edit the master post, how easy would it be to hijack requests to run against a slave?
Alternatively, for a push, if the server detects that its posts time stamp is later than the master’s it could use the clone logic to return the payload.
Another option is to respond differently to a push. When a server detects that a post has been updated locally since it was last cloned then it should return the payload as if it were doing a push. This seems OK, the logic is available in both ends, but what is the client supposed to do with the updated version? Won’t this produce the equivalent of a merge conflict?
Well the problem here is that it’s too late. The updates in the server should have been reconciled with the client before new updates were pushed back to the server. So, the hijacking idea looks like a good idea. When content is edited then the editor will request it from each participating slave.
But it’s still very complicated and time consuming. Perhaps an easier approach would be to provide an admin interface to list the content that has been changed since it was cloned from a particular server and provide a simple pull, rather than push. See shortcode-example/most-recent-work for a starter for the query that would provide the list of posts to consider.
AJAX requests would be:
Where merge conflicts ( updates in both ends) have occurred then we’ll have to provide a method that allows the conflict to be resolved. Most likely a forced push... which is what happens at the moment anyway.
Requirement Allow modified post content to be copied back to the source from an updated slave.
Proposed solution Provide a facility on the Edit page to pull the latest version from the slave server, compare the content with the current and create a new revision if necessary.
Assume this can be easily achieved using the REST API.