WordPress.org

Make WordPress Core

Search Results for: gallery Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 8:02 am on January 29, 2014 Permalink

    Gallery 

    19 open tickets. Last 7 days: +0 tickets

    19 open tickets defect (bug) enhancement feature request
    Awaiting Review 4 5 1
    Future Release 6 1 2
     
  • Robert Chapin 8:05 pm on July 23, 2015 Permalink |
    Tags: , ,   

    Changes to the Shortcode API 

    Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API. Due to the nature of the fix – as is often the case with security fixes – we were unable to alert plugin authors ahead of time, however we did make efforts to scan the plugin directory for plugins that may have been affected.

    With this change, every effort has been made to preserve all of the core features of the Shortcode API. That said, there are some new limitations that affect some rare uses of shortcodes.

    Reminder: Never, under any circumstances, should you hack core files. This includes downgrading specific files. Doing so could have unintended consequences on your WordPress installation, including major security implications.

    Basic Shortcode Usage

    A brief explanation on the original purpose of shortcodes will help to explain the change. In a basic post, like this example, shortcodes are used to insert dynamic code:

    Here are my images. [gallery]

    Here you can see that the shortcode stands on its own as a dynamic element within the blog post content. This is the central premise of the Shortcode API: make it easy to insert blocks of dynamic code.

    Shortcodes with Filtered Styles

    In today’s release of WordPress 4.2.3, however, we’ve added some new limitations that affect some existing plugins. Take, for example, the following shortcode, which is no longer recognized:

    <div style="background-image: url('[shortcode]');">

    The shortcode in the example above appears in a context that is no longer supported. Further, this use of a shortcode stretches the imagination for how the Shortcode API was intended to be used. Fortunately, there are some workarounds still available, so that site administrators are not overly restricted in their use of HTML.

    Workaround

    The following example still functions as expected and is considered more acceptable:

    <div [shortcode]>

    Going forward, plugins implementing shortcodes for inline styles should output the entire style attribute rather than a bare value. Keep in mind that this workaround – just as the original example above – is only available to administrators and editors (i.e. only roles with unfiltered_html). Less-privileged users are still prevented from using shortcodes to output whole attributes in this manner. If a plugin is intended to work with author and contributor roles, we recommend that the plugin output an entire <div>.

    Shortcodes with Bad Quotes

    The following example is also no longer allowed:

    <a href="/[shortcode query="?ref="]">

    In the above situation, the shortcode is now properly recognized as HTML and it is rejected by the API. Apart from the example being confusing, WordPress cannot parse that shortcode.

    Workaround

    Instead, either of the following examples would be appropriate:

    Example 1: <a href="/[shortcode query='?ref=']">
    Example 2: <a href='/[shortcode query="?ref="]'>

    Administrators as well as lesser-privileged authors can continue to use shortcodes in this way, as long is it conforms to the usual HTML filtering rules. However, as explained in the first example, administrators are now somewhat limited in this situation in one case: if the content in this href attribute is generated by a shortcode that does not conform to the HTML filters, then the shortcode is rejected for all users.

    We do not make this change lightly and understand that it may affect some usecases. The above examples and explanations should help plugin authors make the modifications needed to support the Shortcode API.

     
    • Mickey Kay 9:30 pm on July 23, 2015 Permalink | Log in to Reply

      And. . . half our client sites just broke :)

    • Dave Navarro, Jr. 9:55 pm on July 23, 2015 Permalink | Log in to Reply

      may affect “some” usecases…

      LOL! How about, you broke half the internet without so much as a “howdy do”.

      And if it worked before, why exactly can’t it work now? I am still not understanding why it had to change. WordPress itself was not intended for many of its uses today, are you going to start forcing people back into blogging? Designers/developers made better use of it than you intended and you don’t like that?

    • arippberger 9:56 pm on July 23, 2015 Permalink | Log in to Reply

      Can we get a list of the affected plugins?

    • Dave Navarro, Jr. 10:07 pm on July 23, 2015 Permalink | Log in to Reply

      Every single plugin that adds shortcodes that could be used inside of an HTML element. Not because it’s a security issue, but because someone doesn’t like how we play with our toys in their sandbox.

    • kitchin 10:12 pm on July 23, 2015 Permalink | Log in to Reply

      The shortcode API has never been well-defined, as far as I know. What html is allowed in a shortcode, and how shortcodes are allowed in html tags has changed over time. Scanning for the use case above would be difficult since it would involve the help files and sample tags shown to users, which may be formatted with sprintf, etc.

      The API should be defined. The test cases are the de-facto definition, but they are ad-hoc and clearly not complete. It’s very complex, with nesting issues and all the rest.

      I don’t know the security bug, but I wonder if malicious uses could have been filtered out more directly as a short-term fix, until the API was rewritten.

      • kitchin 10:20 pm on July 23, 2015 Permalink | Log in to Reply

        As a further example of complexity, many people are not aware that < and > are legal characters in html attributes, and some authors use them, for instance in sample code in the jQuery plugin Cycle2.

        The shortcode API was never intended to contain a complete html parser, and never claimed to. But it also did not strictly limit html or quoting, as it should have. Really it should have allowed either tags in html or html in tags but not both. Too late now.

    • Braad 10:19 pm on July 23, 2015 Permalink | Log in to Reply

      We’re experiencing some major frustration as a result of this change, and now plugins like Toolset’s Types and Views are basically non-functional. There are a lot of confused and unhappy people filling up their support forum right now: https://wp-types.com/forums/topic/types-shortcode-breaks-after-wordpress-4-2-3-autoupgrade/

      Even if this was a necessary change, it’s one that has far reaching implications, and it would have been nice to get a heads up that this was coming so we could have prepared. A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

      We’re already seeing people on support forums tell each other to just replace the shortcodes.php file with the version from 4.2.2, which as Mark Jaquith has pointed out is not a good idea, but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

      • chriscct7 10:49 pm on July 23, 2015 Permalink | Log in to Reply

        A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

        As stated above, this was not possible.

        but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

        The majority of WordPress users who are not developers will not know how to replace a file on a remote web server.

        • Braad 12:31 am on July 24, 2015 Permalink | Log in to Reply

          Saying something like “Here is a use case for Shortcodes that will no longer be supported” is different from saying “Here is a security vulnerability and how you exploit it”. I have a hard time believing that some form of notice couldn’t have been given, even if it was only given a day before the update.

          But that said, the core devs who deal with this stuff are in a tough position and deserve a big thanks for their hard work. Hopefully they can find a way to keep supporting the affected shortcode use cases while still keeping things secure.

    • Angelika Reisiger 10:20 pm on July 23, 2015 Permalink | Log in to Reply

      Sorry, please delete my previous two posts. I could not post the complete code snippet.

      So here again:

      I tried to follow your recommendation in the article. But whatever I try, it does not fix the issue ticket #33097
      Below is the code:

      http://pastebin.com/8xvN2eb1

    • mvandemar 10:41 pm on July 23, 2015 Permalink | Log in to Reply

      This change is listed as “Improve the reliablity of shortcodes inside HTML tags.” It says absolutely nothing about this being a security issue. Do you have a link to the actual security issue this change fixed?

    • James Huff 10:44 pm on July 23, 2015 Permalink | Log in to Reply

      Thanks for doing this, both the security fix and the write-up!

      I appreciate that the concern was on security over functionality. Existing functionality can always be fixed, and sometimes a better way of doing things is found, but recovering from a security vulnerability is a *nightmare*.

      Thanks again for keeping us safe!

      • Dave Navarro, Jr. 10:56 pm on July 23, 2015 Permalink | Log in to Reply

        Nothing in this write-up says that this is a security issue. Nothing in the release notes say this is a security issue. This is about how they don’t like how shortcodes are being used, so they put a stop to it. And I guess if they don’t like it, they can change it. But if it’s not a security issue, why change it in a security release without any notification so that it breaks hundreds of thousands of web sites? Why not announce “in 4.3 your shortcodes aren’t going to work anymore” and release it then? Well, because someone messed up and merged the update into core prematurely. So rather than fix the mistake, just roll with it…

        • James Huff 11:00 pm on July 23, 2015 Permalink | Log in to Reply

          Nothing in this write-up says that this is a security issue.

          It’s in the very first sentence, “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You’re welcome to form whatever theory you’d like to, I’m just reflecting the published facts.

          As far as I see it, the developers had to make a choice, security or functionality. They chose security over functionality, and I’m thankful they did. It’s the right choice.

        • mvandemar 11:01 pm on July 23, 2015 Permalink | Log in to Reply

          @Dave – the very first sentence in here says that it is a security issue:

          “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You are correct though that nothing in the release notes, or the bug track that I can see, indicates that this is the case.

    • Curtiss Grymala 11:07 pm on July 23, 2015 Permalink | Log in to Reply

      First of all, I want to say that I do truly appreciate the quick security fix, and I fully appreciate how much work is going into keeping this codebase up-to-date.

      Granted, the original example I originally posted in my trac ticket (<a href="/[shortcode query='?ref=']">) was a bit confusing, but I don’t necessarily agree with the idea that this can’t be fixed just because it’s “invalid inout”. A perfectly reasonable example could have been something more like <img src="[post-thumbnail size="thumbnail" id=55]" alt="I want an alt attribute"/> (maybe an example where you want the user to be able to dynamically reference the featured image of another post) or something like that. I don’t see that example being confusing at all, but the results, for most users, will be terribly confusing.

      As someone else already mentioned, this had a major effect on the functionality of the Toolset (Views) plugin, but it also has major implications on a number of other plugins, and, due to the fact that these changes only occur inside of HTML tags (so things may not be visibly broken), it may be a long time before people fully realize how much of their sites are broken.

      Normal users will not understand why things don’t work; they’ll just know that they don’t work (as we have seen from all of the reports blaming the authors of Types & Views for these new issues).

      As plugin authors, we are now responsible for telling users that, if they want to use double quotes in their HTML tags, they have to wrap their shortcode attributes in single quotes. However, if, for some reason, they want to use single quotes in their HTML tags, then they have to wrap their shortcode attributes in double quotes. As if that’s not confusing enough; if we try to help our users out by building an MCE plugin that auto-inserts our shortcodes, we either have to build it to be smart enough to recognize whether there are single quotes or double quotes around the selection, or we’ll have to tell our users to change the tag because it won’t work this way.

      I, better than most, understand just how difficult fixing this issue can be without rolling back the fixes/changes that were released today, but I am not excited about the prospect of breaking so many existing implementations just because it’s tough to come up with a fix. I hope that some minds greater than mine will continue to look into possible solutions for this issue (not necessarily the background-image example, but at least the quotes-within-quotes issue), rather than just writing it off as a won’t-fix.

      • Ipstenu (Mika Epstein) 11:19 pm on July 23, 2015 Permalink | Log in to Reply

        For those playing at home, the trac ticket is https://core.trac.wordpress.org/ticket/33102

        • Curtiss Grymala 11:44 pm on July 23, 2015 Permalink | Log in to Reply

          Thanks, Mika. I probably should have included that link in my reply.

          Also, again, I want to make it clear that I’m not complaining about the security fix (I hope I’m not coming across that way). I agree 100% with @macmanx above, in that I’d much rather have to go through and fix code issues for clients (even if I have to do so for free) than have to deal with security intrusions.

      • Dave Navarro, Jr. 12:11 am on July 24, 2015 Permalink | Log in to Reply

        Custom Content Shortcode, Advanced Custom Fields, and hundreds of other plugins. This isn’t “just a few plugins” or “just a few sites”.

        And if it’s a legit security issue (I still don’t see it that way), then fine.. but handle it better. “We just couldn’t do it is a BS excuse.” And even if you couldn’t, you still should have posted a HUGE MONSTER post about the issue immediately so that there weren’t lost hours of trying to figure out the problem.

        Again, this was VERY VERY poorly handled and all I’m seeing are excuses.

    • mvandemar 11:19 pm on July 23, 2015 Permalink | Log in to Reply

      Actually, I see it now. The fixer of the XSS vulnerability is the same one who owns the bug ticket, namely miqrogroove. Someone just let me know that was where the actual issue was.

    • Mickey Kay 12:20 am on July 24, 2015 Permalink | Log in to Reply

      Third times a charm. . .

      Just to provide another example, in case it’s helpful, of the issue as experienced when using the Types & Views plugins (which seem to be a pretty huge use case based on feedback re: this issue).

      One example of how we might commonly use shortcodes within a Views template to output custom fields:

      <a href="[wpv-post-url]" title="[wpv-post-titlle]" rel="nofollow">[wpv-post-titlle]</a>

      If I had to guess, I would venture that we have upwards of 100+ sites we’ve built that use some form of the above example – all of which are now in theory broken.

      Just for clarification, can you illuminate how this is any more of a security risk than using PHP to spit out the custom field directly? Is it an issue of validation/sanitization? If that’s the case, then why is the decision being made to force a certain format, when validation and sanitization are the developer’s burden in all other cases (custom fields, theme options, customizer controls, etc)? Am I missing something?

      Thanks, and appreciate the open ears to all the feedback (however rough it might be getting at times :)

    • Mickey Kay 12:23 am on July 24, 2015 Permalink | Log in to Reply

      Goodness, this is ridiculous – tried 3 methods to include my code. How the heck do you include code in here? Not normal markdown?

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        It’s not markdown at all. Use code tags.

        <code>

      • Curtiss Grymala 12:49 am on July 24, 2015 Permalink | Log in to Reply

        You have to encode the angle brackets yourself (type the ampersand symbol, followed by either “lt;” or “gt;” – so, &lt; gets turned into <)

      • Samuel Wood (Otto) 8:52 pm on July 24, 2015 Permalink | Log in to Reply

        Perhaps unsurprisingly, we use shortcodes for that. The word “code” in square brackets will do the job for you on the make blogs.. Use “/code” to close the block.

        Example of code
        

        You can also use “php” for PHP code and “css” for CSS. Then it will have syntax highlighting as well.

        <div> html works too, it will encode the brackets for you </div>
        

        I fixed your most recent comment to have the correct syntax.

    • Dave Navarro, Jr. 12:23 am on July 24, 2015 Permalink | Log in to Reply

      So Gary Pendergast and others have convinced me that there really was a security issue, so my apologies for claiming it wasn’t. However, it still comes down to someone not taking the time to fix the security issue WITHOUT breaking so many live `web sites`.

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        Sadly that’s not always a tenable option.

        Once a security issue is known, it’s a mad race against time to get it patched before news gets out and people get hacked.

        • Dave Navarro, Jr. 12:56 am on July 24, 2015 Permalink | Log in to Reply

          Okay, well, I still think they could have make THIS post at the time the update was released and saved a lot of wasted time trying to figure out why sites didn’t work anymore…

          I’m gonna go see if I can find a snickers and if it will make me less cranky. I’ve bitched about this enough that someone on Facebook challenged me to do a better patch… Sadly regular expressions are a major weakness in my dev skills, but I’m gonna try anyway. There’s got to be a way to fix the security problem AND keep the prior functionality.

        • Timothy Jacobs 8:54 am on July 24, 2015 Permalink | Log in to Reply

          That is true in many cases, but not this one. The bug was disclosed in November of last year. Both were responsibly disclosed. And if you look at the trojan emoji security release, the core team has the ability to work on a patch for a long time. There simply wasn’t enough testing done before releasing this patch.

          • chriscct7 9:03 am on July 24, 2015 Permalink | Log in to Reply

            There was a heck of alot of testing done. However regardless of the amount of testing the way less than 1% of 1% of 1% of people use shortcodes makes it impossible not to break sites. For example: nested shortcodes inside of a single html attribute with mixed quotes.

            • Timothy Jacobs 9:23 am on July 24, 2015 Permalink

              I know not all bugs can be caught, but Views & Types seems to have quite a large user base… It just seems that the amount of testing done for this is much less than the trojan emoji bug.

    • mountainguy2 3:25 am on July 24, 2015 Permalink | Log in to Reply

      Downdate 4.2.3 broke my main site, took me 6 hours this morning to fix as I’m a total amature. These automatic updates are the height of lameness. It needs a one-click revert function, as well as a one-click revert that can be done somehow if admin access is broken, as happened to me.

      What is more, near as I could tell from reading, I was at risk for none of the vulnerabilities, I thus had my site broken for no good reason. Again the height of lame.

      MTN

    • codepage 4:42 am on July 24, 2015 Permalink | Log in to Reply

      this fix has broken easy 2 douzen websites of mine plus more of partners of mine. many plugins are broken. i’m working a lot with shortcodes and attributes in my designs. i have no idea on how to hack stuff where only the path is saved and i have for example an id as attribute. please fix this!

      • codepage 4:45 am on July 24, 2015 Permalink | Log in to Reply

        i use plugin OptionTree to make designs configurable. eg:
        <img src="[getoption">

        broke. how am i supposed to fix this? having the customer fill in the html code in a text field? that sucks.

    • lkraav 5:05 am on July 24, 2015 Permalink | Log in to Reply

      Following

    • Shailesh 5:51 am on July 24, 2015 Permalink | Log in to Reply

      Is this change also affect this case?

      <a href="[homeurl]/contact" rel="nofollow">Contact Us</a>

      In most themes I am using [homeurl] and [themeurl] to make dynamic url in links. So I don’t need to worry when I move site from local to live or sub directory to main.

    • Sam Rohn 6:04 am on July 24, 2015 Permalink | Log in to Reply

      here is an easy fix, this resolved WP 4.2.3 breaking some s2member shortcodes on one of my sites

      use single quotes ' for html attributes surrounding the shortcode, and double quotes " for the shortcode’s own attributes

      like this

      a href='[shortcode value="foo"]'

      NOT like this

      a href="[shortcode value="foo"]"

    • twinsmagic 6:39 am on July 24, 2015 Permalink | Log in to Reply

      I’m trying to get this to work:

      I also tried

      @Sam Rohn, your suggestion didn’t work for me unfortunately.

    • AmirHelzer 9:00 am on July 24, 2015 Permalink | Log in to Reply

      We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.

      This is a straight forward change, which takes us one day to complete.

      Would have been great to receive a heads-up about an upcoming change in WordPress, so we could do this change on time.

      We received a huge amount of support requests due to this, but this isn’t the issue. We can deal with a wave a support issues. This time it wasn’t “our fault”, but sometimes it is.

      What worries us, as mentioned above, is seeing our clients (folks who build WordPress sites for a living), losing their faith in the system. They feel like the system sees them as little ants and not as humans. People don’t like seeing their problems being dismissed.

      Many of them run hundreds of sites. They cannot afford to stop everything and fix content on so many sites. Especially not if they are currently away for their family vacation.

      What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.

      We are your partners.

      Without WordPress (secure, stable and reliable), we would not exist.

      Without great themes and plugins, WordPress would not power 24% of the Web.

      WordPress core members already volunteer a lot of their time. I’m not asking for anyone to volunteer more time. Need help? Ask us. There is a huge community of developers who rely on WordPress. We would be happy to get involved and set up whatever is needed.

      Does this make any sense?

      • gfazioli 9:14 am on July 24, 2015 Permalink | Log in to Reply

        I agree!!

      • Mario Peshev 10:46 am on July 24, 2015 Permalink | Log in to Reply

        +1 – it’s not a one-time thing, it’s a process problem. And we had a late night urgent maintenance iteration due to a bunch of broken things for the same reason.

        It’s demoralizing for us and some of our clients don’t trust WordPress to be a stable and reliable platform that will run their business and let them sleep at night, without being afraid that things will break with zero changes on their end.

      • Rasheed Bydousi 2:10 pm on July 24, 2015 Permalink | Log in to Reply

        +1 You’re right. It shouldn’t be conducted in such a way. It is so annoying. Such changes shouldn’t be made arbitrarily. This isn’t a typical behavior pattern when it reaches to WordPress.

      • schutzsmith 2:50 pm on July 24, 2015 Permalink | Log in to Reply

        +1 Absolutely sums up how I’m feeling as well Amir! For instance, our digital agency runs on WordPress, we’ve built over 100 websites for clients on it, but as I tweeted this morning, this was the final nail in the coffin, we have to move away from WP because it’s literally killing our relationships with our own clients.

        I’m truly saddened by it because we’ve loved the community up until the last few months. It’s now at a point where we can no longer keep relying on WordPress to run a smooth and fruitful business.

      • Eliot Akira 3:03 pm on July 24, 2015 Permalink | Log in to Reply

        +1 – Thank you for articulating a sensible and constructive suggestion from the developers’ perspective. As someone who is one of the “folks who build WordPress sites for a living”, this issue has affected me greatly – spent most of the night trying to fix clients’ sites as well as doing the best to help plugin users. But more than the unexpected time and effort for support, as Amir states, the biggest worry for me is the loss of trust and reputation, both for myself as a developer but also for the clients regarding the reliability of the WordPress system.

        Last night, in a desperate attempt to find even a temporary solution, I made a plugin update which provided an option to patch one of the core files so that sites will be functional again. In hindsight, it was a poor judgement and bad mistake – but how the issue was handled was very disappointing. Apparently it was against the rules, and the plugin has been blocked from the official repository – without any warning or message to me. If someone had contacted me, I would have gladly removed the offending code. After all, I was only trying to help the situation. But now, I have no way to provide a reasonable update, and the users cannot access the support forum to get any information about why their sites are broken or what to do about it. Since there doesn’t seem to be any motivation to address the issue from the core side, we are all left hanging.

        “We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.”

        This seems to be the direction I need to take as a workaround solution, to resolve/render plugin shortcodes before passing to WP to process content. Just to note, in the original announcement are listed two cases (Shortcodes with Filtered Styles and Shortcodes with Bad Quotes) – but neither apply to the issue that I’m seeing across numerous sites.

        “What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.”

        I agree with this. At the same time, I can also see why the update was rolled out so quickly without prior notice, due to its sensitive nature. Perhaps the reasoning for not informing plugin developers is that some of them might try to exploit it. Another reason could be that there was no clear way to determine which plugins would be affected – and informing thousands of developers about a security vulnerability would have defeated the purpose of the update.

        I’m glad to see someone suggesting a positive way to look at the whole situation – what can we as developers and users learn from this on-going situation, and how can we contribute to improve the reliability and stability of WordPress sites.

        P.S. If someone of authority can contact me regarding the blocked plugin, I would really appreciate knowing how to remedy it. Almost immediately after the problematic update,I have pushed another update which removed the change. Both myself and the plugin users are waiting for any information that could help us.

      • safesoundaudio 4:03 pm on July 24, 2015 Permalink | Log in to Reply

        Well said Amir! You speak for many hundreds of us in this wonderful WordPress community.

      • dmccan 4:32 pm on July 25, 2015 Permalink | Log in to Reply

        I appreciate that the core team addresses these security issues. At this point, the WordPress ecosystem is so large that it is difficult to ascertain the impact of core changes, so I agree with Amir that we need a better process.

    • Herre 9:14 am on July 24, 2015 Permalink | Log in to Reply

      I fully understand this is an issue… but isn’t this a weird way of updating… almost al our clients are calling / e-mailing us at the moment as their sites seem to be broken…

      Normally it would be better to announce such huge impact changed to the plugin and theme developers…

      This means I need to fully reschedule my agenda… which already is full during holiday season…

    • JesseHeap 1:26 pm on July 24, 2015 Permalink | Log in to Reply

      Wondering if someone could provide some advice for us as I’m having a little trouble understanding what needs to change with shortcodes to fix our particular issue.

      The simpliest example I can give is below:

      Use Case: We use a short code to pass the HTTP_REFERER as a hidden value in our form:

      SHORTCODE in PAGE:

      Code in Theme Functions:
      //pcbReferrer
      function pcbReferrer_func() {
      return(getenv('HTTP_REFERER'));
      }
      add_shortcode( 'pcbReferrer', 'pcbReferrer_func' );

      Based on my understanding of the above, I’m not clear what I would change since we aren’t using attributes for this short code. I have other short codes that do use attributes which I’m trying to fix as well, but that’s a different story.

      • JesseHeap 4:09 pm on July 24, 2015 Permalink | Log in to Reply

        Here’s the solve in case this helps anyone:

        –ORIGINAL SHORTCODE THAT WAS NOT WORKING–

        Page Shortcode Reference:

        Themes Function Code:
        //pcbReferrer
        function pcbReferrer_func() {
        return(getenv(‘HTTP_REFERER’));
        }
        add_shortcode( ‘pcbReferrer’, ‘pcbReferrer_func’ );

        –NEW SHORTCODE THAT IS NOW WORKING–

        To solve this I moved the HTML into Themes Function PHP file. So I changed my form page shortcode to just:


        [pcbReferrer]

        And modified the function to include the HTML that was originally in the page:

        //pcbReferrer
        function pcbreferrer_func() {
        $output = '';
        return ($output);
        }

        Less then ideal as it intermingles more of the HTML with the shortcode and I always try to maintain as much separation as possible.

        But I certainly do not understand the security concerns of the prior approach so I’ll just assume this is the new constraint that we’ll need to follow for the sake of security…

        • JesseHeap 5:57 pm on July 24, 2015 Permalink | Log in to Reply

          Sorry I thought the <code> tags would leave the HTML alone but they are still stripping it away… This commenting system is a little frustrating…

    • safesoundaudio 4:02 pm on July 24, 2015 Permalink | Log in to Reply

      The change to allowed shortcode usage has NOT just affected a few RARE cases of shortcode uses. It has affected the functionality of hundreds (maybe even thousands) of websites including my own commercial site. Aside from the disaster it has caused to hundreds of web designers who use the excellent Toolset plugins, it has destroyed the functionality of a large number of other plug-ins. The forum is just full of examples today.

      As far as I can tell there was no advance notice. SOMEONE should have stopped and thought, ‘best we tell the community what we are planning’ The folks at Toolset seem to have been given no notice and they are probably the biggest plugin designers of the now disallowed shortcode usage.

      We can debate for ever what should be allowed and not allowed with shortcodes but that misses the point. Most of us are in the communication industry and this update has been very sadly lacking in foresight and communication.

      PLEASE role back this disaster of an update. I am 100% sure it was well intended but PLEASE look at the reality of what has happened.

    • crazycanuck27 6:00 pm on July 24, 2015 Permalink | Log in to Reply

      So I’m trying to pass a User Shortcode [currentuser_iserid] as a variable in an iframe and what worked for v4.2.2 suddenly broke and working to recover.


      … used to work but now it passes the shortcode as text. The shortcode works on its own. So is this an issue with the iframe and trying to pass a shortcode .. or quotes, or something else?

    • Claudio Esperanca 11:03 pm on July 25, 2015 Permalink | Log in to Reply

      is removed by TinyMCE when switching between HTML and WYSIWYG views as it is considered an invalid attribute for the tag, so it isn’t a perfect workaround.
    • minderdl 8:55 pm on July 26, 2015 Permalink | Log in to Reply

      While I can agree that wrong quotations do not need to work (i.e. one should only use single quotes inside double quotes and vice versa) the change also killed wrapping shortcodes:

      [blockcode]
      <a href="[myurl]">[mytitle]</a>
      [/blockcode]

      The href attribute will be empty, only mytitle will be replaced.

      Is this also considered “wrong” use of shortcodes??? Wrapping shortcodes are used for conditions, loops, etc. by several plugins. And this could not be changed in the same easy way like just changing quotation :-(

      With version 4.2.3 the part inside a wrapping shortcode is first processed by do_shortcodes_in_html_tags(). There all the replacement of the inner shortcode is done. Only afterwards, the result is passed to the wrapping shortcode callback. This has several problems: For wrapping shortcodes implementing a condition substitions will take place that might be completely unnecessary (ok, only a performance problem). But for wrapping shortcodes implementing a loop, the content will always be the same – i.e. the whole thing is completely broken.

      Did anyone thought about this?

  • Ryan Boren 12:01 am on July 15, 2015 Permalink |
    Tags: , bubbles, , content-overrun, , edit-site, , , , , , network-admin, right-now, ,   

    Today in the Nightly: Site icons in the customizer, editor patterns, more accessible comment bubbles, row toggle focus styling 

    Install the nightly, and try out this fresh batch of shiny.

    Site Icons in the Customizer

    I’ve long wanted site icons in the customizer alongside site title and tagline. The identity information that I always want to edit when first setting up a site are now all together in the customizer.

    For more visuals, see these visual records.

    See #16434.

    Editor Patterns

    Create bulleted lists, ordered lists, and blockquotes using markdown like patterns. I find this particularly handy on phones when the editor toolbar is offscreen.

    Screen Shot 2015-07-14 at 4.39.12 PM

    See #31441.

    Better focus styling for list table row toggles

    See #32395.

    Better accessibility and design for the comments bubble

    The comments columns in our list tables were among the most confusing for screen reader users. Accessibility and visuals are now improved.

    See #32152.

    Eliminate content overruns on small screens

    An audit of content overruns on small screens resulted in many fixes.

    After:

    Before:

    See #32846.

    Styling improvements on small screens for Right Now in the network admin

    See #32962.

    Improved header information in Network Admin Edit Site tabs

    • Use the site’s name rather than URL in the Edit Site header.
    • Provide “Visit” and “Dashboard” links for the site on all tabs.

    After:

    Before:

    See #32525.

    Disambiguate “Automatically add new top-level pages to this menu”

    In the customizer, a menu’s auto-add pages option is now separated from the preceding menu location checkboxes.

    See #32820.

     Passwords UI Improvements

    Passwords received a couple of improvements. The show/hide toggles look better, and passwords ui is on the install screen. Passwords on the install screen still needs a little more flow work.

    See #32589 and #32925.

    For more visuals, see these visual records.

    Reduce link noise in media library list view

    This is visually subtle but removes confusion for screen readers.

    KL_7dmW58c

    See #32254.

     

    Previously: Today in the Nightly: Customize in the Toolbar, Passwords UI, List Tables on Phones, Dashicons

     
  • Ryan Boren 11:25 pm on July 8, 2015 Permalink |
    Tags: beta-testing-flow, , , list-tables, , , , toolbar   

    Today in the Nightly: Customize in the Toolbar, Passwords UI, List Tables on Phones, Dashicons 

    Development leading up to the first beta brought several visual changes. These are available right now in the nightly build. Switch a site to nightly builds and try them out.

    Customize in the toolbar

    To disambiguate between links to the Customizer and links to the Appearance screens from the front-end, Customize now has a top-level toolbar button rather than having links to it mixed with dashboard links in the site menu. This context mixing leads to disrupted user expectations as they navigate, as well as experiences that feel slower or actually are slower in some cases. See #32924.

    This means an additional top-level menu item, but the existing links to Widgets and Themes in the dropdown will now point to the admin, as the Dashboard and Menus links do. The advantage and goal for this change is to make it clear that you are about to enter the customizer. Deep links have not been added back in this go-round; this means that direct links to Header and Background are currently absent (with a very narrow exception related to old browsers). Those two deep links are still available in the admin menu under Appearance, which similarly mixes context but has not yet been addressed.

    More changes are coming to the toolbar. Peek at a possibility for more general improvements to the toolbar, being discussed in #32678.

    Phone friendly list tables

    List tables now scale down to phones. The column truncation strategy they used before didn’t scale down to small screens. A single column layout with disclosures is the new strategy. Some of our most important screens use list tables, notably Media and Posts. Truncated columns was number 5 on our top  5 impediments to flow on touch devices list.

    After:

    Before:

    See #32395.

    For more screenshots, see these visual surveys of the list table screens.

    Toolbar interaction fixes for touch devices

    I’ve been wanting this one for a long time.  Toolbar interaction was number 3 on the top  5 impediments to flow on touch devices.

     

    Fixed!

    Fixed!

    See #29906. That ticket is a good read.  It has: Visual feedback and visual surveys. Punting a working fix to the next release so that a new, more future proof approach could be tried. Development of touch capability detection. Working around iOS. Development of testing checklists. Lots of iteration.

    Passwords UI

    The password set/change UI was updated with these improvements.

    • Generate the password for the user
    • More tightly integrate password strength meter
    • Warn on weak passwords

    See #32589 for more screenshots.

    Dashicons update

    Dashicons received a big update.

    New icons:

    • .dashicons-admin-customizer (f540)
    • .dashicons-admin-multisite (f541)
    • .dashicons-editor-table (f535)
    • .dashicons-filter (f536)
    • .dashicons-hidden (f530)
    • .dashicons-image-filter (f533)
    • .dashicons-image-rotate (f531)
    • .dashicons-layout (f538)
    • .dashicons-sticky (f537)
    • .dashicons-thumbs-down (f542)
    • .dashicons-thumbs-up (f529)
    • .dashicons-unlock (f528)
    • .dashicons-warning (f534)

    Updated icons:

    • .dashicons-plus (f132)
    • .dashicons-yes (f147)

    dashicons-preview

    See #30902.

    Better styling for .form-invalid inputs

    See #32490.

    Responsive styling for my-sites.php

    My Sites now moves to a single column layout on narrow viewports. Here it is on an iPhone 6, an iPad, and a Macbook, as well as at full-width.

    Here’s what it looked liked before.

    my-sites-before

    See #31685 – Better responsive styling for my-sites.php

    Crosslinking Customizer Panels

    The graf in the Menus panel details about using the Customize Menu widget now links directly to the widgets panel.

    customize menus details

    See #32742.

    You might notice the misaligned question mark icon on that screenshot. #32733 is tracking that.

     Easy switching between production and nightly builds

    The beta tester plugin makes it easy to switch a site to nightly builds. Now switching back to the latest stable build is just as easy. It’s not the prettiest, but it is shown only to beta testers and will suffice until we finally refresh the Grand Unified Updater screen. For info on using the beta tester plugin to test with nightly builds, see the Beta Testing page of the core handbook.

    See #32613.

     

    Previously: Today in the Nightly: Site Icons, Text Editor in Press This

     
    • Thong Tran 12:06 am on July 9, 2015 Permalink | Log in to Reply

      Awesome updates. Btw, the ability to move a widget from one widget area to another has gone (in Customizer) in WP 4.3 beta 1, please bring it back.

      • Nick Halsey 3:50 am on July 9, 2015 Permalink | Log in to Reply

        To support a broader UX change made in #31336, it is no longer possible to drag & drop items between widget areas. However, the move-to-area functionality is still present along the reorder buttons when you enter the “reorder” mode, similar to the click-to-add functionality in the admin page.

    • Jon Brown 12:51 am on July 9, 2015 Permalink | Log in to Reply

      “Customize in the toolbar” getting it’s own top level menu is going to make me SOOOoooo happy you have no idea. Every time since 4.2.2 I hit that widgets link and get thrown into the customizer I scream curses at it my installs. Also just inspired me to write a plugin… to scratch another itch I’ve long had around that menu.

    • nikeo 8:48 am on July 9, 2015 Permalink | Log in to Reply

      Hi, thanks for this post.

      Funny : the customize button is something I’ve had to remove from my theme last year because there was “no real justification for elevating the Theme settings page to admin toolbar status.”
      See here : https://themes.trac.wordpress.org/ticket/18164#comment:5

      Well, I guess this is now 100% justified and of course I think this button is an excellent choice ! :)

    • Remkus de Vries 10:21 am on July 9, 2015 Permalink | Log in to Reply

      Love the move of giving the Customizer its own top level link. Love it.

  • Ryan Boren 10:56 pm on June 30, 2015 Permalink |
    Tags: , , , image-editor, , , site-icons, today-in-the-nightly   

    Today in the Nightly: Site Icons, Text editor in Press This 

    Here are a few cool things that recently landed in trunk. They are available right now in the nightly build. Install the nightly, and try them out.

    Site Icons

    We’ve wanted site icons in core for a long time. #16434 was opened four years ago and will be resolved as fixed for 4.3.

     

    Our crop controls are not easy to use on my iPhone 6+. The images overflow the right side of the screen. Horizontally and vertically scrolling an image bigger than the screen while working a rubber band select that resets when the image is tapped is not pleasant.

    Provide feedback on #16434 or on this post.

    See these visual records for more screenshots and flow storyboards.

    Text editor in Press This

    Press This now has a Text editor for editing HTML, just like the standard editor in post-new.php.

    32706.1-wide

    Provide feedback on #32706, in #core-pressthis, or on this post.

     Padding for image settings

    The Image Crop and Thumbnail Settings boxes received a little bottom padding.

    And so that we are always aware of what our mobile experience looks like, here are those settings boxes on an iPhone 6+.

    When you see a sidebar obscuring content on a phone, you can be pretty sure you’re witnessing lingering desktop bias. These screens were designed for desktops where you have room to use  sidebars. You can’t make a screen responsive and call it ready for a phone. The image flow effort is working on this.

    Provide feedback on #31845 or on this post.

    Manage in the Customizer

    Appearance > Menus received a “Manage in the Customizer” button to match Appearance > Widgets.

    Screen Shot 2015-06-30 at 3.16.57 PM

    Next, fix up mobile.

    image

    Provide feedback on #32808 or on this post.

     

    Previously: Today in the Nightly: Inline link toolbar and Press This split button

     
    • Emil Uzelac 11:05 pm on June 30, 2015 Permalink | Log in to Reply

      Just awesome!

    • Ryan Boren 11:45 pm on June 30, 2015 Permalink | Log in to Reply

      To create these posts, I work my way through the latest commits looking for changes to visuals. From the changesets, I visit the tickets. If the tickets don’t have before and after screenshots for both a desktop and a phone, I test the changes on a desktop and a phone and take screenshots. I upload those screenshots to the ticket. I comment on the ticket with any bugs I find in the process. I often find something, especially on phones. If I don’t have time to test and screenshot, I tag the ticket with needs-screenshots so I can get back to it later.

      Now that I have tickets with screenshots. I collect those screenshots and publish them as “Today in the Nightly” using the tool we’re all making together, WordPress. I often find bugs that way, too. Triage, recursive dogfooding, visual archiving, visual awareness, and a useful post to show for it. Recruiting drive: This is a great way to contribute. Help us with flow patrol, as we call it. :-)

    • Andre 4:27 am on July 2, 2015 Permalink | Log in to Reply

      I am just now playing with the beta 4.3, but regarding the site icon…I’m sure many will be extremely happy about that feature being part of the core. The only thing that should be given consideration is the labeling of it. I think it might confuse many end-users who may wonder what is a site icon when most are familiar with the term “favicon”, which as I understand, is the correct name for it. Just something to think about.

  • Ryan Boren 3:50 pm on June 9, 2015 Permalink |
    Tags:   

    Trust, Live Preview, and Menus in the Customizer 

    One of the most important things in WordPress is users being able to feel confident as they make changes to their content and more generally to their sites. Being able to make non-destructive changes and preview them is an important component of building that trust. This is perhaps most noticeable in the “save and surprise” approach of the widgets admin screen – every time you add a new widget, modify its settings, or move one around, the changes are saved and appear live on your site, even if you’re not ready yet. The customizer is our framework for live previewing changes. We are committed to providing live preview for all aspects of site customization and making it usable on all devices from phones to large screens.

    The customizer is the result of a tremendous amount of work over many releases. It was first introduced in 3.4. In 3.9, it received its first big updates in the form of widgets support and improved header upload and cropping. 4.0 brought panels and contextual controls. Development really started to take off in 4.1 when JS-templated customizer controls and a JS api were introduced, making possible an ecosystem of live preview compatible plugins and themes. 4.2 followed that up with two important features, theme switching and mobile support.

    That brings us to today and the ongoing 4.3 development effort. Revamped navigation for the customizer is already in trunk and the nighty builds. The menu customizer feature plugin is a merge candidate for 4.3 and could land soon. These marquee features further our commitment to live preview and need all of the attention we can muster.

    The customizer has come a long way, but it still lacks some features and needs time to mature. We have many improvements planned and in-progress, including transactions, partial refresh, theme installation, speedier loading, scaling to large screens, and possibly even integration with front end editing. Our live preview framework offers many possibilities.

    Meanwhile, the Appearance screens will remain and will be maintained. Appearance > Menus recently received some attention in the form of a few fixes. More attention is needed and will be given. There are still differences in the flows each approach best enables, whether it’s new site/theme setup, small maintenance tasks, or dedicated content managers for heavy usage of widgets, menus, or other pieces of content that benefit from having a preview mechanism. We should gather quantifiable metrics when it comes to performance and time to completion for a given flow, as well as evaluating the less-objectively-quantifiable perceived performance. There may come a time where the worlds converge; however, that time is not now.

    The feature plugin merge window is currently scheduled for June 17th. We have 8 days to get the Menu Customizer plugin ready for merge. Feature plugins must meet several criteria to be considered for inclusion in a release. To meet this criteria, the flow team has started testing and documenting flow and visuals for the menu customizer as well as the recently landed navigation changes. Merge criteria include identifying flows through the customizer, creating visual records of those flows, and creating flow comparisons of existing flow through Appearance > Menus versus flow through the customizer. This is a great and necessary way to contribute that requires no coding. All you need to do is take screenshots and publish them as a captioned gallery using the tool we’re making together, WordPress. We endeavor to be an Alan Lomax of flow, capturing and cataloging real user scenarios. Please help us capture the flows through Appearance > Menus used by you and your clients. We need this information to ensure our new interfaces are mindful and aware of how WordPress is actually used. Information on how to test and contribute visual records is available on the 4.3 development tracking page.

    @ryan, @helen, @designsimply

     

     
    • codezag 3:59 pm on June 9, 2015 Permalink | Log in to Reply

      the database structure of the menus will be changed ?
      is there any chnages to the menu walkers & database ?

      thanks

      • Fabien Quatravaux 7:49 am on June 11, 2015 Permalink | Log in to Reply

        As far as I know, this menu customizer will not introduce any change visible on the front-end side : no database structure change and no change to Menu Walkers. The only issue is about plugins or themes that added features to the Appearance > Menu admin page : those features may require some work to be available in the new menu customizer.

    • Frankie Jarrett 4:02 pm on June 9, 2015 Permalink | Log in to Reply

      Great to see that the core team is so committed to advancing the Customizer! I really believe it’s a glimpse into the future for a more JS-driven WordPress. Takes a bit of time to steer a ship of 75 million sites, but I know we’ll get there, and we’ll do it responsibly without leaving folks behind :-) /fives!

    • Shapeshifter 3 4:11 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan,

      A very thorough synopsis of the current plan.

      Thank you!

    • kevinwhoffman 4:49 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan, thanks for the update. The parallel development of the Menu Customizer alongside maintenance of the existing Menus screen is a good strategy moving forward until the Customizer is better proven.

      I also appreciate the rationale behind the importance of live previewing in different use cases. The more guesswork we can take out of the editing process, the better.

    • Jon Brown 4:52 pm on June 9, 2015 Permalink | Log in to Reply

      Great summery Ryan. I think the backlash against the menu customizer would have been a lot tamer if the proposal hasn’t included removing the appearance/menu page and stating that “this was the solution” for all the long un-addressed bugs in the appearance/menu page.

      Personally I don’t like the UI/UX of the customizer. I think stuffing that much GUI in the side panel is a mistake and editing should happen directly “on the page”. I wouldn’t object strongly to menu editing being added to the customizer panel as on option though, especially since I can always disable it like many of the customizer controls my client base find cluttered and confusing.

    • Morten Rand-Hendriksen 5:14 pm on June 9, 2015 Permalink | Log in to Reply

      Ryan is a calm shore in a raging storm.

      • George Stephanis 6:45 pm on June 9, 2015 Permalink | Log in to Reply

        Yes, behold my lord Boren, the rock, the hard place, like a wind from Texas he sweeps by blown far from his homeland in search of glory and honor, we walk… in the garden of his turbulence!

        (as paraphrased from A Knight’s Tale)

    • Gabe Shackle 5:28 pm on June 9, 2015 Permalink | Log in to Reply

      It’s a great addition to WordPress but the release approach has been terrible. Virtually all the opposition to the Customizer could have been avoided if it didn’t seem like everyone was being forced to use it.

      Things like changing the Widgets link from the admin bar, requiring all settings being in the Customizer by the TRT, and then with this last push that included language to remove the menus admin completely from the dashboard, it’s no wonder people were fairly upset and wrote the entire system off.

      If it had simply been released like this:

      “Check out this great new way to manage menus and widgets.”

      Rather than:

      “Here is the new way to manage widgets and menus. We’re going to be removing the interface you’re familiar with because we feel this new method is better and we don’t have enough resources to maintain both.”

      There would have been almost no push back at all. If the Customizer is truly as great as its developers say, let it stand on it’s own and prove it.

      • Helen Hou-Sandi 5:48 pm on June 9, 2015 Permalink | Log in to Reply

        Let’s take a moment to reflect on reactions being similarly imperfect in language choices and emotive content, and the very real effects that has on attracting and retaining the contributors we need to be able to maintain and improve those interfaces. Continuing to snipe at each other about tone, semantics, and hypothetical “should”s as though everything is predictable is not particularly productive.

        • Gabe Shackle 5:52 pm on June 9, 2015 Permalink | Log in to Reply

          I was merely offering my perspective and a possible reason for the negative reaction. No sniping intended at all.

        • PeterRKnight 10:22 pm on June 9, 2015 Permalink | Log in to Reply

          I thought a lot of the (unfair) reactions were coming from a lack of understanding about why these changes are happening and the way they are coming about. It’s always painful to see folks talking like there’s some kind of powertrip happening amongst some illusory ruling elite.

          But I’m agreeing with Gabe here, I think better communication would have prevented some of the kneejerk reactions that can be demotivating toward the developers.

          Because Gabe is right in that some people are interpreting this as tools being taken away from them, instead of being excited about a new powerful way of managing menus.

        • dmccan 3:26 pm on June 12, 2015 Permalink | Log in to Reply

          This post is great. It communicates and helps people to understand the thinking, planning, work, and process.

          Compared to some feedback I’ve seen, the feedback to this post has mostly been positive and generally constructive. We are all human and learning along the way. It is important to encourage and acknowledge contributions as well as provide constructive feedback. In this case the constructive feedback is that more good communication, like this article, is helpful.

    • Weston Ruter 7:02 pm on June 9, 2015 Permalink | Log in to Reply

      Thank you for writing this, @boren.

    • Knut Sparhell 7:36 pm on June 9, 2015 Permalink | Log in to Reply

      It’s already said, but again: Thank you for writing this, @boren. Record the flows of common tasks, on every kind of device.

    • Jose Castaneda 7:52 pm on June 9, 2015 Permalink | Log in to Reply

      Great write-up! Thank you for this. :)

  • Nick Halsey 12:00 am on June 3, 2015 Permalink |
    Tags: , , ,   

    Feature Plugin Merge Proposal: Menu Customizer 

    The Customizer team is proposing to merge the Menu Customizer plugin into core for WordPress 4.3. In this post, I’ll outline the purpose and history of this project, as well as highlighting the improvements that we have made.

    Purpose & Goals

    The purpose of the Menu Customizer project is to move navigation menu management from the WordPress admin to the Customizer. In the process, we hope to offer an updated design with improved user flow, a mobile-first interface, improved accessibility, rebuild the administration UI from the ground up to be JavaScript-driven, solve long-standing problems with the current implementation (#14134), and clarify the purposes and capabilities of the menus feature. Additionally, Menu Customizer contributes significantly to the long-term goal to move all appearance functionality and, really, everything that could benefit from live previewing, from the admin to the Customizer.

    Background

    Menu Customizer started out as my Google Summer of Code 2014 Project. The initial proposal and revised schedule highlight the initial goals and provide good perspective for where we’ve come in the past year. See also the periodic posts here on make/core for updates. Development has happened on GitHub since the project opened to the community.

    Core API Improvements

    As I began developing this feature in plugin form, it became clear that the core Customizer API would need a lot of improvements to support something as complex as menus. Countless tickets have worked towards this goal over the past year, from the addition of the concept of Panels ( #27406) to JS/Underscore-templated controls ( #29572), and now, full support for dynamically-added sections and controls ( #30737, #30738, and #30741).

    Developers are still realizing the full potential of the Customizer API, and Menu Customizer pushes the boundaries of what can be done here pretty far. One of the goals with our approach is to bring as much functionality that should be natively available in the API into core as possible. With the improvements made here already, as well as the future potential to continue abstracting functionality like the add-menu-items fly-out panel or the ability to add screen options in Customizer Panels, Menu Customizer broadens the potential for developers to extend the Customizer to do anything, in core, plugins, and themes.

    Contributors

    In the initial GSoC project, I (@celloexpressions) developed the plugin from scratch, using Widgets in the Customizer as the design basis, with @ethitter and @obenland serving as my mentors. When the project was opened to the community for contributions, several designers and developers stepped up to help. Code contributors to date include @westonruter, @valendesigns, @voldemortensen, @adamsilverstein, and @kucrut. @designsimply and @folletto have also put in a tremendous amount of time helping with design and usability.

    Plugin Overview

    I highly recommend trying the plugin, which currently requires the latest version of 4.3 alpha. @designsimply has prepared a video demo:

    I’ve posted a comparison of the mobile menus flow in the admin and the Customizer on make/flow, and @designsimply has also posted flows there (more flows with more recent versions of the plugin on trunk are still needed). Usability testing has been conducted on usertesting.com, with results posted on make/design. As further refinements are made, additional testing and feedback can be incorporated to make the new experience as polished as possible.

    A couple of technical details: each menu is a Customizer section, and new menus can be added (dynamically adding new Customizer sections and controls in the process). Menu items are Customizer controls. To maximize scalability, menu items are all rendered using a single JS template, only when their containing menu section is expanded. The add-menu-item panel loads available menu items on an as-needed basis via ajax. The plugin uses several custom Customizer objects including a custom panel that implements screen options, two custom sections (menus, for lazy-loading of menu items, and new menus, which is rendered as a button toggle), and several custom controls. But everything is built off of the core Customizer API.

    A summary of some key improvements that the plugin includes:

    • Modernized, simplified, and more compact UI
    • Mobile-first design that leverages the Customizer
    • Scalable, JavaScript-driven and avoids performance issues ( #14134)
    • All menus easily accessible in one place, without page reloads
    • Live previews of active menus as they are edited
    • Menu locations that can be set from the main panel or while editing
    • Global search that includes all post types and terms in all taxonomies
    • Quick-delete for deleting several items sequentially
    • “Original” item links open directly into the live preview
    • The Customizer API can be used to hook into the experience in countless ways with plugins. Support for additional menu item fields can be added much more easily now in a future release, potentially leveraging the Fields API

    Core Tickets Fixed

    Menu Customizer fixes numerous tickets on core trac. This is not an exhaustive list, but covers many bigger ones:

    • #14134: Menus item are limited to 16 item and will not save more than that
    • #28138: Updating menu item requires passing all of a menu item’s data to wp_update_nav_menu_item() (The plugin steps around this, we can actually fix it in core on merge)
    • #32218: Remove title attribute option in Menu Editor (off by default)
    • #19272: Add Filter to Nav Menu Support Themes Text (can modify via Customizer API)
    • #21603: Add ability to delete multiple menu items
    • #16828: Add filter on initial_meta_boxes for nav menu Probably fixed, all are shown currently, which could use improvement but it will default to more being shown at least
    • #19464: Auto add do_action for menu in admin (can use Customizer API)
    • #31391: Make the list of registered nav menus (locations) filterable (can use Customizer API)
    • #32440: on Menu page, turn posts by default on “view options”
    • #18517: Visual Feedback for Nav Menu UI

    The Plan for the Menus Component

    This project has a very explicit goal of not just adding menu management to the Customizer, but also removing the existing admin page in the process. The menu management screen has significant, fundamental problems in its implementation and will never scale (see #14134) without a significant refactoring along the lines of what we’ve done with the Customizer. Additionally, the new UI in the Customizer is considerably more polished than the admin screen and already includes numerous features and bugfixes proposed for core (see above). Ultimately, the new UI provides a much better experience for all users, including desktop, mobile, accessibility, etc.

    The plan for the “removal” of the old menus admin screen is as follows:

    • Immediately and officially “deprecate” it: wind down any ongoing development efforts and focus all new administration-focused Menus component work on the new UI in the Customizer. Update trac tickets accordingly, and add a “Manage in Customize” link to the existing screen. Any existing tickets proposing enhancements or new features for menu administration would be required to be adapted to the Customizer version, with the (discouraged) option of also making changes to the old screen.
    • Point the “Menus” link in the admin bar to Menus in the Customizer in 4.3. Remove that menu from the admin bar in 4.4 in favor of a top-level Customize link, and put something more useful in its place (as all of its core links will point to the Customizer now).
    • Retain the admin screen codebase, along with existing links to it throughout the admin.
    • In WordPress 4.5 or 4.6, remove all core links (including admin menu) to the Menus admin screen, or point them to the Customizer. This would likely coincide with a similar change for Widgets and Themes to use the Customizer versions exclusively, once full feature-parity is achieved with the Customizer versions of the other features (Menus has it now). At this point the admin screen would be accessible only by plugin-added links or for users who cannot access the Customizer (no-js, IE7, IE8&9 with domain mapping, a very small percentage of users overall).
    • The admin screen and related code would likely not be removed entirely from core in the foreseeable future, and critical bugs or security issues would still be addressed. New feature development and enhancements would be restricted to the Customizer version.

    The above plan is fairly aggressive, to eliminate any ambiguity about future plans and intentions and to avoid the potential for mass trac ticket rot. The fact that the Menus component has no maintainers and has not received significant attention since the 3.6 release indicates that there is a general lack of developer interest in dealing with the mess that the current system is. I am willing to step up as a component maintainer for Menus if the above plan is implemented.

    Ongoing Work

    We have a few issues left that work working on. Notably, @westonruter has proposed refactoring the way menu item settings are handled, along with menu creation and deleted, and has begun work there, but wouldn’t finish until after a core merge due to time constraints and integration with core code. @adamsilverstein is working on improving drag & drop to work with sub menus. There are also several minor issues remaining on GitHub, which would either be handled in the next couplle days or after merge (many issues have been punted to after a potential merge already).

     
    • Weston Ruter 12:20 am on June 3, 2015 Permalink | Log in to Reply

      refactoring the way menu item settings are handled, along with menu creation and deleted, and has begun work there

      Note that this is not a refactor for the sake of making it more elegant. It’s a re-architecture for how the data is represented in the Customizer and eliminating Ajax requests that persist data in WordPress out-of-band with the Customizer session (the settings). The re-architecture is required to ensure that this help text remains true: “Customizer allows you to preview changes to your site before publishing them.” We need to ensure that there are no database changes made at all until the user hits Save & Publish. For more information, see issue 67. It is considered by myself and @ocean90 to be a blocker for shipping the feature in the 4.3 release.

      • Nick Halsey 5:14 am on June 3, 2015 Permalink | Log in to Reply

        Specifically, there are five interactions that result in immediate modifications to the database:

        • Screen option toggles
        • Add new menu item
        • Edit existing menu item, other than changing order
        • Add new menu
        • Delete menu

        For adding and editing menu items, the database changes are essentially just adding draft posts (which is exactly what they are), and these are only saved there temporarily if they don’t get published. Screen options we obviously wouldn’t change as it uses the system used throughout the admin. Menu-addition I would expect to change the db immediately because actually having menus is more of an administrative thing that doesn’t get published in any way until the menu is added to a widget or theme location (which are previewed). Menu-deletion is the one that should be changed if possible, although the delete menu option is only available for menus that aren’t in use published or in the preview, both for UI simplicity and to minimize accidental clicks (there’s also an are-you-sure dialogue), so that does minimize issues there.

        Other than menu-deletion, nothing is published but draft objects are added to the db with the current setup. In terms of user-facing changes, the only tangible impact this would have is that menu deletion wouldn't be permanent, and a couple of bugs with previewing would be fixed (although they could also be fixed in other ways). There's a distinction between published to the publicly visible site vs. published to the database, albeit with a draft status like a draft or autosaved post. The refactoring would also likely improve performance, as there are certain likely unexpected bottlenecks right now that can cause large quantities of these draft items to be generated (especially with submenus).

        Hopefully this clarifies exactly what's going on here, and how a developer might think of this change versus the impact to a user. Blocker for release, but not a change that will have major implications on the user-facing side of things, allowing us to continue testing and iterating on that as needed in the meantime.

    • Spacedmonkey 8:32 am on June 3, 2015 Permalink | Log in to Reply

      One thing that is was not mentioned was plugins that have built on top of the menu panel ui? One off the top of my head that I use is this – https://wordpress.org/plugins/advanced-custom-fields-nav-menu-field/ . Will all of these plugins break after the upgrade? Is there a plan in place to educate both theme/plugin developers and users of this massive change?

      Also, can’t believe that work was done on the menus and this ticket wasn’t touched – https://core.trac.wordpress.org/ticket/16075 . Not being able to easily put CPT archives into the menu is mine and all the people that user my sites biggest pet peeve. I know work around it with custom links, but if you change the slug of the CPTA when that isn’t reflected in all the menus you have the custom link in.

      • Tom 11:52 am on June 3, 2015 Permalink | Log in to Reply

        I am one of those menu plugin authors, yes it would break the plugin. On the up side, it shouldn’t be too much work to get it working again.

        Regardless of that, [i]my[/i] thoughts on this can be condensed into a single sentence:

        Content Management does not belong in the Theme Customizer.

        • Ipstenu (Mika Epstein) 3:37 pm on June 3, 2015 Permalink | Log in to Reply

          Tom, what is it about the change that broke? If it’s something easily grep-able, we can get a list of plugins in the repo that might be affected really fast.

          • Tom 5:14 pm on June 3, 2015 Permalink | Log in to Reply

            My plugin enqueues assets on the nav-menus.php page. It also uses jQuery to add a button to each menu item (which in turn loads a lightbox containing more settings for the menu item). Removing the current nav-menus.php admin page would break that functionality.

            That’s not a concern though, I can change that.

            My concern is I believe this will have a negative impact on the usability of WordPress as a whole. I don’t believe the theme customizer was ever intended to be used for anything more than customizing a theme, it doesn’t seem intuitive to expect users to manage content in there too.

            • Weston Ruter 5:41 pm on June 3, 2015 Permalink

              The Theme Customizer is just a framework for live-previewing any change to WordPress. Initially the customizable settings were just appearance-related things like colors and images, but it never had to be limited to that scope. Starting with 3.9 widgets were added to the Customizer. Before 3.9, it was not possible to see what impact a widget change would have on a site without making it live for all users. The same goes here for menus in 4.3: it allows changes to be previewed before impacting any user.

            • Tom 6:13 pm on June 3, 2015 Permalink

              Weston, a similar argument would be that writing content is essentially customizing a post, and therefore is suited to be done inside the Customizer. You could preview your changes on the fly, but I’m sure most people would agree that the Customizer is not the right place to be editing or managing posts.

              Widgets are a grey area, they look like content on the front end, but they “go” when you switch theme.

              Menus, pages, posts etc are content items that form the “backbone” of a WordPress site. Menu management is content management, not customisation.

            • Weston Ruter 7:04 pm on June 3, 2015 Permalink

              Yes, post editing can be done in the Customizer as well. The Customizer provides a framework for implementing front-end editing, which has been talked about for awhile now. Note that the Customizer doesn’t mandate changes be done in the left-hand pane. They can be done inline as well. So for those who want inline editing, with full preview-ability of post changes on the frontend, then they would certainly think the Customizer is the natural place to do this.

              Widgets should be considered content, and should be stored in posts as well (see #32474). The widgets don’t go when you switch themes. You may have to re-assign them to the new theme’s sidebars, just as you have to re-assign menus to their new locations after switching themes.

          • Tom 5:30 pm on June 3, 2015 Permalink | Log in to Reply

            Here is what you could grep for in my case:

            https://plugins.trac.wordpress.org/browser/megamenu/trunk/classes/nav-menus.class.php#L110

            “nav-menus.php”

          • Merv Barrett 12:28 am on June 11, 2015 Permalink | Log in to Reply

            I second this. Content management does not belong in the customizer.

            Every time the customiser appears I want to find a way out of it. It’s horrible for theme selection when developing sites for clients.

            The customiser is terrible for widget management too.

            It’s probably great for single users working on their own site.

            But where you are building sites daily and have 30 layouts each supporting unique widgets, the customiser is a pretty shiny object that gets in the way of productivity.

            Terrible idea to disable Appearance > Menus

            Sorry for being harsh but if it works don’t fix it

        • Julie @Niackery 11:01 am on June 4, 2015 Permalink | Log in to Reply

          Agreed! “Content Management does not belong in the Theme Customizer”! How does menu content benefit from front-end editing? Not at all! Only menu design does, and it should be left at that…

          • Samuel Sidler 3:48 pm on June 5, 2015 Permalink | Log in to Reply

            There are a couple aspects of menu management that benefit from visual management:

            • menu placement, so you know exactly where your menu is going; naming isn’t always very helpful for this
            • menu item length can cause your site to “look weird” if a menu item is too long for the menu (for example)
      • Ipstenu (Mika Epstein) 1:53 pm on June 3, 2015 Permalink | Log in to Reply

        Plugin developers are emailed before release to remind them about testing, and in general once a feature product hits beta (and is no longer a plugin but included in core) most developers SHOULD be already testing… Can’t make em. We do try to alert and scan the repo for anyone who might be impacted.

        Any chance you want to test the feature plugin with the one you use right now and give a heads up? Then we know for sure and can start scanning and poking around :)

      • Nick Halsey 3:04 am on June 4, 2015 Permalink | Log in to Reply

        Because the new interface is completely different from the bottom up, plugins will need to be adapted to extend the UI. The Customizer API will actually allow for significantly more flexibility with several components, essentially adding hooks throughout the interface and letting devs tweak things at a more specific level from plugins. One of the reasons that we’re proposing to wait a few releases to remove the old screen is so that plugins would have ample time to transition.

        The one thing that the new system does not yet support is adding new fields to individual menu items. Currently, this is only possible in the admin screen for one plugin to do at a time, but it can be done so a few plugins do it. We’re still working out how best to facilitate plugins adding options here; it could be a simple (for us, but would make it much harder for plugins) as an action in the menu item template, or as involved (for us, but would be much easier for plugins) as a API for custom menu item fields, potentially leveraging the Fields API.

        Once the available hooks and APIs for customizing the Menu Customizer experience are complete, we’ll do a post here with details on what old hooks won’t work in the new interface, and what new ones are available. Note that the plugin doesn’t touch the deeper internals of menu management or the presentational layer, only the administrative layer.

    • Andrew Norcross 6:54 pm on June 3, 2015 Permalink | Log in to Reply

      The decision to deprecate / remove the existing menu is a horrible one IMO. While I don’t like the idea of putting menus in the customizer to begin with, removing the existing one poses a lot of problems for existing education / training done with users. I have trained at least 100 clients on how to build and manage their menus, both in person and with online / printed manuals. Removing this creates a new set of required training for both the menu area and the customizer as a whole, not to mention opening up the idea of “can I now customize X part” on sites that were built to specific scope and needs.

      I hope the core team reconsiders this.

      • Weston Ruter 6:58 pm on June 3, 2015 Permalink | Log in to Reply

        Removing the existing Menus admin page wouldn’t happen for quite a while, I imagine. Widgets were added to the Customizer in 3.9, but the Widgets admin page remains and isn’t planned to be removed anytime soon.

        • Travis Northcutt 7:00 pm on June 3, 2015 Permalink | Log in to Reply

          The proposal above lays out a pretty clear plan, including “In WordPress 4.5 or 4.6, remove all core links (including admin menu) to the Menus admin screen, or point them to the Customizer.”

      • designsimply 7:04 pm on June 3, 2015 Permalink | Log in to Reply

        Aside from documentation needing to be updated, I think a better UX for menus combined with live previews will be a benefit for your clients as well as all WP users. Did you try out the plugin? Since you have experience teaching people how to setup menus, do you think they will find the newer flow easier to work with?

        • Andrew Norcross 7:09 pm on June 3, 2015 Permalink | Log in to Reply

          I have tested the plugin, yes. And I’ll keep my opinions on the customizer to myself for a moment, but I in terms of menus I do not think it’s easier or better UX. It’s a constrained space to work with and the live previews aren’t a value-add for something as straight forward as a menu.

          • designsimply 7:15 pm on June 3, 2015 Permalink | Log in to Reply

            I see. In user testing, I have found that the current menus admin page is itself not intuitive and not straight-forward for everyone, which might be one reason why you needed a lot of documentation for it before.

            Thanks for your input.

            • Andrew Norcross 7:20 pm on June 3, 2015 Permalink

              Most users need training because they do not use systems like WP on a daily basis like we do. Once they understand, they find it easy to use. For a few clients who do have the customizer in place, they’ve found it difficult to understand and muddled.

            • designsimply 7:25 pm on June 3, 2015 Permalink

              I’m game for helping test those kinds of interactions. If you spot specific flows that are troublesome, let me know in Slack and they might be things we can make sure to cover in user testing.

            • Andrew Norcross 7:39 pm on June 3, 2015 Permalink

              the important thing here is the removal of the existing menus. I understand it may not “scale” but for the vast majority of users, scaling is not an issue whatsoever.

      • Robert Dall 8:15 pm on June 3, 2015 Permalink | Log in to Reply

        I completely agree with you Andrew.

        Personally I don’t like removing the menu completely from the admin. Sure if you want to use the customizer that fine. But I should be forced to if I don’t want to.

        And to echo Chris Lema’s statement as well.

      • adamsoucie 12:22 am on June 4, 2015 Permalink | Log in to Reply

        I want to second Norcross here in regards to training. Outside of how to write a basic post, the menu system is the area my clients find easiest to understand. Often times they are more comfortable making changes to menus by themselves than they are actual posts because the interface is pretty easy to understand.

        This feels way too much like a solution for a problem that doesn’t really exist for most people, at least as far as my limited experience is concerned.

      • ahortin 2:33 am on June 4, 2015 Permalink | Log in to Reply

        I totally agree with everything Andrew said. I’m not a fan of the Customizer, full stop. I think it’s a horrible user experience and the more options that are added to it, the worse it gets. I don’t like the idea of the menus getting added to Customizer and I would really, really hate to see the existing interface removed. Having a live preview for menus is of absolutely no benefit.

        There needs to be more input from the community when big decisions like this are made. As well as using it on our own sites, we deal with clients every day so we know what they do/don’t like. This new customizer implementation of the menu system is not going to make it easier for end users, and isn’t that one of the things that WordPress prides itself on, being user friendly? This is taking a step backwards.

    • Chris Lema 7:03 pm on June 3, 2015 Permalink | Log in to Reply

      Sticking what has been done in a large screen into a small space feels like the things young people do because they a) learn quickly, b) are tech savvy, and c) have great eye sight.

      But in enterprises that use WordPress, people are often older, learn slower, and are less tech savvy. So I would strongly recommend not squeezing the menu into the customizer. I would also suggest that if this plan goes forward, they leave the main menu in place for years, not versions.

      • intriguingnw 7:03 pm on June 6, 2015 Permalink | Log in to Reply

        In respect of Customizer and Menus, seems like UI decisions do not reflect what users want or do. It’s not just Mr Lema and Mr Hancock folks. See discussions in Advanced WodPress group o Facebook. Most people don’t believe its not a good idea. Chris is right, its not change that people are against, its ‘change for changes’ sake. Please leave support in where it is for menus as its just creating a pain point for no real end-use benefit. I realise you all know much more than most of us about the coding but those of us who use WP and have to get end users, clients, corporates and busy teams sticking with WP want changes where it solves a problem or pain point. This feels like its just creating one.

        I was really tentative about making any commen here because I realise you are all leads on the technical but heck if users start leaving in droves for Squarespace and we make changes that don’t really add value, what is the point?

        What users want is a front end that is more like lasso.(Nick Haskins) so we can compete in the drag and drop world, where most folks want to be. This change just substitutes one place for another. So I may wear glasses, be a bit older but I want positive change as much as young people do but I would like it to make a difference in the market and this already feels like it is not going to do that.

        Realise my voice probably will not make a difference because it looks like its already been decided but somehow before revisions and changes get prioritised can we get some wider participation from users not just expert coders. With all respect.

    • Jon Brown 7:03 pm on June 3, 2015 Permalink | Log in to Reply

      This seems like a really pretty laid out proposal but that doesn’t mean I’m in favor of it.

      First, I share Tom’s concern about existing plugins. There is no talk about hook compatibility between the existing menus and the customizer. There needs to be a plan before this even starts for what happens with plugins when the current menu admin goes away.

      Second, I share Andrews concerns. I still don’t love the customizer, especially it’s attempt to move beyond “theme customization”. I really think content control should have been handled differently. I want to drag/drop/edit widgets directly ON THE PAGE, not in the sidebar. It’s the same issue with this. If I going to do this on the front end, I want to edit the menu directly IN the menu, not in a side tool bar.

      • Weston Ruter 7:08 pm on June 3, 2015 Permalink | Log in to Reply

        As I commented above, the Customizer doesn’t require all interactions to be done in the left-hand pane. Inline editing is also possible but it just hasn’t been widely implemented yet. So yes, drag-and-drop of widgets directly in the page preview is possible, as is doing the same for menus. It is more difficult to implement a cross-theme compatible way of doing such inline editing, however, so this is a reason why editing remains in the Customizer pane.

        • Jon Brown 7:19 pm on June 3, 2015 Permalink | Log in to Reply

          For me it feels like the customizer already has WAY too much going on in there… it’s not intuitive and getting even harder to navigate. User testing here is way more meaningful than my cranky opinions though.

          I think the customizer _should_ require all interactions occur in the pane. That’s easier to understand, as the hybrid some in/some out approach is confusing. Rather than put more in there other UX for editing content (menus/widgets/etc) outside the customizer should be developed.

          +1 on NOT removing the admin nav-menus.php in a few versions… should be in a few years. Still having problems with plugins that were built for the old media library layout, and problems with the new widget customizer dying/freezing on sites with heavy widgets.

          • designsimply 7:24 pm on June 3, 2015 Permalink | Log in to Reply

            Some themes add a lot of extra panels to it too! I think things will keep getting added there though. Ideas to help:

            • Spotlight style help search (I would looove something like that for all WP Admin)
            • Toggle for before-and-after so I can see what I’ve changed via the Customizer before saving

            These are outside the scope of the menus feature itself, but I see your point about findability becoming more of an issue as more things get added to the Customizer.

            • Jon Brown 7:27 pm on June 3, 2015 Permalink

              I think about it this way…

              Why build a GUI into the customizer (ie. the drag and drop arrangement of menu items) when there is a perfectly good GUI in the preview window? Why can’t I just drag and drop ON the page?

              Same goes for widgets…

              The customizer makes some sense when the panel has settings like color, font size, etc… it doesn’t for arranging content.

              As Tom said, it’s content vs design.

          • Weston Ruter 7:27 pm on June 3, 2015 Permalink | Log in to Reply

            problems with the new widget customizer dying/freezing on sites with heavy widgets

            Yes, this is a known problem. See #32103. I have a fix in the Customize Widgets Plus plugin’s “Efficient Multidimensional Setting Sanitizing” module.

      • Jon Brown 7:11 pm on June 3, 2015 Permalink | Log in to Reply

        sorry, premature posting above without editing.

        In short, rather than squeeze more content editing into the sidebar, leave that for “global theme customization” (like it was original intended IMHO), and instead find a better way to enable front end layout and content.

      • Tom 7:15 pm on June 3, 2015 Permalink | Log in to Reply

        I would just like to make it clear that although the change will break the plugin I develop, that’s not my concern here. I can fix that up pretty quickly. If anything it will probably be easier for plugin developers to hook into the menu system through the customizer.

        I’m simply concerned this change would make menu management more difficult and less intuitive for the average user.

        • designsimply 7:19 pm on June 3, 2015 Permalink | Log in to Reply

          I’m simply concerned this change would make menu management more difficult and less intuitive for the average user.

          Why do you think this change makes menu management less intuitive? Can you be more specific?

          • Tom 7:48 pm on June 3, 2015 Permalink | Log in to Reply

            Sure. I don’t think a new or “the average” WordPress user will instinctively head to Appearance > Customizer to manage their menus. I simply wouldn’t expect menu management to be placed there. Regarding increased difficulty, I don’t believe the Customizer offers a suitable amount of space to manage large menus (50 items plus), or menu’s with more than say 2 levels.

            • designsimply 7:50 pm on June 3, 2015 Permalink

              Thanks. I’ll look into these things.

            • Zach Wills 5:24 pm on June 4, 2015 Permalink

              +1

            • Ryan Boren 5:09 am on June 7, 2015 Permalink

              Toolbar > Customize is the route I take. I’d like to move that above Themes now that theme switching is built in. Directly after creating a site I head to the front page and go to Toolbar > Customize. I don’t want to see wp-admin. Having to see wp-admin is a failure. I don’t want to dig through Appearance menus in a busy admin silo. New users don’t instinctively go to Appearance > Menus. They don’t have that history and baggage. They want to Customize. From there they find what they need and never have to delve into legacy. Between the iOS app, Press This, and the Customizer, I can ignore a lot of wp-admin. I want an Edit This plugin that hooks editing and draft centric flows up with Press This so that I can ignore even more of wp-admin. I use wp-admin when setting up a business site with heavier CMS flows, although less and less as we get more capable on mobile. After that I’m good to go on a phone for the bulk of my day to day, occasionally drifting to a laptop to get at the full editor on a bigger screen.

    • carlhancock 7:15 pm on June 3, 2015 Permalink | Log in to Reply

      Not a fan. I don’t think the Customizer UI is well suited to managing Menus. Sure it’s fine if you have a blog with a single menu and simple structure. It will quickly become frustrating when using WordPress as a CMS for a more complex site involving larger menus and multiple menus.

      Not only will it be frustrating to manage a complex menu structure within such a constrained space, it will also be distracting with all the sliding in, sliding out, the site itself being displayed in the main window, etc.

      When i’m creating the navigational structure for a site I don’t look at it in terms of visual design. I look at it is mapping out the navigational structure of the site like i’m sketching a site map. This is exactly why I prefer the existing menu management tool. It’s much easier to concentrate on the task at hand.

      I also think it’s a mistake to further split up Dashboard functionality between the Customizer and the traditional Dashboard. The Customizer makes sense for visually customizing the design of your theme. Not so much for managing content. To me managing menus is more like managing content and not like managing the visual design of a site.

      @chrislema also raised extremely valid points as it relates to the wide variety of users that utilize WordPress. Those types of users most definitely aren’t going to like this. At all.

      • Mario Peshev 12:16 pm on June 4, 2015 Permalink | Log in to Reply

        I’m not sure what’s going on, but it seems to me that the Core team is hanging out with some people in their circle that probably like that change. Among the hundreds of people around me who can’t grasp that idea at all (including myself), I haven’t seen anyone outside of the decision makers who thinks that it is a good idea.

        Democracy may create a a chaos here since every decision would have people who agree or disagree on a given idea – just due to the large volume of active people. But I can’t ignore the fact that numerous major decisions lately did not involve any usability testing with different target groups or actual users.

        Obviously solutions like https://wordpress.org/ideas/ are not getting any attention anymore since there’s some roadmap on getting things in Core regardless of the approval factor from the wide community of developers, business owners, users.

      • Alvaro Gois dos Santos 3:10 pm on June 4, 2015 Permalink | Log in to Reply

        Menu is content. Menu should not be a part of customization except for the placement part. It seems obvious to me.

        And it also seems people who’re involved in this decision, as @nofearinc also puts it, are disregarding a large portion of users.

        If I had to suggest a change in Menu, it would be it’s own place in the dashboard menu, apart from Appearance and not hide inside Customizer.

    • Richard Tape 7:33 pm on June 3, 2015 Permalink | Log in to Reply

      My main concern here is when there is forced SSL on the admin-side (very popular in the enterprise) and not forced SSL on the front-end (sadly, likewise). My experience with this is… the customizer is entirely unusable, as you’re unable to load non-ssl content within an SSL context. This isn’t necessarily tied to this project, but the customizer as a whole.

      I see that links to the menu page would be removed further down the line, but the ability to actually get to and use the menu pages would still exist. Whilst I’m going to let my opinions on this functionality simmer for a while until they are fully formed, I wanted to make a point that it is vital that the ability to affect changes such as menu editing (And widget editing) outside of the customizer remains in place until we all live in a world where SSL is everywhere.

      • Weston Ruter 7:45 pm on June 3, 2015 Permalink | Log in to Reply

        Yes. This is a problem, but I do have working solution in the Customize Widgets Plus plugin’s “HTTPS Resource Proxy” module. (You’ll still most likely have to kiss any 3rd party ads goodbye, however.)

      • Ipstenu (Mika Epstein) 7:48 pm on June 3, 2015 Permalink | Log in to Reply

        To touch on this, it’s only if https://domain.com isn’t workable.

        In my case, I have WordPress HTTPS enabled and set to force ‘https exclusively’ which means if you hit domain.com, it forces http unless I’m on a specific https-only page.

        Obviously the answer is ‘Use https for all the things!’ but that’s both expensive and complicated. In addition, if you happen to have Multisite, good luck finding a GOOD ssl offering that can do both multiple domains and wildcard subdomains on said domains. So until LetsEncrypt.org takes off (soon, soon), it’s not a great experience.

    • Lisa 11:42 pm on June 3, 2015 Permalink | Log in to Reply

      I’m joining because I really care about the future of WordPress, because the future of it depends upon the users not just devs or core contributors. I am heavily invested in the WordPress ecosystem.

      As business owner who runs on WordPress, designer and user, I really don’t want to see so much stuff crammed into the customizer. Navigation and plugins will just make it worse.

      I’ve used it for simple themes and more complex and experienced issues with settings not carrying over from parent to child, and those themes like Theme Foundry’s Make, touted as the example of how the customizer should be used, just seem like waaaay too much stuff crammed into a tight space.

      When I click on widgets in the admin bar, I want to go to the admin, not the customizer – now it’s several clicks away. It’s just annoying.

      My main business is online courses and membership, but I do have a handful of client sites that I host and maintain, and I hear their pain. While it’s more business for me to do the stuff they can’t figure out how to, I really don’t want to, I set them up on WordPress so THEY could maintain their own sites, not me.

      WordPress used to be much more usable and I see this as more of it veering away.

      I would love to see a standardization of an options panel instead. Themes have evolved, and there’s just more room there to handle the evolution.

    • Knut Sparhell 1:09 am on June 4, 2015 Permalink | Log in to Reply

      Nice work! All for this great enhancement. Deprecate and remove the admin interface, but slowly, and everybody will be happy.

    • Piet Bos 3:33 am on June 4, 2015 Permalink | Log in to Reply

      I agree that the current navigation menus UI can be improved and in that aspect the Menu Customizer works great.

      I do not agree that the UI should be added to the Customizer for all the reasons that have been mentioned already.

      What I don’t understand is why these type of decisions seem to be pushed through without too much consideration? WordPress originally was build as blogging software and there is still a vast amount of people using it as a blog.
      But there is also a vast amount of people that have moved beyond and use WordPress as CMS, as @carlhancock already mentions.
      I even have sites for clients where I simply remove everything that has to do with Posts!

      Why does it seem again and again and again that the powers that be simply make decisions on things, without too much consideration or hearing people’s concerns?

      If WordPress is all about “democratize publishing through Open Source”, then why does it feel that the core dev team is more and more a totalitarian regime?

    • Nick Halsey 4:04 am on June 4, 2015 Permalink | Log in to Reply

      First of all, please keep in mind that this is only a proposal. No final decisions have been made yet, other than that we’re tentatively going to merge the plugin, based on today’s dev chat.

      For those who are concerned with the usability of Menus in the Customizer, please try the plugin on trunk and see how it feels. If you’re concerned about your clients, or specific user types, please help us with usability testing and report back with the results. Speculation and theory are subjective and can only go so far, we need to actually put it in front of users to validate our opinions one way or another. If you try the plugin though, I think you’d be surprised at how nicely it works. Even though it may be familiar, the admin screen really isn’t a great experience in a lot of ways (including using much more space than it needs to).

      Many of the objections here are resisting change for the sake of resisting change (ex. revising training practices, etc.). WordPress cannot continue to improve and evolve without making changes like this. This project addresses several specific problems with the existing system, while maintaining nearly all of the existing paradigms for how menus work and retaining a very functionally similar UI. Other than finding the UI (which deep-linking would take care of), users that are familiar with the existing system really shouldn’t have any issues with the new one.

      The problem with keeping the admin screen is that there is barely any community developer interest in maintaining, let alone improving that system. Based on what has happened with other features added to the Customizer, and the current status of the menus component, I think that we’re best off focusing on on admin system for menus and drawing a hard line on it to avoid fragmentation. Menus diverge from widgets her in that they’re feature-complete now, whereas widgets aren’t, so we could remove the admin screen immediately in 4.3. But at earliest we’d keep the legacy system around for a few releases to allow time for plugins to move over.

      • Chris Lema 5:12 am on June 4, 2015 Permalink | Log in to Reply

        “The problem with keeping the admin screen is that there is barely any community developer interest in maintaining, let alone improving that system.”

        This is a scary reason to make this kind of change. I understand it, but if we had done the same with documentation when people weren’t interested in documentation, we’d be in a very different place.

      • carlhancock 12:01 pm on June 4, 2015 Permalink | Log in to Reply

        You think the massive amount of rejections from the community on this post, in Twitter, etc. is because people simply don’t like change? WRONG.

        People don’t like this direction because it’s not a good one. Not because of change.

        I’m all for change. I’m all for making WordPress better. I just don’t think this particular change is the right direction and judging by the comments here, on another blog posts about this change, in Twitter and in Facebook… I am far from alone and it appears I’m in the majority camp on this one.

        It’s pretty amazing that despite the near universal condemnation of this direction that it was agreed to tentatively merge the plugin in the dev chat. You guys obviously haven’t been paying attention to the overwhelmingly negative feedback that has been received on this matter.

        • Gabe Shackle 4:39 pm on June 4, 2015 Permalink | Log in to Reply

          This +1000. I’ve built and maintained many sites with menus running 3-4 levels deep with fairly long titles. Trying to fit menus that large into the customizer would be a massive step backwards in usability. I’d like to see the same example video with a menu containing 50+ items in it and 3+ levels.

          Controlling the DISPLAY location of a menu via the customizer is completely understandable. Forcing users to manage menu CONTENT via the customizer is not.

    • Helen Hou-Sandi 5:11 am on June 4, 2015 Permalink | Log in to Reply

      #18517 and #32218 are fixed now.

    • Ben May 6:04 am on June 4, 2015 Permalink | Log in to Reply

      On the large projects we work on, everything apart from the menu manager is hidden or removed. While there are some quirks to the menu manager, it’s solid enough for clients to work on and use.

      Moving the menu management to the customiser really feels like it’s going to cause a lot more pain for our use case / clients / audience.

    • Jeremy Felt 7:10 am on June 4, 2015 Permalink | Log in to Reply

      This is a really excellent write-up, and the menu customizer team has done a lot of great work to get things this far over the last year. Thanks @celloexpressions and all.

      A few notes from my perspective:

      • I’d like to see a more visual indicator of the drag and drop behavior. I had a hard time in Chrome with the touchpad on OSX getting menu items to consistently drop into place where I expected them.
      • The preview of submenu items in Twenty Fifteen seems broken. There’s no great way for me to expand a menu on the previewed site and then watch as submenu items are reordered.

      Those two probably belongs as GitHub issues, but hey, here we are. :)

      • I haven’t tested it yet, but the architecture is meant to fix the `max_input_vars` issue with the current menu system, which is freaking fantastic. That said, hitting the `max_input_vars` limit in the current menu screen is usually an indicator that some other solution is necessary. (i.e. BU Navigation). I would personally be okay if the customizer UI for menus worked beautifully for smaller sets of menus rather than trying to account for a structure that involves managing hundreds of pages. Dealing with a long set of menu items and trying to drag and drop all the way up the chain is no fun in any interface.
      • The fly-out for adding new menu items is great.
      • The reorder option is great, but does leave me wishing for something just a bit better. I’m not sure what that is yet.

      Overall, I think things have progressed really well and this is a good example of panel usage in the Customizer. I’d like to see this merged in 4.3, though I’m also worried about how much user testing has been done so far. The plugin has 5000 active installs, which is great. It would be nice to have access to more real-world user feedback. I think more usability videos on the .org end would go a long way.

      I’m going to activate it at WSU tomorrow and try to get some feedback over the next week so I have a better idea of how groups will make use of it in our environment.

      The proposal to replace the current menu screen with the Customizer version is a bit premature. I know it’s been mentioned in past customizer posts, but I would have liked to see links to existing discussions to kind of fill in the blanks for those who don’t live core from day to day. There’s a sea of information that we publish together and it’s hard to find all the bits. :)

      Part of me can imagine keeping the old menus interface around in the hopes that it can become a page/menu manager of sorts in the future. I don’t think it’s anything we need to rush into and I think we can still focus on the Customizer being the primary experience after it ships.

      • Nick Halsey 5:59 am on June 5, 2015 Permalink | Log in to Reply

        The first issue (drag-and-drop drop location indicator) is in progress here. Second issue is a minor theme support thing that will be discussed further after a merge. Patch for Twenty Fifteen is two lines of JS I believe, and already included with the other work @westonruter is doing that requires core patches. Essentially, we’re trying to do “partial refresh” previews of changes to menus rather than reloading the entire front-end preview, but this does require themes that have dynamic JS on menus to be using event delegation, etc. properly. We may put this behind a theme_supports flag, but as of right now we’d like to see whether we can enable it by default.

        Note that unfortunately WordPress.org is grossly mis-reporting the active install numbers due to the existence of a similarly-named premium plugin. We really have no idea how many are actually using the feature-plugin, especially since the nightly and per-commit version bumps that the github syncer does results in mass version fragmentation that makes it hard to tell from the version stats.

        Regarding panels, the Panel API was specifically created to support menus in the Customizer, which posed the problem of user-created Customizer sections that absolutely required a dedicated area. Glad that we can finally use the API for this :)

      • designsimply 12:49 pm on June 5, 2015 Permalink | Log in to Reply

        It would be nice to have access to more real-world user feedback. I think more usability videos on the .org end would go a long way.

        Agreed. Great suggestion! I will work on this.

    • davel 7:10 am on June 4, 2015 Permalink | Log in to Reply

      Not a fan either. I have small firm clients; clients who are not technical. I only give them access to the parts they need to control; and to the parts where they could not mess up the site; like the customizer could do.
      Moving the menu to the customizer in therefore not a good idea. Regardsless of how good of bad the UI is of the customizer; some clients go into panic seeing to many options to click. And the thing is: most of my clients don’t want to have acces to modify the ‘looks’ of the site. If customization needs to be done they contact me -the webdesigner-. So having opening up the gate to the customizer some of my client would experiment or would click wrong and then would be suprised if their site looks horrible or changed into something else.

      • Ryan Hellyer 12:09 pm on June 4, 2015 Permalink | Log in to Reply

        That doesn’t really make sense to me. This doesn’t allow your clients to change anything more than they already could, it just moves the UI from the backend to the frontend.

        • Seth Alling 12:38 pm on June 4, 2015 Permalink | Log in to Reply

          I believe @davel may do what I do. With some clients, I remove the permissions for them to edit widgets and use the customizer, but they still have to ability to edit the menus. This is because they could do some serious damage to their site.

          Forgive me because I haven’t used the customizer much, but is there a way to lockdown areas of the customizer based on capabilities? If there is, then I’m neutral with the change, but if not, then I’m against it as well.

        • Slava UA 1:01 pm on June 4, 2015 Permalink | Log in to Reply

          But it makes sense to lots of other people and developers. We, the Community, are your “focus group”. You proposed this particular change, most of us rejected it.

          And now regarding Davel’s example. We change admin area nav-menu items visibility. We want editors (or any particular user) not to have access to customizer. But they should have access to Menus – and this is an easy task right now. And now, when you move things to Customizer, we are in situation when we should give such non-tech users more power in destroying their site (accidentally). Menus are NOT visual thing by nature, it’s a navigation – rather structural thing. I just don’t understand why it should be where you propose it to be.

        • Ipstenu (Mika Epstein) 1:41 pm on June 4, 2015 Permalink | Log in to Reply

          A lot of people lock down or remove the customizer, especially on Multisite (I know!) to maintain a homogeneous site design. All you can edit are menus and widgets. No color changes etc.

    • Fabien Quatravaux 9:35 am on June 4, 2015 Permalink | Log in to Reply

      This proposal is, in my opinion, a very good move. I have realized that the current menu management page is really hard to work with for new WordPress users. So it’s very good news that menus can now be managed directly in the customizer.

      I’m also a plugin developer that uses the current menu administration page. I’m using the “wp_edit_nav_menu_walker” filter to let user add an image to each menu item. That could be a good thing to grep for you @ipstenu.

      Thanks @celloexpressions for the detailed explanation and keep up with that hard work everybody !

    • MyInternetScout 12:18 pm on June 4, 2015 Permalink | Log in to Reply

      Without repeating all the solid points already mentioned about how the menu shouldn’t be moved to the customizer, I support Chris Lema’s (and others’) position to not move forward on this item as proposed. Training and re-training clients can be difficult. A sudden change like this could overwhelm the support capabilities of a small boutique design firm. Also, many see the menu system as a ‘content’ element that should be located were ‘Post’, ‘Pages’, ‘Categories’ and ‘Tags’ are – something I agree with.

      A little off topic, but related… because the WP user-base is so large and diverse now, I wish the Core team would start minimizing the frequency of UX changes to maybe once a year. WordPress does have a steep learning curve for non-developers (aka my small business clients)…and, unless these UX changes are truly intuitive improvement, such as drag and dropping photos into the media library, they’re not helpful. It presents WordPress as an unpolished product/platform.

    • John Teague 12:38 pm on June 4, 2015 Permalink | Log in to Reply

      Honestly, if the goal is to turn WP Admin into to Squarespace UI just say so and let’s be done with it.

    • jadpm 12:53 pm on June 4, 2015 Permalink | Log in to Reply

      Sorry to say, but WordPress seems to be trying to solve the multiple not-standard loaded problem on theme options frameworks with a single standard even-more-loaded GUI that deprecates existing, working and familiar interfaces.

      Not a fan.

    • danhgilmore 1:35 pm on June 4, 2015 Permalink | Log in to Reply

      In my largest installation, I have 38,752 sites. Will the current menu settings be moved over to Customizer, or will I have to train my customers how to do it?

    • Ipstenu (Mika Epstein) 1:39 pm on June 4, 2015 Permalink | Log in to Reply

      I’m not opposed to change. I’m not opposed to changing my mind. I think that having the menus as something I can set visually, to see how long a menu is and how it will look on my site in the GUI like the theme customizer is a good thing.

      Having the menu be visual, to see “oh hey, this looks bad on mobile” by resizing the screen, is awesome.

      But I don’t think it should be the ONLY place we do that.

      Similar to widgets, if I want to quickly reorder things, the widget panel is faster. One click to the page, move a box, done. Swapping out a link, I don’t want to go through the customizer not because it’s different, but because the flow is not sensible for what WordPress has been.

      Menus are post types, which has driven much of our design and purpose with it. Since they’re post types, we treat them as content, not design. Exactly like we do for widgets. Menus and widgets are both content.

      As for the customizer, well, using that for theme design makes sense. You (should) only design your theme once. You set it up, make it pretty, and you concentrate on what’s important. Content. Yes, we want to see how our content looks within the context of the site, and to that end I laud the customizer. But to have it be the only place, while annoying to mess with for support in two places, strikes me as a bit more logical.

      I would hope the ten tickets with solved issues (including the fact that the menus hang on save with ‘too many’ items) is carried back to the original menu interface. It’s a more practical interface for many businesses who lock down the customizer, in order to prevent people from changing major design aspects.

      And of course, given that the customizer doesn’t work if you have any sort of http(s) mismatches when you have secure admin but not a front end (not all CSS or font content will load because of insecure content), it feels like a ‘not yet’ moment. We gave WP the ability to be used in myriad situations. We have to support those people now.

      • carlhancock 1:58 pm on June 4, 2015 Permalink | Log in to Reply

        I’m not opposed to a Customizer style UI either. I’m just opposed to how it’s being down as it is right now. It seems obvious that there are plans for the Customizer to become the defacto WordPress administration tool. This is fine with me, if it’s done right.

        I don’t think doing it piecemeal the way it’s being done is the right way. Fragmenting the WordPress admin having some functionality in the Dashboard and some functionality in the Customizer just causes confusion. Especially when things are moved from one to the other in a piecemeal manner.

        If WordPress wants a Squarespace style admin, then build a Squarespace style admin. Outside of WordPress. In a plugin like MP6. Over a longer period of time. With more developer buy in. Work with plugin and theme developers to prepare for such a change over a longer period of time. Publicize the hell out of it and prepare the public for such a change. Then roll out the admin all at once at a later date with a big release.

        Yes this is a daunting proposition. Scary actually. But I think that baby steps with the UI involving fragmentation of functionality between 2 different UI’s just looks bad from a product standpoint. It looks patchworks. Amateur.

        Otherwise leave the admin alone and keep the customizer confined to managing the visual aspects of your site. While Menus are displayed visually on a site, they are actually a type of content. Stick to styling the menus in the customizer and managing the menus in the Dashboard.

        I wouldn’t be at all opposed to a radical new admin UI along the lines of what the Customizer is. Let’s face it… It’s a SquareSpace admin UI. It’s worked for Squarespace. It could work for WordPress.

        But i’m not a fan of the piecemeal implementation that is happening. It’s not good from a usability standpoint, and makes the WordPress admin look like a hot mess of different user interfaces.

        • Ipstenu (Mika Epstein) 2:28 pm on June 4, 2015 Permalink | Log in to Reply

          I don’t think the customizer should be the de facto admin tool. Maybe the DESIGN tool, for people who can’t code it’s great. But design and day to day work aren’t the same thing. They engage different parts of your brain.

          “Menus are content” – exactly that.

          • carlhancock 2:42 pm on June 4, 2015 Permalink | Log in to Reply

            I agree. Right now the customizer is a design tool. That’s how it was implemented.

            But Squarespace, and others, have proven that an admin UI can be implemented overlaid on the front end of the site like this and incorporate more than just design elements. Let’s face it, that’s where this pressure is coming from. Solutions like Squarespace, Wix, etc.

            It can be done. But how WordPress is doing it is just causing UI fragmentation which accomplishes nothing but making the product look piecemeal and inferior to the other web site solutions on the market.

            Menus are content, and with the current direction that WordPress is headed with having the Dashboard for content and the Customizer for design… putting it in the customizer is not ideal.

            But if WordPress is heading in the direction of having everything in the Customizer, at which point it won’t be the “Customizer” anymore but rather the new Dashboard or Admin… then they need to go about it a different way. Piecemeal is not the way to do it.

            IF the longterm goal is entirely new admin UI based on the customer then doing it piecemeal is the easy way from a development standpoint. Baby steps. BUT at this rate it will take years to migrate everything over. And during that time WordPress is going to look like Frankenstein. A patchworks of different UI conventions split over the traditional Dashboard and the Customizer style UI. I think that is a mistake. It makes WordPress look bad as a platform.

            I mentioned this on Twitter and it’s relevant in this discussion…

            Developers are not always product people. Ditto designers. WordPress needs more product people involved in core and decisions like this. Situations like this are perfect examples of what happens when there isn’t a product person or product person(s) guiding the overall direction.

            WordPress is an open source project. But it is every bit a product and needs to be treated as such. Anyone with an eye for product development would see that this kind of fragmentation is not a good idea for WordPress as a product.

            • carlhancock 2:52 pm on June 4, 2015 Permalink

              And let me be clear. I think WordPress SHOULD move towards a Squarespace style UI like the Customizer for ALL THINGS. But NOT how it’s being done now. Not in a piecemeal manner. And not with the current UI.

              Squarespace UI is far more elegant. The arguments regarding the constrained space don’t take into account the UI can expand as needed, even going full screen. Which is exactly what Squarespace does.

              I just don’t think doing it piecemeal is the right way from a product standpoint. UI fragmentation is bad. Especially when WordPress is already daunting and complex for many users, something that us power users typically take for granted. Fragmenting the UI makes it that much more difficult and annoying for end users.

              I’m all for a completely rethink of the entire WordPress admin. I’m all for a Squarespace/Customizer style interface. I just think handling it in piecemeal fashion is a mistake.

            • Elio Rivero 3:23 pm on June 4, 2015 Permalink

              So far I’d like what you’re doing with the menus. I’ve tested the plugin and it’s certainly intuitive. Leaving aside the debateable issue of whether menus are content (which I believe they are) or interface (which I believe they are too), the current path is good.

              Now, there might be other alternatives down the road better than this? I hope so. I would like to see some tool like Iseulde’s Front End Editor to edit every content in the site, whether it’s the site title, tagline, or, yes, the menus. Right now the (dissociative) nature of editing content on one panel and seeing it in other like is a bit distracting. It’s not what we’ve been used to do since, let’s say, word processors? you edit the content inline, but you can also select something and apply style. Another example is to write some text in real life: you choose the color (style) of the text (content) you want to produce. It’s always strictly separated, styling tool – content. Customizer could be something like this, becoming a glorified toolbar strictly dealing with styling, allowing users to enter their content inline.

              Hope it makes sense. Basically, I like the plugin and the overall idea, but I expect to see something more overlaid on top of the site, maybe along the lines of Front End Editor.

      • Nick Halsey 7:06 am on June 5, 2015 Permalink | Log in to Reply

        Slight clarification: menus are actually taxonomy terms, not posts (menu items are post objects). Accordingly they bridge both post objects and taxonomy terms grouping post objects into a sort of index of content accessible on the site. Closely tied to content, but not really content in themselves.

        Of course, as westonruter mentioned a couple of times here already, the Customizer can and should be used to edit content. If you look at our component page linked in the post, you’ll see that front-end-editing that leverages the Customizer is one of our goals for the future.

        • carlhancock 8:53 pm on June 5, 2015 Permalink | Log in to Reply

          My issue is NOT with using a Customizer style UI for managing menus. My issue is with the implementation of the Customizer UI in WordPress beyond theme styles and the fragmentation of the WordPress admin that is happening as a result.

          WordPress is becoming Windows 8. Microsoft made the mistake of fragmenting the UI and it was such a stupid mistake that they are skipping Windows 9 when they launch Windows 10 to further separate it from the UI mistakes made in Windows 8.

          Were all of the UI decisions made in Windows 8 bad? No. But the implementation was poor so now they’re having to fix it and blend the ideas behind the 2 different Windows 8 UI’s into a single unified interface.

          WordPress is in a similar situation. Right now it’s making the same mistake Microsoft did with Windows 8.

          If a Customizer style UI is the future of administering a WordPress site as a whole… then WordPress needs to go all in with it.

          Splitting administrative functions between 2 very, very different UI’s is NOT good from a user interface or user experience standpoint and makes WordPress look like a Frankenstein of a CMS. Piecemeal is NOT the way to do this.

          I have no issues with the general direction that the UI of the Customizer uses. Squarespace has a similar user interface. It looks great and is far more elegant and consistent. When admin functionality requires more screen real estate, the sidebar expands to accommodate it. It doesn’t try to do everything in extremely narrow columns. For complex actions it expands wider than simple actions. It’s not bouncing you around completely different user interfaces.

          WordPress needs to decide what the future of the WordPress Dashboard is. If it’s a Customizer/Squarespace style UI than fantastic. But the WordPress project as a whole needs to pick which direction it’s going in and commit to it full stop.

          I think it should go in that direction.

          But if the approach is to slowly move things over piece by piece and leave users, developers, plugin developers, and theme developers to have to jump between the old Dashboard UI and the new Customizer UI as pieces are slowly moved over across what would likely be years… I think it is a horrible mistake.

          I blogged about this here: http://carlhancock.com/wordpress-is-making-the-same-mistakes-microsoft-did-with-windows-8/

          Don’t mistake dislike for this direction as dislike of change, or some sort of education issue. It is neither. It’s a dislike for turning the WordPress UI into a fragmented mess of a user interface.

          • Weston Ruter 9:38 pm on June 5, 2015 Permalink | Log in to Reply

            @carlhancock Yes, fragmentation of the admin UI is a concern. However, we also have logistical problems as you’ve also identified, where this is an open source project with volunteers contributing, so it is impossible to go the route of a closed proprietary team taking an entirely new radical direction all at once. Leaving aside the training/education aspects of changing where things are managed, there is the more fundamental problem of “person-power” to implement the change.

            If the eventual goal is to improve the Customizer to a point where it can serve as the shiny new JS-driven WordPress admin, with all of its current deficiencies accounted for, then the only way it can happen is in a piecemeal way: adding more and more capabilities to the Customizer with each release. The critical thing here though, and this seems to be the primary concern of almost everyone commenting here, is that the existing Menus admin page cannot go anywhere. Perhaps everything needs to stay right where it is in the WP admin until the eventual point where enough contributions have been made to make the Customizer complete enough to serve as the new de-facto interface for WP administration.

            If this is the direction we’re going in, it will take time. If people find the current issues with the Customizer too aggravating to bear with, then they should be able to continue to do things the old way in the WP admin. We need the WP admin to remain anyway for backwards compatibility. But they should check-in periodically to see how the Customizer has improved, and gradually see it evolve to a point where they can say, “Hey, I actually prefer this now.” But in order for that to happen, we need constructive feedback on how specifically it should be improved, and we also need more contributors.

            (BTW, and a bit of a tangent, but my understanding from elsewhere on the Web for why Microsoft chose to name it Windows 10 and not Windows 9 is because of legacy applications that are hardcoded to check for Windows 95 and Windows 98 via looking for the substring “Windows 9”. I could be wrong :-) )

            • nathanrice 10:04 pm on June 5, 2015 Permalink

              Then that’s a good reason to develop features as plugins first. That way, they can be tested thoroughly without polluting the admin for users in the time between version 0.1 and version 1.0.

            • Nick Halsey 10:38 am on June 6, 2015 Permalink

              Yes, and for quite a long time the “tipping” point for the Customizer being able to actually take over an entire section of the admin was thought to be moving everything in “Appearance”. Menus is the last major thing there, but it turns out that we can go further, really.

              Not everything should or will move over from the admin, but I’d like to eventually get to a point where the admin is a secondary interface that is more power-user-oriented and has more advanced options. We have to keep everything in the admin there for at least some users because WordPress supports no-js. There will always be use cases, like list tables, bulk edit, etc. that don’t make sense outside of the admin context. But eventually I see the ideal user flow, at least for new users, being primarily oriented around the Customizer. The next big thing to tackle will be content and front-end-editing integrations, but that will of course take a lot of effort to even attempt. Biggest question is where we should remove elements from the admin that really belong exclusively in the Customizer, and I’d say things categorized as “Appearance” would make sense as Customizer-only. If a content-centric (list-table-integrated) menus experience is built in the future in another spot in the admin that’s fine, but menus are currently more at the presentational level of a site than being the actual content (controlling how to present the content in terms of the visitor’s perceived structure, not the actual data structure).

              Sidenote: I actually think Windows 8 was really well done (8.1 particularly, as it addressed most of the issues, but then it was more of a branding problem), especially for the types of interactions it was designed for (hybrid touch and mouse/keyboard). It’s great on a touch screen laptop or a hybrid, less great on a desktop but still better overall than Windows 7 on any device. The navigation between the two UI styles there is pretty seamless, and until we’re able to route users primarily through the Customizer we need to do what we can to guide them in and out. That’s why we’re emphasizing the front end context, and accessing the Customizer from the front-end instead of the admin.

    • Curtiss Grymala 1:52 pm on June 4, 2015 Permalink | Log in to Reply

      Well said, Mika.

      I’d also like to add that menus aren’t necessarily tied to a theme location at all.

      There are a number of use-cases where you can create a menu specifically for use within a widget, and that widget may only appear on a single page or group of pages. Trying to create a menu like that exclusively through the customizer would be extremely cumbersome and potentially very confusing.

      Aside from that, there’s also the current issue that the customizer is locked to a side of the screen (as far as I know, it can’t easily be re-factored to run horizontally along the bottom/top of the screen), which, in many cases, triggers a different, potentially mobile-friendly, layout. A lot of small firms/hobbyists will be completely thrown off if they’re trying to customize a menu this way when, visually, it doesn’t match what they’re used to seeing on their computer screens.

      • designsimply 1:07 pm on June 5, 2015 Permalink | Log in to Reply

        in many cases, triggers a different, potentially mobile-friendly, layout

        I’ve run into this problem too. There’s a collapse option at the bottom left of the customizer controls panel, do you think it would help to make that more prominent and maybe even re-label it? (Not sure yet what a more user-friendly label might be, but I like the idea of that.)

    • tommcgee 1:54 pm on June 4, 2015 Permalink | Log in to Reply

      I understand the need for mobile-first for a lot of things; but as someone here has pointed out you generally set your menu once and then leave it.

      What kind of menu change would I need that would be so urgent that I couldn’t wait until I got back to my desktop PC? And is it worth the trade-off for making the original setup that much more difficult because of the narrow space that is allowed in the customizer?

    • Lisa 3:43 pm on June 4, 2015 Permalink | Log in to Reply

      Thanks @carlhancock for mentioning SS because now I’ve decided to build a site with it so I can really compare the difference.

      I’m tired of hearing about folks moving to it and bashing WP, so I need to take a good look. Then I’d like to find a way to contribute here more to the future of WordPress.

      So the issue I experienced and mentioned in my comment about child themes is here – https://core.trac.wordpress.org/ticket/27177

    • lockedown 4:36 pm on June 4, 2015 Permalink | Log in to Reply

      The decision to move Menus to the Customizer, and immediately deprecate the Menu admin seems very rushed and may hurt WordPress, the platform.

      There are billions of websites. WordPress powers a quarter of those, so hundreds of millions of people are affected by the UI decisions made by a handful of developers.

      The majority of users are comfortable with using the Menus screen. After all, it’s been that way for a decade. But now, the proposal is to eliminate it completely. I think this will cause mass confusion for those hundreds of millions of users who aren’t part of the WordPress 1% who follows these changes closely.

      I understand that WordPress needs to scale. But when you an important change like this, to how people use the platform, that re-training becomes difficult to scale. The development team will not be able to help re-educate the hundreds of millions of clients who will wonder where their menus went.

      Put menus in the Customizer, but don’t immediately eliminate the Menus screen. Because users will not blame the themes or plugins that don’t update with these changes, they will blame WordPress the platform.

      • designsimply 1:09 pm on June 5, 2015 Permalink | Log in to Reply

        If you haven’t already, please test menus in the customizer! It sounds from your comment like you haven’t tried it yet.

    • Dan 4:52 pm on June 4, 2015 Permalink | Log in to Reply

      I want to voice my concerns with this move as well. I completely agree with those who are outlining the issues with re-training, the UI, and how this is fragmenting the admin interface and confusing the end user.

      Taking into account the discussion had over forcing repository themes to use this, I really think the WordPress core team needs to take a time out and have a larger discussion about where the Customizer. This approach of shoving it down our throats clearly isn’t working.

      • designsimply 1:12 pm on June 5, 2015 Permalink | Log in to Reply

        Would you be willing to test the plugin with a few users in a training setting? I’d love that and can help with ideas for testing and gathering feedback if it sounds like something you want to help with.

    • bmoredrew 5:05 pm on June 4, 2015 Permalink | Log in to Reply

      Has anyone considered the implications to managing a large menu, like one with 100+ items and several levels deep? This feels like a square peg in a round hole in that case.

      I’m not 100% opposed to menus being brought into the customizer – but at minimum the dedicated menu screen should be left in place.

      • designsimply 1:13 pm on June 5, 2015 Permalink | Log in to Reply

        Let’s test it. Are you volunteering to help test?! :)

        • Bowe 2:28 pm on June 5, 2015 Permalink | Log in to Reply

          Since it’s already approved for merge in core you’d think.. I dunno.. that you’d tested this before accepting it into core?

          • designsimply 9:57 pm on June 25, 2015 Permalink | Log in to Reply

            It was. :)

            I would like to encourage more testing though! If you are complaining here, you should really try testing the feature yourself. Many of the commenters sounded to me like they hadn’t tested, and being part of an open source community means you have the chance to get involved in a more positive way.

    • Jonathan Christopher 5:06 pm on June 4, 2015 Permalink | Log in to Reply

      Thinking out loud, regarding removal of the link to the existing Menus area: what about the Links Manager approach? For those unfamiliar: as of WordPress 3.5 the Links Manager was simply hidden for new installs and existing installs got to keep it, untouched. To this day you can enable the Links Manager on a fresh install of the latest version with a simple filter:

      `add_filter( ‘pre_option_link_manager_enabled’, ‘__return_true’ );`

      I realize this goes against the grain of being a decision, and a ton of thought/work went into this proposal, but I’m wondering if it’s feasible to consider the Links Manager approach?

      Again, this thought just occurred to me over lunch, I haven’t fully thought it through, and it doesn’t solve the issue of the tickets for the Customizer-version-of-Menus not being rolled into Menus, but personally I think the existing Menus system can continue to work in many ways.

      • David Sullivan 6:12 pm on June 4, 2015 Permalink | Log in to Reply

        That’s effective. It would save devs link me scores of questions about missing a missing menu editor. Plus going forward, new users get acquaint to the new UI.

      • Mike Selander 8:25 pm on June 4, 2015 Permalink | Log in to Reply

        This is a very clever idea but it would be difficult to implement for existing sites. We have somewhere in the range of 200 live sites on which we still have contact with the owners and it would be a beastly job to add this to even a tenth of them and retraining that many clients is unfortunately not an option.

        • Justin Sternberg 1:08 pm on June 5, 2015 Permalink | Log in to Reply

          I believe the idea is that: If you already have WP installed and using the menus, the UI will stay in place. If you’re installing a fresh version, the UI would be hidden by default.

          • Matthew Eppelsheimer 1:42 pm on June 6, 2015 Permalink | Log in to Reply

            This is a very good idea — similar to what was done with links.

            I share others’ concerned about remove the existing admin menu system. We never want to break backwards compatibility if we can help it. But I think this concern is adequately addressed, if the existing admin menu settings page is kept in place for existing installs, off by default for new installs, and available to be re-enabled for new installs.

      • santeven 8:35 pm on June 7, 2015 Permalink | Log in to Reply

        Remember the custom Header and custom Background admin pages? And whatever happened to the Themes and Widgets links in the front-end admin bar? As of today in 4.2.2 they easily can be displayed within the admin bar, in addition to the corresponding Customizer links already there.

        So long as the Menu Customizer team does no more with nav-menus.php and themes.php than what the Widgets Customizer team did with widgets.php , I expect the same will hold true for the Menus and Themes admin pages.

        Full write-up and plugin zip-file at http://wpmulti.org/old-school-themes-admin

        `
        <?php
        /**

        • Plugin Name: Old-School Themes Admin
        • Plugin URI: http://wpmulti.org/old-school-themes-admin
        • Description: Display admin bar links to the old-school dashboard appearance pages, in addition to the newer customizer links that recently have replaced them. Themes= themes.php Widgets= widgets.php Background= themes.php?page=custom-background Header= themes.php?page=custom-header
        • Version: 0.1.0
        • Author: Martin Robbins
        • Author URI: http://wpmulti.org
        • License: GPL2 or later
        • License URI: https://www.gnu.org/licenses/gpl-2.0.html

        */

        add_action( ‘wp_enqueue_scripts’, ‘old_school_themes_admin_bar’ );

        function old_school_themes_admin_bar() {

        $custom_css = ”
        .customize-support #wpadminbar .hide-if-customize,
        .customize-support .hide-if-customize {
        display: block;
        }”;

        wp_add_inline_style( ‘admin-bar’, $custom_css );

        }

        ?>
        `

    • theresajennings2011 5:42 pm on June 4, 2015 Permalink | Log in to Reply

      Shoving the menu into the customizer reminds me of Facebook’s decision to have PMs entered in a tiny little box at the bottom of the browser window. I agree with Chris Lema’s relating it to poor vision in older people. I’m 57, but I’m certainly not at a 800×600 resolution. I have a 30″ monitor at its highest resolution! Still, the customizer feels cramped.

      So in the video, I see a brief nod at sub-menu items, but what if you have sub-sub-menu items, and heaven forbid, sub-sub-sub menus too? It feels like we’d be doing our work inside a broom closet. The menu is content, and working with the menus in WP is light years better than working with them in Joomla. It’s like a breath of fresh air, in fact. Could the menu experience be improved? Absolutely. But the menu *is* content, not styling, and needs to stay in the admin area. At the very least, please don’t remove it from the admin area.

    • Matthew Boynes 6:58 pm on June 4, 2015 Permalink | Log in to Reply

      If this plan went through as proposed, this would be the first feature to only exist in the Customizer. I think the Customizer is a wonderful addition to WordPress, but I think it should remain a complementary feature. I don’t think that any (core) feature should only exist in the Customizer. I’m therefore opposed to removing the existing admin page.

      Dashboard-page-debate aside, great work on a complicated feature!

      • Job 7:30 pm on June 4, 2015 Permalink | Log in to Reply

        From a non-dev perspective, I agree with this.

        I think having the menu option in the customizer is great. It’s a lot more intuitive for new users, especially since you get to see the result straight away.

        However, I think at least until it has become a routine for existing users to add menus in the customizer, keeping it in the dashboard as well, makes a lot of sense. That would also solve the problems Chris Lema identified on his blog. A more relaxed transition would also allow bigger companies to get more adjusted to all of this.

        That being said, having the menus in the customizer is great. I remember at first struggling to find where to edit the menus. If the customizer was there when I started with WP, I would have faster found them in there then where they are now.

      • Konstantin Obenland 4:39 pm on June 5, 2015 Permalink | Log in to Reply

        I’m therefore opposed to removing the existing admin page.

        There are currently no plans to remove the existing menu admin screen. While the proposal suggested it, it was never part of the decision to merge the existing plugin.

        • Matthew Eppelsheimer 1:50 pm on June 6, 2015 Permalink | Log in to Reply

          This is a little confusing Konstantin, because the proposal makes a very strong assertion that does seem to be a plan, not just a suggestion.

          > “This project has a very explicit goal of not just adding menu management to the Customizer, but also removing the existing admin page in the process.”

          Is that goal not sanctioned by the core team?

          Thank you for clarifying.

          • Nick Halsey 8:30 pm on June 6, 2015 Permalink | Log in to Reply

            It’s a goal of the team building this feature, but it’s been decided that we aren’t going to make any official decisions on it yet in terms of core.

    • Jimmy Smutek 7:24 pm on June 4, 2015 Permalink | Log in to Reply

      I’m also not a fan of this idea for all the same reasons mentioned above. I did want to try the functionality out so I installed the Menu Customizer plugin from the repository. After activating the plugin the site crashed when trying to access the customizer with `Fatal error: Call to undefined method`.

      This is on a clean install of WordPress 4.2.2, 2015 theme, and no additional plugins, all running locally on a VVV box.

      For me, as an average user, I don’t understand how such a huge decision could be made to not only move forward with this, but to quickly remove the menu admin screen, when the plugin implementing the functionality doesn’t even seem to be stable at this point.

      Something minor I can understand, and I understand that it’s a feature that is under development – but my _first experience_ with this functionality was a white screen, on a completely clean site.

      I don’t get it.

      • Jimmy Smutek 7:52 pm on June 4, 2015 Permalink | Log in to Reply

        *note – it would have helped if I were running 4.3 alpha, as the plugin requirements state.

        Sorry about that.

      • Konstantin Obenland 4:38 pm on June 5, 2015 Permalink | Log in to Reply

        I don’t understand how such a huge decision could be made to not only move forward with this, but to quickly remove the menu admin screen

        There are currently no plans to remove the existing menu admin screen. While the proposal suggested it, it was never part of the decision to merge the existing plugin.

    • John Teague 8:16 pm on June 4, 2015 Permalink | Log in to Reply

      I have read through the many comments here today, and also on twitter and elsewhere and decided to write a rare blog post with my views on it. I mainly did this because I have been having this conversations for several months now, and I also agree with @carlhancock on many of his points. Might be worth a read, might agree, or you might want to run me out of town on a rail. But for what it’s worth: http://johnteague.me/wordpress-admin-ui-moving-to-squarespace-ui/

    • leehodson 1:06 am on June 5, 2015 Permalink | Log in to Reply

      I don’t get it. Why replace the existing menu editor with something that adds more clicks to the menu creation process. Why not replace the whole process with a more visually intuitive menu editor that lets users build menus exactly as they display on screen? e.g. drag page tabs directly into the menu bar they will be used in.

      Maybe look for enhancements of the existing system before we move it to the Customizer. For example, the existing menu management system could be enhanced with collapsible top-/sub-level menu items so that lengthy menus can be more easily managed.

      I dislike using Customizer for widget management. Looking at the video I know I will not enjoy using the Customizer for menu management.

      Change can be good and I look forward to seeing the WordPress UI develop. I just don’t like the idea of change being implemented for the sake of it or because the intended result feels cute. Not keen on this particular change.

      • designsimply 2:41 pm on June 5, 2015 Permalink | Log in to Reply

        Thanks for your feedback. The changes were definitely not just made for the sake of it, and making an assumption like that isn’t really fair nor is it a good conclusion based on how much detail is in the proposal about the thought that went into the improvements and the amount of work people volunteered to do to get it to the proposal stage. :)

        You mentioned you watched the video, but it sounds like you did not test the plugin. Would you be willing to test?

    • kimstuart 4:08 am on June 5, 2015 Permalink | Log in to Reply

      I think it’s a terrible idea for a number of reasons that have already been stated. It’s a terrible mobile experience, it’s a badly designed UI for a desktop experience, and it’s overcomplicating the situation for a vast number of users.

      Envato etc will become even bigger than they are – authors will write themes that people like and want to use and when they are installed, they’ll just start hiding all the parts that don’t work for what their buyers like. And those authors don’t care a whit about being in the repo, they care about cashing checks from sales.

      And what’s the hurry to gin this up so fast anyway? There seem to be a large enough number of objections from qualified people that it should trigger a review of the whole process in more detail, with some serious testing on the possible side effects.

    • Philip Arthur Moore 4:33 am on June 5, 2015 Permalink | Log in to Reply

      Please understand how much time, money, blood, sweat, and tears go into training users for WordPress. Deprecating the Menus screen because there’s not currently interest in it is a very poor argument. I understand the importance of the Customizer, and as a developer use it as much as possible. But trying to force feed this down users’ throats will ultimately cause people to abandon the product. The overwhelming consensus in the comments on this thread and on Twitter, blogs, etc., is that this is a bad move. I truly hope that Menus sticks around the Appearance screen until Menus in the Customizer (and anything in the Customizer) is made better. Right now it feels like we’re trying to create solutions to problems that don’t exist.

      • designsimply 2:43 pm on June 5, 2015 Permalink | Log in to Reply

        Deprecating the Menus screen because there’s not currently interest in it is a very poor argument.

        Would you be willing to work on the menus admin page? It sounds like it needs some love!

      • Konstantin Obenland 4:33 pm on June 5, 2015 Permalink | Log in to Reply

        There are currently no plans to remove the existing menu admin screen. While the proposal suggested it, it was never part of the decision to merge the existing plugin.

        • Jon Brown 7:51 am on June 14, 2015 Permalink | Log in to Reply

          Even if not removing the existing menu admin screen it sounds like “it’s dead” and no one is ever going to fix the trac tickets for that screen.

          For example is #14134 going to be set to wontfix? or is the idea that their actually fixed by the customizer? (not: I still can’t get the menu customizer working on large menus that used to be an issue with #14134, it just hangs making it no better than the old admin screen).

          Elsewhere it’s been said that the idea is the admin will remain for “power users”, but what good is that if it still doesn’t work for power users?

          Just want to raise what “fixed” actually means in this context before tickets start getting marked “fixed”

    • Piet Bos 6:30 am on June 5, 2015 Permalink | Log in to Reply

      Something I don’t understand. I was under the impression that it is a PROPOSAL, right?

      But I just find an email in my inbox that says “It was approved for merge” (https://make.wordpress.org/core/2015/06/05/dev-chat-summary-june-3/)

      How does that work exactly?

      Can anybody shed light on this?

      • Tom 11:40 am on June 5, 2015 Permalink | Log in to Reply

        I am not sure of the official process (or if there even is one), but here is what I believe has happened:

        The decision to develop Menu Customizer as a “feature plugin” was made a long time ago. The intention of Feature Plugins is that one day they will end up in core.

        On June 3rd at 1am the official proposal to merge the plugin into core was made. The surprise here is the proposal was not just “it’s ready to merge”, but also included the idea of removing the existing menu page.

        Between 1am and 9pm, 11 people had commented on the proposal, most of them opposing the idea of removing the menu page. At 9pm the dev meeting was held and a handful of developers gave it the go ahead. Important note: the proposal to remove the existing menu page was not approved, that will be decided on some time in the future.

        Most of the comments you see here and social media have been made since the dev meeting was held.

        My take on the decision to merge was that it’s just a formality. The decision that the Menu Customizer would one day end up in core was made a long time ago. The dev meeting was just to discover whether it will be ready or not for 4.3.

      • designsimply 2:34 pm on June 5, 2015 Permalink | Log in to Reply

        Roughly, the process is that developers who take time to create and submit new features go through the checklist guidelines on the following link and then the core developers, together with the release lead, decide whether to approve. There are a lot of factors involved, but this page in the core handbook has a good overview:
        https://make.wordpress.org/core/handbook/how-the-release-cycle-works/features-as-plugins/

        If you are interested in contributing code or learning more about how WordPress gets made, you should definitely check out the core handbook.

    • Bowe 7:29 am on June 5, 2015 Permalink | Log in to Reply

      What I don’t get is why for some reason everything that includes a “Live” preview should be tucked into the customiser. I can absolutely see the benefit of having a live preview of your new menu before you put it live. So what about just doing what WP has been doing for years with Post previews? Why don’t they add a big nice, shiny “Preview Menu” to the existing (incredibly well made) Menu manager that shows how your new menu will look? And what if this preview window would automatically refresh whilst you are working on your menu. You could dedicate a full browser tab/window to having constant live previews without having to cram all of this advanced functionality into one screen.

      And if that previewer works you can look at using some of the awesome JS stuff in Core to load this preview through a fancy animated JS/AJAX preview. This way you could move towards a preview that does not require a second browser tab/window to be open. Like this: http://codyhouse.co/demo/animated-page-transition/about.html

      What I’m trying to say here is.. It feels and seems like the Core team has decided in order to move WordPress forward it needs to make things more clear and easy to the user through showing changes as they happen. I think this is a great idea but hinging all of this on the Customiser simply because it’s the only part of WP that currently offers this type of live preview functionality is troublesome.

      Please reconsider this way of moving forward Core devs. I think it’s a mistake from especially an user experience point of view.

    • buzztone 9:58 am on June 5, 2015 Permalink | Log in to Reply

      I see no issue with Menus being added to the Customizer. Objective measurement of its popularlity there, compared to the current Menu UI, could then be used to justify subsequent removal of the Admin Menu UI.

      Personally I’d be extremely surprised if Customizer Menus ever show the popularlity necessary to justify removal of the current Menu UI.

    • Jimmy Smutek 4:44 pm on June 5, 2015 Permalink | Log in to Reply

      @designsimply – I’ll help test. I already have a local test site setup with 4.3 Alpha, I have the plugin installed, and have been messing around with it.

      @Nick Halsey mentions education being an issue. I’m all for education and am more than willing to help out where I can and keep an open mind. @Bowe asks [this question](https://make.wordpress.org/core/2015/06/03/feature-plugin-merge-proposal-menu-customizer/#comment-26036 “Permalink”), above:

      >Since it’s already approved for merge in core you’d think.. I dunno.. that you’d tested this before accepting it into core?

      That’s a pretty good point, and a fair question. Can someone answer that?

      • Nick Halsey 10:44 am on June 6, 2015 Permalink | Log in to Reply

        It has definitely been tested with lots of menus with lots of items (I’ve played with 4-5 level deep and confirmed that you can do up to ten deep, and menus of roughly 50+ items). But of course the best testing comes in real-world usage, so if anyone is able to test with actual sites and menus (on local copies of course) that’ll help us identify and address any issues before the feature is actually released.

    • nickmg 6:11 pm on June 5, 2015 Permalink | Log in to Reply

      Joining the discussion in the official channel based on recommendation from others. To me the inclusion of the menu system in the Customizer is just scratching the surface of a much bigger issue.

      The core of the problem in my opinion is the current implementation of the Customizer. You want to have a Customizer with a live preview? Fine, no objections there. But if you do such thing, please step back and understand the importance and the implications of not doing it right.

      More specifically, the Customizer is designed and implemented with the Mobile First, Responsive guidelines in mind. Indeed, on a mobile device the Customizer looks and works fine. Great job, well done! No complaints there. Provided that I want to use an iPhone to control my site settings. But that’s another conversation.

      The problem, however, is when you start using the Customizer on the desktop. Then what you see is a cluttered, crowded space, with navigating options that don’t make much sense in the desktop world. The irony is that the UI doesn’t even take advantage of the desktop wide screens. Why, because the width of the Customizer is designed to fit the mobile screen in vertical position.

      To accomplish simple tasks, you need to make several clicks, provided you know where to click first. As many others have said here there are so many UX issues with the Customizer UI, so I am not going to repeat them. And why did this happen in the first place? Because we tried to have one code base for the mobile and desktop versions. Why? Because that’s what flies currently as the dominating design trend and is cheaper. What could have been done and could be done differently going forward? Accept the fact that Desktop and Mobile UX are two different animals and treat them differently. Yes, it’s more expensive. Yes, it’s more work. Yes, it’s worth it.

      The irony of the situation is that mobile users are now treated as first class citizens while it’s clear that the desktop users are an afterthought. And then while having these priority in place — “Mobile first, Desktop last” (punt intended), ask yourself how likely is to design the look and feel of your site on an iPhone.

      Until this problem is acknowledged and addressed we will keep arguing whether a particular element is content or design, and whether it should be included in the Customizer or not.

      • Helen Hou-Sandi 8:55 pm on June 5, 2015 Permalink | Log in to Reply

        The customizer has been around since 3.4 but was only made usable on smaller screened devices in the last release (4.2). It was definitively not created “mobile-first”.

        • nickmg 9:56 pm on June 5, 2015 Permalink | Log in to Reply

          Yours is a rather selective definition. Tablets are mobile devices as well and version 3.4 was obviously designed to work on tablets. See https://make.wordpress.org/core/2012/05/03/wordpress-3-4-tablets-touch-ui/

          I don’t remember whether at the time the mantra “Mobile First” was formulated or not, but that’s not so important. What’s important is that from day one, the Customizer was designed with Mobile interface in mind. Again, nothing wrong with that. What’s wrong is to impose mobile friendly UI onto the desktop and when users complain about it to put the blame on the users. That’s what is wrong.

          It’s another matter that users when complaining about the Customizer UI are not able to articulate best the meat of the problem. But that’s the job of the Product Manager — to collect all the data and make the best interpretation out of it. Because when people complain in droves there is a good reason for it — they are not happy with what you are offering them. Nitpicking on what is a content and what is not is taking away the focus from the main issue.

          • Helen Hou-Sandi 3:31 am on June 6, 2015 Permalink | Log in to Reply

            I was an active contributor during 3.4. That tablet/touch team did not have much, if any, crossover with the customizer. In fact, that team existed exactly because we needed to retrofit touch capabilities into the admin – the opposite of mobile-first. In any case, I think we can agree that the particular details of that are not important – what is interesting is that your perception of things is that they are developed as “mobile first” when my experience has been the opposite, in particular with the customizer, which I personally spent many hours fixing on small screen iOS devices during 4.2 because it was not created with them in mind whatsoever. So to your specific point about the customizer being designed around iPhones – it categorically was not. We made no effort to cater to devices/windows under 600px wide until 3.8.

            I’m going to take a little time to think through how the perception of “mobile-first” comes about, though, because it is very interesting to me. I find the term to essentially be meaningless, since as we do very much agree, UX needs to be treated very differently between different contexts, which includes but is not limited to devices and their capabilities.

            • nickmg 4:39 am on June 6, 2015 Permalink

              First of all, Thank you for contributing to WordPress. I want you to know that your contribution is highly appreciated. WordPress is a great product which we all love and that’s why we are so passionate about it.

              Getting back to the discussion, I don’t want to shift it to details which are more of a semantic nature rather than substance. When I use the term “mobile first” I don’t mean to say that the first incarnation of the Customizer was done so it can work on smart phones. It could be just my perception as you imply, but from what I have seen, it is my belief that the first version of the Customizer was tablet friendly, which we all would hopefully agree is a mobile device.

              Anyway, the philosophy behind the “mobile first” trend implies that mobile devices as targeted devices are of higher priority, and than the Desktop. As such, more attention and effort is put on the mobile devices than on the Desktop.

              I am very optimistic and thankful that you will take the time to try to understand why the term “mobile first” is not meaningless to me. Because if you do so, you might be able to understand the problem at the very core, not as the symptom which this thread is about. Then you and the people involved would be empowered to make the right decisions and to change course accordingly.

              To me a first step towards resolution of this problem would be accepting the fact that the Customizer UX on the Desktop is not ideal and the navigation principles found in the Customizer are mostly used in the mobile devices.

              Please let me know what else I can do to help you understand better the origin of the “mobile first” perception in my thought process.

    • Kai 7:16 pm on June 5, 2015 Permalink | Log in to Reply

      I’ve tried the plugin on a site with ~ 50 menu items and, to be honest, it wasn’t better or worse than the current menu manager.
      I think it would really help the project if you manage to improve the shortcomings of the current menu manager, like ( ignoring the open issues this preview version obviously has) :

      • add a switch for a “minimized” item view (just title text, smaller font etc) while dragging/reordering long menus
      • allow for toggling sub-menus

      And in general: I wonder why the whole customizer wrapper isn’t wider on larger screens resp. resizeable (to a certain max-width )?

      • Nick Halsey 11:26 am on June 6, 2015 Permalink | Log in to Reply

        Thanks for the feedback. I generally feel about the same way in terms of handling larger menus – the experience is about the same, I’d say slightly better. I definitely think we’ll be able to improve that by doing things like the ability to collapse sub-menus in future releases.

        I recently started using a large-screen desktop setup (for non-wp things) for the first time and several years, and could see the benefits to going a bit wider than 300px on very large screens (larger than 1600px, would probably set a breakpoint around 1750px). However, while parts of the UI would scale up, it would still be one-column, and I don’t think the width should be user-configurable. I think we need more contributors and feedback from those that use these sizes of devices regularly to make a decision here. See https://core.trac.wordpress.org/ticket/32296.

        • Piet Bos 3:12 am on June 7, 2015 Permalink | Log in to Reply

          A screen wider than 1600px is definitely **not** a “very large screen”. Perhaps it is in your perception, but that is not a global definition of a very large screen.

          If we take for instance the iMac. The smallest iMac has a screen of 21.5″ (on my 2009 iMac that is a maximum screenwidth of “only” 1920px). Yeah, it’s a large screen, but not very large as it is the smallest in the iMac family. The other one is no less than 27″, which I would qualify as “very large”.

          As I suggested on the Trac ticket (https://core.trac.wordpress.org/ticket/32296#comment:14) I would suggest 1 breakpoint of 1280px. Below that use a width of 300px, above it use a width of 600px.

          • Nick Halsey 12:50 am on June 8, 2015 Permalink | Log in to Reply

            We absolutely would not make a jump in the size like that. We already have issues with the preview window being too small and triggering responsive layouts. I’ve never had problems with 300px on my 1600px laptop. On larger screens than that, I could see allowing proportionally more width but it wouldn’t make sense to have an arbitrary jump; it should grow slightly as screen size increases. Which would allow there to be different experiences more optimized to the exact device size, such as 21″ or 27″ as you mentioned (no idea how those compare in terms of pixels).

    • OdysseyForge 3:51 am on June 6, 2015 Permalink | Log in to Reply

      The customizer is pretty awesome and it’s a fantastic design tool.That’s what it should be limited to as implemented. There’s a reason that frontend designer / developer and backend designer / developer are often split across two to four individuals. They’re often very different. The customizer is the WRONG tool for managing menus. The frontend is the WRONG place to be editing anything that isn’t just styling as it exists. The menu customizer is a nice OPTIONAL way to deal with WP menus and it should NOT become the ONLY way.

      WP also has an awesome granular role / capability system. It allows backend access to be tailored to nearly any situation. The customizer is not particularly well suited to this task and is quite immature as compared to the Appearance -> Menus screen. Moving the menu screen to the frontend removes that flexibility and degrades the client experience at once. If Automattic is ok with sending us a check to cover the time lost to retraining and support for what is / will seem to the client as an unnecessarily large change, then that’s at least something. Since that’s not at all likely to happen, I pray you all come to your senses and finally dispense with this rash foolishness until you’re better able to execute on an idea like this. By WP v5 maybe but you’re nowhere near ready to pull such a large change like this off well.

      If the plan for the “removal” of the old menus admin screen moves forward as described here, We may have to make some hard choices regarding whether we continue to use WordPress for new projects. If you insist on dragging everyone kicking and screaming into the customizer then we may either choose to stop using any version past v4.2 or fork WordPress itself. Neither are great options but if you remove the choice to allow people to continue to use the dashboard instead of the Customizer for Menu management, could you really blame us?

    • carlhancock 3:04 pm on June 6, 2015 Permalink | Log in to Reply

      Who is in charge of leading the direction of the WordPress UI from a long term project standpoint? At one time I know that Jen Mylo played that role. Who is that person today? Is there one?

    • Ryan Boren 12:58 am on June 7, 2015 Permalink | Log in to Reply

      Use the beta tester plugin to put a site on the bleeding edge nightly track and install the Menu Customizer plugin as described here: https://wordpress.org/plugins/browse/beta/

      The Menu Customizer plugin is updated nightly, as we try to do with all feature plugins. The beta tester plugin will automatically update your site to the latest core nightly every night.

      That’s a pretty convenient way to follow 4.3 development. With that in place, create a captioned gallery visual record full of your feedback. Like this: https://make.wordpress.org/flow/2015/06/04/menu-customizer-iphone-6/

      We could really use visual records that compare flow through nav-menus.php with flow through the menu customizer. In fact, comparison vizrecs should be one of the feature plugin merge requirements:

      https://make.wordpress.org/core/handbook/how-the-release-cycle-works/features-as-plugins/

      Here are some example comparison vizrecs. These are very useful and valuable.

      https://make.wordpress.org/flow/tag/flow-comparison/

      I don’t say patches welcome. That’s way too high a bar for having an opinion. I will say visual records welcome. Everyone who commented on this thread is capable of applying their opinions to a set of screenshots and publishing them as a captioned gallery using the tool we all make. Pick a goal, such as adding a menu to the top of the front page containing Home, About, what have you. Start on the front page and show the flow. It sounds like those in this thread have insight into actual, real user flows. Document those in a vizrec using both nav-menus.php and the menu customizer. Compare the two flows for yourself and show your work in a captioned gallery visual record. Help us curate these flows and increase our awareness of what our users are really doing.

      And don’t just do this on desktop. Do this on mobile. Do this on every device you have. There is a lot of desktop bias and mobile blindness in our development community. We are WordPress. We will put the open web in pockets and make it capable and usable. We must be competent on phones.

      • Piet Bos 3:16 am on June 7, 2015 Permalink | Log in to Reply

        Just wondering why core dev seems to be so keen on making theme settings work on mobile is a necessity? Who in his/her right mind would want to do anything related to the Customizer on for example an iPhone???

        • Ryan Boren 4:18 am on June 7, 2015 Permalink | Log in to Reply

          Many people don’t have a laptop. I use mine mainly to test. I start, customize, and maintain most of my sites on an iPhone 6+. Not accommodating mobile is how 23% slides instead of rising to 51.

          And, we are an open source project dedicated to the open web, regardless of device. That is part of our philosophy and soul. We will not force our users into walled gardens.

    • nickmg 5:47 pm on June 7, 2015 Permalink | Log in to Reply

      Agreed that all devices have to be supported. Anyone who wants to use an iPhone to administer their site should be free to do so. In my opinion the majority of people who are not happy with the direction the Customizer is taking, don’t mind the fact the Customizer works on mobile devices. Also agreed that the backlash is coming from the ones who use the Admin predominantly on the Desktop, hence the “Desktop bias”

      It seems to me the main point we are trying to communicate (if I may speak for the part of the Community not happy with the direction the Customizer is taking) is not well understood. It could be that we are not describing well what the issue is or there is not a real will on behalf of the leadership team to listen and interpret what we are saying. Or it could be both.

      Because of that, I am going to make one more attempt to communicate what seems to me to be at the core of the problem and then ideally we can get to the root cause. The inclusion of the Menu Editor in the Customizer is just the tip of the iceberg. It’s the last grain of sand which triggers the avalanche of backlash. As such, it’s critical we treat it as a symptom, not the root cause.

      Below is a short list (far from being complete) of the main issues with the Customizer:

      1. Not everyone believes there is a need for the Customizer. The Admin “as is” is just fine.
      2. The ones who need the Customizer and want to use it are not happy with the user experience on the Desktop:

      • UI is slow
      • Not intuitive
      • Cumbersome
      • To accomplish something requires multiple navigational actions.
      • Available space is too little and feels overwhelmingly crowded.

      So when we say that the UI follows the trend “Mobile First” what we are trying to say is that the overall design and navigational principles used by the Customizer are better suited for mobile devices than the desktop. I think the use of this term is what is throwing off some of the core contributors. They seem to take the term too literally and get caught in the semantics instead of trying to interpret what we are trying to say.

      So while we are headed to expansion from 23 to 50, let’s not alienate the group who mostly do their work on the Desktop, because if this continues to be the trend, the math will work out the other way — from 23 to 10.

      How would we know that our voice is heard and understood?

      A first step would be to freeze all development effort of the Customizer and go back to the drawing board. Then summarize all use cases – from self hosted DIY makers, to Managed Hosting Solutions, to Enterprise Market. Then, and only then you will see that not everyone needs the Customizer. The ones who do will want first class experience, however, not something that feels like an afterthought, like a step child. Because if you listen carefully and filter out the noise, you then may be able to understand that the Desktop users feel like being left behind for the sake of Mobile users.

      • Ryan Boren 3:34 pm on June 8, 2015 Permalink | Log in to Reply

        > 1. Not everyone believes there is a need for the Customizer. The Admin “as is” is just fine.

        The customizer is about live previewing changes. There is emphatically a need for that.

        The customizer is also about pulling together the things that affect front end visuals. Pulling title and tagline out of settings is one of the most important things the customizer does.

        Aside: Toolbar > Customize is my first stop after setting up a new site, and I setup a lot of them, each with a different focus and flow. I set up sites on several major hosts. I have visual records for mobile and desktop that go from a host’s front page, through their onboarding, through extremely mobile unfriendly cpanel gesticulations, and on through changing the theme, title, and tagline with the customizer via Toolbar > Customize.

        > UI is slow

        Agreed. This needs to be improved. Widgets load in, in particular, feels slow. There is work in progress to speed things up.

        > Not intuitive
        > Cumbersome

        I think the navigation rework we’re testing in trunk improves this.

        > To accomplish something requires multiple navigational actions.

        More so than bouncing around the admin and juggling between admin and front end due to lack of live preview? This is why I want flow comparison visual records of real user flows. This is where contributors to this thread could really help.

        > Available space is too little and feels overwhelmingly crowded.

        Customizer is about live preview. Thus, the big preview area. The big preview area caters to desktops, not mobile. Sidebars are not at all mobile friendly.

        Overwhelmingly crowded is how many describe wp-admin. Aside: reducing crowding is something I’d really like to see feature plugins experiment with.

        I’d rather navigate the customizer than navigate the Appearance screens in wp-admin, and I created most of those screens.

        > So when we say that the UI follows the trend “Mobile First” what we are trying to say is that the overall design and navigational principles used by the Customizer are better suited for mobile devices than the desktop.

        As detailed elsewhere in this thread, the customizer was designed for the desktop. Until recently, it was not usable on mobile. The customizer doesn’t follow a mobile first trend, it follows a desktop biased “customizer with live preview” trend.

        > A first step would be to freeze all development effort of the Customizer and go back to the drawing board. Then summarize all use cases – from self hosted DIY makers, to Managed Hosting Solutions, to Enterprise Market. Then, and only then you will see that not everyone needs the Customizer. The ones who do will want first class experience, however, not something that feels like an afterthought, like a step child. Because if you listen carefully and filter out the noise, you then may be able to understand that the Desktop users feel like being left behind for the sake of Mobile users.

        I agree with summarizing all use cases. I want visual records for every use case brought up in this thread.

        Of course not everyone needs a customizer. I and many others do, however. I want live preview. I want the things I change most often to be in the customizer where I can see the result of my fiddling. That includes menus. Live preview of my menu changes will be powerful and beautiful.

        Desktop users shouldn’t be feeling left behind. They are still catered to almost exclusively, customizer included. We’re getting better on mobile, but we are still chock full of desktop bias.

    • Mel Choyce 12:04 am on June 8, 2015 Permalink | Log in to Reply

      Really excited to see this merged. This is a really fantastic feature that I, for one, am going to use a lot once it’s in core. It keeps even more of the site building process in the Customizer, making the initial site setup and build much easier and faster for users.

      I think it’s pretty clear that the tremendous work put into this feature will help improve the Customizer as a whole as it moves forward and is iterated upon.

    • Fabien Quatravaux 8:35 am on June 11, 2015 Permalink | Log in to Reply

      A lot of the negative feedback posted here is about the Customizer not being easy to use. I was really surprised, as my thoughts (and the feedbacks I have from my clients) are exactly the opposite : Customizer is easier to use than other admin pages. That’s because everything is right there : you do not have to look for the right admin page to modify this or that. And that’s because changes can be seen immediately : you know exactly want you are doing.

      In the next WordPress Meetup I will attend in my local area (Le Mans, France), the subject will be : how to setup and customize a new site. We are targeting small shops owners and new WordPress users and will use the Customizer heavily. I think the Customizer is a perfect tool for new WordPress users.

    • dinamiko 10:58 am on June 13, 2015 Permalink | Log in to Reply

      I tested the menu customizer plugin and I think that it maybe can be a cool feature in the future but right now in my opinion needs a lot of improvement.

      As for including it in 4.3, I think that although it will be a good and tested version in the future, maybe will be better that it continues as a plugin, there are a lot of users that not need these features and there are other users that love it, so for the users that love it, they can use it as a plugin.

  • Daniel Bachhuber 11:35 pm on June 1, 2015 Permalink |
    Tags: , ,   

    Shortcake (Shortcode UI) chat summary – June 1st, 2015 

    Present: @danielbachhuber, @matth_eu

    If you’d like to get involved, our documentation could really use some editing / additions. Feel free to open a GH issue with suggestions, or stop by #feature-shortcode in Slack.

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1433185206000006

    Next chat: same time and place

     
  • Ryan Boren 10:52 pm on May 8, 2015 Permalink |

    Version 4.3 

    4.3 was kicked off on April 28th by release lead @obenland and is currently scheduled for August 18th. Enabling users of touch and small-screen devices is the focus of 4.3. make/core is the development hub for WordPress. If you want to follow WordPress 4.3 development, that’s the first place to look. Posts relevant to 4.3 are tagged accordingly.

    If you want to dive deeper into 4.3, development is discussed at a weekly meeting in the #core Slack channel every Wednesday. The next meeting is Wednesday 20:00 UTC 2015.

    Feature Teams

    A good way to contribute to 4.3 is to help out a feature team. 4.3 has five feature teams.

    Editor

    Priorities:

    1. Improve the editor on mobile. (ticket#)
    2. Save and update without a page reload. (ticket#)
    3. cmd/ctrl+S should work in the text editor and when the visual editor is not focused. (ticket#)
    4. Full list.
    Admin UI

    Leads: @helen

    Slack Channel: #design

    Weekly Chat: Thursday 17:00 UTC 2015

    Weekly Updates | Component Page

    Priorities:

    1. Better responsive list tables.
    2. Getting rid of media-new.php.
    3. Screen-by-screen sweep for low-hanging fruit on small screens and touch devices (e.g. inconsistent spacing or font sizes at a given media query point).
    4. The state of the CSS roadmap.
    5. Full list.
    Multisite Admin UI

    Priorities:

    1. Piggyback on other Admin UI improvements. The network admin often seems quite a bit behind everything else. Responsive list tables would be fantastic.
    2. Start looking at network admin screens on mobile. There are many places where workflow can be reimagined.
    3. It may be possible to start working on what a future site switcher would look like. Especially on mobile, providing context can be tough when working on a network of many sites.
    4. #22383-core and #31240-core for nicer ways of creating and editing sites. Might lead to some domain/path validation, which could be useful elsewhere and help address older tickets.
    5. Under the hood, significant progress on WP_NetworkWP_Site, WP_Site_Query, and maybe WP_Network_Query would be nice.
    Customizer

    Leads: @westonruter

    Slack Channel: #core-customize

    Weekly Chat: changed to Mondays on Jun 1st Monday 23:30 UTC 2015

    Feature Plugins: Menus, Partial Refresh

    Weekly Updates | Component Page

    Priorities:

    1. UI/UX changes, which include the dependencies for Menu Customizer
    2. Menu Customizer (plugin, issues)

    Future:

    1. Customizer Concurrency (aka Control Locking)
    2. Partial Refresh — punted non-menus functionality from 4.3
    3. Theme Installation
    Passwords

    Leads: @mark

    Slack Channel: #core-passwords

    Weekly Chat: Monday 17:00 UTC 2015

    Weekly Updates | Component Page

    Priorities:

    1. Re-work password choosing/changing UI
    2. No manual or e-mailed passwords for creating other users
    3. Upon password reset, generate new password, and fill it in
    4. Password reset links should expire
    5. Users should be notified of password/e-mail changes
    6. Full list.

    Testing

    Use the beta tester plugin to put a site on the bleeding edge nightly track. This will set you up to receive nightly updates for core WordPress.

    That’s a pretty convenient way to follow 4.3 development. With that in place, test the customizer and create a captioned gallery visual record full of your feedback. Like this: https://make.wordpress.org/flow/2015/06/04/menu-customizer-iphone-6/

    Here are some example comparison vizrecs. These are very useful and valuable.

    Pick a goal, such as adding a menu to the top of the front page containing Home, About, what have you. Start on the front page and show the flow. If you have flows of interest to you or your clients, document those in a vizrec using both Appearance > Menus and the menu customizer. Compare the two flows and show your work in a captioned gallery visual record. Help us curate these flows and increase our awareness of what our users are really doing. And don’t just do this on desktop. Do this on mobile. Do this on every device you have.

     
  • Konstantin Obenland 7:45 pm on April 28, 2015 Permalink |
    Tags: , ,   

    WordPress 4.3 Kickoff 

    First I’d like to thank @drewapicture for his outstanding work in 4.2! I was particularly impressed with his ability to keep meetings on track and in time, I’ll work on making sure that won’t change going forward. :) A lot of the structure and artifacts he put in place have been proven quiet successful and I’d like to continue that, so you shouldn’t see too much change in that regard either.

    Release Date

    We’re aiming to release on Tuesday, August 18th. The 4.3 schedule is live and can be found here: https://make.wordpress.org/core/version-4-3-project-schedule/

    Deadlines are not arbitrary, and with your help I fully intend to get this version shipped comfortably on the 18th. Past releases have been quite good about releasing on time, let’s make that a signature trait of the WordPress project!

    Features

    WordPress 4.3 will be all about enabling users of touch and small-screen devices. @ryan has been testing flows on a myriad of different devices the past few releases and uncovered many things that desperately need attention.

    @joedolson has published a post over on make/accessibility about a11y priorities.

    If you see anything that sparks your interest feel free to leave a comment here and attend the kickoff meeting tomorrow, when we go through the list of things that were suggested. Specifically, Admin UI can will need a lot of hands. The meeting will also be a good time to suggest additional areas that you want to work on.

    Kickoff

    We’ll kick 4.3 off with a 2-hour meeting in #core at the usual time, April 29, 20:00 UTC.

     
    • sara cannon 7:55 pm on April 28, 2015 Permalink | Log in to Reply

      Excited for this release! I would love to help out with the Network Admin UI

    • Dave Navarro, Jr. 7:58 pm on April 28, 2015 Permalink | Log in to Reply

      Would like to see an update of the AUDIO shortcode as well to pull the title text from the audio file and display it.

      Really excited for the Shortcake stuff, hope it makes it.

    • Nick Halsey 9:51 pm on April 28, 2015 Permalink | Log in to Reply

      I have several ideas for continuing to work on themes in the Customizer building on 4.2. Would like to aim for adding theme install in 4.3, which would require a shiny install process, and shiny updates could work into that well too. I won’t be able to get started on that for a couple weeks, but should have a functional and tested proposal together well before the scheduled decision time.

      Along with the other mobile and touch improvements, I’d really like to see the much-needed Customizer UI design changes happen as well, hopefully we can pick back up with #31336 soon cc @folletto @designsimply.

      FYI, as is usually the case, I won’t be able to make most dev chats again this cycle.

    • aradams 10:07 pm on April 28, 2015 Permalink | Log in to Reply

      Hello All,

      I am not part of Make, just a WP user & designer. I have watched the unfurling of the New Editor saga over at WP.com and am concerned that there might be movement to implement that Editor to replace “Classic” editor for self-hosted WP. Could someone speak to that? I would be most grateful.

      • Konstantin Obenland 2:28 am on April 29, 2015 Permalink | Log in to Reply

        There are no plans that I’m aware of.

      • James Huff (MacManX) 5:27 am on April 29, 2015 Permalink | Log in to Reply

        You can use the new editor at WordPress.com for your self-hosted WordPress.org blog already if you have the Jetpack plugin installed and its Manage module active. Note that you’ll actually be using the new editor *on* WordPress.com, and can continue to use your WordPress.org blog’s Dashboard and “classic” editor as normal.

        Considering that WordPress.com and Jetpack are both products of Automattic Inc, and WordPress(.org) is not, I’m pretty sure there will be no deeper integration or replacement.

    • Pete Nelson 10:59 pm on April 28, 2015 Permalink | Log in to Reply

      Just a couple of patches waiting for that sweet, sweet commit: #31813 #31029

    • Stephen Edgar 11:49 pm on April 28, 2015 Permalink | Log in to Reply

      Admin UI – In #26311 I added a patch to make the “export admin screen” more responsive, I did this by replicating existing functionality from other admin screens, turns out these screens use tables, details of who, what and where tables are used in admin screens is also listed in that ticket.

    • mrjarbenne 3:50 am on April 29, 2015 Permalink | Log in to Reply

      It would be great to see this attended to: https://core.trac.wordpress.org/ticket/29606. Still can’t re-order gallery images on mobile (on iOS at least)

    • Max 7:37 am on April 29, 2015 Permalink | Log in to Reply

      I am not sure if that relates to Admin UI but #12706 is something which has been flowing around for a very long time without getting any closer to being fixed…

    • Ryan Boren 9:31 am on April 29, 2015 Permalink | Log in to Reply

      The touch bug I most want to see fixed is #29906. It is lingering desktop bias that fouls important toolbar flow.

    • leemon 12:45 pm on April 29, 2015 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list

    • Torsten Landsiedel 1:13 pm on April 29, 2015 Permalink | Log in to Reply

      It would be really great to fix https://core.trac.wordpress.org/ticket/28303 in 4.3. I know this is a problem just for a bunch of languages, but files being overwritten is always a big problem and people are complaining in our local forums.

    • Ryan Boren 7:47 pm on April 29, 2015 Permalink | Log in to Reply

      Perennial wish, retire media-new.php.

      https://make.wordpress.org/flow/2015/01/29/retiring-media-new-php/

      Seems like most of the work would be hooking the media addition ui from the grid view into the list view with some row insertion ajax. The list view would also need to become a full screen drop target like grid view.

    • pingram3541 8:07 pm on April 29, 2015 Permalink | Log in to Reply

      Would love to see the ability for nesting multiple shortcodes of the same name. Many themes and plugins could benefit, especially when building grids and nesting columns etc. The logic is fairly simple but there is no way to filter this currently.

      Another thing I’d love to see is the ability to define query “orderby” based on multiple meta_key, meta_values, currently you can pass an array to order by a single meta_value + any of the other orderby arguments but not 2 or more meta_keys.

    • Weston Ruter 9:59 pm on April 29, 2015 Permalink | Log in to Reply

      My proposals as I’ve also blogged:

      Customizer Partial Refresh
      This greatly improves performance of previewing changes in the Customizer for non-postMessage transport settings (JS-applied changes) by just refreshing the area of the page that has been changed. As such it eliminates some of the need to do postMessage in the first place, while also reducing the amount of duplicated logic that would have to be implemented in JS to mirror what is being done in PHP. This resurrects some code from the old Widget Customizer feature plugin developed for 3.9. Writeup and feature plugin are available.

      Customizer Transactions
      A low-level re-architecture of the Customizer plumbing that has a lot of side benefits and bugfixes, introducing some exciting possibilities for future feature plugins like scheduled settings, setting revisions, and drafted/pending settings. Partial Refresh is a dependency for this. Pull request available, but needs refresh. See proposal.

      Customizer Concurrency/Locking
      This is an important one for a client project I’m involved with, and so I’m having to prioritize it. I’m working on a client site that will have many users in the Customizer at a time, and given the way the Customizer is currently implemented (as with most areas of WP), there is no concurrency/locking support. So I’m working on adding locking at the control/setting level. See #31436.

    • RENAUT 11:31 pm on April 29, 2015 Permalink | Log in to Reply

      what about reviewing all the mails send by wordpress ?

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar