thednp
commented
8 years ago Why don't you try to use the Unyson Back-up Extension to move your site around? Also create a demo install and try to install that would probably work in this scenario.
Closed randallbruder closed 8 years ago
thednp
commented
8 years ago Why don't you try to use the Unyson Back-up Extension to move your site around? Also create a demo install and try to install that would probably work in this scenario.
ghost
commented
8 years ago Your replace script will corupt serialized and json values. You should migrate to another domain with our Backup & Demo Content, it has an advanced replace url technique.
randallbruder
commented
8 years ago Here's the thing though, the only commands I've run in the database are:
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'beta.greenspace.com', 'greenspace.com');(and the same for wp_posts looking in the post_content field.)
Why would that corrupt the JSON values for some posts, but not all posts (and only specifically recently made posts)?
ghost
commented
8 years ago This is how our replace functionality works: On database import, it searches in every row your new url in different versions/encodings https://github.com/ThemeFuse/Unyson-Backups-Extension/blob/v2.0.11/includes/module/tasks/type/class-fw-ext-backups-task-type-db-restore.php#L317-L380
I recently moved a Wordpress install that contained the Unyson framework from one folder to another on a server (from /beta/ to the root folder) and changed the URL in Wordpress from beta.greenspacecafe.com to greenspacecafe.com. I also did a MySQL find and replace for
beta.greenspacecafe.comreplacing withgreenspacecafe.comto correct all the media links.At this point, let me say I stupidly did not make a Wordpress backup first. I've never had an issue moving a Wordpress install on the same server before, but this is also my first time working with the Unyson plugin.
While most everything actually carried over fine, I found anything related to the Unyson plugin no longer worked properly—two things specifically: (1) Pages built with the page builder, and (2) the theme settings. The database was exactly the same as before, with the exception of my find and replace removing instances of
beta.when it occurred before the domain.I did a deep dive into what was happening, and found some interesting results:
Under the
wp_optionstable in the database, was thefw_theme_settings_options:flycoffeoption (I'm using the flycoffee theme). The theme options are stored there as in a long JSON like format. The database actually had what looked like the correct settings in it:but weren't being read properly by Wordpress/Unyson/The theme, and seemed to ignore the settings. So out of curiosity I recreated the settings exactly as they were before, checked the same
fw_theme_settings_options:flycoffeMySQL entry and found this:Which looks almost the same as what had been there previously. I ran the original data and the recreated data through a character-level diff engine, and found only two differences:
So the only difference between the two are the numbers associated with the two Media Library URLs. I'm not sure why that is, or what happened there, but that's one issue resolved.
Secondly, and the reason for this post, is the pages built with the Unyson page builder.
So I took one page as an example, so traced it through the database. It still had an entry under
wp_postsbut the post content is a commented out hash (as it should be for Unyson.) Then, underwp_postmetaI found a bunch of entries matching the page'spost_id, and one of those entries, with themeta_keyfw:opt:ext:pb:page-builder:json, had the now missing content built with the Unyson page builder:So, like the options, I rebuilt this page in the Wordpress backend, then checked the same entry in the database and found this:
(The
unique_idwas updated with a new hash, but I manually pasted the old hash in to see if that was part of the issue—it was not. With the recreated page & old hash, the website still showed the content.)I ran another diff on these two entries, and found the only difference was all the
"and/characters (when inside a text field or URL) were escaped with a backslash.This is where I'm confused. Why would Unyson now require the quotes/backslashed in text be escaped? I know I can "recover" all the data by pulling out the
fw:opt:ext:pb:page-builder:jsonentries from the database and using those as a guide to rebuild every page, but unlike the sample page above, most of the other pages have significantly more content.Another interesting point, the most recently updated page (updated 2 weeks ago) didn't break when I changed the website URL (2 days ago.) I checked the content for that in the
wp_postmeta,fw:opt:ext:pb:page-builder:jsonentry and found all the double quotes and backslashes properly escaped: