WordPressSynch
From MWWiki
Contents |
WordPress Synchronizer
Using XML-RPC to Synchronize two Blogs
Overview
This web application sits in between two WordPress blogs, synchronizing their entries through the WordPress implementation of XML-RPC.
Description
This project has gone through several phases.
Phase I: The first phase was extremely rudimentary and did not use XML-RPC at all. Instead, it assumed one WordPress installation was local and the other was remote. It would perform hard queries to the local database, retrieve all the entry attributes (restrictions to be discussed soon), and loaded them into a form that would then post to a symmetric form on the remote server. That remote form would collect the fields submitted and insert them into the remote database. This was a very fragile and un-scalable implementation; there was no two-way communication. As such, determining which entries to send to the remote server depended entirely on a comparison of timestamps: any entries posted since the last synchronization would be sent to the remote server. If an error occurred, there would be no way to track that the entries had not successfully (or, perhaps fully) been synchronized with the remote server. Furthermore, the implementation depended on a static database implementation, as well as identical database schemas between the local and remote servers, presenting issues if either WordPress installation was upgraded.
Phase II: This utilized XML-RPC to open up a two-way channel of communication between the remote and local servers. The application still made the assumption that one server was local (and would query the database for entry information), but would send XML-RPC requests to the remote server to determine which entries should be sent. Scalability, however, continued to be a problem. The WordPress XML-RPC implementation does not include a lightweight method for simply ascertaining entry IDs; as such, in order to fully synchronize (and allow for synchronization customization), the basic attributes of every single entry on the remote server had to be retrieved, incurring a cost directly proportional to the number of entries. As a blog grew into the thousands of entries, this architecture became unwieldy and reached the point of failure.
Phase III: This involves a more robust implementation making use of the XML-RPC functionality, but this too proved unsatisfactory. More details about this phase can be observed from the notes and source listed below under Iteration 3.
Phase IV: The current fourth iteration involves completely encapsulating the functionality into an official WordPress plugin that interacts wholly with the WordPress application. Doing so enables the program to hook into the WordPress framework and make use of the impressive internal API without sacrificing the strength of the xmlrpc protocol. Every effort has been made to streamline the process by caching database queries and RPC results.
Status
Iteration 4: beta
Download
File structure:
Notes:
- The WordRPC class was once again rebuilt; static methods were removed, and more methods added to assist with Category synchronization.
- Synchronization when posting, editing, and deleting specific entries is functional, along with selective entry synchronization.
- Full one-time synchronization is still under development, primarily due to the intensive processing that has to take place to completely re-sync all entries (tests are being done using 3000+ entries; process takes upwards of half an hour between hosts on the same machine).
- FirePHP tiered debug system was also put in place, varying the verbosity of debug comments to the FirePHP console.
- Still need a more robust error-display system; FirePHP (with debugging at or above level 1) is currently the only way to be informed of an error. add_filter may be the answer.
Iteration 3: canceled
File structure:
- rpcuploader/
Notes:
- Only known serious issue involves failure to properly insert dummy entries upon synchronization, resulting in a breakdown of the overall communication protocol.
- Unfortunately, this is going to be a costly bug to fix, as it arose from the fundamental change in the communication philosophy. It relied on having access to each existing entry ID in order to determine where and how many dummy entries to insert. The solution will require querying the server for all entry IDs in between the last synchronized entry and the most recent entry to be synchronized, and filling in all needed dummy entries.
