Faster maybe_unserialize

[hakre]

In #14429 many have taken care to optimize the is_serialized speed.

The function is of good general value and most often used to "maybe" unserialize.

It was originally smabauers who reminded that it's only about to check what it's about to check.

Option values, if serialized are only serialized Array, Objects or Strings. No exceptions. And they are always trimmed strings.

As is_serialized() is of general use and might be used by plugin authors, maybe_unserialize can get a new playmate.

introducing is_serialized_maybe

Option values, if serialized are only serialized Array, Objects or Strings. No exceptions. And they are always trimmed strings.

This is an incorrect assumption - the API allows you to provide already serialised data if you want.

Replying to westi:

Option values, if serialized are only serialized Array, Objects or Strings. No exceptions. And they are always trimmed strings.

This is an incorrect assumption - the API allows you to provide already serialised data if you want.

Well that's what for the "or Strings" part of my sentence is about. You must have just missed it, my sentence is very correct indeed.

Replying to hakre:

Replying to westi:

Option values, if serialized are only serialized Array, Objects or Strings. No exceptions. And they are always trimmed strings.

This is an incorrect assumption - the API allows you to provide already serialised data if you want.

Well that's what for the "or Strings" part of my sentence is about. You must have just missed it, my sentence is very correct indeed.

No it's not - what about serialized integers?

Replying to westi:

Replying to hakre:

Option values, if serialized are only serialized Array, Objects or Strings. No exceptions. [...]

No it's not - what about serialized integers?

I've created a table in my post ​Serialization in Options: Cant see the Wood for the Trees that handles each data case and tells whether it is serialized in options or not. It's the first table.

The "Option Values" I talk about are those that come from the database, not those that are returned by get_option(). That function will always return the unserialized value, in case of your serialized integer, the serialized integer.

If you look into the code of the patch, it becomes clear about what functions this is about.

Does this helps to better understand?

Replying to hakre:

Replying to westi:

Replying to hakre:

Option values, if serialized are only serialized Array, Objects or Strings. No exceptions. [...]

No it's not - what about serialized integers?

I've created a table in my post ​Serialization in Options: Cant see the Wood for the Trees that handles each data case and tells whether it is serialized in options or not. It's the first table.

The "Option Values" I talk about are those that come from the database, not those that are returned by get_option(). That function will always return the unserialized value, in case of your serialized integer, the serialized integer.

If you look into the code of the patch, it becomes clear about what functions this is about.

Does this helps to better understand?

Not really.

You are still making an assumption: You are assuming that the only place maybe_unserialize is ever used is for unserializing things which have been maybe_serialized - you are changing it's behaviour by not supporting all types of serialized data.

It has had this behaviour since WordPress 2.0 - we are not going to break it!

Replying to westi:

You are still making an assumption: You are assuming that the only place maybe_unserialize is ever used is for unserializing things which have been maybe_serialized - you are changing it's behaviour by not supporting all types of serialized data.

That's no argument against the enhancement itself. If maybe_unserialize is not the right place for that enhancement, it's easy to find that right place.

It has had this behaviour since WordPress 2.0 - we are not going to break it!

I never said I want to break it, keep cool.

Related: #17375