Thanks for the feedback Will! And I appreciate you going so far with the diagnosis here. My recommendation would be to check with the Tablepress devs and find out why they do it that way and if they would be willing to change it.

Here are my thoughts on it: they might have a really good reason why they did it this way, but it’s not standard. WordPress doesn’t do anything like this, and it’s almost always best to stick within normal conventions. Static URLs in normal post content look exactly the same in the final rendered HTML as they do in the database, etc. Tablepress might be having to parse the post content further or something like that, but the way they are storing those URLs not only makes it incompatible with NS Cloner replacements but every other search and replace plugin out there (Better Search and Replace is one we use a lot ourselves, and I’m guessing it would also fail in this case if trying to replace full URLs).

There’s also more information out there along similar lines, but the top answer from this thread:
https://stackoverflow.com/questions/14795811/mysql-php-escape-string-why-is-it-not-saved-in-the-database-with-the-backs
sums it up nicely: “Let me begin by saying that you should really not really store data in any particular escaped format in the database, you’ll regret it later if you need to extract it in another format or search the data for some reason later.”

And that would be our take on it as well. The data should be stored in the DB in such away that no post-processing is required for it to be properly formatted or appear as intended. As it is right now, that’s not the case. It looks like what Tablepress is storing in the DB for URLs is useless without additional processing, and I would see that as the root cause of the problem. Even if we were to add and maintain special code just for this one exception, Tablepress data will still cause problems for other plugins out there needing to work with or alter the raw data.

We always think it’s better to solve the root cause of something, and we wouldn’t really see an update to the Cloner to compensate for this specific quirk of another plugin as a viable option.

Best!
Andrew