Incorrect length calculation in serialization of string data

[mikethicke]

In the attached SQL dumps of a WordPress options table, some string data is not being serialized correctly.

Command: cat wp_1000642_options.sql | ./go-search-replace hcommons.org heinlein.mlacommons.org > wp_1000642_options_replaced.sql

The error occurs for one long field containing CSS. Here are the relevant snippets:

Original:

...
s:16:\"additional-style\";s:24458:\"div.gdlr-blog-co
...

There is one substitution performed of hcommons.org -> heinlein.mlacommons.org

Result:

...
s:16:\"additional-style\";s:6533:\"div.gdlr-blog-co
...

The new serialized length should be 24469, reflecting the difference in string length between the two URLs, but it is instead reported as 6533. If I serialize the value using PHP's serialize function, it is serialized correctly. The serialization appears correct other than the length.

Original file (renamed .txt for uploading):
wp_1000642_options.txt

File after replacement:
wp_1000642_options_replaced.txt

[joshbetz]

There's a flaw in the regex that fails to account for \"; within a field. In this case, the CSS that is stored in the database contains that string, which makes go-search-replace think it's the end of the serialized string.

Since we do a simple search-replace which doesn't depend on unserializing the string, the actual data is still correct. This flaw only impacts the calculation of the length of the string. We need a more robust way of calculating the length.

[kevinfodness]

This issue just came up for me, and means that I can't use the search-replace feature of VIP-CLI when preparing database imports for VIP environments. I'm not sure whether this tool is used behind the scenes when copying data from production down to other environments on WordPress VIP, but if so, it means that environment copy would need to be manual (download copy of production DB, import locally, run wp search-replace - which works properly - then re-pack the DB and push it to the proper environment).