WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 5 months ago

#46314 new enhancement

JSON strings in postmeta issue

Reported by: Jonua Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.2
Component: Options, Meta APIs Keywords:
Focuses: Cc:

Description

Using and storing data as JSON is becoming more and more widely used. Also in the course of the increased future use of JavaScript for the WordPress admin area.

JSON strings could be part of an serialized array in the postmeta database value. Unfortunately update_post_metadata() removes all backslashes and may destroyes JSON string syntax if protected quotes are included in the JSON string.

In general all stored backslashes in postmeta will removed whether from a JSON string or part of an code example value etc. update_post_metadata() should not change the value at all. This is what to expect from this and any other function that takes a value to store that value in the database.

update_post_metadata() is used by many plugins and themes without providing wp_slash() to the value before. Is there a chance to solve that problem?

Cheers
Johann

Change History (4)

#1 @subrataemfluence
5 months ago

  • Keywords reporter-feedback added

Welcome to trac!

I think you are talking about update_post_meta() function.

Is this possible to please explain with an use case why and where you want to store an entire JSON string as a meta?

#2 @Jonua
5 months ago

Hi, sorry for the wrong function name. Yes I talk about update_post_meta().

I build a plugin years ago https://de.wordpress.org/plugins/advanced-custom-fields-table-field/ which has more than 20.000 active users now. That plugin adds table editing functionality for the Advanced Custom Fields Plugin. The user editing UI of the table is pure JavaScript driven. To save the table data (a JavaScript object) to WordPress meta, I had to use an input text field. At first glance, it was logical to me, to encode and save the data JavaScript object as JSON string. Well, this was a bad decision resulting in trouble. This annoyance drew my attention to the general problem of update_post_meta() removing backslashes.

I would at least suggest that in the documentation to update_post_meta() should pointed out, if one reads foreign meta data and stores them again with update_post_meta(), that wp_slash() must be applied beforehand, in order not to change the original data.

Thanks,
Johann

Last edited 5 months ago by Jonua (previous) (diff)

#3 @swissspidy
5 months ago

  • Component changed from Database to Options, Meta APIs
  • Keywords reporter-feedback removed

Relevant documentation about this in the plugin developer handbook: https://developer.wordpress.org/plugins/metadata/managing-post-metadata/#character-escaping

#4 @Jonua
5 months ago

Thanks,

great, the documentation is well done and clear. But unfortunately in practice I´m experiencing, that no plugin developer provides wp_slash() before update_post_meta(). Not even well know plugins. Also the ACF Plugin itself didn´t do this until I pointed this issue out to the developer and he agreed to my arguments and fixed it as well other plugin developers to. But I can not contact all plugin developers whose plugin does not use update_post_meta() correctly and breaking the meta values of other plugins.

In practice, with update_post_meta() as it behave now, pure JSON strings can´t stored in meta. Plugin developers will not recognize that issue with update_post_meta(). As I mentioned, the point is that it is not expected that a function that should simply store a value in the database will change that value.

thanks a lot,
Johann

Note: See TracTickets for help on using tickets.