WordPress.org

Make WordPress Core

Opened 21 months ago

Last modified 19 months ago

#25671 new enhancement

get_theme_mods does not have a filter

Reported by: scottsweb Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Themes Keywords: has-patch reporter-feedback
Focuses: Cc:

Description

I am making use of the Theme Modifications API for the first time and using it to store theme customisation options controlled via the theme customiser.

I hit an issue when previewing customisation changes using the refresh transport. The theme modifications functions are not aware of the $_POST'd changes coming from the theme customiser.

Let's say a user has changed a heading colour from red to blue and not yet hit save. The get_theme_mod('heading_colour') function is still returning red in the preview panel. This bug does not overly concern me (it may be that way by design) but to get around it it would be handy to be able to filter get_theme_mods (see patch).

For now I have gone higher up in the API and used a filter on get_option:

add_filter( 'option_theme_mods_' . $theme_slug)

Attachments (1)

theme_mods.diff (450 bytes) - added by scottsweb 21 months ago.
Initial patch with added filter

Download all attachments as: .zip

Change History (9)

@scottsweb21 months ago

Initial patch with added filter

comment:1 @mark-k21 months ago

  • Keywords close added

yes, you have to filter the option itself, but what is wrong with that? What you suggest is just a code bloat which doesn't add any value and is not doing enough to be a "sweetener". And if you truly think this kind of filter is needed then you need to supply another 3 for get,set and delete.

This is just too much work with almost zero added value.

comment:2 @scottsweb21 months ago

No problem. But seeing there is a filter on get_theme_mod, it made sense to me for there to be one on get_theme_mods too. I guess it depends on how standalone / complete each API should be.

comment:3 @rmccue21 months ago

  • Keywords close removed

+1 on this. We should avoid needing to use option_ filters where possible in these higher APIs.

comment:4 follow-up: @mark-k21 months ago

The way I see it, get_theme_mods is an internal function used by *_theme_mod functions. The only reason to call it directly is in a misguided attempt in early optimization or for debugging.

I think it is just need to be documented as internal, otherwise its functionality should match performing multiple calls to get_them_mod and to do that you will need to have a loop that applies the relevant filter to each mod name.

Otherwise, if a new filter will be added like in the patch a plugin that wants to change a specific theme mod will have to hook on both filters.

comment:6 in reply to: ↑ 4 @johnbillion21 months ago

Replying to mark-k:

The way I see it, get_theme_mods is an internal function used by *_theme_mod functions. The only reason to call it directly is in a misguided attempt in early optimization or for debugging.

I think you're misunderstanding the problem. get_theme_mods() is called internally whenever get_theme_mod() is called by the theme. The resulting output is not aware of POST changes made by the theme customiser. If you want to make your theme preview aware of changes made in the theme customiser you need to filter the option return value. As rmmcue said, there should be a higher level filter to abstract it from the storage mechanism.

comment:7 follow-up: @mark-k21 months ago

If you want to make your theme preview aware of changes made in the theme customiser you need to filter the option return value

then why not use the theme_mod_$name filter?, what is the advantage of having a new filter?

comment:8 in reply to: ↑ 7 @nacin19 months ago

  • Component changed from General to Themes
  • Keywords reporter-feedback added

Replying to mark-k:

If you want to make your theme preview aware of changes made in the theme customiser you need to filter the option return value

then why not use the theme_mod_$name filter?, what is the advantage of having a new filter?

I have the same question. Perhaps the customized (for example) is using get_theme_mods() directly? I don't think it is. But seems like the right filter is already in place.

Note: See TracTickets for help on using tickets.