Published

This is a story of how our standard testing practice came to byte us in the backend (enjoy the puns, folks. I’m here all week!)

There were some important technical updates we needed to make to a simple PHP application so we cloned it and set it up on a development server using phpapp.test as the domain. For this particular app to work, we had to update the database to change all occurrences of therealdomain.com to phpapp.test. Not a problem, any text editor with a search-and-replace functions will do.

The test app launched fine. The errors didn’t start appearing until we initiated the update process. We kind of expected errors but always hold out hope that things go smoothly.

After a bit of digging we managed to localise the issue to a section of the update code that was reading serialized text from our database. In programming terms, serialization is a way to represent complex data structures as plain text which makes it easier to store or share around. The update process had to unserialize the data (i.e. convert it back into its original form) to perform some operations but some of it was failing to unserialize properly. We thought some of the data had become corrupted but a closer look soon revealed the answer.

Programming languages such as PHP have a data structure called an “Array” which you can think of as a list of items. For example, you may want to record the name and email of an individual like this:

array(
"name" => "Angus MacGuyver",
"email" => "[email protected]"
)

Serializing this data would produce this:

a:2:{s:4:"name";s:15:"Angus MacGuyver";s:5:"email";s:27:"[email protected]";}

Serialized text needs to keep track of the length of their data. For example, the portion that reads s:4:"name" means “there is going to be a string of text coming up that is 4 letters long”. And indeed, “name” is a string that is 4 letters long.

Remember when we replaced therealdomain.com with phpapp.test? Well it changed the data in the serialized text as well so it now looked like this:

a:2:{s:4:"name";s:15:"Angus MacGuyver";s:5:"email";s:27:"[email protected]";}

This made our serialized data invalid. The portion s:27:"[email protected]" says “there’s going to be a string of text coming up that’s 27 letters long”. Unfortunately [email protected] is only 21 letters long. Trying to unserialize this text will result in the errors that we encountered.

So the solution was simple: use a test domain with the same number of letters as therealdomain.com. We recreated the development app, chose a 17-letter test domain and re-ran the update. No errors this time.

Caveena Solutions has been building websites and web applications for over 20 years now. I find it rather funny that we’re still finding such niche problems all these years later. While it’s great that serializing data has these integrity checks built-in, I think I prefer using JSON for convenience.