Add Customizer to Appearance submenu as first item

[jane]

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.

[ryanhellyer]

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.

[ryanhellyer]

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.

[ryanhellyer]

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.

[ryanhellyer]

Adds customizer link at beginning of Appearances menu in WordPress

[obenland]

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.

[scribu]

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

[nacin]

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:

1. have JS enabled, which we need to detect in the browser, client-side.
2. you are not using IE7, which we *could* detect server-side, but currently use feature detection in JS, which is preferred.
3. 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.

[DrewAPicture]

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?

[jane]

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.

[DrewAPicture]

Would be nice to get this resolved in 3.6.

[DrewAPicture]

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.

[DrewAPicture]

Refreshed and cleanup on themes.php

[lancewillett]

Can we get this into beta-1? Patch looks good in testing.

[DrewAPicture]

remove admin-header.php change

[lancewillett]

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.

[DrewAPicture]

Remove gap from first li on themes.php

[DrewAPicture]

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

[lancewillett]

Per r20918 we do need the admin-header.php checks in place (was in .2 patch, now reverted in .3 patch).

[lancewillett]

For later testing notes: try with IE8/9 and ​http://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/ (thanks to ethitter for the reference).

[markjaquith]

In 23871:

Add "Customize" as first item under Appearance menu.

fixes #21413. props ryanhellyer, obenland, DrewAPicture

[ethitter]

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.

[SergeyBiryukov]

In 23879:

Consistently show "Customize" item in the admin menu. props ethitter. fixes #21413.

[nacin]

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.

[markjaquith]

I can't think of a good reason it would have to be first.

[MikeHansenMe]

switch customizer and themes in menu

[nacin]

In 24048:

Revert [23871] - Customize should be added to the menu, but not hacked in as first. see #21413.

[nacin]

[24048] was supposed to be a straight revert so I could apply a second changeset. Anyway, the patch (as would be applied with [23871] reverted) was simply adding 'customize.php' == $item[2] to themes.php and adding Customize as $submenu['themes.php'][6].

[nacin]

In 24049:

Customize requires edit_theme_options. If you only have switch_themes (rare, but a case that core supports), you should not have access. fixes #21413.