Problem with WordPress's built-in export/import feature due to Cornerstone's improper escaping during export?

[fundibu]

Hi!

Cornerstone saves JSON data about the layout of each page in a _cornerstone_data entry in the wp_postmeta table.

When I use WordPress’s built-in Tools > Export feature to export pages to an XML file, and then I use the Tools > Import > WordPress feature on a different site to import the XML file, these JSON strings get imported into the target site’s database with extra backslashes (not present in the origin site’s database) that make the JSON invalid and prevent Cornerstone from recognizing its own content on any of the pages.

The XML file contains these extra backslashes because your wxr_export_skip_postmeta filter (in cornerstone/includes/classes/admin/class-wp-export.php) calls wp_slash on the $meta->meta_value variable. I don’t think it should. The wxr_cdata function, which WordPress’s exporter calls on the contents of all wp:meta_value tags by default, wraps the string in a CDATA section and splits any occurrences of ]]> within the string. Doesn’t that mean no further escaping is required?

I know there are other reasons why exporting Cornerstone content from one site to another might not work perfectly, but the fact that it’s impossible due to over-escaping (or under-unescaping) seems like a bug. If you wanted to make it impossible, you could have added the _cornerstone_data field to the $meta_skip_list array instead of the $meta_slash_list array, right?

By the way, I see that some other users have asked for a way to export font and color definitions from Cornerstone. Just adding a +1 to that.

Thanks!

WordPress 6.0
Pro 5.1.5

[ruenel]

Hello @fundibu,

Thanks for your feedback. We will forward this message to our developers.

Best Regards.

[alexander]

Hi @fundibu,

Thanks for reaching out about this. I do wonder if something has changed in WordPress. I moved a site recently and had an issue where some pages came through but others didn’t, and some of the HTML entities were double encoded. I recall that when we originally created class-wp-export.php to setup export compatibility it did need the slashes to get things working properly.
We’ve not checked this in-depth (I mean recently) so I could be mistaken, but we’ll make a note to look at this more closely.

The $meta_skip_list tracks things that need to be entirely omitted from the export. For example, _cs_generated_tss is in that list which includes a cache of the CSS generated to be displayed on the front end. This shouldn’t be part of the portable data since the styles can regenerate after the data is imported on the new site.

By the way, I see that some other users have asked for a way to export font and color definitions from Cornerstone. Just adding a +1 to that.

For the upcoming release we’ve added a way to access the raw JSON for colors and fonts via the Dev Toolkit. This can be used to easily move items between sites. Give it a try once we get this next update out!