[wp-trac] [WordPress Trac] #62483: maybe_serialize() does support double serialization, but does not inform the developer if doing so
WordPress Trac
noreply at wordpress.org
Sat Mar 1 08:29:14 UTC 2025
#62483: maybe_serialize() does support double serialization, but does not inform
the developer if doing so
-------------------------+------------------------
Reporter: apermo | Owner: audrasjb
Type: enhancement | Status: reviewing
Priority: normal | Milestone: 6.8
Component: General | Version: 3.6.1
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
-------------------------+------------------------
Comment (by apermo):
@TimothyBlynJacobs
Sure I'm happy to.
Well in the first place it was once disallowed 15 years ago, and only
added back for backwards compatibility.
Double serialization does:
**Increase complexity of code and data structures**
Adding manual serialization or worse mixed use of double and single
serialization will decrease code quality and can be a source of bugs. A
custom sniff will likely not be possible to find this.
**Risk of data corruption**
Single serialized code is already a pain to read and while you should not
manually "fix" serialized data in the database, we know that people will
occasionally do so. And having to deal with double serialization will
increase the odds of breaking sites.
**Decrease performance**
While this is out of the scope of WordPress core, and serializing a string
will not be as "expensive" as serializing a complex array, it's still
overhead. If developers properly use the auto-serialization WordPress does
provide, they will save one `serialize()` and `unserialize()` plus get a
very cheap early exit on `is_serialized()` via `if ( ! is_string( $data )
) { return false; }`. This might not be much, but it still adds up.
There might be more reasons, but these are those best to grasp in my
opinion.
----
In addition I've suggested a different approach to take care of this issue
https://github.com/WordPress/wordpress-develop/pull/8434. Instead of
adding a `_doing_it_wrong()` we could as well add a `add_action()` in the
same spot.
This will still allow professionals to easily monitor and improve their
code base and projects. As well as taking @audrasjb's concern into
account, that bystanders will not be annoyed by warnings and prevent
another "loading text domain in time" discussion.
The PR is green, if you guys think that is the better approach, I'm also
happy with it. This will kind of fail the point of making less experienced
developers aware, but still give professional teams a tool to increase
their code quality.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/62483#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list