Meta endpoints shouldn't include meta ids

[danielbachhuber]

meta_id and umeta_id are internal to core, and shouldn't be returned in meta endpoints.

cc @nacin

[danielbachhuber]

I've decided to obscure meta_id in WP-CLI because: 1) it's supposed to be internal in core, 2) meta_id isn't actually used to update entries and is an auto-incrementing column.

See wp-cli/wp-cli#1251

[aryanduntley]

? Isn't meta_id necessary in met endpoints as a return because the only way to update a meta tag is to provide id, key and value? Therefore, meta cannot be updated unless id and key are previously known?

[danielbachhuber]

Core APIs don't support updating meta values by meta_id, but rather the object ID

[aryanduntley]

I apologize, I thought this was in respect to wp-api. WP API is getting and setting meta values by meta_id with get_metadata_by_mid and update_metadata_by_mid. I would prefer not using meta id and work with the key value pair alone as I suggested at the bottom of #322

[danielbachhuber]

Right. It shouldn't be using get_metadata_by_mid()

[rmccue]

I disagree that we shouldn't be using meta ID. There are core functions to use it (get_metadata_by_mid, update_metadata_by_mid, delete_metadata_by_mid) and a (misnamed) function to fetch it (has_meta). The majority of these functions were introduced relatively recently as well (3.3 for *_by_mid, but 1.2 for has_meta).

When updating metadata, keys are not unique, nor is a post ID/key pair unique. Even post ID/key/value is not guaranteed to be unique. This means that in order to be able to operate on singular metadata items, we need some sort of unique ID. We could invent something here, but that seems strange to me given that there's already a guaranteed-unique ID in core for this.

👎, recommend close.

[aryanduntley]

#338

[rmccue]

We talked through this one at WCNYC, and we're all in favour of continuing to use meta ID.