Make WordPress Core

Opened 6 months ago

Last modified 6 days ago

#25571 new enhancement

Remove Custom Header Page in favor of the Customizer

Reported by: celloexpressions Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Appearance Keywords: has-patch
Focuses: ui Cc:


We can't really expect theme developers to use the customizer instead of theme options pages if we continue to rely on separate pages for core customization features. Additionally, the custom header screen is a bit of a mess (especially around image uploading, cropping, etc.). I was originally going to propose cleaning it up, but removing in favor of the customizer is a much better solution (also cleans up the admin menu).

The customizer provides a much better way to edit and preview these changes, and merging all of the existing options there will help encourage making the customizer the canonical place to customize themes.

Really, we only need image upload & crop support to fully duplicate functionality in the customizer (everything else's there already). Once that's in place we can look at potential back-compat concerns. Might be slightly worse than the custom backgrounds but I think we should realistically be able to remove the separate "Headers" page entirely.

Related: #25569. Blocked by #21785.

Attachments (1)

25571.diff (2.2 KB) - added by celloexpressions 6 days ago.
Hide "Header" from admin bar when customizer is supported.

Download all attachments as: .zip

Change History (6)

comment:1 dreamwhisper6 months ago

  • Cc dreamwhisper added

comment:2 SergeyBiryukov6 months ago

Probably worth noting that Customizer isn't always available, see ticket:21413:7.

comment:3 westonruter6 months ago

  • Cc weston@… added

As for why header image uploads were removed from customizer, see #21355 and [21383] for context from 3.4.

Last edited 6 months ago by westonruter (previous) (diff)

comment:4 celloexpressions3 months ago

  • Focuses ui added

At first, the page can simply be hidden when the customizer is available (with the inverse process of the one that shows the customizer links - perhaps create a hide-if-customize class). We will also need to contend with the custom_header_options action somehow. Other than that, I think #21785 is the primary prerequisite.

celloexpressions6 days ago

Hide "Header" from admin bar when customizer is supported.

comment:5 celloexpressions6 days ago

  • Keywords has-patch added; needs-patch removed

Now that the Customizer fully supports custom headers, and arguably provides a much better interface for managing them, we can consider this.

Since Headers (and Backgrounds) have always been part of the customizer and are one of the most significant features in the customizer, there is little reason to use the separate pages at this point other than not knowing that the functionality is in the customizer (or the customizer not being available).

I've added a patch to hide the headers link from the front-end admin bar when the customizer is available (it also fixes spacing/formatting of - only actual change is the addition of .hide-if-customize). The admin menu is a mess... the best option I can think of there is to do something like this in CSS:

.customize-support #menu-appearance a[href="themes.php?page=custom-header"] {
	display: none;

That does work, but I was wondering if anyone has a better idea that allows it to stay for no-customize support?

Since a similar iteration of backgrounds in the customizer could potentially happen in the near future, causing the customizer version to surpass that page in usability, these could both go together. The key issue to consider is whether hiding these pages will cause issues for updating users. New users actually tend to have trouble with the separate headers page, expecting that functionality to be in the customizer, from what I've seen. For updating users, a simple pointer on themes.php to the customizer link in the admin menu stating that "Custom Headers and backgrounds can now be managed in the Theme Customizer" would probably be sufficient.

We also need to contend with the custom_header_options action on this page, primarily gauging usage. Anyone using it should be able to port those options to the customizer pretty easily.

Note: See TracTickets for help on using tickets.