You build WordPress websites on your computer because it’s the fastest and most secure way. Deploying it to the live server, however, is stressful and time-consuming. Luckily, Local Sync helps you deploy your localhost website with ease.
What’s Local Sync?
Local Sync takes care of all the hassle that comes with syncing the latest version of your website between local, staging, and live environments. It helps you effortlessly move the latest version of your website between the localhost environment and live environment, doing in minutes what would manually take you hours.
There’s no desktop app or port forwarding needed. Just open your localhost website in a browser, and Local Sync takes care of the rest.
How can Local Sync help me?
WordPress website development on localhost is the fastest way to get things done, since it’s fast and you can work offline. Once the localhost website is ready, Local Sync will copy the site from local to a website server. There you will spot any issues that would not show up in the local environment.
Local Sync works both ways. Let’s say you just got a new client and their website needs some work. You don’t want to wreck the live website, so you use Local Sync to push the latest version of the website to a local environment. Once the work is done, Local Sync will deploy the changes back to the live website.
Local Sync can:
- Sync differences between a website on your local computer and the one on a website server
- Deploy a website from your local computer
- Sync websites on different website servers
To get Local Sync to work, you just need to:
- Get your localhost WordPress website up and running
- Install and activate the Worker plugin
Local Sync will take care of the rest. It’s so straightforward, you’ll wonder why anyone in their right mind would deploy a localhost website any other way.
How is Clone different from Local Sync?
Clone relies on backup archives to get things done. It’s slow but very reliable.
Local Sync, on the other hand, skips the “create a backup in cloud storage” step and transfers the website content straight to the destination website:
- Once you pick a localhost website and a live website to synchronize, your local website will open in a new browser tab. Since localhost is not accessible from the internet, we’re using the browser to connect to the local website. This tab needs to remain open until synchronization completes.
- File checks are done on both websites and Local Sync lets you choose which modified files you want to push. The destination database is overwritten, just as with Clone.
Local Sync is essentially a lightweight version of Git Push command, where existing websites act as repositories.
Local Sync is currently in beta. With so many different server setups on the web, it is impossible to test them all in advance. That’s why we need your help.
Go to the Local Sync page on your single site dashboard, play around with it, and try to break it. Send us bug reports, but also your feedback – both good and bad. Help us turn Local Sync into a valuable asset.
Local Sync roadmap
We want to go above and beyond the Git functionality – you choose which files and database tables you want to sync. More importantly, we want a world where you make changes in staging and push them to a live website without any stress, in under a minute — and with no data loss. You gotta admit that it’s a great goal to have!
iimeorgin
Local Sync gives you Git-like ability to synchronize your localhost WordPress website with another environment, saving you hours of your time in the process.
Lucas Reis
I am not able to get this working. It always say it could not detect active Worker plugin, but the plugin is activated, when I click on “continue anyway”, it will give me an fatal error.
” Fatal error: Uncaught Error: Cannot use object of type stdClass as array in https://s42013.pcdn.co/code/wp-content/plugins/worker/src/MWP/EventListener/PublicRequest/CommandListener.php on line 189″
You can also see a print screen at: https://ibb.co/ym2Mx97
Marko Tanaskovic
Hey Lucas, can I ask you to open a ticket for our support team? With your account ID we will have much more to go on and explore what is going on.
Steven
Most devs who have a proper setup with local/staging/live environments will be using git and likely deploying via SSH, which works great for us and is something as a community we should be encouraging. I can’t see Local Sync being something we would use, although I can see the potential of syncing db changes and assets.
I would be cautious of syncing database changes from one env to production, usually we get the client to manually reproduce any changes made by them on staging to live, although I can see the benefit of Local Sync saving them time if it can selectively just sync those changes and nothing else..
What we really need in order to grow as a business is for ManageWP to pick up the WP/plugin updates made outside of MWP (deployed via git) so they can be included in the client reports – currently we cannot use this feature as it doesn’t show the client all of the work we do, which results in less client engagement/visibility etc. I feel that MWP is catered more towards site builders who update in real-time than developers who do things more methodically, Local Sync may help bridge that gap but it would be good if it had more of a developer first approach.
Frank
Hi,
I’am interested if this feature doens’t conflict with database of woocommerce? Just want to make and test some plugins/ coding and frontend style locally but don’t want to take risk with the woocommerce registrations (orders) for our running event.
Kyle Charlton
I tried the app today, it was very simple to use and fills in the missing gap between live and local development. I did experience one bug where single word page titles such as “Home” , “About”, “Contact” became lowercase title “home” , “about”, “contact”. Pages with 2 or more words were not affected. Very excited about this app.
Marko Tanaskovic
So glad to hear that you like our new feature Kyle.
I’ll make sure that someone looks at this particular issue although it should not be related to Local Sync working mechanism.
If you have any ideas for improvement, please share your thoughts via the ‘Send feedback’ option within the dashboard. They will be greatly appreciated.
Kyle Charlton
Disregard my comment above, I had tried a different system called “LocalSync” not “Local Sync”
Jurre
This is great! Thanks for this update and let’s make it a good one 🙂
Tim Martin
This is a fascinating idea. I develop WordPress sites locally using Laravel Valet and Nginx. I’ll run some tests later this week and see if I can break it.
Luther Adams
How do I test this in beta, I cannot see the option in my dashboard. Thank you.
Vladi
Great Goal? That’s like a dream coming true 🙂
Jean-Francois Arseneault
You mention on the feature page “Smart database merge, so you won’t lose any database entries that happened in the meantime”
I’m curious how / if you’ll be able to solve this, given others have tried it and failed : VersionPress, MergeBot, etc
The issue becomes : How can you reconcile new “local” posts/postmeta using a given ID, with the fact that given ID might have been used in the “live” environment. Perfect example would be creating a new page in “local”, but the client has published a new blog post in “live”, therefore creating a potential collision… and how can you avoid this while ensuring all post_metas are kept in sync, should you change on of the post_id ?
Nemanja Aleksic
We should be able to detect a conflict, i.e. different products under the same id. From there we need to determine every place where this id is referenced, give on of them a new id, and search and replace the database.
Now, this makes it sound straightforward, but the actual reality is much harder, and it might take a lot of work to get there, but it’s not impossible.
The only real hurdle is the lack of WordPress coding standards, where each plugin could potentially be a liability.
Leonardo Gandini
This will definitely be THE killer feature since almost nobody merges DBs without losing something. So at the moment is not possible right?
If a client publishes a post on the live site, the local DB push will replace it, right?
Is exciting to see this new Local sync, and I can easily see the same application but to a non-local website. This way we can have some sort of Local Stage – OnlineDevStage and OnlineLive.
Borek Bernard
Hi, one of the authors of VersionPress here.
The approach you have outlined, Nemanja, means that Local Sync will need to have _perfect_ semantic understanding of all plugins and themes and their data structures, otherwise the sync will not be reliable. Well, reliable may be a weak word here as replacing `123` -> `124` in the database _and not being extremely careful_ might lead to e.g. changing a price of something.
That is “unfortunately” the nature of database merging in WordPress and every tool trying to do it will face the same challenges. At the same time, I think it’s a very noble goal and I applaud you for trying. I would also like to offer our expertise in this area if you or your engineers ever want to discuss anything; the topic is a passion of mine and I’ll be happy to help. Feel free to reach me at borekb@gmail.com.
Thanks,
Borek
Nemanja Aleksic
I agree – while on paper it may sound straightforward, in reality it’s a ton of work.
Will reach out to you in due time to see how we can help each other out. Thanks for being so open about it!
Brad Touesnard
This is the approach we took with Mergebot, but we ultimately ran into a chicken-egg problem.
We needed lots of people to use it and to contribute plugin schemas (describe how the plugins store their data) to make it more reliable. But few people were willing to use it because it wasn’t reliable.
Ultimately we found people weren’t willing to analyze their plugins and come up with schemas for them. And who could blame them? It’s a lot of time and effort and not fun.
I had a chat with Boris about Mergebot earlier this year. Let me know if you guys would like to chat again.
Patrik Alienus
This would be absolutely lovely if it worked, but I’ve been burned by these types of features before that I would be scared to use it. Even WP Engine’s StagingLive doesn’t always work, and that simply replaces everything.
I’d rather just replace the DB altogether and add in changes afterwards. Usually when starting a project on an existing site, I tell the client to log all changes they make to posts/pages, so that we can re-add them afterwards.
Borek Bernard
Just for the record, VersionPress is still the only existing solution that actually does database merging and we feel pretty much alive 🙂 It’s true that the open source project didn’t receive much love in the past year or so but the basics are solid and we have quite a few individuals and agencies who depend on it in their day to day work. By my estimates, VersionPress will require something like 20 man-years of work; we have invested roughly 7 into it and are working hard to be able to fund the next 12 (that is, man-years, not calendar years 🙂 ).
Borek Bernard
(It would also help if I could add up two numbers 🙂 )
Vinodh David
Hello, Founder of WPMerge here. We have been working on this problem for almost 2 years now and we have cracked the processes without using Database schema. It has been not a simple ride but we would also be glad to discuss more on making this happen with Local Sync if ManageWP is open 🙂
Morten Ellegaard Larsen
I can’t get my hands down, this is like a wet dream to me! 🙂
I haven’t tested it yet (my hands are still up in the air), but this function is what I have missed. I my first born hadn’t moved out, I would have shipped him right away.
Nemanja Aleksic
Don’t forget to send us feedback once you test it!
Paul Beck
I’m anxious to see this work. I tried to dump my operational site to my localhost dev site, and it destroyed my database. I had to re-install WP, add in UpdraftPlus plugin and restore the database from my last Updraft backup. I tried it three times, and it failed all three times in the same way. I’m not sure what I am doing that differently that would cause it to totally destroy my local database. My local URL is 192.168.1.11/asa. I use the fixed I/P address so I can access my local instance via other devices on my LAN. My operational site uses many custom DB tables. Perhaps that is a contributor.