Unserialize error?

[ipstenu]

I upgraded to 3.0 beta for testing and found that a couple plugins are giving me an odd error:

Warning: unserialize() expects parameter 1 to be string, array given in ...

This happens in two different plugins (JournalPress and Google Analyticator). WordPress works with the error, and JournalPress even posts to my blog AND my LJ.

[ocean90]

​unserialize() is a PHP function.

unserialize() takes a single serialized variable(string) and converts it back into a PHP value. 

Please inform the plugin developers, its not a WordPress issue.

[nacin]

It might be from core however, i.e. something that changed from 2.9 to 3.0, but we need to know the line number and more information on how it gets triggered.

Please re-open if you have steps to reproduce.

[ipstenu]

If it had only been ONE plugin, I'd have agreed ocean90, but once it comes up twice, I get suspicious. And it ONLY happened once I upgraded to 3.0 (worked FINE in 2.9.x).

I can reproduce the LJ plugin every time I try and save ANY post while it's activated. And the Google Analyticator one just by trying to view the dashboard 'plugin'.

The problem is I'm the user, not the dev. I'll ping them for support and ask them to come here.

[nacin]

We can't do anything unless we know more about the error. At the very least, line numbers?

[sivel]

If I am correct in my assumption it is something with get_post_meta. I had to update a plugin for WP 3.0 to use maybe_unserialize instead of unserialize because get_post_meta is unserializing the data it returns.

[ipstenu]

I went to some examples for you:

Warning: unserialize() expects parameter 1 to be string, array given in /home/ipstenu/public_html/blog/wp-content/plugins/journalpress/jpconfig.php  on line 696

Warning: unserialize() expects parameter 1 to be string, array given in /home/ipstenu/public_html/blog/wp-content/plugins/journalpress/jpconfig.php on line 703

Warning: unserialize() expects parameter 1 to be string, array given in /home/ipstenu/public_html/blog/wp-content/plugins/journalpress/jpconfig.php on line 709

And I saw sivel's comment. Changing unserialize to maybe_unserialize fixes everything.

Interesting, that. I'm passing it on to the devs.

[nacin]

*sigh*. maybe_unserialize is only half of it. That plugin is trying to unserialize a result from get_post_meta(). The meta, options and transients APIs all handle that transparently. There should be no unserialize call there at all.

[nacin]

After some investigating (thanks sivel), looks like there may be something going on here. I want to look at this some more.

[lupinek7]

The same problem with get_option() – unexpectedly returns unserialized data in 3.0beta-1 (in 2.9 everything worked just fine).

[nacin]

We're looking into this. It comes out of a change to maybe_serialize() in r13673, which for a long while serialized already serialized data, and now no longer does. We'll probably revert this.

Bottom line is, plugin developers are using the _option, _meta, and _transient APIs horribly incorrectly for this change to cause problems.

These APIs already serialize and unserialize objects and arrays transparently. Thus, this works:

update_option( 'my_plugin_options', array( 'blah', 'foo', bar' ) );
get_option( 'my_update_plugins' ); // returns the array

Instead, far too many are doing this:

update_option( 'my_plugin_options', serialize( array( 'blah', 'foo', bar' ) ) );
unserialize( get_option( 'my_update_plugins' ) );

More or less, that means that you're serializing the data, then update_option is serializing serialized data, then get_option is unserializing it once, and unserialize is unserializing it again. r13673 breaks this, as update_option doesn't serialize the data a second time any more, causing the plugin's unserialize() to attempt to perform a second unserialize() on data that was only serialized once.

I will revert the changes in r13673. But please, update your plugins, spread the word.

[nacin]

(In [14074]) Revert changes to maybe_serialize() made in r13673. Do not prevent double-serialization of data. see #12930. see also #12416. xref #7347, r8100, r8372, and others.

[ipstenu]

nacin, thank you very much for tolerating my stupid-head explanation :) I am passing this on to every dev I know!

[cavemonkey50]

I apologize nacin for the incorrect serialization usage in Google Analyticator. Normally I'm aware of that usage of of the options API, but the code that caused a problem was written during a quick coding session and it must have slipped my mind.

Anyway, Google Analyticator 6.0.3 will have this fixed, regardless of what happens in core.

[nacin]

:-) No problems folks. We don't like breaking plugins even if the plugin is 'Doing It Wrong' in the eyes of the API. The change to maybe_serialize() was unintentional so we've switched it back.

[hexalys]

Nacin, r13673 may have addressed those plugin error at the time, but you introduced a new cache defect.

In update_option() where your changed to $alloptions[$option] = $_newvalue; and wp_cache_set( $option, $_newvalue, 'options' );
$_newvalue should be kept $newvalue when it come to the cache, to remain consistent with the way add_option() works.

Right now add_option() store options as serialized while update_option() stores them as arrays which is very inconsistent.
It really messes things up, especially with a memory cache, where you suddenly may get unexpected arrays instead of serialized values, but can't really know for sure what you will get.

[ocean90]

As this ticket was closed as fixed on a completed milestone, please open a new ticket or take a look at #23381

[hexalys]

Replying to ocean90:

As this ticket was closed as fixed on a completed milestone, please open a new ticket or take a look at #23381

OK thanks, I missed that ticket.

[huynhquocnha]

My error :
Fatal error: Uncaught exception 'Exception' with message 'Serialization of 'SimpleXMLElement' is not allowed' in /home2/wp-includes/functions.php:384
Stack trace:
#0 /home2/wp-includes/functions.php(384): serialize(Object(SimpleXMLElement))
at web: ​http://vaytinchapdng.com/

Help me about this error, thank any one !

[dd32]

@huynhquocnha you appear to be passing a SimpleXML element to an options/transient/cache function, which PHP doesn't support. Cast it to a string first or something.

Trac is not a support avenue, please use the ​WordPress Support Forums for further assistence.

[huynhquocnha]

Replying to dd32:

@huynhquocnha you appear to be passing a SimpleXML element to an options/transient/cache function, which PHP doesn't support. Cast it to a string first or something.

Trac is not a support avenue, please use the ​WordPress Support Forums for further assistence.

@dd32 thank