All builder elements lost after changing the host
-
Topic
-
-
Replies
-
Hello,
WordPress stores all of this as serialized data in your database. If you’re messing with the data manually, you’re most likely going to run into problems and lose any serialized data stored throughout the database. So, in the future you need to be aware of how to work with your database, taking into account serialized data.
A common example people run into with this is when they switch to a different domain, and they have to a mass find/replace of the URL string in the database. — If you’re doing just a straight find/replace of your domain throughout your database, you’re going to screw up all of your serialized data because everything is calculated down to the character count.
In other words, at the point where you’re doing the find/replace of your domain is where you’re currently losing all of that data. So, you need to be aware of this when you’re changing the domain. This is a great tool that I use when I transfer any WordPress site:
http://interconnectit.com/products/search-and-replace-for-wordpress-databases/
When you initially do your database transfer to the new site, throw that PHP file up on the new site temporarily, navigate directly to it in your browser, and use it to do your find/replace. Then, delete the file from your server.
That feature is also build in to clone/migration tools, like Duplicator http://wordpress.org/plugins/duplicator/ Click, click done. Anyone can do it. Just read up a bit first, like “Clean/disable cache” Is in Codex for this moving stuff http://codex.wordpress.org/Moving_WordPress#External_Resources
Is an issue because even experienced people ignore or just have not had major problems in their face. So give wrong info. Check this 2013 article in SmashingMagazine http://wp.smashingmagazine.com/2013/04/08/moving-wordpress-website/ and note the comment from super editor
Thanks to everyone for the feedback! The section on editing the database was updated! Sorry for any inconvenience caused.
Author still do not get it judging from comments. From people who also have had nightmares. They do not forget 🙂 Is almost true “plugins” for this cost money though, but the simple and I think original InterConnectit script does not, Duplicator and some others also not. No need for BackupBuddy or anything.
I’m familiar with those tools Karlo is mentioning and have used them, but I also find it as additional process. I haven’t yet try the one Jason is referring to.
I also know that widgets won’t be replicated but didn’t expect this for the JS builder data. I’ve had just to adjust elements for 2 pages and I’ve had the data on the localhost, so it wasn’t a big deal that’s why I called it “small nightmare”.I’m not a developer, trying to focus mainly on the webmaster/design part, and I do not know is there other way to code it. If there’s no other way then ok, but if there’s the other way I see this as a bad practice.
However discussion is usually constructive and reading what Jason wrote I realize that all will stay intact if the character count stays the same, which may be of help in some instances. In the example were we are changing the domain, if the domain is the same length WordPress serialized data won’t be interrupted. Am I realizing this well?
Yeah think so. Why some do the trick of making sure dev. site name has same length as final site – then no problems apparently.
About widgets, there is not one but 2 plugins for that:
http://wordpress.org/plugins/widget-importer-exporter/
http://wordpress.org/plugins/widget-settings-importexport/Can be a big deal if heavily in to widgets.
Extra step is true and that is why you have payware available 🙂 Is often like that. Extra step will be wrapped in convenience and features if you pay for some clone de luxe thing.
I seem to find extra steps with most thing so not really bothered with this. But crucial to know about. Is when you do not it can be annoyance.
If Jump Start can do something about it it should! But even with own export/import feature you would still have to think of other data so cant be 100% sure solution. He will tell you if wrong 🙂
Karlo, if you pay attention you’ll notice I’ve said “In the example were we are changing the domain”. So it’s just the example, I do not intend to change the domain that way but was sticking to the example Jason was using to eliminate the confusion. The trurh is that I wasn’t changing the domain, since I was changing the hosting as I said in the OP. So I didn’t have to change the localhost to the live domain, but I still edited the sql file and it was enough to lose the Builder data. There are plenty of things you can edit in the database. I know it isn’t a big deal installing aditional plugins, but sometimes is annoying especially when you used to quicker process.
I think there is just sort of a learning curve here for general best practice in editing your database. In specifically talking about the Layout Builder, it’s important to point out that we’re using all built-in WordPress features to save and store everything.
A custom layout is actually a post of a custom post type, and then the elements of the layout are meta data saved to that post. Only existing WordPress functions are used to set all this up and save everything. So, in other words, we’re not doing anything custom to make all this happen. We’re doing our best to work within the constraints of WordPress and how they’ve already set everything up.
The reason I bring this up is because it should demonstrate why it’s important to just sort of be aware of what’s happening here when editing your database. It’s possible that in the past maybe you’ve kind of gotten lucky in what you’re editing, but generally speaking, to just open up the database and start making changes can be dangerous.
And then getting off specifically about editing the database, I also wanted to point out that because we’ve set the custom layouts up like this, they actually are available to be imported/exported through WordPress via Tools > Import/Export. — So, if you run into this mistake in the future, you can go to Tools > Export on the old site, export WordPress XML file of the
tb_layoutcustom post type, and then import this into the new site through Tools > Import.I highly recommend this awesome plugin when moving from, local, staging and live environments.
http://wordpress.org/plugins/wp-migrate-db/
- You must be logged in to reply to this topic.