Opened 7 years ago
Closed 7 years ago
#38082 closed enhancement (wontfix)
Allow negative (placeholder) IDs in calls to get_metadata
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Options, Meta APIs | Keywords: | dev-feedback has-patch |
Focuses: | Cc: |
Description
See #38072 for full background. Nav menu items are created in the customizer with negative IDs to serve as placeholders. This allows such nav menu items to be referenced before writing to the database. This works for previewing nav_menu_item
posts, but it turns out to not work for postmeta for such posts. The reason for this is get_metadata
uses absint
as opposed to intval
and so the placeholder nature of the object ID is dropped. Along with this change the get_metadata
function can short-circuit for such negative IDs after the get_{$meta_type}_metadata
filters apply since no such objects would exist in in the database which uses UNSIGNED INTEGER
for ID fields. As such, placeholder meta would only be supplied via filters.
Attachments (1)
Change History (7)
#1
@
7 years ago
- Keywords dev-feedback has-patch added
- Milestone changed from Awaiting Review to 4.7
#3
@
7 years ago
And #38072 is about removing the use of such negative IDs as placeholders.
Nevertheless, the get_{$meta_type}_metadata
filter is actually like pre
filters elsewhere, as it short-circuits the filter returns a value. It is similar to pre_option_{$option}
in this regard.
Can I just say this feels like a massive hack that should never have been done in the first place, and probably shouldn't be extended to other parts of the codebase? I'd actually prefer anything that *does* allow something like this to be removed, or in the event of a negative ID being passed,
return false
ing immediately before filters.If there was a need to inject "placeholder" items into the structures, they shouldn't be calling/running
get_*($neg_id)
but instead being supplied by some kind of apre_*
filter on the object getters..