#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.
Attachments (5)
Change History (25)
#3
@
11 years ago
- Cc weston@… added
#4
@
11 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.
#5
@
11 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.
#7
@
10 years ago
See also #28032: Make Customizer more visible with visual cues on deprecated areas of the admin.
#8
@
10 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.
@
10 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
@
10 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.
10 years ago
#12
@
10 years ago
- 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
@
10 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.
This ticket was mentioned in Slack in #core by celloexpressions. View the logs.
10 years ago
This ticket was mentioned in Slack in #core by celloexpressions. View the logs.
10 years ago
#17
@
10 years ago
- Owner set to ocean90
- Resolution set to fixed
- Status changed from new to closed
In 30459:
Probably worth noting that Customizer isn't always available, see ticket:21413:7.