[Resolved] serialized array in a string field

[Author]

Posts

[emanuelaB]

I used to store a serialized array in a string custom field, and then to manage them in a view, passing the raw data as parameter to a custom php shortcode that reads the string, de-serialize it, and uses the resulting array to return something to display in the view.

It always worked almost until wp-types 1.9.

I've just realized that with types 2.2.23 (and maybe with types 2.x at all) this don't works anymore:

[types field="stringa1" output="raw"][/types]

returns an empty value.

I've checked the meta_value in wp_postmeta table and the format seems to be the same, something like

s:1869:"a:10:{...

could you please help me?

thanks in advance

[Beda]

I am not sure, maybe we introduced some safety check and sanitize the output, although, with the raw set, this should not happen

It is however surely unusual to store such values in a Custom Single Line Field.

Is there no better option to do that?

In any way, please send me a copy of that site so I can have a look.
hidden link
Please exactly elaborate where I can find all needed elements on the duplicate, and how to use them.

If possible please submit me a copy where you already made some basic no-conflict tests like using a native theme, no other plugins, and possibly a minimal code.

I will have a look as soon I have that data

[emanuelaB]

Hi, thanks for your quick reply.

we use that method because we receive those data (a list of external images) from another site that stores that list as serialized arrays.

we have a script that insert this string in a custom field, alongside with a lot of other standard fields managed in a canonical way, so we can use a content model to display standard fields and the php shortcode to generate html code to display images.

maybe it's unusual, and for sure there should be a better way to do that, but that means that we have to rebuild that part of that site (of those sites, we use that method on more than one site, sites that have been working perfectly for years).

I don't understand why, when we specify "raw" format, we get something different from the raw meta_value field, as it happened with older types version: is there a way to restore the old beaviour?

I'm not able, at the moment to send you a copy of the site, but the code we're using is simply

[types field="images" output="raw"][/types]

and database rows are like that

meta_id: <incremental value>
post_id: <related post id>
meta_key: "wpcf-images"
meta_value:
s:1869:"a:10:{i:0;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:19:"Cedral Click Smooth";s:2:"id";s:5:"10674";}i:1;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:17:"Cedral Click Wood";s:2:"id";s:5:"10674";}i:2;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:17:"Cedral Lap Smooth";s:2:"id";s:5:"10674";}i:3;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:15:"Cedral Lap Wood";s:2:"id";s:5:"10674";}i:4;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:18:"EQUITONE Linea 3x2";s:2:"id";s:5:"10674";}i:5;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:27:"Equitone Materia, materiale";s:2:"id";s:5:"10674";}i:6;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:19:"EQUITONE Natura 3x2";s:2:"id";s:5:"10674";}i:7;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:20:"EQUITONE Pictura 3x2";s:2:"id";s:5:"10674";}i:8;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:20:"EQUITONE Tectiva 3x2";s:2:"id";s:5:"10674";}i:9;O:8:"stdClass":3:{s:3:"src";s:78:"hidden link";s:11:"descrizione";s:20:"EQUITONE Textura 3x2";s:2:"id";s:5:"10674";}}";

thanks again, Luca

[Beda]

I assume you use a single line field, as that is where strings are usually added to.

This does not get saved the same way as it's input.
If you could confirm that adding your "string" to a single line field and saving it will produce a different entry in the Database?

It's clearly re-serializing it, destroying the initial value.

I found that saving it with 2 wrapping apostrophes solved the issue:
So there must be some sanitization issue here.

For now, that is the quickest solution.
I will investigate with the Developers why this is happening, and if we allow this sort of value.

[emanuelaB]

Yes, I confirm I'm using a single line field, and I confirm that the serialized array string is serialized again as string: database values is in the form

s:1869:"a:10...

I've tried your workaround, using 2 wrapping apostrophes solved the issue, thanks.

But I've also tried with an old Types version (1.9), and the db value is stored exactly in the same way (serialized string plus array serialized string, s:1869:"a:10...).
What changes is that

[types field="stringfield" output="raw"][/types]

with Types 1.9 returns the serialized array string, with Types 2.x returns an empty string.

Maybe it's changed the way "output="raw" is managed?

Thanks again, Luca

[Beda]

I cannot confirm this.

While with Toolset Types 1.9x the value is truly displayed exactly as saved in the database, updating to Toolset Types 2.x does not break the output, but it strips it from the first occurrence of " onwards.

Moreover, I believe the Single Text line should not create a serialised string in the entry, but a simple string.

I escalated this to the developers, but I cannot grant that it is safe and allowed to store such data in such fields

I will update you in regard.

[Beda]

I think this issue is resolved in the current release?

I tried to replicate this over and over on the fresh copies from the download area of the Toolset Plugins, and as well on existing installs.
This seems to be resolved!

Can you confirm?

[emanuelaB]

Hi
Yes, thanks, I confirm, now I get the correct value for the serialized array, but now I have another big problem.

I tested new plugin release (I presume it's Types 3.0 and Views 2.6) on a development site: luckily, because those updates break content models and views previously defined.

First of all, update Types and Views from Commercial Tabs didn't work: Views update hangs, and I could not even see anymore the Commercial Tabs. I had to delete both plugins and reinstall them uploading zip files downloaded from Toolset site.

Then, content models associated to WordPress post types were no longer visibile, I can see only the "standard" WordPress display.

Enabling Debug Mode, I see that the function used by the theme I'm using (Tagdiv Newspaper) now is seems to be

td_module_single_base::get_content

I did not update the theme, I've been using it for years on many sites, and I've always used only get_content in wpv-content-templates-theme-support-function configuration field.

I'm really scared, if someone updates Types from the WordPress plugin panel, without knowing that he must ALSO change the name of the function, he will not see anymore a large part of the site, I'm afraid.

Is there a way to avoid this?

Thanks, Luca

[Beda]

Views update hangs, and I could not even see anymore the Commercial Tabs

Most likely, this is because the site (Types) was not registered.
Then, it got the 2.3 update which is the free Toolset Types update from WordPress ORG.

As you did already, the solution would be to delete all Toolset Plugins, download them manually from the Toolset repository and re-install + activate them.

No data will be lost, nonetheless, please perform a backup previous to those steps.

I'm really scared, if someone updates Types from the WordPress plugin panel, without knowing that he must ALSO change the name of the function, he will not see anymore a large part of the site, I'm afraid.

Toolset does not change those functions, they are not ours, they are theme's functions, we just detect them.
Have you tried to change the current setting to use the method?

If that does not work, we need:
- a new ticket as this will be a compatibility issue
- a copy of the named theme, in case it's a paid product
- instructions how to replicate the problem.

What may be (but is very unlikely, as it seems to work fine in my tests) is that Views does wrongly detect the function and then that would be a BUG, but I cannot replicate a similar problem when I use custom functions in a theme.

I suspect, this is a compatibility issue with the mentioned theme.
In any case, we will need to handle this in a new dedicated ticket, in case the issue persists.

Thanks!

[emanuelaB]

the development site is registered, but I can confirm that deleting Types plugin and uploading the new version no data were lost.

about the problem, I understand it's another issue, I'm opening a new ticket.

thanks for your help.

best regards, Luca