WordPress.org

Ready to get started?Download WordPress

Make WordPress UI

Tagged: mp6 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 3:17 pm on November 19, 2013 Permalink
    Tags: mp6   

    Targeting the new dashboard design in a post-MP6 world 

    There’s been a lot of chatter about how to handle the detection of the new dashboard design in a plugin in WordPress 3.8, now that the “mp6″ body class is gone. I have three suggestions, any of which can be used depending on the situation.

    The WordPress admin assigns a “branch-x-y” class to the body. So, branch-3-8, branch-3-9, etc. But rather than targeting 3.8 or newer this way (which will require you to add selectors for versions far into the future), target 3.7 or older. So if the latest version of your plugin supports 3.6 or later:

    .branch-3-6 .some-selector,
    .branch-3-7 .some-selector {
         /* some rules go here for 3.6 and 3.7 */
    }
    .some-selector {
         /* 3.8+ rules go here */
    }
    

    As your minimum requirements increase over time, the older rules can simply be removed. Pretty easy.

    The second method is for when you require greater UI robustness. (This is also good for instant compatibility with existing code written against MP6.) Simply add your own mp6 class to the admin. The admin_body_class filter is a little funky, so bear with me:

    add_filter( 'admin_body_class', 'nacin_please_prefix_this_add_mp6_class' );
    function nacin_please_prefix_this_add_mp6_class( $classes ) {
        if ( version_compare( $GLOBALS['wp_version'], '3.8-alpha', '>' ) ) {
            $classes = explode( " ", $classes );
            if ( ! in_array( 'mp6', $classes ) ) {
                $classes[] = 'mp6';
            }
            $classes = implode( " ", $classes );
        }
        return $classes;
    }
    

    An added benefit here is some nice standardization: If multiple plugins need this same class, it’ll simply be added once and be subject to shared usage.

    The final method is for if you need to know in PHP whether MP6 the plugin is enabled outside the body class. For that, simply use the version_compare() above.

    if ( version_compare( $GLOBALS['wp_version'], '3.8-alpha', '>' ) ) {
        // 3.8 dashboard theme
    }
    

    To those asking why we shouldn’t just include the class in 3.8: WordPress evolves over time, and even 3.8 has significant changes when compared to MP6 the plugin. While we do strive to maintain backwards compatibility — including, to some extent, when we merge in popular plugins — a line needs to be drawn somewhere. Short of introducing a “version” string of the UI (which would be redundant, given WP versions), there’s just no great way to solve this, especially when trying to be forwards compatible with future design changes (to 3.8 and beyond). It’s worth noting that the branch-x-y classes were introduced a few versions ago specifically for the purposes of managing UI changes in plugins.

    A side note, and this is purely a personal preference, I’d really like to *stop* calling the dashboard design “MP6″. I don’t just mean in code, I also mean in general nomenclature and bug reports. Code names are cute in software development, and it helps to have a shorthand. (We already have a lot of them — too many, even.) But we’ve reached the point where we are about to ship this to tens of millions of users. It’s time to drop it. In bug reports, let’s simply set the “version” field to “trunk” and file it under the Administration component. In general, let’s celebrate it as the new design and aesthetic that WordPress 3.8 brings/brought us. It’s no longer MP6. It’s now just WordPress.

     
    • John Blackbourn 4:21 pm on November 19, 2013 Permalink | Log in to Reply

      I’m not sure this addresses the main concern that was brought up (#25906), which is themes that have a fixed header and need to fix it at a certain number of px from the top in order to clear the admin toolbar.

      The height of the toolbar has changed in 3.8, so themes that want to retain backwards compat with pre-3.8 need a simple way of targeting pre-3.8 in CSS.

      Sergey’s added a patch to #25906 which adds the branch number to the front end body class. Is this likely to go in? If so, themes will be able to use that.

      • Andrew Nacin 4:59 pm on November 19, 2013 Permalink | Log in to Reply

        Great question. I have been thinking about this for a while.

        For starters, themes could use one of the techniques listed here by adding their own classes for 3.7 or earlier. Twenty Fourteen is already filtering the body classes, so it would be a few short lines of code. This likely affects very few themes anyway.

        It would be great if we can come up with a solution for Twenty Fourteen that negates the need to account for the toolbar. I hate that the situation even exists where a theme must know 28px versus 32px, and we should pursue multiple avenues to avoid it. A new class is possible (for the branch or something like .admin-bar-32). But, it’s not like this is a CSS-only situation; the JS is already being used to fix the header and could be used to look at the height of the toolbar.

        It would be interesting to see if the toolbar can be designed without those extra 4 pixels, even if just on the frontend. It actually looks quite good at that height. The extra pixels are most needed in the admin so it doesn’t feel cramped when compared to the rest of the admin.

    • Hassan 4:43 pm on November 19, 2013 Permalink | Log in to Reply

      The demise of the “MP6″… sniff :P

    • George Stephanis 4:57 pm on November 19, 2013 Permalink | Log in to Reply

      If doing the `version_compare()` check against a src checkout, it’ll actually not work, as version_compare returns `-1` when doing `version_compare( $wp_version, ’3.8-alpha’ )` — as $wp_version is `3.8-alpha-src` — which is calculated to be less than `3.8-alpha`

      So do `version_compare( $GLOBALS['wp_version'], ’3.8-alpha-src’, ‘>=’ )` instead and you should be good.

      • Andrew Nacin 5:00 pm on November 19, 2013 Permalink | Log in to Reply

        $wp_version is currently 3.8-alpha-26127-src, which is greater than 3.8-alpha. The check in the post is fine.

        • George Stephanis 5:04 pm on November 19, 2013 Permalink | Log in to Reply

          Ah, just needed an `svn up` locally. I was at the interim revision before r26127 where it was merged in, but the version was still 3.8-alpha-src without the revision.

    • Jason (Theme Blvd) 7:47 pm on November 20, 2013 Permalink | Log in to Reply

      Within the various admin color schemes, there are a lot of useful CSS classes we can use that are all prefixed with “mp6-” — i.e. mp6-primary, mp6-text-primary, mp6-highlight, mp6-text-highlight, etc.

      Will these end up being changed to something else?

    • Shea Bunge 9:36 am on November 21, 2013 Permalink | Log in to Reply

      How are we now supposed to specifically target all versions running new interface or the old interface in CSS?

    • Bryce Corkins 9:46 pm on November 21, 2013 Permalink | Log in to Reply

      Didn’t see anywhere to post general questions, so thought I’d ask here:
      I’m writing a new plugin framework and I’d like to support the new WordPress admin style / MP6 from launch as much as possible. Is there a guideline for how to style jquery-ui tabs within a single plugin’s settings page? I’m thinking either white page body with the “active” tab also white, or grey page body with the inactive tabs dimmed somehow.

    • Juanfra Aldasoro 3:50 pm on December 4, 2013 Permalink | Log in to Reply

      Is there a simple way/function to get the current admin color scheme programmatically speaking and not css? I’ve seen that I can find that within the $GLOBALS, but is not so handy.

      I’m asking this because I now have to call different icons for the menu, depending on the color scheme (the default style requires light icons, light style requires dark icons ).

      Thanks!

    • olyma 7:04 pm on December 5, 2013 Permalink | Log in to Reply

      Okay, this entry above seems to sort of maybe answer my question, but I could use a little more clarity. It sounds like from what people are saying here and there is that the admin interface is now quite skinnable. If this is true, that the interface is much more skinnable:

      1) Where are the skin files located in my wordpress installation?
      2) Is there a skin to change it to appear the 3.7.1 way or in any other way than what comes box-standard?
      3) Should we use the method above and where should we plop that code in order to change the skin?

      Many Thanks!

  • Matt (Thomas) Miklic 10:52 pm on November 8, 2013 Permalink
    Tags: mp6   

    MP6 2.2 

    We’re back with another Friday update to MP6. We’ve had a flurry of improvements and bugfixes as we come down the home stretch.

    • Open Sans is now included in MP6 instead of linking to Google Fonts. (background and discussion)
    • Responsive fixes to the color scheme picker.
    • Hide 3rd-party adminbar elements at responsive sizes to prevent the adminbar from overflowing its container.
    • Improvements to sizing and spacing of responsive adminbar icons.
    • Updated Dashicons with new glyphs.
    • Fixes to Press This.
    • Icon fonts are no longer blurry in Firefox 25/Mac thanks to -moz-osx-font-smoothing.
    • New :focus style for Screen Options and Help tabs.
    • Added @-ms-viewport so IE10/11′s “snapped” mode takes advantage of responsive sizes.
    • Added a fix for the Windows Phone 8 viewport size bug.
    • Manymanymore bugfixes. (see full log)

    This edition of MP6 includes contributions from Shaun Andrews, Joen Asmussen, Mel Choyce, Kelly Dwan, Ben Dunkle, Helen Hou-Sandí, Till Krüss, and myself.

    Several of the team will be meeting up in-person and via Skype tomorrow to work on readying MP6 for its merge into core. Since this may be the last regular update to MP6 the plugin, now’s a good time to thank all of you who helped test and provide feedback on MP6 along the way, to everyone who’s contributed designs or code to MP6, and to @matt for jumpstarting the effort. We’ve come quite a way since March, and we couldn’t have done it without the mountain of help we received. So, thank you!

     
    • Matt Thomas 11:05 pm on November 8, 2013 Permalink | Log in to Reply

      We’ll hold our regular office hours Monday, November 11, 2013 18:00 UTC to discuss the state of the merge.

    • shaunandrews 11:34 pm on November 8, 2013 Permalink | Log in to Reply

      Thank you, MT! You’re the best!

    • OriginalEXE 12:04 am on November 9, 2013 Permalink | Log in to Reply

      There seems to be a small bug that is not happening when the plugin is deactivated.

      I am not sure if it was introduced with this latest update because I haven’t done this prior to updating just now.

      When I click on any select inside WordPress dashboard, top (About WordPress) menu pops out. I can see in elements inspector that #wp-admin-bar-wp-logo get’s class ‘hover’.

      Issue does not happen:
      -if I deactivate the plugin
      -if I disable javascript
      -if I change the browser (tested in ff)

      What I tried:
      -incognito mode with no extensions loaded
      -triggering any even that came to my mind on select (none of them caused this issue)

      My Chrome version is Version 30.0.1599.114 and I’m running latest Kubuntu. WordPress is updated to the latest stable release.

      Screenshot of an issue: http://pbrd.co/1c6OJlv (note that select works normally, for some reason Ksnapshot does not capture it, but imagine it’s opened :) )

      Let me know if there is anything else I can do to test this.

    • portfola 1:07 am on November 9, 2013 Permalink | Log in to Reply

      MP6 looks really, really great. Thanks for this.

    • Nick Halsey 5:58 am on November 9, 2013 Permalink | Log in to Reply

      Wow, @-ms-viewport makes a big difference (not sure why they don’t just go with the meta tag…). I’m making a ticket and patch to get that into the default themes.

      That should get into the customizer too (I suppose we can start ticketing & patching directly after the merge).

      • Matt Thomas 7:25 pm on November 9, 2013 Permalink | Log in to Reply

        One caveat to keep in mind with @-ms-viewport is that setting width: device-width will cause Windows Phone 8 devices to report that value in hardware pixels instead of CSS pixels. So a Lumia 920, for example, will respond with a device with of 768px, pretty much disabling responsive styles for that device.

        There are two workarounds: set a fixed width of 320px for @-ms-viewport, which will work around the bug in Windows Phone 8, but negatively affects IE 10/11 on Windows 8 because its “snapped” view is no longer responsive, but stuck at a fixed width of 320px.

        The second workaround is to set width: device-width in your CSS, then add a bit of JavaScript recommended by Microsoft. This solves the bug in Windows Phone 8 while still letting IE10 take full advantage of your responsive styles when in Snapped mode. This is the approach we took with MP6.

        Good news is that this bug’s been fixed in Windows Phone 8 Update 3. Since it’s going to take a while for that update to roll out to devices, though, I’d recommend implementing one of these workarounds for now.

        There are excellent write-ups of the issue and the solution at http://timkadlec.com/2013/01/windows-phone-8-and-device-width/ and http://mattstow.com/responsive-design-in-ie10-on-windows-phone-8.html.

        • Nick Halsey 11:27 pm on November 9, 2013 Permalink | Log in to Reply

          Thanks for the info!

          I think the WP8 Update 3 has actually gone out to most devices at this point. Mine did a few weeks ago, and it’s an HTC, not Nokia, and the Lumias tend to get the updates first. We’ll probably be fine by December, since I think most users probably apply the updates. I think we’ll probably avoid the js in the bundled themes (the css just got committed, I’m bring it up though).

          With Windows 8.1 & IE11, it’s pretty critical that the snapped view is fully responsive since it can now be anywhere between 320px and roughly 1600px wide, so `width: device-width` is the best solution.

          For reference, the bundled themes ticket is #25888.

          • Matt Thomas 11:33 pm on November 9, 2013 Permalink | Log in to Reply

            My AT&T Lumia 920 hasn’t been so lucky just yet :) but it may well be that it’s out by the time of 3.8′s release.

    • Matt Thomas 12:42 am on November 10, 2013 Permalink | Log in to Reply

      I’ve tagged an update, 2.2.1, reverting back to Google Webfonts as the default source for Open Sans, while we investigate the best way to serve appropriate subsets for extended character sets. 2.2 was causing some missing characters in Czech and other languages.

    • John Blackbourn (johnbillion) 3:09 am on November 12, 2013 Permalink | Log in to Reply

      I have a list of bugs relating to MP6, some of which are new and some of which have gotten forgotten along the long journey of MP6 :)

      Are we ready to open individual tickets for MP6 issues on core Trac yet, or should we hold off, or?…

    • Shea Bunge 8:25 am on November 12, 2013 Permalink | Log in to Reply

      When using the the visual editor with media buttons disabled, like this:

      wp_editor( $content, $editor_id, array( 'media-buttons' => false );

      The whole space on top of the editor where the tabs are and the media buttons would usually be is a blank white bar:

      This happens for both the TeenyMCE and TinyMCE editors when media buttons are disabled.

    • Anderton 1:00 am on November 18, 2013 Permalink | Log in to Reply

      Good thing inlcuding the fonts. One (other) issue with serving fonts via Google is that Google is blocked in some countries. So good call!

      • Anderton 1:04 am on November 18, 2013 Permalink | Log in to Reply

        Posted without saying that i know that issue have been discussed earlier (like in the thread mentioned above).

  • Till Krüss 8:54 am on October 21, 2013 Permalink
    Tags: mp6   

    MP6 2.1.1 

    Holla!

    We just released this minor point release to have you look at a beautiful WP 3.7 update page, just in time for it’s release. Besides that, this release also includes:

    • Major overhaul of the widgets screen (again)
    • Better styling of un-approved comments
    • Improved highlight color for pointers
    • Several RTL fixes

    …and more. Have a look at the full changelog.

    MP6 2.1.1 includes contributions from Joen Asmussen, Kelly Dwan, Shaun Andrews and myself.

    As always, thanks to everyone who tested, suggested and reported. Keep the feedback coming!

    The next weekly IRC meeting in #wordpress-ui will be on Tuesday, October 22, 2013 02:00 UTC+8.

     
    • Rami Yushuvaev 1:34 pm on October 21, 2013 Permalink | Log in to Reply

      Good work with the RTL, i see all the issues solved. Now try the “RTL Tester” plugin with “mp6″ and witout “mp6″. The rtl-tester helps developers to see the site/admin in rtl view. but it seems like mp6 breaks with rtl-tester.

    • Trifon 6:43 pm on October 21, 2013 Permalink | Log in to Reply

      Nice work on the widgets overhaul! It really seems to set the widgetized areas in the spotlight.
      I only noticed one thing; scrolling through the widget list doesn’t work in Opera 12.16. Although I don’t know if that’s still supported…

    • Ulrich 7:13 pm on October 21, 2013 Permalink | Log in to Reply

      Hi, you want to do that same thing as 791083 but with “wp-admin-bar-top-secondary” also.
      http://plugins.trac.wordpress.org/changeset?reponame=&new=791093%40mp6&old=791083%40mp6

    • Justin Tadlock 1:44 am on October 22, 2013 Permalink | Log in to Reply

      This update has broken widget controls that are wider than the size of the sidebar. WordPress allows developers to define a width of the widget control options. I believe the standard width is 200, but we need to make sure to allow the widget controls to expand outside of the sidebar if larger than that.

      Here’s a quick screenshot of the issue:
      http://justintadlock.com/blog/wp-content/uploads/2013/10/mp6-2.1.1-widgets.png

      • Justin Tadlock 2:02 am on October 22, 2013 Permalink | Log in to Reply

        I dug into the CSS a bit and found the line of code overwriting widget control widths. It’s line 171 of /mp6/components/widgets/style.css. In particular, the !important set on the width: auto. It also needs a little z-index love to make sure really wide widget controls aren’t hidden by the list of sidebars.

        Here are my changes for that bit of code:

        div.widget-liquid-right div#widgets-right .widget {
        	z-index: 999;                    /* New code. */
        	margin: 0 auto !important;
        	width: auto;                    /* Altered code. */
        	min-width: 50%;
        	box-shadow: none;
        	border-bottom: none;
        	-webkit-box-sizing: border-box;
        	-moz-box-sizing: border-box;
        	box-sizing: border-box;
        }
      • shaunandrews 7:46 pm on October 22, 2013 Permalink | Log in to Reply

        This update has broken widget controls that are wider than the size of the sidebar.

        “Broken” isn’t the word I would have used. This was an intentional decision made by me. The ability for widgets to “break out” of the sidebar containers has always struck me as very strange. Its a weird experience all around.

        This latest update to the widgets.php design gives sidebars a fluid width. At window sizes above 900px, sidebars are split into two columns taking up a combined 55% of the screen. At smaller sizes, sidebars are shown in a single column.

        Sidebars are no longer restricted to a fixed width — this means your widgets should no longer expect to be contained inside a fixed width container.

        …we need to make sure to allow the widget controls to expand outside of the sidebar…

        I don’t think we do. Widgets should respect their containers and adjust their layouts as needed. Widget/Plugin authors can provide responsive styles to make sure their widget’s content displays properly.

        • Justin Tadlock 4:27 am on October 24, 2013 Permalink | Log in to Reply

          “Broken” isn’t the word I would have used. This was an intentional decision made by me. The ability for widgets to “break out” of the sidebar containers has always struck me as very strange. Its a weird experience all around.

          This is literally an option in the core WP widgets code. This plugin doesn’t respect that option. I consider that broken, but the word itself is largely irrelevant to this discussion.

          For many of us, we’ve relied on this for years now and don’t see it as strange. Currently, I’m fielding support tickets for users of this plugin who can no longer use their widgets. I’m having to tell them to roll back a version or alter the plugin code, which doesn’t really help anyone.

          I’ve provided the above code to you as a patch and hope you implement it or find another fix.

          If this is an option you’d like to see removed from WordPress core, you should open a Trac ticket first and get it implemented into core. This way, developers will have a version or so to make the changes they need. Then, this plugin can make those types of design decisions.

          I don’t think we do. Widgets should respect their containers and adjust their layouts as needed. Widget/Plugin authors can provide responsive styles to make sure their widget’s content displays properly.

          Responsive styles are not the issue at hand. I’m fine with adding responsive styles to my plugin/theme widget controls. I’m referring to not having the ability to create widget controls that are wider than the sidebar, which is not the same thing.

          This is also made much harder to style by !important used in the CSS.

        • Justin Tadlock 4:54 am on October 24, 2013 Permalink | Log in to Reply

          If nothing else, can you please remove the !important on the width so those of us who want to change this behavior can do so?

    • boldfish 12:46 pm on October 28, 2013 Permalink | Log in to Reply

      Can anyone tell me why MP6 makes the fonts go fuzzy in Safari?

      Chrome has nice rounded smooth fonts, but something in MP6 is switching the rendering in Safari from smooth to spindly – I can see it happen on first page load.

    • mrwweb 6:33 pm on October 28, 2013 Permalink | Log in to Reply

      This is an issue in the existing admin bar and the MP6 admin bar, but it seems like MP6 may be the best place to fix it. When there are a lot of items in the admin bar (such as when you have a lot of debug bar extensions), there can be widths where the items overflow the admin bar.

      Screenshot: https://dl.dropboxusercontent.com/u/9941629/adminbaroverflow.PNG

      It would be great if the admin bar could handle this probably-not-that-unlikely edge case by adding height to encompass the additional items.

      • justinngc 3:57 am on November 4, 2013 Permalink | Log in to Reply

        Using WPMU Dev’s Branding plugin. Custom admin bar links went gone when viewing in responsive mode.

    • Zack Tollman 6:45 pm on October 31, 2013 Permalink | Log in to Reply

      I found a bug in version 2.1.1 of MP6 and it is still present in trunk.

      I get two errors with MP6 in IE10 when “swiping” left or right. A “swipe” occurs when you click and drag the mouse. The errors are:

      SCRIPT5007: Unable to get property ‘removeClass’ of undefined or null reference
      moby6.js, line 46 character 5

      SCRIPT5007: Unable to get property ‘addClass’ of undefined or null reference
      moby6.js, line 44 character 5

      To reproduce:

      1. Open any admin screen in IE10 with MP6 installed
      2. Locate a piece of screen real estate that is relatively blank (easier for testing)
      3. Perform a left or right swipe. Sometimes you need to repeat it multiple times to produce the error

      I could not reproduce this issue in Chrome, Safari, or Firefox. It may have to do with differences in response to the swipe event.

      The problem is that within the callbacks for the swipe functions, the `this` reference is incorrect.

      My patch is here: https://gist.github.com/tollmanz/7254803

    • Christian Foellmann 11:29 am on November 1, 2013 Permalink | Log in to Reply

      Hi guys,

      I am not sure where to ask this but I think this is a place where it will be seen by the right people.

      The “icon32″ gone in MP6. Will it stay this way?

      I am not pro or con but if it is scraped from core I will not bother adding icon32s into my plugins anymore.

    • geertvanderheide 2:26 pm on November 2, 2013 Permalink | Log in to Reply

      The new design looks awesome Matt! Good luck getting it finished up and into WP 3.8.

      One question: Where / how do I choose a color scheme? I understand there’s several, but I can’t find the setting to change it. Thanks!

    • Justin Tadlock 4:50 pm on November 6, 2013 Permalink | Log in to Reply

      <select multiple="multiple"> needs a little style love. I noticed this in the theme customizer, so I’m not sure how they’re being treated in other areas of the admin. Right now, they’re squished down to a single option.

  • Joen Asmussen 7:00 pm on October 11, 2013 Permalink
    Tags: mp6   

    MP6 2.1 

    Been a while since last tagged release, but it’s not been quiet on the MP6 dev front. Major new items aside from a plethora of bugfixes include:

    • A bunch of new dashicons
    • A spiffy new widgets page by Shaun Andrews from his Widgets project
    • Improvements to customizer, color schemes, menus section and much more
    • New color scheme, Midnight!

    You can also peruse the full changelog, and of course get the plugin at the MP6 plugin page.

    MP6 2.1 includes contributions from Till Krüss, Mel Choyce, Ben Dunkle, Kelly Dwan, Shaun Andrews, Payton Swick, Matt Thomas, Helen Hou-Sandi, Dave Whitley, Kate Whitley, and myself.

    Big thanks to the contributors, bug reporters, testers, moral supporters and givers of ideas and suggestions! Keep it coming.

    The next weekly open meeting in #wordpress-ui will be Monday, October 14 at 18:00 UTC.

     
    • toscho 10:41 pm on October 11, 2013 Permalink | Log in to Reply

      When will the automatic update be rolled out? Reinstalling this plugin manually each time is not very convenient.

      • Ipstenu (Mika Epstein) 11:27 pm on October 11, 2013 Permalink | Log in to Reply

        Huh? WP 3.7 auto updates itself, not plugins. And this plugin can be normal upgraded. Worked fine on 3.6 and 3.7 beta

        • toscho 7:04 am on October 12, 2013 Permalink | Log in to Reply

          Sorry for the confusion. What I meant: I never get an update indicator for MP6. Works fine for all other plugins, but not for MP6. I always have to delete and to reinstall it.

          • Justin Tadlock 1:18 am on October 17, 2013 Permalink | Log in to Reply

            It was like that for a long time for me too. Then, one day it just started working. I have no idea why.

            • toscho 6:17 am on October 17, 2013 Permalink

              Yesterday I got finally my first update notice for this plugin. Looks like it is fixed now. I just would like to know why it didn’t before.

            • Till Krüss 7:44 am on October 17, 2013 Permalink

              Automatic updates are working since a couple of MP6 releases, 1.4 if I remember correctly, but you only see them if you WordPress version matches the version requirement of MP6′s readme.txt file.

      • Till Krüss 1:22 am on October 12, 2013 Permalink | Log in to Reply

        You can update to MP6 2.1 through your WordPress admin, no need to reinstall anymore. If you are referring to automatic background updates, you can enable them for MP6 using the `auto_upgrade_plugin` filter.

    • addressee 5:38 pm on October 12, 2013 Permalink | Log in to Reply

      re: MP6 2.1 Appearance > Widgets

      Liking the new icons and styling/behavior for this section of admin. It’s nice to see but seems perhaps a little incomplete

      Overall, the Widgets page no longer has a description, leaving a user to guess what the Widgets page does.

      The widgets location section (“widget-liquid-right”) could be improved with a hinting of the status of a widget location: If populated, indicate with a visible icon or shading. If empty, present the collapsed location as-is with no icon visible. The side-by-side presentation of widget locations unfortunately hinders presentation of the natural top-down precedence of the widget areas. The same hinting could also be used for the Inactive Widgets section.

      Available Widgets no longer has a description, leaving a user to guess what the widget does, or a new widget to be left unexplained. A description could be hinted on hover or on mousedown (preferred) or selected optionally.

      Available widgets are placed in a scrolling list, which is located inside a scrolling window. This is the styling that long-plagued the post-editor page, only to be ‘fixed’ with a full-screen editor option. Please don’t let the widgets page suffer the scroll-within-a-scroll problem. Also, if Inactive Widgets is collapsed, you’re left with a scrolling window above a large expanse of blank page.

      The evolution of MP6 is interesting to follow.

    • Ulrich 1:32 pm on October 15, 2013 Permalink | Log in to Reply

      There is a slight issue with the admin bar on smaller screens. Some plugins and themes add links to the admin bar and as these links break the layout on smaller devices. RTL tester is a plugin that adds a link if anyone want to test it. http://wordpress.org/plugins/rtl-tester/

      • Joen Asmussen 7:27 pm on October 15, 2013 Permalink | Log in to Reply

        Excellent point. I’ll take a look at that this week.

      • Joen Asmussen 8:25 am on October 21, 2013 Permalink | Log in to Reply

        Pushed a change to hide *all* third party toolbar items in responsive view.

        • toscho 8:29 am on October 21, 2013 Permalink | Log in to Reply

          That’s dangerous. Some necessary debug tools would be inaccessible now: language switcher, screen info, error lists.

          • Joen Asmussen 8:36 am on October 21, 2013 Permalink | Log in to Reply

            On smartphones, all 3rd party toolbar items are invisible, so they can’t break the toolbar as they have done so far. If you need to see the items for development or debugging purposes there’s an argument to be made that you’re working on a desktop anyway. You can expand the window to make the items available, click the items you need, then size the window small again.

            Could certainly be worth exploring putting all 3rd party items in an “overflow menu”. But for now, I believe this is a decent fix.

    • Looimaster 8:27 am on October 16, 2013 Permalink | Log in to Reply

      Just my two cents: customizer that changes its colors makes it difficult to be used with color pickers or jQuery UI sliders and other custom sections. Do theme authors need to style it for each customizer skin? In my opinion Customizer should have plain white background at all times.

    • Justin Tadlock 1:27 am on October 17, 2013 Permalink | Log in to Reply

      Nice work. I’m loving the new Midnight theme and have switched all my sites to it.

      The widgets screen is awesome too. I’m not sure I’m sold on the scrollbar for the “widgets” section of that screen though.

      The customizer design is a nice touch. I did find one minor issue with the image uploader on the customizer. With three tabs (Upload New, Uploaded, and Default), the third tab drops down. It’d be nice if we could get at least that third one in line with the others. Check out the screenshot:
      http://justintadlock.com/blog/wp-content/uploads/2013/10/mp6-three-image-tabs.png

    • Amado.Miami 4:31 pm on October 17, 2013 Permalink | Log in to Reply

      Definitely missing the widget descriptions. Finding myself going back to non MP6 widget screens to get the description. It looks nice, yet for me personally the widget descriptions are very important.

    • Paal Joachim Romdahl 9:05 pm on October 18, 2013 Permalink | Log in to Reply

      What about right below the drop down select color scheme have 4 hexcode boxes for the user to add custom hexcode for the most used color areas?

    • mrwweb 10:33 pm on October 18, 2013 Permalink | Log in to Reply

      I think it’s been this way for a while, but I’m suddenly really struck by the lack of visible arrow indicators on metaboxes/widgets etc. They appear on hover, but for something like a collapsed sidebar on Appearance > Widgets, there is no visual indication that a sidebar is toggled closed or toggled open.

      I think making these indicators persistently visible would be a fairly minimal and easy change with a big win. Items that can collapse/expand would suddenly be much clearer for everyone new to the interface. Also, no hover on touch, so that.

      • Joen Asmussen 7:43 am on October 21, 2013 Permalink | Log in to Reply

        I’ve pushed a change to this. Collapse arrow indicators are now always visible on the widgets page (though semitransparent until hovered). For now this change is on the widgets page only, let’s discuss whether it’s necessary also on the dashboard.

    • Ulrich 7:01 am on October 19, 2013 Permalink | Log in to Reply

      There is some layout issues on the new 3.7 about page. /wp-admin/about.php

      Here it how it looks normally-
      https://www.diigo.com/item/image/4dblo/a7wj

      And here with mp6
      https://www.diigo.com/item/image/4dblo/876j

    • Paal Joachim Romdahl 12:57 pm on October 19, 2013 Permalink | Log in to Reply

      MP6 and contrast between boxes and the background. Looking through various screen the boxes blend too much into the background. Having just a pinch of darker border contrast will help to separate the two.

      In regards to the widget screen. A large layout causes there to be two columns for both widget areas. Taking it one step smaller we suddenly have a large left widgets area and a smaller right area. It would be nice to wait with taking the one step smaller until the screen size is even smaller then what is seen today. I created a post about this: http://easywebdesigntutorials.com/wordpress/mp6-and-the-widgets-screen/

      When looking at my contrast screen one can obviously see the difference between a little darker border around the boxes then what mp6 uses today. Perhaps someplace between what I am showing and the existing mp6 css will help create a better contrast of boxes and background.

  • Mel Choyce 5:22 pm on October 1, 2013 Permalink
    Tags: , mp6   

    MP6 Color Schemes 

    Hi there, WordPress community.

    The MP6 team has been working on adding color schemes in the past couple weeks. Now, we’d like to get your input about which color schemes you want to see make it into the core plugin. Please check out the schemes and let us know which color schemes you would use:

    Which of these MP6 color schemes would you use?

    We’re also taking suggestions for color scheme names.

     
    • Terry Sutton 5:24 pm on October 1, 2013 Permalink | Log in to Reply

      Ectoplasm for life!

    • Valerio Souza 5:37 pm on October 1, 2013 Permalink | Log in to Reply

      I would love it if it had an option to force all users to have a pre-defined layout.

    • esmi 7:07 pm on October 1, 2013 Permalink | Log in to Reply

      All of the suggested color schemes re very pretty but what would be really cool would be to have at least 1 user-selectable high contrast scheme for visually impaired users. Yellow on black would be one possible option. Ditto a very low contrast scheme for some dyslexics. I’d be more than happy to wok on this with someone.

      • Helen Hou-Sandi 7:19 pm on October 1, 2013 Permalink | Log in to Reply

        Have you taken a look at the default and light themes? Note that this poll is regarding *extra* schemes.

      • Trifon 8:47 am on October 3, 2013 Permalink | Log in to Reply

        The readability of the default is really good for me (being dyslexic myself). You should take a look at it, for I think that it works great for your purposes.

      • Mel Choyce 8:58 am on October 3, 2013 Permalink | Log in to Reply

        Let me know if either of the default schemes (light or dark) works — if not, I’d love to chat some time in the next week about making a high and/or low contrast scheme. At the very least, we could create a plugin pack of accessibility-focused color schemes.

        That reminds me — it would also be great to make a plugin that replaces Open Sans with OpenDyslexic (which would be super easy if we were using a pre-processor for more than just color schemes!).

        • Joe Dolson 11:17 pm on October 4, 2013 Permalink | Log in to Reply

          I looked into the OpenDyslexic question, but unfortunately it’s not under a GPL compatible license (CCA 3.0 Unported). I couldn’t find any other Dyslexia-focused fonts that were under GPL licenses, so doesn’t seem to be an option.

          • Mel Choyce 11:19 pm on October 4, 2013 Permalink | Log in to Reply

            Oh no! For some reason I thought it was MIT. Bummer.

            • Joe Dolson 12:12 am on October 5, 2013 Permalink

              Yeah, I thought so too — I knew they’d been wanting to get it into Google Fonts, so I’d assumed it was something GPL compatible…but no.

    • Native Imaging 8:00 pm on October 1, 2013 Permalink | Log in to Reply

      I thin Color schemes are a bit of waste of efforts. Why not just create a panel to define your own color schemes, and let users import and export them.

      What I am hoping to see are the bug fixes and hard CSS resets for the Admin.

      I know it must be hard or nearly impossible to hard reset all of the CSS HTML and scripts running inside of 3rd party plugin developers. but what I see, is a Union of Compliance that needs to be set and sponsored by the best-of-the-best plugin developers. There needs to be some form of speed-optimization and responsive-touch standards implemented into all plugins, or else, get chucked-from-the-movement. The utmost complaint I have from 90% of clients is that their windows OS’s are not working , and they can’t even get online due to Anti-Virus softwares. #2, they are completely flabbergasted when trying to understand the wordpress backend, even when all they see is Posts, Pages, and Profile as an Author. WordPress has an awesome core that can be configured in anyway, but I’m watching the innovative progress of the MP6 plugin slowing down.

      Certain things that are unfixed problems i’ve personally noticed (yet I still use MP6 on every single website I maintain)
      • unchecked boxes are horizontally collapsed.
      • viewing admin bar horizontally on mobile devices is broken.
      • Media Uploader does not work at all for mobile touch ready devices. Should load in a full screen container with BIG BUTTONS creating galleries and/or images.
      • Drag and drop does not seem to utilize the predefined styles for Android & iOS.
      • No one uses their computers anymore, and sadly said that the WordPress App does not work at all for 90% of the devices I’ve test it on.
      • The MP6 is a good start, but it’s still labeled as a secret. WE NEED Responsive and Speed Optimized Compliance with all large plugin authors. I hope to see a network created soon to encourage this type of flexible development for all successful developers.
      • Users are On-the-go and this should be taken into consideration for all developed plugins. (Hence some sort of compliance needs to be encouraged. )

      Other than that, other bugs are small, and I hope that the MP6 does see its way into the WP, core and probably should’ve been a while back. Social Media continues to dominate the average/Non-Savvy computer user. Today, only 10% of clients use computers, and less than 2% of visitors come from desktop computers. The numbers are staggering and falling each day.

      Sorry if i’m posting in the wrong thread, but just wanted to share my opinions about the MP6 development and where its getting of track and falling behind…

      • Hassan 9:02 am on October 3, 2013 Permalink | Log in to Reply

        Good points here.

        While I agree that desktop traffic is slowly declining, I believe your statements “No one uses their computers anymore” and “only 10% of clients use computers” are a bit incorrect. I maintain a couple of sites where the vast majority of users come from their desktop PCs. Mobile might be on the rise, but it is still site-specific. Some sites -by their nature- attract more mobile visitors, while others do the opposite. So, yeah, it’s subjective.

        That said, I do not see desktops going anywhere anytime soon. They still have looong life left :)

    • hakaner 11:16 pm on October 2, 2013 Permalink | Log in to Reply

      I prefer an option to create your own.

    • Hassan 10:06 am on October 3, 2013 Permalink | Log in to Reply

      MP6 dark, light, and midnight schemes are the one’s I’d probably use. Not particularly fond with the other ones; they look kind of “out of sync” to me, though I’m not really sure what that means :)

      The idea of users having the ability to create their own custom schemes sounds interesting indeed! Perhaps something like a color picker..

    • Terence 2:51 pm on October 10, 2013 Permalink | Log in to Reply

      Sorry, not a bug or a fix, just a want ~ I would really like to know if anyone is working on a plugin or extension/s to MP6 which would allow me to run a webstore (Woo Commerce) in the back-end, like WordPress.com does. Either that or I am going to have to break my promise and go learn how to code it. Now you wouldn’t want that on your conscience would you? Well WOULD YOU?… 8^)

      • Mel Choyce 2:54 pm on October 10, 2013 Permalink | Log in to Reply

        Hi Terence, MP6 is just a visual update to wp-admin. There are plenty of e-commerce plugins for WordPress.org you can use. If you google “best wordpress ecommerce plugins” you should be able to find some helpful information.

  • Till Krüss 3:02 am on August 31, 2013 Permalink
    Tags: , mp6, svn   

    MP6 2.0 

    Heya! It’s been again over a month since the last MP6 release and this version comes with some new goodness.

    General

    As usual, we made some UI improvements and fixed a few bugs. Shadows are now fewer and consistent, buttons are flatter, font sizes are more consistent, metaboxes are simpler and lighter and a couple of other improvements. You can see the full changelog here →

    Icons

    We decided on recommendations for custom icons in plugins/themes, you can read more about this and have a look at some examples are in this GitHub repository. Be default MP6 does now hide all images in admin menu item and replaces them with a generic default icon.

    Method C, using a SVG as CSS background image, works thanks to the new JavaScript SVG painter, which re-colors base64 encoded SVGs on the fly. It might not catch all SVG color markup right away, if that’s the case, please post a link your SVG file in the comments.

    Color Schemes

    We bundled this release with 4 additional admin color schemes. You can choose them under “Your Profile”. There are probably more color schemes to come.

    MP6 color schemes as made with SASS, because LESS didn’t handle default variable values. A color scheme can be as simple as this, or it could define a few extra colors for better readability. If you’re making your own color scheme, make sure you include MP6′s core color scheme file.

    Another Note

    If you want to check if MP6 is activated, use the MP6 PHP constant. In CSS use mp6 body class, not admin-color-mp6, I’m looking at you Jetpack.

    MP6 2.0 includes contributions from Joen Asmussen, Mel Choyce, Ben Dunkle, Kelly Dwan and myself.

    And as always, thanks to those of you who tested, reported bugs and contributed ideas and suggestions! Keep them coming!

    The next weekly open meeting in #wordpress-ui will be Monday, September 2 at 18:00 UTC.

     
  • Helen Hou-Sandi 7:51 pm on August 19, 2013 Permalink
    Tags: , mp6   

    I will be interim-leading MP6 in a mostly-project management capacity while @iammattthomas is on sabbatical. We’ll resume weekly open meetings in #wordpress-ui next week, Monday, August 26 at 18:00 UTC.

     
  • Till Krüss 11:21 am on July 30, 2013 Permalink
    Tags: mp6   

    Heya! It’s been over a month since the release of MP6 1.8 and we’ve been busy making MP6 better and better. We had 98 commits since version 1.8, containing so many changes, it’s too much to list each one of them, but here’s a summary:

    • 3.6 Compatibility
    • TinyMCE Advanced Compatibility
    • Added color schemes component, including a blue theme.
    • Improved font sizes, margins, paddings, hover states, animations and shadows across the entire admin UI.
    • Improved responsiveness, especially of the admin-bar and editor.
    • MP6-ified TinyMCE modals.
    • Overall RTL improvements.

    The experimental color schemes component is by default disabled. If you’d like to help us test the blue color scheme, define define( 'MP6_COLOR_SCHEME', 'blue' ); in your wp-config.php and enable the component by un-commenting line 24 in plugins/mp6/mp6.php… or make your own color scheme and post it below!

    MP6 1.9 includes contributions from Joen Asmussen, Ben Dunkle, Kelly Dwan and myself.

    Thanks to everyone who’s reported bugs and contributed ideas and suggestions, it helps us a lot! Keep them coming…

     
    • Ayman 11:46 am on July 30, 2013 Permalink | Log in to Reply

      It’s nice to see that the Idea of having another color schema is being applied (Even if it’s disabled by default)

    • tomdryan 12:09 pm on July 30, 2013 Permalink | Log in to Reply

      Thanks for all your work Till! Where is the best place to provide ideas and suggestions for MP6? I have a few small tweaks in mind that would improve WP usability immensely.

      • Mel Choyce 2:27 pm on July 30, 2013 Permalink | Log in to Reply

        Feel free to post them here. :)

        • tomdryan 3:50 pm on July 30, 2013 Permalink | Log in to Reply

          Okay, here you go:

          WordPress MP6 1.9 UI Proposal
          1. Add “pin” option to make the left dashboard menu persistent when browsing site content, just as it is with the admin bar. Clicking the “W” in the admin bar could toggle the dashboard menu on/off instead of loading the About page.

          2. Move the About page from the “W” to the Welcome menu section and add as much technical information as possible to the About section, like disk space used by site, available space, Perl version, memory usage, current site health, etc. (where possible)

          3. Make the dashboard menu “collapse/expand” sticky (no auto collapse) and/or add a manual “pin” option

          4. Single window use case: Currently, WP is a bit clunky to use for those without dual monitors or working on laptops. To fix this, add a button in the Admin bar to that toggles between the current WordPress admn page and the last site page viewed (with auto reload). This would really speed interactive editing! This would be similar to the way the View Page/Edit Page toggle works, but be more universal when working on other parts of a site.

          5. Populate dashboard menus such as Posts, Pages, User, Themes, etc. with submenus which include recently used items for quicker access

          6. Have an option to preview the destination page when you hover over a dashboard menu choice, a click makes it active. This eliminates the back and forth clicking that many new users must do to find the right option.

          7. Extra credit. Add an easy way to list all the sites the logged in user administers in the admin bar and enable them to switch between them with a click. Perhaps this could be in the “Visit Site” section.

          • Native Imaging 4:35 pm on July 30, 2013 Permalink | Log in to Reply

            what?

          • Ipstenu (Mika E.) 5:48 pm on July 30, 2013 Permalink | Log in to Reply

            Tom, MP6 is skinning the admin, not massively changing the fundamental functionality of the dashboard. #2 is out of scope, as that would require a total re-do of the page in core :) #4 and #7 also are beyond MP6.

            • tomdryan 7:44 pm on July 30, 2013 Permalink

              Fair enough on 2, 4, 7. (although I think #4 might be able to be hacked fairly easily from the existing edit/view page code). Where does that leave us on 1, 3, 5, and 6 then? :)

          • Mel Choyce 8:23 pm on July 30, 2013 Permalink | Log in to Reply

            1: We were actually talking about implementing something similar as a later iteration. Matt Thomas mocked up some great ideas a little while back, which we’ll hopefully get to explore during the 3.8 release cycle.

            2: Out of scope, but maybe worth making a feature request for it on trac.wordpress.org. Would also be a great plugin.

            3: Can you elaborate on this a bit? I’m not sure I totally understand.

            4 + 5: Out of scope — seems like that would take some pretty intense back-end dev work to implement, and we’re pretty much limited to css and js with mp6.

            6: Worth exploring during 3.8

            7: Also out of scope

            Thanks for your suggestions. :) If you think or more, keep posting them in this (or subsequent) mp6 threads.

            • tomdryan 8:50 pm on July 30, 2013 Permalink

              You’re welcome! As a relatively new user to WordPress, its usability quirks are fresh in my mind and several of these changes would make a huge difference in usability and interface consistency.

              What is the best way to get the “out of scope” and “worth exploring: suggestions into formal consideration and to review/provide input as those features are developed? Is that trac?

              Clarification on #3: Currently in MP6, if you expand the dashboard menu on the left hand side so that it shows both icons and text labels, once you make a menu selection, it automatically collapses back to display icons only. It would be nice if it did always not revert back to icons, but kept your setting, either icons or icons+labels. If a user decides they don’t want to see the text labels, they can collapse it manually.j

              Let me know if that makes more sense…

            • Mel Choyce 9:11 pm on July 30, 2013 Permalink

              Sorry @tomdryan, can’t indent another level so I have to reply to my own comment.

              I’m unsure if adding ideas to trac would be best, or if you should wait a few weeks for development of 3.7 and 3.8 to get more underway and bring it up after a #wordpress-dev meeting on IRC. Hopefully someone else will chime in with their thoughts regarding that.

              Re: #3, that actually sounds like a bug — what device/OS/browser are you using? The menu should behave as you’re describing by default (and does for me in Chome on Mac)

            • tomdryan 9:18 pm on July 30, 2013 Permalink

              I’m using Chrome (Version 28.0.1500.95 m) under Windows 7. I just tested in IE (v10.0.9200.16635) and it’s doing the same thing. Also, another issue is that when I expand the menu to show icons+text, it does a two step display of the text, first the text appears flush to the very edge of the page, then it jumps to proper location. It makes the menu expand function look jumpy. It’s doing this in both Chrome and IE.

    • JonMasterson 12:48 pm on July 30, 2013 Permalink | Log in to Reply

      This is so cool. Thanks for your work!

    • Native Imaging 4:12 pm on July 30, 2013 Permalink | Log in to Reply

      Checking it out now. There was a few small problems with the admin bar. Lately since “-webkit-overflow-scroll: touch;” is standard in mobile devices, i have to push for this being used in the admin bar, especially since there will never be a perfect way to allow other plugins to utilize the top level admin bar.

      Oh, the blue makes my eyes feel like they are going to bleed, please don’t make it the default color or i will probably modify the plugin. There was a joke recently floating around about how the WordPress admin should match the color of facebook so beginning users can mentally grasp the options. PLEASE DONT. In-fact, the colors should be customizable.

      There are some plugins that have issues with the new vector icons such as Woocommerce.

      Also, when viewing the Admin on Android Motion, the Menu icon floats above the admin bar in its own block with a transparent background.

      And the Scroll bars need to be styled for web browsers.. Right now, there are the hideous mac/windows scrollbars.

      Un-Checked check boxes are all collapsed to 0px width.

      Several Input Text & Text-Area Fields are overflowing out of their containers as well as many format breaks with other plugins. I know there is no 100% proof system, and will require some plugin developers to make their plugins play nicely with MP6, but it’s definitely worth taking a look at to see if the MP6 can handle small layout issues. ie FontPress is an example of layouts breaking.

      Lastly for now:
      I dont think the media uploader works at all among many other WP Core functions.

      Thank You for all of the hard work! I’m extremely excited this new system is being developed. I still think that a more touch-swipe horizontal-carousel menu system with large icons is the way to go. I wish that things would be much more fluid and user friendly, but i’m just a dreamer.

      • Native Imaging 5:16 pm on July 30, 2013 Permalink | Log in to Reply

        One thing I wish something could be done about is the hideous white screen for the inner page content. It really kills the eyes after starring at it day in and day out. I know it could be a headache for handling some plugins, but not nearly as bad of a headache that millions of WordPress users get everyday form looking at the bright-white page wrapper background.

        Also, i’ve found icomoon.io to be thee best font-glyph system out there. They allow you to upload your own SVG’s as well as saving the JSON file to backup and restore your font glyph sessions….

    • hakaner 4:21 pm on July 30, 2013 Permalink | Log in to Reply

      Wow, this is a great! I’ve created a gray version: http://bit.ly/18L2Oon

      • BandonRandon 7:52 pm on July 30, 2013 Permalink | Log in to Reply

        Just a quick look over the grey version. You may want to name `colors-blue.css` to `colors-gray.css` you also have `This is the CSS file that makes MP6 blue by
        overriding MP6′s default styles.` if this makes it gray that is not true :)

    • Samuel Wood (Otto) 8:14 pm on July 30, 2013 Permalink | Log in to Reply

      Note that the color scheme is experimental, and probably will be implemented somewhat differently later. The way MP6 is (ab)using the admin color schemes offends me slightly, but it’s my own fault since I wrote it that way to begin with. I’ll probably pull it apart and make it do-it-right a bit later. :)

    • hakaner 8:20 pm on July 30, 2013 Permalink | Log in to Reply

      Thanks BandonRandon. I forgot this line in the colors-blue.css but if I change the name of colors-blue.css, you need to specify the new name in the colors.php. So I left it as it is.

    • BandonRandon 8:26 pm on July 30, 2013 Permalink | Log in to Reply

      Like @Otto said above, the color scheme is expermental. However, there appears to be a major bug that requirers the color scheme to be colors-blue. Here is a gist of the problem and a simple fix. https://gist.github.com/BandonRandon/fa9d631e2e91995f0510 Note, this will only work if the color scheme is required to be defined in the wp-config.php

    • Native Imaging 9:22 pm on July 30, 2013 Permalink | Log in to Reply

      I have one odd request that might be useful and solve some concerns about new design techniques…

      I’ve noticed a lot of websites are now using sticky headers & Navs for slicker navigation through their sites, but the wordpress admin conflicts with fixed positioned elements since it too is fixed at the header. I’ve tested a few snippets to move the admin to the bottom of the html window and the sub menus popping up above instead of down below, but this probably isn’t really the best idea for the Admin area. Although it did work, a few small kinks with MP6, i though it might be a good idea to have a check box or select option to move the admin bar above or below on the front-end (since MP6 is a rework for the WP Admin UI).

      • Seven sparks has implemented this for their new Sticky Nav extension.
    • Avocadesign 3:28 am on July 31, 2013 Permalink | Log in to Reply

      I’m also seeing checkboxes on the post and page edit pages collapsed to 0 width

      I’m sure you’re also aware to but the #post-body-content is missing the margin-bottom: 20px; to replicate the margin of the other meta boxes and the top one is currently flush with the bottom of the content editor.

    • Ipstenu (Mika E.) 3:34 am on July 31, 2013 Permalink | Log in to Reply

      Weird alert ‘box’ showed up when I had an upgrade available.

      http://cl.ly/image/0V1P3N2B372B

      It went away as soon as I updated the plugin, but that was totally weird.

    • Nick Halsey 3:35 am on July 31, 2013 Permalink | Log in to Reply

      I missed some other stuff in the editor styles. The biggest issue now is that it’s inheriting mp6 styling instead of theme styling unless the theme styling is fairly specific.

      Since Twenty Thirteen’s header colors are the same as the body text colors, they aren’t explicitly defined. So tinymce-dialog.css:394 causes blue headers in Twenty Thirteen, which are obviously out of place. I like the design intent a lot; perhaps there’s a way to only load some of that stuff (including open sans) if there are no theme-defined editor styles. That’s probably more difficult to do from the plugin, though.

      The beautified code looks much nicer, by the way!

    • tomdryan 8:32 pm on July 31, 2013 Permalink | Log in to Reply

      Is it possible to make it so the left dashboard menu is fixed and doesn’t scroll along with the page (i.e. the same behavior as the admin bar)? This would make it easier to work with WP since the menus would always be in the same location. Thanks!

      • Till Krüss 1:54 am on August 1, 2013 Permalink | Log in to Reply

        This is already happening as long as your browser window is taller than the admin menu.

        • tomdryan 12:59 pm on August 1, 2013 Permalink | Log in to Reply

          Doh! I see that now. I was playing around with with a shorter window.

        • tomdryan 2:55 pm on August 1, 2013 Permalink | Log in to Reply

          Now I recall where I had found this issue previously…If you have JetPack loaded and click on the JetPack menu choice, for some reason, that left admin navigation menu is no longer fixed,. but it scrolls with the page. This happens even when the browser window is taller than the admin menu on both Chrome and IE (Windows 7). The JetPack menu option is the only one that I have found that does this. Strange.

        • tomdryan 3:25 pm on August 11, 2013 Permalink | Log in to Reply

          Till, here is an idea for a different way to handle the “browser window too short to display entire admin menu” issue:

          Currently, if the browser window is too short, we just throw out the sticky menus all together and scroll with the page, no matter how long that page is.

          The proposal for those cases is to scroll the admin menu with the right side page just until the the last menu item is displayed and then lock it again in that position unless the user starts scrolling up again and then allow it to scroll with the page until the top of the admin menu is reached,.

          This way, you can handle the case where the window is too small, but the user will never lose site of the admin menu. It is important to the UX that the user not ever lose site of that menu. Also this gives a very smooth feel to the admin interface.

          You can see an example of how this works in action in FaceBook. The ads on the right hand side of the page will scroll until you reach the last ad, then it will stay fixed on the page,even though you keep scrolling the page (although they make you go all the way back to the top of the page before you can see the top of the ad column).

    • tomdryan 12:29 am on August 1, 2013 Permalink | Log in to Reply

      I’m not sure if this is the best place to put this, but I wanted to get it out there for discussion (happy to post it somewhere else if that makes more sense). Here is a proposal to organize the admin menu in a way that better meets the needs and expectations of users (especially those new to WP!). Some of the changes are as simple as renaming existing options to be consistent across the entire menu and some of the changes will likely be a bit more involved….

      WordPress New Admin Menu Re-Structure Proposal.

      Dashboard

      Posts
      Manage Posts
      Add New
      Categories
      Tags
      Settings (was: Settings>Writing)

      Media
      Manage Media
      Add New
      Settings (was: Settings>Media)

      Comments
      Manage Comments
      Settings (was: Settings>Discussion)

      Pages
      Manage Pages
      Add New
      Settings (was: Settings>Reading)

      Layout (could be included under Pages instead)
      Menus
      Widgets

      Users
      Manage Users
      Add New
      Edit Current Profile

      Themes
      Manage Themes
      Add New
      Customize
      Header
      Editor

      Plugins
      Manage Plugins
      Add New
      Editor

      Tools
      Import
      Export
      Updates

      Site Settings
      General
      Permalinks

      Help (this should also go on the admin bar under a “?” icon)
      Welcome
      About WordPress
      wordpress.org
      Documentation
      Support Forums
      Feedback

      —————-
      JetPack
      other plugins, etc.

    • titanas 2:22 pm on August 2, 2013 Permalink | Log in to Reply

      Inspired by the new MP6 i created a quick mockup (13-inch screen laptop) for a possibly the new admin. Maybe MP6 v20. My three rules of thumb are 1) speed 2) reduced clutter 3) adaptability

      I’m sure that data from WordPress.com could reveal real usage patterns but judging from my daily habits as a power user i rarely need the full menu on the left, even collapsed.

      Since the top bar is pretty much default, i thought we can mimic the design of the WordPress iOS app for simplicity, functionality, ease of use and speed.

      There are a few ideas like universal search (posts, pages, attachments, comments etc) i couldn’t resist to include :)

      Mockup available here https://dl.dropboxusercontent.com/u/184353/wordpress-admin-mockup-v-01.png

      • tomdryan 3:29 pm on August 2, 2013 Permalink | Log in to Reply

        Thanks for the mockup @Titanas! I can’t wait to get a chance to play with it to see how it works in action.:) In any case, we should unify the functionality (eliminate duplication) of the left and top admin bars, whether or not they remain separate items.

    • Bryan Hoffman 5:44 pm on August 27, 2013 Permalink | Log in to Reply

      One tweak and a small bug I’d like to mention:

      1. I like Lato, but prefer the lighter weight. font-weight: 200
      2. Higher specificity on the public facing admin bar styles. My theme seems to override some styles. Here’s a screenshot: http://spig.io/image/1v041B2e0M3s

      Loving MP6 overall. Especially the plugin title banner. Comic Sans, Papyrus, bevel & emboss, linen, and a lens flare! Fantastic!

      Can’t figure out the butler though… which bad graphic design icon does that represent?

  • Matt Mullenweg 2:03 pm on July 4, 2013 Permalink
    Tags: mp6   

    MP6 feedback: just to start a new thread people can leave comments on, drop one here if you have any MP6 bugs or feedback you’d like to share.

     
  • Matt (Thomas) Miklic 9:34 pm on June 7, 2013 Permalink
    Tags: , mp6, ,   

    Hello all! We’re here with the final regularly scheduled weekly installment of MP6, version 1.5. As we’re beginning to wrap up our visual redesign, we’ll continue to release updates to MP6 when necessary, but will no longer be announcing them every Friday. We’ll miss you guys. :)

    New this week:

    • We’ve begun merging colors-mp6.css and wp-admin.css. This is just about done, but we need to do a bit more testing before we flip the switch and use the new CSS files for everyone. When we’re done, this will allow for much cleaner future potential patches/merges into Core.
    • Load Open Sans on the login screen.
    • RTL: Fix comment bubble tail and positions, view switch margins.

    This week includes contributions from Michael Erlewine (mitcho), Till Krüss, and myself.

    You can continue leaving comments here with feedback for us. And we’ll issue new posts when there’s something big new for you guys to take a look at (we’re already noodling on some larger core design issues we’re looking forward to sharing with you). As always, thanks for all your helpful feedback in advance.

     
    • Ulrich 10:13 pm on June 7, 2013 Permalink | Log in to Reply

      I am still having problems with the mobile menu. I am not sure what is causing it.
      Here is a screenshot
      http://pix.am/CfdX.png

      • codydh 1:05 pm on June 8, 2013 Permalink | Log in to Reply

        I am seeing this too, though I’m on WP 3.5.1, and I’m wondering if that’s the cause.

      • Matt Thomas 8:58 pm on June 12, 2013 Permalink | Log in to Reply

        I was able to reproduce this, but only on a 3.5 installation and not very consistently. Since it doesn’t affect 3.6 that I can tell, we probably won’t spend too much time debugging this, but let me know if you get any insight into what’s causing it, and we’ll take a look.

    • harribellthomas 11:16 pm on June 7, 2013 Permalink | Log in to Reply

      I am having a problem where the burger doesn’t appear on custom pages.
      Here is a screenshot:
      http://pix.am/E433.jpg
      Swiping still reveals the menu, as you can see, and the burger is visible on all generic WordPress pages, but not custom ones.
      Thanks for the plugin by the way, it has revolutionised the way I use WordPress!

      • harribt 11:37 am on June 16, 2013 Permalink | Log in to Reply

        I’ve solved this; I wasn’t using the div class ‘wrap’ for my settings page. I simply added this and all works as is supposed to.

    • codel1417 4:19 am on June 8, 2013 Permalink | Log in to Reply

      unlock horizontal scroll for non optimized that go off screen

    • Lea Cohen 7:21 am on June 9, 2013 Permalink | Log in to Reply

      Oh, mixed feelings: I’m very happy for you guys that the plugin has reached this maturity! But I’ll miss the Friday announcements :)

      This is a good opportunity to thank you for all the RTL care! I really appreciate it, and especially the fact that you listened to my feedback.

      However, it seems I can’t leave without adding some issues to your list :) , so here are this week’s additions:

      1) In the comment bubble tail and positions that you fixed this week, I forgot to mention that the hover doesn’t show the sorting arrow…

      2) The submit button on some screens is still left aligned. For example, the export.php acreen, all the options screens (options-general.php, options-media.php, etc.), the edit-tags.php screen, and maybe there are more – I’m not sure I went through all the screens.
      It’s funny, because in some screens, someone *did* remember to right-float it , for example: theme-editor.php, and plugin-editor.php (although it seems to me that text-align:right would have been enough. Why float it alt all?)

      Thanks again, and good luck !

      • Matt Thomas 9:06 pm on June 12, 2013 Permalink | Log in to Reply

        Thanks, Lea (and thanks for all the feedback on the RTL component over the last few weeks). I’ve added these issues to our to-do list, and should have a fix for them in trunk soon (when we do, I’ll bump the version number so you get an update notification).

    • webdevmattcrom 7:19 am on June 11, 2013 Permalink | Log in to Reply

      I seem to have quite a few issues with TinyMCE editory with MP6. A tiny issue I might have a fix for. The webfont icons don’t align well in the buttons. This is how I tweaked it to get them to align well:

      .wp_themeSkin span.mceIcon, .wp_themeSkin img.mceIcon {
      KEEP THIS–>display: block;
      REMOVE THIS –>width: 20px;
      KEEP THIS–>height: 20px;
      ADD THIS –>position: relative;
      ADD THIS–>bottom: 5px;
      }

      The problem then is buttons that still actually use images rather than the webfonts. One fix creates other problems, but I think this is a step closer to doing it well.

      Love this UI, such a HUGE improvement. Thank you!

    • jbrunet 1:15 pm on June 12, 2013 Permalink | Log in to Reply

      when you have a select multiple, just shows one line. In colors-mp6.css
      #wpbody select {
      line-height: 24px;
      height: 24px;
      border-color: #bbb;
      }
      The height property is not needed I think.

    • Linda Lee 9:12 pm on June 16, 2013 Permalink | Log in to Reply

      Matt I have been asking around but no one has given me a solid answer. Is the new dashboard going to be part of the new WP 3.6 release?

    • Ivan D. 5:17 pm on June 17, 2013 Permalink | Log in to Reply

      Hi,
      I’m new here and I like the MP6 ergonomy !
      But i think we can do more. I’ve made a little plugin to do little improvements.
      Look here the result : http://rcrea.fr/img-host/mp6-perso-17-06-13.jpg
      If you want the little plugin or more info just ask.
      I don’t know how i can help on this, if it’s not the right way tell me ;)

    • mrwweb 6:06 pm on June 17, 2013 Permalink | Log in to Reply

      I am still seeing this gross Firefox font-rendering issue that I raised way back in this comment. I went and checked and it does affect the dashboard on WordPress.com as of the release of the new interface there today.

      I’ve established that it doesn’t seem to be tied to any add-ons or hardware accelleration and can be fixed by either not using Open Sans or getting rid of fixed positioning. Beyond that, I haven’t figured out how to fix it.

      • Matt Thomas 9:52 pm on June 17, 2013 Permalink | Log in to Reply

        We’ve had a hard time reproducing it reliably; it seems to be some specific combinations of Firefox, OS, and hardware. We’ve still got this one on our to-do list, though.

        • mrwweb 8:22 pm on July 2, 2013 Permalink | Log in to Reply

          Glad to hear you’re still working on it. I came back at it today to see if I could find some other info that might help with a fix. In the past, I’ve noticed that removing fixed positioning resolves the issue, but now I’ve found another “solution:” on colors-mp6.css on line 1170, there’s the following:

          #adminmenuback, #adminmenuwrap {
          background-color: #222222;
          }

          If you remove #adminmenuwrap from the selector, the rendering issue ceases.

          You can similarly fix the admin-bar rendering by remove the background of #wpadminbar.

          So that seems to suggest the problem is a weird combination of fixed positioning and background color. That led to a new round of Googling that turned up empty like the last run, but this feels like a bit of a breakthrough.

          Hopefully this is useful.

    • Knut Sparhell 11:12 pm on June 20, 2013 Permalink | Log in to Reply

      I have TinyMCE Advanced on some sites. With MP6 some buttons become invisible.

    • FAT Media 10:08 pm on June 24, 2013 Permalink | Log in to Reply

      I’ve noticed that MP6 is loading admin styles on the front end needlessly. A quick check to see if the user is logged in should prevent this. I opened an issue on the plugin support forum over here: http://wordpress.org/support/topic/prevent-admin-menu-styles-from-loading-on-the-front-end?replies=1

      Here’s a direct link to the code that needs updated as well: https://gist.github.com/fatmedia/5853892

    • WebsiteDoctor 11:23 am on June 26, 2013 Permalink | Log in to Reply

      I think the new UI looks great. There are some problems with accessibility, in particular when using the Zoom feature on MacOSX and some other systems frequently used by those with visual impairment (partially sighted). This is a regression from the existing WP UI where the zoom works correctly.

      Where should I report this?

      • Matt Thomas 3:37 pm on June 26, 2013 Permalink | Log in to Reply

        Thanks — you can let us know right here, and we’ll add the issue to our to-do list. It’ll help if you can include screenshots of the problems you’re seeing. We’ve tested the core admin with browser zoom enabled quite a bit (see: http://cl.ly/image/113d231d0s1o), so a list of any plugins and other modifications you might have made would be helpful too.

    • Aaron D. Campbell 6:56 pm on July 1, 2013 Permalink | Log in to Reply

      I tried MP6 on my S3 and while I’ve not tested everything, here are some of the issues I’ve found. Let me know if there is a better place for bug reports.
      1) While I know the Settings option is at the bottom of the nav, I can’t actually get to it. This is scrolled all the way to the bottom: http://cl.ly/image/2v2H0F1V1S1d
      2) If there are added buttons with the Media button, it overlaps the editor buttons. This happens in both text and visual mode, and when it happens you can’t change between text and visual editors – http://cl.ly/image/2Y063X1X3b2P and http://cl.ly/image/0Y0k342c0r0f
      3) On the post list page, checkboxes are clipped – http://cl.ly/image/3D3P2M012L1f

    • gmcosta 8:33 pm on July 1, 2013 Permalink | Log in to Reply

      Hey guys, congratulations for the job you’re making with WP.
      I would like to suggest something. How about you include in WP Core, this feature:

      “When you search a plugin (under Plugins > Add New), wordpress auto check the version installed and display only compatible plugins with that version.”

      After searching for two hours for plugins that I could use on my project, 95% of them are not recommended and at least, half, doesn’t work at all.

      Please, let me know what you guys think about this.

      Kind Regards,
      Gmcosta

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