One of the ways website creators produce content for their websites is to first use a staging environment to make that content before deploying the finished post or page to a live website. There are a couple of different ways to set up a 'staging' environment. One option is to use a bespoke facility on the webserver that hosts the live website, or alternatively, a 'staging' environment can be hosted locally on one's own 'server' in the form of a MAMP or XAMPP installation on a personal computer.
From an efficiency standpoint, it is usually better to use the bespoke staging environment provided by the live website host as changes can usually be deployed to the live environment relatively easily. However, from a security perspective, having a local copy of one's website that has never been exposed to the internet can be very useful. If a live website is ever compromised with malware and needs to be replaced with a clean copy, the local copy of the web property can often be used to replace the infected one. This makes the troublesome process of searching through an infected website for hidden malware unnecessary, although you still have to work out how the website was hacked in the first place to patch any vulnerability.
More...
Practically speaking, however, it can be quite difficult to keep both the live website and its local copy perfectly synchronised. If one is doing it manually, creating new content will usually involve creating that content on the local copy first. This will typically be followed by transferring the new content using copy & paste (as well as the uploading of any media) onto the live version. This tedious process can sometimes take almost as long as creating the new content in the first place!
ManageWP Local Sync
Enter Local Sync from ManageWP. The idea behind Local Sync is to automate the process of synchronising your locally hosted website with the external live one. With Local Sync, you can create new content on your local copy to your heart's content and make any other changes without needing to keep track of anything. When you are ready to make the new content or changes go live, it is simply a matter of pushing them through ManageWP's Local Sync interface keeping both copies of the website in perfectly synchrony. Only files that have been modified on the local copy are modified in the live website directory, while the live WordPress database is replaced with the locally hosted copy.
The synchronisation process can also run in reverse so that new content created on the external live website can also be used to update the local copy on your computer, although the use case for this is not as clear.
Although not part of the interface yet, the ultimate aim for Local Sync is to add options to allow the user to decide which files to synchronise. In addition, it is hoped that databases can be smartly merged rather than replaced so that only changes to the source database are synchronised.
For the single website owner, who might prefer to keep a clean copy of their website on their computer, ManageWP Local Sync is a godsend. The caveat, however, is that Local Sync is still in beta and has been that way for over a couple of years. Testing it out reveals that, although it works well most of the time, it is prone to breaking way too easily. Your author has tested it out on 3 different simple websites on different web hosts and has managed to permanently break the synchronisation process for all three without even trying to!
Because of the high failure rate, your author was not able to fully test Local Sync, since it seems that once a website encounters one particular error, it would cease to function in the Local Sync process (even after various attempts to reset the domain in the ManageWP interface - see below). After breaking the Local Sync process on three different websites, the thought of making an endless string of new ones only for the Local Sync process to break on them so easily seemed like it would take more time than it was worth.
In addition, although contacting ManageWP support for help with resolving the fatal errors did get a timely response, indicating that the problem was being assigned to one of their developers, the problem was never resolved on your author's end and he has yet to hear anything more from them.
Your author, however, was able to test out the Local Sync process to a certain degree while the synchronisation was working for the test websites. Below is a summary of what parts of the Local Sync process worked well, where adjustments were needed, and what problems your author encountered.
What worked well
Using Local Sync demonstrated that the WordPress files and database were all synced perfectly, while the permalinks for Posts, Pages and Media were all properly updated from the localhost:8888 domain of the local website address to the domain of the live website. This was all done automatically and behind the scenes.
TablePress: Your author uses the WordPress plugin TablePress to create tables when displaying data in tabular form. Local Sync had no trouble with TablePress tables. Notably, it updated the content within the tables themselves wherever a localhost domain was used (eg. for image locations) modifying it to the external domain of the live site without any issues.
Thrive Themes: Your author also uses the Thrive Architect page builder plugin and the Thrive Themes Builder application from Thrive Themes to create content on this and other websites. Local Sync had no trouble with transferring any of the Thrive Themes ecosystem from the local copy of the website to the externally hosted one.
What adjustments were needed
Bulletproof Security: Your author uses the Bulletproof Security (BPS) plugin to help in securing websites. Although, activating BPS on the local copy of the website is usually unnecessary (since the local website is not exposed directly to the internet), in order to keep BPS activated on the external site, the local copy of BPS had to be activated as well. However, this resulted in the BPS firewall blocking Local Sync from connecting to the local website. In order to get around this, the cloner.php script used by Local Sync needed to be whitelisted in the Root htaccess file custom code section of BPS as shown below:
Whitelist rule in Bulletproof Security to allow Local Sync to connect
Wordfence: Another security plugin you author uses is the Wordfence (WF) plugin from Defiant. Once again, although having the security plugin active on the local copy of the website is unnecessary, it is necessary if you want Wordfence on the live website to remain activated after synchronising.
Importantly, having the WF plugin active on the local website and even having the 'extended protection' of its firewall active, presents no issues for Local Sync. However, WF automatic malware scans enabled on the local copy (in order to keep it also enabled on the live site) can cause your local webserver (ie. your computer) to slow down unnecessarily whenever the malware scan process itself becomes active. This is further compounded if the local webserver hosts several different websites each demanding CPU resources to run unnecessary malware scans. The only workaround for this issue currently is to keep automatic scans disabled on the local copy of the website and then to just remember to activate it on the live site each time a synchronisation is carried out.
A similar issue arises with Wordfence login 2-Factor Authentication (2FA) which is used to increase security on the login page. From a security perspective, it is highly unlikely that anyone needs 2FA to protect the local copy of their website, however, it is useful to have it active on the live version to prevent login hacking attempts. Unfortunately, in order to have it remain active on the live website after synchronisation, one is forced to also have it active on the local copy as well. Once again, the only workaround for this is to keep Wordfence 2FA deactivated on the local site and to just remember to activate it on the live site each time a synchronisation is performed.
Jetpack: Another common plugin used by many-a-WordPress user is the Jetpack plugin from Automattic. Some of the settings on Jetpack are only accessible when the website is linked to a WordPress.com account. Unfortunately, locally-hosted websites cannot connect Jetpack to WordPress.com accounts making some settings in the plugin only settable on the live version of the website. That means that each time a local-to-live website synchronisation process completes through Local Sync, the Jetpack plugin will likely have to be reconnected and the live website-only accessible settings re-set (NB. your author uses the word 'likely' here as the Local Sync process broke before it could be specifically confirmed!).
The Solution for plugin settings-related issues (maybe...)
Ideally, ahem... ManageWP developers (if any of you happen to be listening), if we could choose which plugins are synchronised during the Local Sync process, this could potentially alleviate most of the above issues in one go. We would only have to set up these sensitive plugins once on the live sites and then prevent them from synchronising in the future so that their live-only settings remain untouched.
What did not work so well
ManageWP disconnection: An annoying rather than fatal error your author encountered with Local Sync is that each time the synchronisation process was run, it would terminate with the disconnection of the live website from ManageWP. As far as your author could see, the synchronisation process completed successfully, and it was simply a matter of going through the reconnection process using the bespoke connection key to re-link the live site with the ManageWP interface. This issue was more of an annoyance than a problem and certainly did not stop your author's enthusiasm for Local Sync!
The fatal error: Unfortunately, what did stop your author's enthusiasm for and testing of ManageWP's Local Sync was the Local Sync-breaking error encountered on all 3 test websites. There was no clear discernable event that led to the error other than running the synchronisation process and having it stop (prematurely?) with an error. This error was fatal since, once it occurred, it seems to be permanent for that website. The warning "An error occurred while loading your data" appeared in the ManageWP Local Sync interface for that website and could not be corrected no matter what your author attempted to do to resolve it.
Removing and re-adding the website to the ManageWP interface did not resolve the issue, nor did deleting the live website and re-installing a fresh default WordPress installation along with a new ManageWP connection solve the issue. In addition, moving to a different web host and reconnecting the website was the final attempt your author tried to resolve the error without success.
In the end, your author gave up trying to solve the problem for that website and moved onto another test website (on a different domain) until that too encountered the same unresolvable error. It appears that once a domain in the ManageWP interface encounters this fatal flaw, it is unresolvable without help from the developers at ManageWP. Unfortunately, contacting the ManageWP support to have this matter fixed has yet to lead to any productive outcome a few weeks later and counting...
Conclusion (so far!)
There is still more to test with ManageWP Local Sync, but alas, right now it is difficult to do so especially since developers at ManageWP do not seem to be too responsive to any issues encountered. In fact, your author gets the impression that ManageWP (aka GoDaddy) does not appear to be actively developing Local Sync anymore. Does it have anything to do with the acquisition of ManageWP by GoDaddy? Has the GoDaddy goliath inadvertently killed an excellent new feature on ManageWP just by simply not bothering to get their developers to continue working on it? That would be a terrible shame and typical of large companies acquiring small innovative start-ups just to end up killing off the very innovation that made them so good in the first place.
ManageWP's Local Sync is a brilliant idea that holds great promise for website creators. If the application ever gets out of beta and functions more reliably, your author will be amongst the first to purchase a subscription to it. However, right now, sadly, I cannot yet recommend incorporating it into your workflow. Fingers crossed that this will change in the near future and I will be able to update this article with a more positive conclusion.