Yesterday, I was chatting with a fellow WordPress developer and, as we were reviewing some code, we came across the use of maybe_unserialize
. You can read more about it in the Codex, but the short of it is this:
Unserialize value only if it was serialized.
Seems a little odd, doesn’t it? I mean, shouldn’t we know if a value has been serialized?
I think at one point in my career, I would’ve said “Yes, definitely” and I would have thought it was odd to even have a particular function like this. But working with software breeds maturity (however much is still up for question, I think :) but if a function exists in an application as large as WordPress, you can bet it’s there for a reason.
And this one is no different. So when might we actually use a function like this?
If you’re someone who’s in control of a project from beginning-to-end, then there may not be a reason to actually use this. After all, if you’re dealing with all of the data flowing through the application, then you should know how it’s being validated, serialized, and retrieved, right?
But not all software – nor all projects – work like that. Instead, we inherit codebases from other people and we end up needing to fight against some of the decisions that we may not have made when working on the project.
This isn’t to say these are inherently bad decisions, but we’re still fighting against them, nonetheless.
Maybe Unserialize
Anyway, so when we could actually use something like maybe_unserialize
? So imagine that’ve you’ve, say, inherited a codebase from an agency, a client, or someone else, and then you’re responsible for picking up where they left off and moving forward from there.
You dig into the code like a good developer would do in order to understand what’s happening and then you come across this maybe_unserialize
function.
“What?” you think. “I thought things were already serialized.”
There’s some truth to this. But there’s also come confusion around this, too. You can serialize an array as in save it to the database and let WordPress work its magic to save it as a record, or you can serialize an array and then let WordPress save that result to the database.
Then what do you do? Do you just retrieve the information from the database as is? In some cases, sure. In other cases, maybe. I mean, what if you get erratic behavior and you’ve no clue what to do?
Maybe you should try to unserialize the data that’s coming back (see what I did there?).
And that’s but one use of the function. Sometimes, people will be saving data in a way that maybe you wouldn’t save bit, so you need to retrieve it in ways that you wouldn’t normally retrieve it.
So here’s the thing: Maybe the previous programmer didn’t write code the way that you would’ve done it, but maybe we can at least grant him or her the possibility that they had a reason for doing it the way that they did.
After all, are we privy no the context and the variables that played a role in their position? Not likely.
With that said, just roll with it. Better yet, refactor the code – if possible – so that “maybe” you don’t have to do anything and you can save an array and retrieve as you would at any other time.
Whatever the case, don’t judge programmer by their actions – at least in some cases – just judge the code :).
Are there other use cases for this function? I’m sure there are and I’d completely dig how you have used them in the wild so feel free to share them in the comments.
Leave a Reply
You must be logged in to post a comment.