Opened 8 years ago
Closed 4 years ago
#39449 closed enhancement (duplicate)
`customize_loaded_components` filter is too late for themes
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Customize | Keywords: | needs-patch |
Focuses: | Cc: |
Description
As a WordPress theme developer, I want to remove nav menus from the Customizer when the theme doesn't make use of widgets or menus.
The customize_loaded_components
filter fires on plugins_loaded
though, which mean my theme can't use it to filter components to load. Instead, I have to use an imprecise set of remove_action
and remove_filter
calls.
It would be better to have an explicit API for themes to filter which components to load.
Previously #33552
Change History (4)
#2
in reply to:
↑ 1
@
8 years ago
Replying to dd32:
For that specific use-case of what you're requesting here, wouldn't it be better for the Customizer to just not register the menu components
if ( ! $supports_widgets && ! $menu_locations )
?
Yes, I think this is sensible behavior.
I know the menu components are still loaded if no menus are registered when the menu widget is present, but it doesn't make sense to load the menu components if widgets aren't available either.
#3
@
8 years ago
- Keywords needs-patch added; dev-feedback removed
- Milestone changed from Awaiting Review to Future Release
It may be possible to defer the initialization of the components until after_setup_theme
, which is what would be required if we're to let the theme configure which components are loaded. There may be some unintended dependencies on the current early init, however. Will need investigation.
#4
@
4 years ago
- Milestone Future Release deleted
- Resolution set to duplicate
- Status changed from new to closed
Not showing menus or widgets based on theme supports seems like the most common need for this, and potentially a better fix than changing when the filter fires. #38967 also suggests that approach, so marking as a duplicate for now.
This could be reopened if there are other use cases for the filter running earlier.
For that specific use-case of what you're requesting here, wouldn't it be better for the Customizer to just not register the menu components
if ( ! $supports_widgets && ! $menu_locations )
?