WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#25571 closed enhancement (fixed)

Remove Custom Header Page in favor of the Customizer

Reported by: celloexpressions Owned by: ocean90
Milestone: 4.1 Priority: normal
Severity: normal Version:
Component: Customize Keywords: has-patch commit
Focuses: ui Cc:

Description

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 (5)

25571.diff (2.2 KB) - added by celloexpressions 6 years ago.
Hide "Header" from admin bar when customizer is supported.
25569-25571.diff (3.2 KB) - added by celloexpressions 5 years ago.
Link header and background to Customizer in the admin menu when it's supported, only show them in the admin bar when the Customizer isn't supported.
25569-25571.2.diff (3.4 KB) - added by celloexpressions 5 years ago.
With deep-linking.
25569-25571.3.diff (4.9 KB) - added by westonruter 5 years ago.
https://github.com/xwpco/wordpress-develop/pull/50
25569-25571.4.diff (5.0 KB) - added by ocean90 5 years ago.

Download all attachments as: .zip

Change History (25)

#1 @dreamwhisper
6 years ago

  • Cc dreamwhisper added

#2 @SergeyBiryukov
6 years ago

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

#3 @westonruter
6 years 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 years ago by westonruter (previous) (diff)

#4 @celloexpressions
6 years 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.

@celloexpressions
6 years ago

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

#5 @celloexpressions
6 years 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.

#6 @SergeyBiryukov
6 years ago

#28584 was marked as a duplicate.

#7 @westonruter
6 years ago

See also #28032: Make Customizer more visible with visual cues on deprecated areas of the admin.

#8 @celloexpressions
5 years ago

  • Keywords has-patch removed
  • Milestone changed from Awaiting Review to 4.1

Per this week's dev chat, we'd like to do this in 4.1, especially with Twenty Fifteen's emphasis on this feature.

Three options:

  • Hide the link for users who can access the Customizer.
  • Show the existing link for users who can't access the Customizer, and a deep-link into the Customizer for users who can access it. Requires #28560.
  • Remove the link from the admin menu entirely, potentially removing related code/files.

We also need to decide whether we want to bother continued maintenance of these screens and whether we can close the numerous tickets related to them.

@celloexpressions
5 years ago

Link header and background to Customizer in the admin menu when it's supported, only show them in the admin bar when the Customizer isn't supported.

#9 @celloexpressions
5 years ago

  • Keywords has-patch added

It ended up making more since to do one patch for both this and #25569 to avoid conflicting patches, and we'll need to keep the backgrounds ticket open until #21483 is completed for tracking (whereas we're good to go for headers, as they already have media library support).

25569-25571.diff should be committable now, then we can add the deep-linking once that's ready (and it isn't even necessarily needed). Now would be a great time for any suggestions on alternate implementations if we do want to wait. I went with the deep-linking approach, as that's what the consensus was during the Customizer meetings and there don't seem to be other strong opinions one way or another. Unfortunately, the best way to implement hiding the existing links when the Customizer is supported is with CSS, but I think it's reasonably clean, especially relative to the other options.

This ticket was mentioned in IRC in #wordpress-dev by celloexpressions. View the logs.


5 years ago

@celloexpressions
5 years ago

With deep-linking.

#11 @celloexpressions
5 years ago

Refreshed patch includes deep-linking, which is now implemented and will bring users right to the corresponding sections in the Customizer. Should be ready for commit. Fixes this ticket, also basically #25569, but we should leave that open for tracking in relation to #21483.

#12 @westonruter
5 years ago

In 25569-25571.3.diff:

  • Remove todo comment and normalize alignment
  • Restore Header/Background links to admin bar but deep-link to Customizer
  • Deep-link to Background/Header controls instead of sections

Changes: https://github.com/xwpco/wordpress-develop/compare/e4d8e43...24c33e5

@celloexpressions: I realized a gotcha for Customizer deep-linking replacing these admin pages: what if the background or header controls are flagged as not being contextual for the homepage (i.e. 'active_callback' => function () { return ! is_front_page(); })? This would result in the header and background being completely inaccessible :-(

#13 @celloexpressions
5 years ago

  • Keywords commit added

I don't think we need to worry about people making these contextual - header image might be, but if it is it's more likely to be available on the front page than not, and users can still get to these by navigating around in the Customizer. The main point here is to move away from the poor UX that the old pages have, attempting unsuccessfully to preview the header/bacground in the admin. Additionally, the functional UI is much improved for both headers and, with #21483, backgrounds in the Customizer.

This looks good to go.

#14 @ocean90
5 years ago

What about current_user_can( 'customize' )?

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


5 years ago

#17 @ocean90
5 years ago

  • Owner set to ocean90
  • Resolution set to fixed
  • Status changed from new to closed

In 30459:

Customizer: Use deep-links for Backgrounds, Headers, and Widgets.

Replace links in admin menu and toolbar to Custom Background/Header screen with deep-links to the Customizer section.
On the Widgets screen display a link to the Customizer widgets panel.

props topher1kenobe, rzen, celloexpressions, westonruter
fixes #25569, #25571, #28032.

This ticket was mentioned in Slack in #core-themes by philip. View the logs.


5 years ago

#19 @ocean90
5 years ago

In 30657:

Make notices added in [30459] less ugly.

see #25569, #25571, [30505].

#20 @ocean90
5 years ago

In 30793:

Themes: Use Customizer deep-links inside the theme modal.

props DrewAPicture, ocean90.
see #25569, #25571.
fixes #30553.

Note: See TracTickets for help on using tickets.