spent longer than i want to admit debugging a migration where the search and replace ran clean and every elementor page still pointed at the old domain.

posting the cause here because it is not obvious and it bit me twice.

elementor stores the whole page layout as json inside a php serialized value. when that gets encoded, forward slashes escape. so what is actually sitting in wp_postmeta is

https://oldsite.com/wp-content/uploads/hero.jpg

not

https://oldsite.com/wp-content/uploads/hero.jpg

search for the normal form and there are zero matches. the tool reports success. it did replace things, just not those, and you do not find out until someone opens a page.

the obvious next move is to search for the escaped form instead. that matches, and it breaks the row. php serialization writes the byte length of every string before the string, like s:19:"https://oldsite.com". swap in a 22 character domain and the prefix still says 19, unserialize() hits the wrong boundary and returns false, and wordpress gets nothing back. that is the "search and replace corrupted my database" story people post here.

if you want to check whether it happened to you, run this after your replace:

SELECT COUNT(*) FROM wp_postmeta WHERE meta_key = '_elementor_data' AND meta_value LIKE '%oldsite.com%'; 

if it is above zero, the escaped slashes are why.

doing it properly means unserializing rather than pattern matching, walking the whole tree, decoding the json leaves, replacing inside them, re-encoding with the original escaping style preserved, then re-serializing so lengths are recomputed. that escaping step is the subtle one. two json encodings of the same data are both valid and different lengths, so you can get the replace exactly right and still produce a value that does not match its own length prefix.

i wrote a plugin that does this. free, gpl, on wp.org and github, no paid tier and no trial. visual preview before it writes, optional snapshot, one click undo.

https://wordpress.org/plugins/lucid-search-replace/

https://github.com/ibrahimhajjaj/lucid-search-replace

disclosure, it is mine. i also sell a backup plugin separately and this is not a lite version of that.

curious whether anyone has hit the same thing with other page builders. i only verified the elementor case properly.

spent longer than i want to admit debugging a migration where the search and replace ran clean and every elementor page still pointed at the old domain.

posting the cause here because it is not obvious and it bit me twice.

elementor stores the whole page layout as json inside a php serialized value. when that gets encoded, forward slashes escape. so what is actually sitting in wp_postmeta is

https://oldsite.com/wp-content/uploads/hero.jpg

not

https://oldsite.com/wp-content/uploads/hero.jpg

search for the normal form and there are zero matches. the tool reports success. it did replace things, just not those, and you do not find out until someone opens a page.

the obvious next move is to search for the escaped form instead. that matches, and it breaks the row. php serialization writes the byte length of every string before the string, like s:19:"https://oldsite.com". swap in a 22 character domain and the prefix still says 19, unserialize() hits the wrong boundary and returns false, and wordpress gets nothing back. that is the "search and replace corrupted my database" story people post here.

if you want to check whether it happened to you, run this after your replace:

SELECT COUNT(*) FROM wp_postmeta WHERE meta_key = '_elementor_data' AND meta_value LIKE '%oldsite.com%'; 

if it is above zero, the escaped slashes are why.

doing it properly means unserializing rather than pattern matching, walking the whole tree, decoding the json leaves, replacing inside them, re-encoding with the original escaping style preserved, then re-serializing so lengths are recomputed. that escaping step is the subtle one. two json encodings of the same data are both valid and different lengths, so you can get the replace exactly right and still produce a value that does not match its own length prefix.

i wrote a plugin that does this. free, gpl, on wp.org and github, no paid tier and no trial. visual preview before it writes, optional snapshot, one click undo.

https://wordpress.org/plugins/lucid-search-replace/

https://github.com/ibrahimhajjaj/lucid-search-replace

disclosure, it is mine. i also sell a backup plugin separately and this is not a lite version of that.

curious whether anyone has hit the same thing with other page builders. i only verified the elementor case properly.