If you have been banging your head against the proverbial brickwall trying to debug a intermittment post_meta bug then this may help.
I googled all aspects, but did not find any post to shed light. Eventually figured it out….
Put simply:
- get_post_meta() is case sensitive on the meta-key
BUT
- update_post_meta is NOT case sensitive
Thus If there is a pre-existing meta record with a key in UPPERCASE, then one can
- issue an update for a lowercase key that will
- update the UPPERCASE key, and not create a lower case record. (Usually update will ‘add’ if no record exists).
Delete_post_meta() has the same behaviour – you can try to delete a lowercase key, but the uppercase version will get deleted (too?)
Then of course when you try to fetch with your same lwoercase key that you did the update with, the fetch will fail as it does not exist – only the uppercase key exists.
That was fun trying to debug……
See trac ticket raised for details or progress.
Mysql db collation
It seems it has a lot to do with the mysql db collation being used. The default in many db setups is a _ci (case insensitive one) – they are faster and give more ‘natural’ sort orders, although that very much depends on the language you are using.
The get_post_meta behaves differently apparently because wordpress caches the data so one is not necessarily querying the database.
If you are keen to know more, see