Opened 12 years ago
Closed 12 years ago
#21413 closed enhancement (fixed)
Add Customizer to Appearance submenu as first item
Reported by: | jane | Owned by: | markjaquith |
---|---|---|---|
Milestone: | 3.6 | Priority: | normal |
Severity: | normal | Version: | 3.4.1 |
Component: | Customize | Keywords: | has-patch commit |
Focuses: | ui | Cc: |
Description
I suggest we add the customizer to the Appearance section as its own submenu, and make it first in the list (above Themes). It serves as a one-stop shop for the Appearance section anyway, the main thing that would be needed would be to add in some links in the customizer back to individual Appearance screens.
For label we could go with Customize (should still use Live Preview on Themes screen for not-activated themes), or some other suggestion that's better. Wouldn't be too hard to do some testing to see what label gets the idea across the best.
Attachments (8)
Change History (33)
#3
follow-up:
↓ 4
@
12 years ago
This adds the link, but does not detect whether the customizer is being used or not (I'm not sure how to detect that):
http://pixopoint.com/products/customizer-link/
I'm not entirely sure where this should go in core either, hence it's still only a plugin instead of a patch.
#4
in reply to:
↑ 3
@
12 years ago
It turns out there is no need to detect if the customizer is loaded or not, as it is always used regardless of whether a theme adds anything to it or not.
#5
@
12 years ago
21413.diff adds a (pretty bad) hack to maintain 'themes.php'
as the top level menu location. This would maintain easy backwards compatibility with add_theme_page()
etc.
Since it looks like we get a Menu overhaul anyway this release, maybe we should wait for the new API to be ready?
Somewhat related: #21404, since part of it is adding a "Customize" menu item.
#6
@
12 years ago
Since it looks like we get a Menu overhaul anyway this release, maybe we should wait for the new API to be ready?
Yes, please: #12718
#7
@
12 years ago
Our current menu paradigm (beyond just the API) is that the top-level link must be the same as the first submenu item.
Aside from being a well-established paradigm, this is also important for accessibility purposes. You click the first item to open the submenu (if you don't use the flyout), as an alternative to the old click-to-expand.
A few issues with this. One, this means clicking "Appearance" will open the customizer — this isn't good, because it opens a completely different workflow. While assuming you want to customize your theme is a safe assumption more often than it is wrong, the separate workflow can be jarring if you did want to end up on themes.php.
Two, the Customizer isn't always available. At the moment, this means you:
- have JS enabled, which we need to detect in the browser, client-side.
- you are not using IE7, which we *could* detect server-side, but currently use feature detection in JS, which is preferred.
- are not using IE8 or IE9 if you have a domain-mapped front-end (and your plugin doing the domain mapping does not un-map for the customizer). We currently detect this server-side (to check the URLs) and then feature detection in JS.
That the Customizer isn't always available means "Appearance" will sometimes open up a regular window and other times the customizer, and it won't be easy to establish when exactly it should link to one or the other. ryanhellyer's code works around this to some extent, but overall the request ain't pretty to implement.
#8
@
12 years ago
- Cc xoodrew@… added
What about _not_ setting it as the first submenu item? It would be a nice-to-have since we can currently access it directly via:
- The frontend Toolbar
- The Welcome area
- Appearance > Themes
But if Welcome is hidden, it takes two steps to get there from anywhere in the Dashboard (other than those screens). We can still hide it if no-js in the admin menu, correct?
#9
@
12 years ago
Never saw @nacin's comment 5 months ago, oops! Appearance and Themes are not the same thing, we put Themes first because it was the most important, but Customizer is the closest thing to an overal Appearance view/editor. Yes, it would change the flow. Most UI changes do that to some degree or another, so having to click to click to Themes doesn't bother me if that's specifically where someone wants to be. The real problem is that the customizer takes you out of the dashboard and there are no navigations links. At the time I proposed it, the customizer was supposed to get some 'round 2' attention to make it better than our first release of it. That would need to happen before I'd want it to be a default screen. In meantime, just getting it in the submenu would be a tangible improvement.
#10
@
12 years ago
- Component changed from UI to Appearance
- Keywords ui-focus added
- Milestone changed from Awaiting Review to 3.6
Would be nice to get this resolved in 3.6.
#11
follow-up:
↓ 12
@
12 years ago
- Cc sisir@… added
We could append the link with js/jq. So, any user who don't have js enabled won't see the menu item.
#12
in reply to:
↑ 11
@
12 years ago
- Keywords has-patch added; needs-patch removed
21413.2.diff refreshes 21413.diff. It also cleans up the options list on themes.php to be more uniform: http://cl.ly/image/0H142h3k3M3d
Replying to prionkor:
We could append the link with js/jq. So, any user who don't have js enabled won't see the menu item.
For customizer links we apply the .hide-if-no-customize
class which handles both no-js and any Customizer filters. This is covered in 21413.2.diff.
#14
@
12 years ago
Discussing in IRC today log we discussed addressing Nacin's concerns above, re older IEs and mapped domains. This menu item acts exactly like previous menu items, 3.5 shipped with the link under the currently active theme.
So this new menu item just adds another link with same CSS class for hide-if-no-customize
for hiding the menu item if the browser doesn't support it.
#15
@
12 years ago
21413.4.diff removes the gap from the hidden Customize link on themes.php if no-customize-support. Note the gap that was between the 'Options:' label and the 'Widgets' link: http://cl.ly/image/38090N0Z1T3U
#16
@
12 years ago
Per r20918 we do need the admin-header.php checks in place (was in .2 patch, now reverted in .3 patch).
#17
@
12 years ago
For later testing notes: try with IE8/9 and http://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/ (thanks to ethitter for the reference).
#18
@
12 years ago
- Owner set to markjaquith
- Resolution set to fixed
- Status changed from new to closed
In 23871:
#19
@
12 years ago
- Cc erick@… added
- Resolution fixed deleted
- Status changed from closed to reopened
As Lance noted, without the change in wp-admin/admin-header.php
, the Customize link only appears when viewing themes.php
.
21413.5.patch contains just the change to admin-header.php
that should ensure the Customize link shows consistently.
#21
@
12 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
I'm trying to figure out if there was any final reasoning on why Customize ended up being the first link. I couldn't find anything in the linked IRC logs.
Best I can tell, the current situation — Appearance not going to the customizer, but Customize being the first link anyway — seems worse than the alternatives (Appearance opening the customizer, or Customize being the second link) in of terms of consistency. My comment 8 months ago discussed both paradigms and accessibility. Jen (jane) did reply that a change is okay, but I think she was saying that it was okay that Appearance opened the customizer, not that the links were out of order.
Also, [23871] moved the Customize link on themes.php from before "OPTIONS:" to being one of the options. I imagine that was done simply because that code pulls from $submenu — but it should probably be switched back.
I have a plugin that almost does this, but does not place the link first in the list. I'm working on rewriting it to be first in the list for you at the moment. I'll post a link when it's ready.