Ryan McCue has done another in-depth API-explainer, this time on the state of handling meta with the API. His post is a great exercise in understanding some of the complexity of assuming things (or not assuming things) with the API, and more specifically in learning the details of why auto-discovering meta in the API is such a challenge.
Some key points:
- WordPress has a goofy way of defining protected versus unprotected meta (the underscore prefix), which people use pretty willy nilly in regard to whether meta really should be actually private, or not private.
- But if the underscore prefix is used, it then won’t show up in the custom fields metabox (I personally always use it, purely to avoid meta showing up there).
- You can store anything in meta, including (for an example that’s all to realistic) a serialized object (which Ryan notes can then be instantiated when unserialized, causing a convenient attack vector for remote code execution, yay!).
- There isn’t a way too filter protected (underscored) meta, to change whether it should be protected.
- Permissions with meta are generally ambiguous, so ever assuming meta should be viewable (or rather, auto-discoverable via the API) is a tricky business.
It’s fun already, right?
Well, there’s a ticket (part of the plan Jeremy Felt documented at the A Day of REST hack day) that’s a real sticking point for helping solve these problems. And the ticket needs some attention before all that much can be concluded with regard to meta and the API. Basically, developers need to be able to say more about their intentions for meta data when registering it. That would allow the API to have better checks, and more reliably auto-discover meta in the API without unintended consequences.
But this ticket needs lots of eyes. And meta is likely not going to progress much without eyes, opinions, and decisions. So, it’s important that people that have opinions on the matter speak up!
These problems aren’t insignificant, but can be solved. Ryan and the other leaders of the WordPress REST API would like to see stronger, fuller meta support in the API. But they don’t want to wait on solving these particular problems (at the core level, not the API level) before shipping.
