I’m finally transitioning from an old HTML+CSS website to a WordPress 6.5.5 site developed in LocalWP Version 9.0.4+6699 on a Windows 10 Pro desktop. It’s a pretty basic informational site for a small consulting business, using the free Astra theme and just these plugins: Contact Form 7, Instant Images, and wpDataTables. Everything worked pretty well during development. In the last 30 or so hours I’ve had three very long phone calls with tech support at my web host (bluehost.com) just to get the site uploaded and working properly. A couple of minor issues have required multiple corrections but one (the home link in the menu directing to my local server rather than the live site) seems finally resolved, while the other one (Contact Form 7 emails not coming through) will supposedly be resolved in the next hour or so.
However, there is a larger issue lurking that I did not anticipate. My expectation was that once the site was live, I could do maintenance (whether just adding or editing posts, or more structural stuff like adding a new page, adding a new plugin, changing the settings of a plugin, etc.) either locally or on the live site, and when done I could simply export the database from wherever the change was made and then import it to the other location. My intention was to be able to do maintenance wherever was convenient (on my desktop most of the time, but on bluehost’s servers from my laptop when traveling). That way I would always have an up to date local copy of the entire site. And if I ever needed to part company with bluehost I wouldn’t need to depend on them (or their backups) to reconstruct the site elsewhere.
A few hours ago, I exported the database from both locations and then tried some experiments. I took the export from LocalWP and imported it to the bluehost server, and it instantly broke the header navigation menu. I then figured I could fix that problem by simply importing the export from bluehost back to the bluehost server to restore the site, but when I tried that the script failed - it seems that bluehost’s export routine creates a script that attempts to create tables without first dropping them, which really surprised me. So, it took another phone call to tech suppport to get the site working again.
Now I’m reconsidering my plan to be able to do maintenance on either location, and I’m wondering if I just have to limit my maintenance activities to bluehost’s servers. What am I missing here? How have others dealt with this issue? Thanks in advance for any help you can offer.
Once the initial site development is complete and deployed to a server, I usually split my “site maintenance” activity into a few main categories:
Content updates (new posts/pages, changes to navigation menus, uploading media). Once a site is live, I do these changes wherever that is hosted, in your current situation, that would be Bluehost. It makes sense to keep the content changes focused on the production site in order to avoid the hassle of merging content back into the production site.
Plugin and/or WP Core upgrades. Depending on the site and the kinds of Plugins or themes that are installed, I might pull down the latest version of a site into Local and test an upgrade before upgrading on the production site. Sometimes I don’t clone the production site down and that boils down to if I feel like the plugins that are installed are well maintained by developers with a good track record of maintaining backwards compatibility. One other reason I might pull a site down for upgrades is for major changes like the remote environment needing an upgrade of PHP version.
Custom development. I’ll almost always clone a site down if I’m going to be making code changes to the theme or any custom plugins. This is because I don’t want accidentally break things on the remote site while changing the code.
Those are all mostly rules-of-thumb, and are informed by how comfortable you are with moving changes between environments. In general, getting a site into Local is pretty easy, since you can usually just drag-and-drop a zip of a site backup to import it.
Deploying from Local to production is a little more tricky. If you host with WP Engine or Flywheel, Local allows you to use the Connect feature to simplify pulling down and deploying changes with a remote environment.
For other hosts, you can definitely do the manual route, which sounds like what you’ve done so far, or you might consider using a migration plugin to help automate the deploying changes between environments. We (WP Engine) have WP Migrate which many use, but there’s probably others that could serve you well.
Anyway, hope that helps guide your thinking and give you some options for how to proceed!
ben.turner, thanks so much for the detailed response - it is quite helpful. Since I posted my question, a lot has happened. I finally got my contact form issue resolved, but only through messing around myself - Bluehost tech support went from just OK to absolutely abysmal over the course of half a dozen calls, but that’s a whole other story.
Now the live site is finally running as it should, and i was able to back it up successfully using the backwpup plugin. That backup comes in the form of a huge (250 MB) zip file. I’m able to import that into Local by dragging and dropping it into the Local window (after first deleting the old site, to prevent URL conflict). However, once the import into Local completes successfully, if I try to display the admin page I get a 404 error, and when I try to display the site I get a 403 error. Is there some trick to pulling the live site into Local? Again, I’m happy to do most normal maintenance on the live site, but I need to know I can pull the entire live site into Local if necessary.