Make WordPress Core

Opened 12 years ago

Closed 8 years ago

Last modified 3 months ago

#12302 closed defect (bug) (wontfix)

add_metadata() Fails to Store Serialized Values as BINARY

Reported by: miqrogroove Owned by: ryan
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Database Keywords: needs-patch close
Focuses: Cc:



WordPress stores corrupt values in post_metadata if there are any non-UTF-8 bytes in the meta_value.

Steps to reproduce:

Call add_metadata() with non-UTF-8 values such as a latin-1 copyright char.

Even though the serialized string goes through prepare() before the query, MySQL is required to truncate the invalid value being assigned to the meta_value field. The result is that the stored value can never be un-serialized.

This behavior can also be replicated by trying to inject CHAR(169) into any UTF-8 table query.

Change History (7)

#1 @miqrogroove
12 years ago

  • Summary changed from add_metadata() Fails to Validate Inputs Before Serializing Them to add_metadata() Fails to Store Serialized Values as BINARY

#2 @miqrogroove
12 years ago

After giving this some thought, I've come to the conclusions:

  1. Post metas are not binary-safe.
  1. There is no way to make them binary-safe without converting all existing values to a proper binary column.

#3 @Denis-de-Bernardy
12 years ago

similar bugs referenced here: #9549

#4 @dd32
12 years ago

  • Keywords needs-patch added
  • Milestone changed from 3.0 to Future Release

Shifting to Future release pending patch, Too close to release to be changing anything related to the Schema anyway.

#5 @bpetty
8 years ago

  • Keywords close added
  • Priority changed from high to normal
  • Severity changed from critical to normal
  • Version set to 3.0

As the MySQL connection and encoding is defined through the global DB_COLLATE and DB_CHARSET definitions on installation, and I don't believe there's ever going to be the possibility that metadata values will ever be re-encoded to a new binary-safe encoding on upgrade, I just don't think this will ever be supported.

If you absolutely need to store non-UTF8 encoded strings or binary data, the best option I can think of is to do so in a custom table with your explicit schema, or somewhere other than in the DB. Otherwise it should be expected that your strings are encoded with whatever DB_CHARSET was in use on installation.

#6 @nacin
8 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Yeah, I don't see this as something we're going to do.

#7 @miqrogroove
8 years ago

Why not? BINARY is compatible with all encodings. The upgrade would be easy. Trivial even. I hear so many WordPress developers complain about this! What a shame.

Note: See TracTickets for help on using tickets.