Make WordPress Core

Opened 4 years ago

Last modified 8 months ago

#24726 new enhancement

New filter hook for get_metadata()

Reported by: JD55 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Options, Meta APIs Keywords: has-patch
Focuses: Cc:


The get_metadata() function has one filter hook: get_{$meta_type}_metadata. While this filter can be used to override or short-circuit the return of get_metadata(), it can't easily be used to filter the meta value. In the options API, get_option() has two hooks: pre_option_$option and option_$option. The get_{$meta_type}_metadata corresponds to the former, but it would be useful to have something similar to option_$option that will filter the actual meta value. Maybe get_{$meta_type}_metadata-{$meta_key}?

Attachments (4)

24726.patch (1.1 KB) - added by JD55 4 years ago.
24726.2.diff (1.9 KB) - added by MikeHansenMe 2 years ago.
Refresh and cleanup
24726.3.diff (2.6 KB) - added by MikeHansenMe 21 months ago.
Added Docs and Refresh
24726.4.diff (3.7 KB) - added by jtsternberg 21 months ago.
Add new filter

Download all attachments as: .zip

Change History (19)

4 years ago

#1 @JD55
4 years ago

  • Keywords has-patch added

Added patch with filter get_{$meta_type}_metadata-{$meta_key}.

#2 @nacin
3 years ago

  • Component changed from General to Options and Meta

#3 @sc0ttkclark
3 years ago

As the lead developer of the Pods project, I would also find this useful so we could only cover the fields that the user creates, instead of loading up the Pod config and checking if the field exists for that meta_key.

2 years ago

Refresh and cleanup

#4 @MikeHansenMe
21 months ago

  • Keywords needs-docs added

21 months ago

Added Docs and Refresh

#5 @MikeHansenMe
21 months ago

  • Keywords needs-docs removed

#6 @jtsternberg
21 months ago

Hmm, wouldn't it be preferable to put the new filter up above/below the existing "get_{$meta_type}_metadata" filter? [Like this](https://github.com/WebDevStudios/CMB2/blob/master/includes/CMB2_Field.php#L191-L227).

#7 @sc0ttkclark
21 months ago

+1 on specificity before catch-all filter (meta key filter first)

#8 @MikeHansenMe
21 months ago

I think one difference is that it is passing the meta_value into the filter which is not set until later in the function.

#9 @jtsternberg
21 months ago

Ah, my fault, the purpose of the ticket is to provide a filter on the retrieved value, but I think it also makes sense to have a pre_get filter above the catchall.

21 months ago

Add new filter

#10 @jtsternberg
21 months ago

Updated patch which includes another pre-get filter with the meta-key as a dynamic portion of the hook name (and only if they passed a meta-key), and changed the actual value filter name to "{$meta_type}_metadata_value" since its actual purpose is to filter the value. I also removed the dynamic meta-key from the hook (and instead passed it as a parameter) at that point since we are not guaranteed to have one.

#11 @MikeHansenMe
21 months ago

@jtsternberg, couldn't you just hook on get_{$meta_type}_metadata and check the meta_key that is passed in? Seems to accomplish the same without the additional filter.

#12 @jtsternberg
21 months ago

I think @sc0ttkclark may weigh in as well, but there are many reasons why that would be valuable. Also, it follows precedence with the "pre_option_{$option}" filter: https://github.com/WordPress/WordPress/blob/master/wp-includes/option.php#L45

#13 @MikeHansenMe
21 months ago

yea, thought about the similar implementations after I posted. Makes sense.

#14 @jeremyfelt
12 months ago

#36088 was marked as a duplicate.

#15 @MikeHansenMe
8 months ago

@jtsternberg's patch 24726.4.diff still applies.

Note: See TracTickets for help on using tickets.