REST API and protected meta fields

[AlchemyUnited]

After reading this:

http://torquemag.io/working-with-post-meta-data-using-the-wordpress-rest-api/

I kinda have to wonder if the leading _ in the meta field name should be optional in some way. Mind you, per the article, there's a work around / viable solution. But why add those steps if it's as simple as "underscore or not to underscore, that is the question?" :)

[justintadlock]

There really doesn't seem to be any argument for adding an underscore based on that article. It seems to lean toward non-underscore as easier to implement. I don't think we should make this optional. The purpose is to make a standard. If we make the name optional, the entire point of the project is pretty much useless.

If you're adding an underscore to hide your meta keys from the "custom fields" box, drop the underscore and use register_meta() instead.

[AlchemyUnited]

The scenerio I was envisioning - given the API layer (if you will) - was wanting some meta fields to be visable, and others not. For example, personal personnel info. Maybe you wanna to make sure that's not "accidently" exposed.

I hear ya. I understand the nature of the effort. That said, the wisdom of the WordPress way embedded (?) intelligence in the meta field key name. What it is, it is. And I would think that feature might deserves some consideration within the context of this effort - because again, the feature is there and some will want / expect to exercise their right to use it.

btw, fwiw I'm not really concerned about the custom fields meta box.

That's the extent of my input. Feel free to close this if it doesn't matter. NP :)

[justintadlock]

Given that meta fields have to be explicitly exposed via register_api_field(), I don't see an issue. If you don't want them exposed via the API, don't write the code to expose them. No meta can be exposed without registering it with the API, regardless of whether it's protected meta. However, any meta can be exposed, regardless if it's protected, given the right code.

Admittedly, I'm not up to date on the API, so I might be missing something.

[AlchemyUnited]

re: "don't write the code to expose them."

yes, agreed. my point exactly. :)

so when using these standards some are gonna wanna go one way, and some the other. "standard" or not, some will want to deviate. and i was just wanting to suggest that perhaps that moment be anticipated and baked into the spirit of the standards.

also, once I get one of these 3rd party products i might want some other respesentation (so to speak) of the meta data in the context of how I'm approaching the architecture of my application - esp if I'm using the API. I'm thinking the final hands-on dev should get the last say.

I realize this is kinda a non-traditional WP pov, but that's the nature of the API. it's evolving and bending the beast. Put another way, you and I might be cool with some of the quirks of the WordPress way but the API is - I'm expecting - going to open the door to a different crew of devs. And if you're new to WP and using the API I'm gonna say you might not be so happy with some of the WordPress ways. I would want - and expect - control, as much possible.

that's it. time will tell. thanks. i'm going to the mat on this. i was just mentioning a "hey, this feels kinda weird to me." i might be the only one. not the first time ;) nbd.

close it up. :)

[AlchemyUnited]

maybe the simple answer is these standards should always use a leading _ all the time. lock'em down, so to speak, and if need something then you'll have to deal with the "worst case scenerio" (if you know what I mean.)

Maybe this was already covered? If so, just ignore all this then :)

[justintadlock]

I'm getting a bit lost with the conversation, so I want to get us back to the basics. Based on the article you linked to, there's three points of note:

• No meta is exposed by default.
• The only way to make meta exposed is to write some code to expose it.
• Meta can be exposed regardless if it's protected.

The premise of this ticket is to allow for an underscore prefix as part of the meta standard in some way. What's the purpose of allowing the underscore in relation to the REST API?