PHP

SERIALIZED DATA IN WORDPRESS

Leave a comment

Developers often choose to store specific information in the database like theme options, or settings. Typically this data is serialized in the database so it can be copied or restored easily without compromising the integrity of the information.

ABOUT SERIALIZED DATA

“Serialized data” is just a fancy way of saying “to list data in a specific order”. PHP has a function called serialize() which stores data as a serialized row in the database. For example the “active_plugins” row in wp_options of your database may look like this:

a:8:{i:0;s:31:"query-monitor/query-monitor.php";i:1;s:57:"accesspress-instagram-feed/accesspress-instagram-feed.php";i:2;s:19:"akismet/akismet.php";i:3;s:29:"easy-captcha/easy-captcha.php";i:4;s:43:"google-analytics-dashboard-for-wp/gadwp.php";i:5;s:33:"instagram-feed/instagram-feed.php";i:6;s:19:"jetpack/jetpack.php";i:7;s:47:"really-simple-captcha/really-simple-captcha.php";}

That probably looks like a lot of nonsense, but in reality it’s just taking a list of items and placing it on a single row. The array has a total count of items, each item has a number in the sequence, and each item has a total count of characters.

a:8 = There are 8 items in this array

i:0 = This is item 1 in the array (counting begins with zero)

s:31 = This item has 31 characters

query-monitor/query-monitor.php = The value of the item is located in quotes. The number of characters here should always match the numerical value proceeding it.

You can also break the single line out into multiple lines for easier reading. Just be aware that it must be on a single line if copied back into the database.

$array = array(
'0' => 'query-monitor/query-monitor.php'
'1' => 'accesspress-instagram-feed/accesspress-instagram-feed.php'
'2' => 'akismet/akismet.php'
'3' => 'easy-captcha/easy-captcha.php'
'4' => 'google-analytics-dashboard-for-wp/gadwp.php'
'5' => 'instagram-feed/instagram-feed.php'
'6' => 'jetpack/jetpack.php'
'7' => 'really-simple-captcha/really-simple-captcha.php'
);

POTENTIAL ISSUES

The most common conflict occurs when copying your site to a different environment, as this will change the domain. If your site uses serialized data in a row that contains the domain the character count will no longer match the updated value.

For example, say your site stores serialized data in a row with the URL in it, like this:

a:1:{i:0;s:23:”http://mycooldomain.com”;}

Notice that the value of this item has 23 characters, and is denoted by s:23 in the array.

If copied using one of our Copy Site tools, the URL is search and replaced automatically to the new domain value. That means that the same row on your new environment would end up like this:

a:1:{i:0;s:23:”http://newsite.wpengine.com”;}

But after this change, the value is now 27 characters long meaning s:23 is incorrect. This invalidates the array and the entire row.

So for example, if your theme options stored a full URL path for some settings or an image, it would end up showing default theme settings on the site instead of your custom theme and settings.

If you are performing a basic SQL search/replace on your site, it won’t be able to intelligently update these rows containing serialized data, because it can’t automatically update the character count.

However, if you are performing a search and replace with PHP, this will work for serialized data.

When copying sites, there are a few options to search using PHP, so as to not break the serialized rows:

If you are running into issues with broken serialized data even when using one of the above methods, often times themes or plugins which store important data as serialized rows will offer an export option. With this option, you can export the settings, then import them to the new environment to fix the issue.

'Coz sharing is caring
Software Architect

Great software is not built, it is grown

Leave a comment

As an architect you are tasked with providing the initial structure and arrangement of software systems that will grow and change over time, will have be to reworked, will have to talk to other systems, and almost always in ways you and your stakeholders did not foresee. Even though we are called architects, and we borrow many metaphors from building and engineering, great software is not built, it is grown.

The single biggest predictor of software failure is size; on reflection there’s almost no benefit to be had from starting with a large system design. Yet at some point we will all be tempted to do exactly that. As well as being prone to incidental complexity and inertia, designing large systems upfront means larger projects, which are more likely to fail, more likely to be un-testable, more likely to be fragile, more likely to have unneeded and unused parts, more likely to be expensive, and more likely to have a negative political dimension.

Therefore resist trying to design a large complete system to “meet or exceed” the known requirements and desired properties, no matter how tempting that might be. Have a grand vision, but not a grand design. Let you and your system learn to adapt as the situation and requirements inevitably change.

How to do this? The best way to ensure a software system can evolve and adapt is to evolve and adapt it from the very outset. Inducing a system to evolve means starting with a small running system, a working subset of the intended architecture – the simplest thing that could possibly work. This nascent system will have many desirable properties and can teach us much about the architecture that a large system, or worse, a collection of architectural documents never can. You are more likely to have been involved in its implementation. Its lack of surface area will be easier to test and therefore less prone to coupling. It will require a smaller team, which will reduce the cost of coordinating the project. Its properties will be easier to observe. It will be easier to deploy. It will teach you and your team at the earliest possible moment what does and does not work. It will tell you where the system will not evolve easily, where it is likely to crystallize, where it is fragile. Where it might break. Perhaps most important, it will be comprehensible and tangible to its stakeholders from the beginning, allowing them to grow into the overall design as well.

Design the smallest system you can, help deliver it, and let it evolve towards the grand vision. Although this might feel like giving up control, or even shirking your responsibilities, ultimately your stakeholders will thank you for it. Do not confuse an evolutionary approach with throwing requirements out, the dreaded phasing, or building one to throw away.

'Coz sharing is caring