WordPress has a reputation of being very portable but after reading a recent article on WPGarage.com, there is a certain condition in which the data in WordPress can become non-portable. It has to do with the serialization of data. However, they offer up a few different ways in which to deal with the problem so that you don’t lose data via a database dump.
BTW, I would be perfectly happy to have the entire core stop using serialized PHP variables for *anything* and start using JSON encoded data instead. This wouldn’t suffer from the length changing issue, and JSON is far more widely portable. If anybody wants to try to convince others, I’ll agree with you. :)
I like this JSON idea.
I ran into an issue with this just today actually. When setting up a testing server for a live site, a number of plugins stopped working for me. Thanks for the link and the suggested solutions, I’m going to try them out now!
Otto – would you be so kind as to point us “naive” folks toward the better ways.
Is there a way to monitor for serialized data? Is it defined within the table structure? Are there common serialize/deserialize functions used in the WordPress world?
@Otto – +1 I’ve been doing this in my newer plugins and it’s worked well. If the options API could manage this transparently too so we didn’t need to use json_encode and json_decode when pulling option values out it’d be even better
Data should be separated from the language forms that use it. ie, no language specific data should appear in a DB, because when other languages hook into that DB they can’t handle all of the data. This is a simple and often ignored rule in the creation of databases :-)
But WP’s schema dates back to simpler times, MySQL 4 and a need to work well on slow DBs at low cost providers – that was more of a priority than pure DB theory.
Also because of the way Web apps have to work, using the DB as a sort of variable store isn’t unusual and it’s sort of OK so long as other things aren’t going to have to work with that data. WP isn’t exactly spot on with that – the text widget, for example, stores data in a serialised string, which is a bit mad, hence why we wrote the Spots plugin.
Anyway, we run into this all the time, and years ago I created a script to help with migrations and doing a safe search and replace on a DB: http://interconnectit.com/124/search-and-replace-for-wordpress-databases/ does the trick, gets downloaded a hundred or so times a day, so must have something going for it :-)
Incidentally, although JSON is a better format to handle, it’s still language locked.
Another thing worth noting is that WP isn’t strictly a true DB app. It uses the DB as a data store, rather than leveraging the capabilities of database engines to manage performance, security and so on. Consequently you can’t fully apply good DB theory or practice to it.
@David Coveney – I ran into your plugin yesterday and can’t tell enough people how much of a help it’s been. Previous to learning the true nature of the issue, migrations for us were always fraught with errors. I would literally save a text copy of my widget contents so I could upload them again when the site inevitably dumped everything. Thank you so much for creating this script, and saving us so much time and energy!
@otto – +1 for json.
Probably would not be that hard to change using an “extract and override” technique. The overridden call could be put in the deprecation queue for WP 4.
My personal pet peeve `wp_parse_args` could be fixed the same way (that is, to call it what it really is, `wp_merge_array`).
Good luck with the json.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
They don’t really explain the issue properly. The issue is not with serializing data and putting it in the database. That is actually fine, for certain specific kinds of data. Not every kind of data is something that needs to be searchable using a relational database model. The settings for a plugin, for example, are generally stored serialized.
The issue happens when you store URLs or local directory paths in serialized data. People who are migrating sites from one URL or server to another might try the naive approach of doing an SQL dump, doing a search/replace on that dump, and then importing the dump to the new site. When they do so, they’ll find that serialized data which they modified will be gone, because they forgot to change the length values to match correctly.
The solution is to make smarter search-replace mechanisms, or better yet to simply not store URLs and directory paths in serialized data. The WordPress core tries to avoid this, though it has not always been successful. If you find a place in core where URLs and such are being stored in a serialized format, the core team considers that a *bug* and would appreciate a ticket and/or a patch to that effect.
Migrating sites in that “naive” way is something you shouldn’t be doing anyway, IMO, but that’s a whole different argument… There’s better ways to set up your dev/staging/production environments, without needing to change URLs around.