WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: core plugins Toggle Comment Threads | Keyboard Shortcuts

  • samuelsidler 4:40 pm on February 27, 2014 Permalink | Log in to leave a Comment
    Tags: core plugins   

    Feature Plugin Chat on March 4 

    As mentioned at this week’s and last week’s meeting, we’re going to be holding a feature plugin chat on March 4 2014 21:00 UTC. If you have an idea for a new feature, this will be a great opportunity to bring it up and find others interested in helping out. In fact, just like we’ve done before, post your feature ideas here.

    Please leave one comment per feature idea with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • A list of those involved or already interested in your feature plugin (including you!)
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    This post and the accompanying chat is for posting ideas that you’d be interested in working on. It is not for posting every feature idea you have for WordPress.

    Current feature plugin leads: Please post an update for your plugin here, along with the information above.

    See you all at the chat!

     
    • scotthack 4:52 pm on February 27, 2014 Permalink | Log in to Reply

      I’d like to see a plugin built that will accept an XML file to import custom post types and taxonomies. That way theme authors can just provide an XML file with their themes. Then the end user can use the import file to create custom post types and taxonomies and it would be imported independent of the theme.

      This is in the idea stage. My coding skills are very basic, so I’d be of little to no help in the coding department. It would need to be picked up by a competent programmer to actually see it through. I’m only able to help with testing, feedback, and idea conception.

    • UaMV 5:33 pm on February 27, 2014 Permalink | Log in to Reply

      Extend proper author/contributor support when defining custom post types. Currently, when a CPT is registered with support for ‘author’, the metabox returns a list of users with the author role (even if those users don’t have ‘edit_posts’ capability for the CPT. Even in the standard post editor, the author metabox includes only users with an author role, not necessarily those who can contribute (or have edit_posts capability). I believe this metabox should return any user that has the ‘edit_posts’ capability for the specific post type in which the author metabox is being supported.

      There is currently a plugin, Authors Autocomplete Meta Box, in the repository that extends this functionality.

      Rachel Carden (aka bamadesigner) is the author of this plugin (commissioned by ereleases.com). I have, as of yet, had no contact with her regarding the plugin, but find it of great use on my site with multiple CPTs and multiple custom roles.

      Not sure at the moment how I might assist.

    • Janneke Van Dorpe 6:36 pm on February 27, 2014 Permalink | Log in to Reply

      The Front-end Editor is a plugin that allows posts to be edited on the front-end (so it’s really WYSIWYG) and aims to have all the features available that the back-end editor has.

      It’s currently in development on GitHub and updates a posted weekly on the UI blog.

      I’m the project lead (@avryl) and those who are involved or have shown interest are @azaozz, @brainstormforce, @bravokeyl, @gcorne, @helen, @henrywright, @hugobaeta, @joen‎, @kraftbj, @markjaquith, @melchoyce, @mrahmadawais, @obenland, @protechig‎, @rafaelxt, @rhurling‎, @roundhill, @samuelsidler, @shaunandrews, @tillkruess, @ubernaut, @wholegraindigital and others.

      If you’re interested, take a look on GitHub and join our Skype chat (add jannekevandorpe). The next meeting will be Tuesday, 4 March 2014, 17:00 UTC in #wordpress-ui.

    • Chris Reynolds 12:46 am on February 28, 2014 Permalink | Log in to Reply

      AH-O2 (aka Admin Help) is venturing to reimagine the help system in the WordPress admin.

      It’s currently in development is on GitHub with updates being pushed weekly to the WordPress plugin repository. Updates are posted to the Docs and UI P2s.

      I’m the project lead (@jazzs3quence) and other contributors and folks who’ve been involved one way or another are:
      @brainfork, @trishasalas, @jdgrimes, @ubernaut, @zoerooney, @ninnypants, @mdbitz, @clorith, @nikv, and @veraxus

      We need help with:

      1. Documentation — new tooltips are being added to every admin page. Coders (the folks adding them) != writers, so many of these need to be (or will need to be) reviewed, fixed, updated or written. Also, it’s been pointed out that the help overviews we’re building — which replace the help tabs — may not be best suited for the existing documentation in the help tab (which we’re currently pulling from). So help documentation for those areas may need to be edited/changed/added/removed/etc.
      2. Coders — tooltips are added with javascript (and a little php, just to add the translatable string) but fear not! It’s really easy and repetitive. With about 10 minutes of guidance I think I can walk just about anyone through the process of adding a tooltip.
      3. Testers — please break our stuff (and create tickets)! https://github.com/jazzsequence/WordPress-Admin-Help/issues
      Also, extra brownie points to anyone who can test existing, open tickets to confirm/deny a behvior that has an open ticket.

      We meet weekly in #wordpress-sfd on Monday 18:30UTC.

    • Greg Ross 7:50 pm on March 4, 2014 Permalink | Log in to Reply

      The Admin Theme Experience is an update to the existing admin theme system to try and match the site theme user interface. It has two primary goals; simplify the creation of admin color themes and bring the Site Theme Experience to admin themes.

      Current plugin status: under development

      A list of those involved or already interested in your feature plugin: Me!

      What you’d like help with: Anyone with knowledge of the current site theme code would be helpful.

  • John Blackbourn 1:06 am on November 27, 2013 Permalink
    Tags: core plugins,   

    Features as Plugins: Register Your Interest 

    Three of the features in the upcoming WordPress 3.8 release were developed first as feature plugins:

    • MP6, the new visual style for the admin area
    • THX38, the new theme management experience
    • DASH, the refreshed dashboard screen

    Feature plugins are regular plugins whose ultimate aim is to be put forward as new features for future versions of WordPress. This model allows for efficient, collaborative development over longer periods of time, and a certain amount of visibility among people who help develop for core. The status of existing feature plugins can be seen here.

    This post is a call for people who are planning on working on feature plugins in the near future to make themselves known in the comments. People who would like to pro-actively help out should then comment on individual comment threads.

    If you are a developer, designer, or curator who’d like to act as a project lead for (or at least take a primary role in) the development of a feature plugin, please leave a top-level comment on this thread with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • Your role in the plugin (developer, designer, lead, etc).
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).
    • A top secret magic code name for your plugin (optional).

    Please note that this thread is not for putting forward ideas for things unless you are planning on taking an active and primary role in its development. This is an organisation thread, not an ideas thread.

    Anyone who’d like to collaborate on any of the plugins listed in the comments should leave a reply to the corresponding comment indicating your interest and what you can help out with.

    Bear in mind this is not a list of potential features for WordPress 3.9, or indeed any other particular future release. Feature plugins are not tied to any specific release and will only be considered for potential inclusion in core once they reach a certain level of completeness.

    We’ll see how this list pans out over the next few days and go from there! It’s expected that we’ll organise some IRC meetings in due course.

     
    • George Stephanis 1:24 am on November 27, 2013 Permalink | Log in to Reply

      The Search Initiative needs brave souls willing to spearhead some of the varied bits in it. If anyone wants to work on something, but isn’t quite sure what, please snag one of these bits and run with it!

      I’ll be continuing my previous work in addressing points 1, 4, and 7 from that list. If anyone would like to take points 2, 3, 5, or 6, please do!

      • Weston Ruter 3:35 am on November 27, 2013 Permalink | Log in to Reply

        For 5, I’ve been working with @johnregan3 on a plugin called Admin Screen Search (WIP). The idea is to index the full text (not just links) of all admin pages (accessible to the user via the admin menu), to parse out areas of each page and assign weights to text matches appearing in headings, labels, help texts, and input values. When doing a search, admin page results would be sorted by weighted matches. Our plan is to let it be one of Omnisearch providers, and happily to be merged into the core plugin and into core itself.

        Our role: leading development of search results for admin pages

      • Sam Sidler 10:08 pm on December 2, 2013 Permalink | Log in to Reply

        Are you planning on holding weekly chats again?

        • George Stephanis 10:54 pm on December 2, 2013 Permalink | Log in to Reply

          I was intending on finding the people that would want to attend and working the weekly meeting around them, do you think it would be more useful the other way about?

          • Sam Sidler 11:19 pm on December 2, 2013 Permalink | Log in to Reply

            Either way works, but if you haven’t found others yet, it might be worth announcing a weekly chat and having weekly status updates so others can passively get involved. If no one shows up, still holding office hours is good, so if someone decides to show up one day, they know when and where.

    • John Blackbourn 1:32 am on November 27, 2013 Permalink | Log in to Reply

      Here’s mine: Keyboard shortcuts for WordPress. Adding Gmail-like shortcuts for the admin area for navigation, saving posts, adding content, etc. Lots of possibilities.

      Status: Under development. Functional proof of concept here.

      My role: developer

      I’d like help with: General collaboration on development.

      • Tareq Hasan 3:08 pm on December 2, 2013 Permalink | Log in to Reply

        I did something like this about a year ago :)

      • Sam Sidler 11:24 pm on December 2, 2013 Permalink | Log in to Reply

        How are you deciding what the shortcuts will be? Are there other web apps we can look at that have keyboard shortcuts we can compare to? Obviously Gmail, but Google Docs? Blogger? Probably quite a few do, though I’m struggling to think of any right now.

        Once you’ve decided on a set of shortcuts, can most of this be done directly in core? Doesn’t seem like it needs to be a feature plugin unless there are some major-ish UI/UX or backend changes to consider. Making it extensible for plugins might be part of that consideration, I suppose.

        Would love to see it as a plugin in the repository too. :)

        • John Blackbourn 6:43 pm on December 3, 2013 Permalink | Log in to Reply

          I’ve looked at a few web apps/sites (see https://github.com/johnbillion/wordpress-keyboard-shortcuts/issues/3). “G” followed by another key appears to be a defacto standard for navigation, as do others such as “/” for search and “?” to display the list of shortcuts.

          Extensibility is important. I started it as a plugin for the same reasons that feature plugins exist anyway – easy iteration and collaboration, and if they never end up going into core then we still end up with a plugin.

          • kkalvaa 1:54 pm on December 4, 2013 Permalink | Log in to Reply

            Have you considered international versions of those hotkeys? Several “standard” hotkey setups are completely unsuable on non-english keyboard setups due to several characters being mapped to a modifier key (shift/alt). Both “/” and “?” are characters with modifier keys for several keyboard layouts.

      • Tareq Hasan 7:46 am on December 3, 2013 Permalink | Log in to Reply

    • @ubernaut 2:06 am on November 27, 2013 Permalink | Log in to Reply

      i have gotten mixed opinions as to whether this fits within the features as plugin paradigm but i think it would be huge improvement to ux especially for particularly active sites from a content production standpoint. The feature is having categories pre filled and un-selectable in bulk edit mode. Doing this operation (removing categories) for a large number of posts one at a time is really tedious.

      Status – idea stage (http://core.trac.wordpress.org/ticket/11302)
      Role – Maybe design or lead if applicable but i’m not proficient in php
      Help needed – development primarily i think there isn’t much to this besides the coding and ux/ui determinations
      Code Name – Geronimo

      • Sam Sidler 10:11 pm on December 2, 2013 Permalink | Log in to Reply

        This doesn’t need to be in a feature plugin.

        As a ticket in core that seems to be wanted, it just needs a patch for inclusion. I recommending finding a developer who’s interested in doing that work.

    • Ryan McCue 2:07 am on November 27, 2013 Permalink | Log in to Reply

      The WP API team is ramping up development over the coming weeks, and we’re looking for anyone interested to help out!

      I’m leading the team as we work to build an awesome JSON API with hope to launch as a core feature in WordPress 3.9.

      Anyone who’s interested is welcome to get involved, no matter who you are. Javascript and theme developers are our weakness at the moment, so they’re especially welcome.

      • Julien 11:10 am on November 28, 2013 Permalink | Log in to Reply

        Hello Ryan,

        how can I join your team ?

      • Sam Sidler 10:14 pm on December 2, 2013 Permalink | Log in to Reply

        Is your goal to ship the entire feature plugin (as in, all parts of it) as a feature in WordPress 3.9? With authentication still under development, that’s a tight timeline. Have you considered breaking out the pieces that are most ready/complete and polishing them for inclusion? (On the flip side, you could break out the in-development parts. Both ways focus on polishing what’s closest instead of working on new features.)

        • Ryan McCue 9:05 am on December 5, 2013 Permalink | Log in to Reply

          Sorry for being so slow to get back to you.

          The core (that is, all the routing and base parts) should be done by Christmas, and that will be ready for merge. For everything built on top of that, probably best to handle it case-by-case, which is an advantage of keeping it modular.

          I suspect we’ll be able to merge all of it, but it depends on the timeframe for 3.9. Word on the grapevine is that we won’t be seeing it for a few months yet, and if so we can hold off merge until mid-cycle. Of course, my sources could be wrong there. :)

          • Sam Sidler 7:49 pm on December 9, 2013 Permalink | Log in to Reply

            I imagine, given the holidays, that the merge window won’t happen until January. But who really knows? ;)

    • Chris Reynolds 3:06 am on November 27, 2013 Permalink | Log in to Reply

      The Admin Help improvements team is still working on our feature plugin. The goal is to rethink how help is presented in the WordPress admin.

      • Status: Under development
      • My Role: Lead, developer
      • I’d like help with: We can always use more devs. When we’ve got something to test, we will also be reaching out to accessibility and internationalization folks.
      • Sadly, I don’t have a top secret magic code name.
    • Mike Schinkel 6:47 pm on November 27, 2013 Permalink | Log in to Reply

      Post/Object Relationships

      Status: Implemented and in use on client products as 1st generation, about to redo as 2nd generation for current client project.
      Role: Project lead/developer/architect
      Codename: Relatable

    • Manny Fleurmond 8:13 pm on November 27, 2013 Permalink | Log in to Reply

      I’m stretched thin as it is but I would love to extend the media modal even further to allow full previews of media, as well as abstract out the image editor to a Backbone app

    • Scott Taylor 10:30 pm on November 27, 2013 Permalink | Log in to Reply

      Audio/Video 2.0

      I have a few ideas:

      • Audio playlists with a Spotify/Rdio/Soundcloud like UI
      • Shareable/embeddable widget that loads an iframe to your site’s player/music
      • Make you site an oEmbed endpoint provider – turn your Audio / Video / Playlists into embeddable widget iframe code
      • Subtitles for video

      The gist: let your site do what Soundcloud et al do.
      How? Don’t know! Let’s find out.

      • Fab1en 8:39 am on December 2, 2013 Permalink | Log in to Reply

        I can help with that : I’m using WordPress as a audio/video publisher for artists and web-documentaries since version 3.2. You can see artists web sites here with an audio player and the artist’s discography that shows as playlists. And various web documentaries where each video is a WordPress Media.

        I published partially the code I’m using for those sites in 1player plugin. Sadly, I did not find the time to update it recently. I was delighted to see that WP 3.6 adds video and audio support directly into the core, but I see that some of the features I need are missing.

        Video and audio support is well integrated into the Media Library, but, in my opinion, those media specificity should be addressed more precisely, as this has been done for images management.

        • You can avoid to specify src parameter in the shortcode : WP will get the media attached to the post instead. That’s great, but there is the same issue as there were for the gallery shortcode : video/audio must be attached to the post, so to publish one video in several posts you have to duplicate it. Why not introduce an “id” (or ids) param in the shortcode to allow easy video/audio embed ?
        • Each video/audio can only have one format (resolution and encoding). It would be great to provide several versions for the same video/audio : mp4/webm or mp3/ogg and low/hight resolution for example, with the same mechanism as the one used for image thumbnails. This would allow to output several tags inside the tag.
        • It’s generally a good idea to host video/audio files on a CDN. WP Media Library should provide a way to save an attachment in the Library with an _wp_attached_file pointing outsite WP server install. This remark is also valid for other media like images.
        • Specifying the poster image source in the shortcode is not very convenient. One would expect to use an image from the WP Library. That would also allow to use built-in image resize service to fit the video size. One solution is to attach poster metadata to the Media object that represents the video. Another solution for posts with “video” post-format would be to use the featured image.
        • I’m a little bit disappointed by the way video/audio embeds are displayed in the tinymce editor. That would have been great to display a nice picture as for the gallery shortcode.
        • There should be a graphical UI to set some player parameters : default video size, controls display… MediaElementJs allows you to tune your player this way. Why not put this in Settings > Medias screen ? There would be room there for advanced settings as well, like a list of available skins and controls (play, pause, next, volume, fullscreen…), control bar position, and flash fallback policy.
        • On top of that, some advanced features could be implemented : playlist support (via video/audio gallery), subtitles and chapters, Dailymotion and YouTube integration within the mediaelement player, and as Scott said oEmbed endpoint, iframe embed widget …
      • Sam Sidler 10:16 pm on December 2, 2013 Permalink | Log in to Reply

        Sounds like a large and exciting project! I recommend writing up an overview of your vision, perhaps for make/ui to start, and starting a weekly chat to gauge interest.

    • Janneke Van Dorpe 12:37 am on November 28, 2013 Permalink | Log in to Reply

      The Front-end editor is currently in an idea/planning/design stage. The goal is to make a perfect, easy to use WYSIWYG editor.

      A plugin is being worked on, we have weekly IRC meetings on Mondays, 16:00 UTC, #wordpress-ui, and publish regularly on make/ui. We also set up a Skype group, so let us know if you’re interested and I’ll add you to the conversation. My Skype username is jannekevandorpe.

      Anyone who’s interested is welcome, at the moment we’d like to experiment more with different interfaces, and develop something to preview oEmbeds and shortcodes/galleries. TinyMCE experts are especially welcome!

    • mttktz 1:37 am on December 14, 2013 Permalink | Log in to Reply

      I’ve often thought that the big difference between WordPress and a tumblr, facebook, twitter, etc is that WordPress is write only. You don’t read and re-share like you do on those platforms. I think it’s more natural and conversational to read where you write. I’ve started a plugin that integrates a feed reader into WordPress’s admin area in the style of google reader.

      I’ve got a working prototype – you can subscribe to feeds, mark items as read, unsubscribe, etc. http://wordpress.org/plugins/orbital-feed-reader/screenshots/

      I really want this feature to exist in wordpress, so I started it – but I don’t want to be the only person working on it and I’d like if it became part of the default.

      I’d like help with design/wireframing, development and any suggestions on how to improve this and make it an actual feature. I think it would be a good additions to core.

      • mttktz 1:38 am on December 14, 2013 Permalink | Log in to Reply

        Erm – please do check out the screenshots. I forgot to mention that I’d like for you to be able to easily reblog – and that is working at the moment as well.

      • Sam Sidler 7:24 pm on December 14, 2013 Permalink | Log in to Reply

        An interesting idea! This is a good place to find other people, but this post is getting older and I bet not a lot of people are following these comments anymore. We’ll try to get another post up for feedback and you should introduce your project and hopefully find others to help.

        • mttktz 12:22 pm on December 23, 2013 Permalink | Log in to Reply

          Thanks! I’m still chugging away at it and I’m still hopeful that it would be interesting to WP core folks.

    • Eric Mann 2:28 am on December 14, 2013 Permalink | Log in to Reply

      A little later to the post, because with 3.8 on the horizon I didn’t realize this was for post-3.8. At the same time, I still want to flag this project:

      Overview:
      Refactor WordPress’ `get_template_part()` to behave like an actual, object-oriented templating framework. Developers will be able to pass objects/data in to the function and have it immediately available from the template without needing to declare globals or mess with output buffering to juggle scope. Likewise, commonly-used objects (like `$wp_query` and `$_REQUEST` should be available without needing to reference the (super)global directly.

      Current plugin status:
      Was custom code deployed for a client. Has since been rolled into a feature plugin and is hosted on GitHub: https://github.com/ericmann/MVPress

      My role:
      Developer/Lead

      What I need help with:
      Feedback on approach – does this do what we want it to do?

      Top secret magic code name:
      Going with “MVPress” for the time being.

    • GregRoss 3:07 pm on December 24, 2013 Permalink | Log in to Reply

      **Overview:**
      Replace the current admin theme system with a more robust model that mirrors the site admin theme code.

      **Current plugin status:**
      I’ve created a proof of concept plugin, The Admin Theme Experience (wordpress.org/plugins/the-admin-theme-experience/) which is functional but not complete (see the readme for additional details).

      **Your role in the plugin:**
      Developer/Lead

      **What you’d like help with:**
      Anyone with knowledge of the current site theme code would be helpful.

      **A top secret magic code name for your plugin:**
      The Admin Theme Experience

  • Mel Choyce 7:43 pm on October 23, 2013 Permalink
    Tags: , , core plugins, mp6   

    MP6 — 3.8 Proposal 

    The WordPress admin has not had a major visual overhaul since 2.7, and its age is starting to show. In a rapidly changing web environment where users are starting to expect good design, we need to make sure that our aesthetics match — better yet, exceed — their high expectations.

    MP6 is a movement towards modernity. It is an exploration into the infinite possibilities that exist for improvement within our existing framework. It is a tenderly crafted visual update to the admin that we all know and love. MP6 is the future.

    Screenshots

    What problems are we trying to solve?

    The current wp-admin has:

    • An outdated visual appearance.
    • Outdated technology.
    • Low contrast.
    • Suboptimal readability.

    We’ve solved these problems with the following:

    Modern aesthetics

    • Open Sans — a font as free as we are.
    • Cleaner styles — goodbye decoration, hello simplicity. Affordances still welcome.
    • Let it breathe — increased spacing between elements, which allow for better overall hierarchy and whitespace to guide the eye.

    Improved contrast and readibility

    • Higher contrast dark default color scheme — great for eyes of all ages.
    • Lower contrast light default color scheme — helpful for those with dyslexia and sensitivity to light.
    • Refined typography — larger font sizes, crafted with better readability in mind.

    Future-forward

    Inherently HiDPI

    • Vector icons — beautiful and crisp at any resolution.
    • CSS effects instead of images — cleaner, faster, and more flexible.

    Responsive

    Why MP6?

    Results

    While we haven’t explicitly user tested this new skin, it’s been running on WordPress.com for months with minimal issues. The same old WordPress admin functionality is still there, just with a fresh coat of paint.

     
    • lessbloat 7:56 pm on October 23, 2013 Permalink | Log in to Reply

      Let me be the first to say:

    • Nile Flores 8:12 pm on October 23, 2013 Permalink | Log in to Reply

      I like the idea of the color choice, but personally… I’d like the color choices to go further. I’m using my own version not too far off from this idea using my own brand’s signature colors.

    • Daniel Bachhuber 8:12 pm on October 23, 2013 Permalink | Log in to Reply

      Looking good! One programming note: Shouldn’t the screenshots be uploaded to WordPress to prevent link rot?

    • Daniel Bachhuber 9:14 pm on October 23, 2013 Permalink | Log in to Reply

      I’d like to pitch an idea I’ve been mulling over for the last week: MP6 as WordPress’ (Twitter) Bootstrap for the admin.

      For those not in the know, Bootstrap is a collection of UI / UX patterns, and their corresponding CSS / JS. The goal for Bootstrap is to make it much easier to get your web application up and running — many common UI / UX problems are solved for you. Want a login form? Boom. Want a modal? Bam.

      As a plugin developer, I poach from WordPress admin UI elements as often as I can. For instance, button primary is a godsend. Laziness is probably the primary reason, but consistency is probably more important. As you can find going through the Bootstrap website, there are many UI / UX patterns not defined in the WordPress admin that could be defined in MP6.

      It would, clearly, be additional work. I think taking on the work could provide these advantages:

      • Promote greater UI / UX consistency between core, plugins, and themes. A usable style guide seems like a reasonable, reachable outcome.
      • Clean up rough edges in existing styles. Making your code reusable, and having others use it, is guaranteed to improve the quality.
      • Make my life much easier.
      • Manny Fleurmond 9:16 pm on October 23, 2013 Permalink | Log in to Reply

        A reference for the dasicons would also be nice

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

          We have an unofficial guide here: http://melchoyce.github.io/dashicons/ (It’s missing a couple recent changes, I’ll be updating it soon)

          @helen mentioned the MP6 style guide below. @ryelle created an MP6 helper class page for hooking into color schemes within the MP6, and it could also be a good place to integrate a dashicons reference and instructions page.

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

        This is what I have been talking about for quite a while and have started to work on, but it’s a slow road when you’re alone.

        P.S. define(‘MP6_STYLE_GUIDE’, true);

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

        + 1,000,000

      • saas 5:09 am on October 24, 2013 Permalink | Log in to Reply

        I would be happy to see “(Twitter) Bootstrap” being a core of admin UI, it will surely make life of dev’s like me much easier (frankly I also find current UI based on .scss files quite easier to use, special thanks to @ryelle for providing .less version of for dev’s like me, keep up the good work @ryelle)

        But it would be good if we could and should or would use “Twitter Bootstrap” for core admin UI, it will bring a standard for not only admin UI but also will provide a guideline for building frontend UI, which will not be possible if we keep working on existing UI files (MP6), we will have to adapt it in a way, so we can bring more than just a rapid prototyping or ease of use.

        As we all know its been a dream for us to customize not only frontend / login screen but also admin UI to match the client website’s color scheme and brand. Which MP6 started to resolve but to seriously considering MP6 to be a part of core, we should bring all the tools (from gurus toolbox) on the wordpress table and pick the right tools for future of wordpress UI (admin, login screen, themes, plugins) and bring harmony between these so we can represent clients brands better.

        While we are on the UI topic, I would like to throw another suggestion out in the wild regarding which is regarding “UI Builder or Page Builder” it will be awesome if we could build such thing in core and using “Twitter Bootstrap” as a core UI framework with help build “Page Builder” a solid solution for our current UI building (generator) needs.

        I remember reading article regarding “Page Builder” being built for core but don’t remember it’s url, but I am sure you guys already know.

        So +!o,000,oo to Twitter Bootstrap :)

      • Scott Kingsley Clark 1:43 pm on October 28, 2013 Permalink | Log in to Reply

        Where do I send all of my +1′s? I’ve got a bag full just for you!

    • @ubernaut 12:51 am on October 24, 2013 Permalink | Log in to Reply

      hey everyone finally got a chance to put together my comments regarding the space efficiency issue i have been talking about in the office hours. While i do appreciate the concept of more white space i think that the removal of all of the separators does to some extent create a significant amount of whitespace in and of itself i believe it is possible to have the best of both world so to speak, anyway here is my post:

      http://ubernaut.wordpress.com/2013/10/21/mp6-the-other-side-of-the-coin/

    • Amy Hendrix (sabreuse) 3:20 am on October 24, 2013 Permalink | Log in to Reply

      I sometimes forget MP6 isn’t already the real admin. Totally in favor of getting it merged ASAP.

    • Gage Morgan 1:21 pm on October 25, 2013 Permalink | Log in to Reply

      You guys can’t ditch this idea like you did the Custom Post Formats UI. This NEEDS to be released in Core 3.8.

    • jeffr0 12:57 pm on October 28, 2013 Permalink | Log in to Reply

      Concerning MP6, color styles and custom menu icons. I’m using MP6 with the Midnight color scheme and although they don’t look terrible, the custom menu icons for some of the plugins I’m using don’t look very well. They look better or worse depending on the color scheme used.

      http://i2.wp.com/www.wptavern.com/wp-content/uploads/2013/10/CustomIcons.jpg?resize=146%2C243

      What can I do to inform plugin developers that they will now need to update their menu icons so that they look good with the different color schemes provided by MP6?

    • Central Geek 4:05 pm on October 28, 2013 Permalink | Log in to Reply

      WordPress is evolving, that’s for sure. I wasn’t too impressed with the MP6 plugin at first, but it is coming along very well. I think it would be great merge into WP core.

    • Helen Hou-Sandi 5:06 am on October 29, 2013 Permalink | Log in to Reply

      I moved development of the component + style guide thing to GitHub, as it’s more suited toward a developer-specific portal and isn’t meant for end user distribution: https://github.com/helenhousandi/wp-style-guide

    • mrwweb 4:08 pm on October 30, 2013 Permalink | Log in to Reply

      Can someone clarify whether this is nominating MP6 with or without the recently-added Widget admin changes? Until recently, that was its own project.

    • Ipstenu (Mika Epstein) 9:05 pm on October 30, 2013 Permalink | Log in to Reply

      Is there any way to have the toolbar reflect the css colors on the front end? It’s always black, and I kinda want to see sexy seaweed up front. :)

    • godhulii_1985 3:41 pm on November 1, 2013 Permalink | Log in to Reply

      User feedback:

      Is there any way that current leftmost column menu will retain its colour? (#21759B or #333333) All the left menu panel colours here were hurting my eyes. It would be better if current colours also exist in new colour schemes.

    • padelisspart 1:44 pm on November 2, 2013 Permalink | Log in to Reply

      OMG, So beautiful!!!

    • OriginalEXE 10:48 pm on November 5, 2013 Permalink | Log in to Reply

      First of all, I am all for this change, please add it to 3.8

      Next, I have one question. Will ‘mp6-highligh’ class change it’s name if this would be merged to core? I am asking because I am building interface now and would like to use ‘mp6-highlight’ class so that active item in the interface would adjust based on the color scheme chosen in the users profile.

      Thanks

    • LoweryAustin 7:03 pm on November 6, 2013 Permalink | Log in to Reply

      I am really enjoying MP6 so far but I found a bug in the css with Tinymce Split buttons. I wanted to share the fix so I wrote a post on it here:
      http://austinlowery.com/mp6-css-bug-with-tinymce-split-buttons/

      Is there a better place to file a bug report on this?

    • Ipstenu (Mika Epstein) 10:04 pm on November 6, 2013 Permalink | Log in to Reply

      Just ran into a layout ugly with Importers

      http://cl.ly/image/1n1i2d362A2I

      Does not happen on Plugin installs (the pop-in looks fine)

    • Rajesh Namase 12:07 pm on November 10, 2013 Permalink | Log in to Reply

      So nice, now users can choose different colors for dashboards. Font also looking nice,

    • keha76 8:03 am on November 13, 2013 Permalink | Log in to Reply

      I think that it’s an overall improvement that is really needed! But the admin menu feels unorganized without any menu dividers at all, a thin subtle gray 1px line would do it just fine.

  • lessbloat 7:40 pm on October 23, 2013 Permalink
    Tags: , , core plugins,   

    DASH – 3.8 proposal 

    Prerequisite: Must have latest version of MP6 installed and activated.
    Plugin link: https://github.com/growthdesigner/wp-dash

    Visual comparison

    The existing dashboard (the page you see by default when you log into WordPress) looks like this:

    It hasn’t been touched in years, leaving it feeling a tad bloated, and dated. Here’s what the dashboard looks like with our plugin enabled:

    What’s changed?

    We tackled 5 major areas, and made them each separate includes within our plugin (separate php, js, and css files).

    • We combined “WordPress Blog”, “Other WordPress News”, and “Plugins” to form the new simplified “WordPress News” plugin.
    • We merged “Recent Comments” into the new “Activity” widget, which now also shows you any scheduled posts and your most recently published posts.
    • We converted “QuickPress” into “Quick Drafts” putting the emphasis more on drafting ideas than publishing, and we merged in “Recent Drafts”.
    • We removed the “Number of columns” screen option. Instead the dashboard is now responsive, and shows the appropriate number of columns based on your screen resolution.
    • The Right Now widget was visually reduced.

    Here are a few extras:

    • We removed incoming links (which doesn’t seem to really work anymore).
    • We replaced the “Dashboard” H2 title with a fun group of friendly welcome text and idioms.
    • We added a bunch more hooks for greater extensibility from any of the dashboard widgets.
    • There’s a fun little smiley if you delete all posts and comments

    What problem is your feature plugin trying to solve?

    While functional, WordPress’ dashboard page hasn’t kept up with the rest of WordPress. We mean to improve the experience of the first page of WordPress. Streamline it, clean it up looking at all the widgets, and make it responsive.

    We’d also love to see future development in the new activity widget, where plugin developers can add more “activity stream” related content.

    What other potential solutions did you explore?

    If you work backwards through http://make.wordpress.org/ui/tag/dash/ you’ll get a pretty good idea. We met weekly in IRC, and brainstormed/iterated daily via our Skype channel.

    Have you done user testing?

    Nope, but if this get’s the “all clear”, we’re more than happy to do that.

     
    • Brandon Wamboldt 10:11 pm on October 23, 2013 Permalink | Log in to Reply

      Your GitHub link has no link in the href attribute and just points to the current page…

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

    • Louy Alakkad 10:24 am on October 24, 2013 Permalink | Log in to Reply

      Amazing, I like the idea. Except the H2 thing :)

    • portfola 5:21 pm on October 24, 2013 Permalink | Log in to Reply

      This is way cool, thanks!

    • memuller 6:18 pm on October 24, 2013 Permalink | Log in to Reply

      I’ve been testing this plugin on my WordPress network for a couple of weeks. I didn’t collect hard data, but I’ve heard a few things informally.

      Feedback has been, broadly, of three kinds:
      – people don’t notice the change unless it’s mentioned; but once they do, they’re happy about it.
      – people don’t notice the change, and are neutral about it – they think it’s not a significant improvement, or that they won’t use it anyway.
      – people notice the change, and are happy about it.

      I think that not noticing the change is an issue, but it’s hard to avoid that – most users in this installation are already “trained” to ignore the Dashboard, since it’s not useful for them (without custom widgets).

      Some users noticed the change due to the absence of the “Right Now” widget and its characteristic coloured numbers for comment status – apparently, they draw the eye more than I thought.

      It’s interesting to note that, once I started using MP6 in this same network many months ago, quite a few users mentioned how the dashboard looked “clunky” and outdated when compared to the much more modern interface.

      Overall, I’m quite happy with the results. I liked some of the initial ideas for this project a lot, but most of them were discarded in favor of a less groundbreaking approach – which was a good move (albeit a sad one); since the result now is a clear, faultless, solid and expansible improvement. It’s hard to argue against it.

      • lessbloat 6:49 pm on October 24, 2013 Permalink | Log in to Reply

        This feedback is amazing! Thank you for being so detailed/descriptive. I feel like you summed it up really well in your final paragraph. While I would have loved to have had some of that other stuff as well, I’m content to see this as a good stepping stone for even more awesome stuff down the line.

    • Eric Andrew Lewis 10:06 pm on November 3, 2013 Permalink | Log in to Reply

      The changes here all make sense to me.

    • demoman2k10 3:17 pm on November 22, 2013 Permalink | Log in to Reply

      Love all the changes please tell me someone is looking at an overhaul of the Plug-in… This is way outdated and would be great to have some better abilities to SEARCH Plug-in’s by Support for version, Newest and other methods. Would like to see it work and function more like one of the stores offered by Apple, Microsoft or Google even. A section for paid and free would be nice as well. As nothing is more frustrating then downloading something that doesn’t work unless you pay for it.

    • codel1417 1:36 am on November 25, 2013 Permalink | Log in to Reply

      the new dash which shows up in 3.8 beta 1 is now even more useless. at least an option to add multiple rss feeds to the dashboard in seperate boxes. i used the other wordpress news box but never cared for the wordpress updates box or the plugins and now its kinds forced apon me

    • allm 2:22 am on December 15, 2013 Permalink | Log in to Reply

      “We removed the “Number of columns” screen option. Instead the dashboard is now responsive, and shows the appropriate number of columns based on your screen resolution.”

      Well, the way it is build now does not feel like the appropriate number of colmns is chosen. If the admin-area shows up on a wide screen and there are only 2 active columns, I still see 4 columns. The 2 on the right are not used, and the 2 on the left are really narrow.

      Actually, if I decrease the width of the browser window to the point where there are only 3 columns my active columns are getting wider.

      I would propose either:

      . get the ‘number of columns’ screen option back
      OR
      . set the appropriate number of columns as is done now BUT NEVER MORE THAT THE ACTUAL NUMBER OF COLUMNS.

  • Matías Ventura 7:34 pm on October 23, 2013 Permalink
    Tags: , , core plugins, thx38   

    THX38 “Theme Experience” Overview 

    Re-imagine a theme experience that is beautiful, visually focused (able to display more/bigger screenshots), fast, and mobile-ready. Plugin url: http://wordpress.org/plugins/thx38/

    Initially we were covering themes.php and install-theme.php. Time and dev resources constraints forced us to focus the last few weeks solely on getting themes.php fully ready.

    Screen Shot 2013-10-23 at 5.18.19 PM

    Screen Shot 2013-10-23 at 5.18.29 PM

    Screen Shot 2013-10-23 at 5.18.44 PM

    Problem Solving

    Problems:

    • A very text and information heavy interface for something that is eminently visual.
    • Convoluted presentation of your current theme, your installed themes, and adding new ones.

    First user test with current admin interface showed the amount of time between arriving at themes.php and understanding what was going on (which themes are installed, how to add new ones, etc) was quite big, going to the install themes screen took them ages. In contrast, tests ran with the THX plugin showed us the interface was grasped very fast, and people got to the install themes page in a matter of seconds.

    Solutions:

    • Moved theme descriptions to a details overlay, and streamlined the presentation to its bare bones.
    • Removed tabbed interface and made adding new themes organic to the grid presentation.
    • Focused on perceived performance, made theme browsing and search faster, with a fully responsive design at all stages.
    • Added url triggers for opening specific themes, as well as arrow-keys navigation while browsing the detailed view.
    • Added basic support for multiple screenshots per theme, and bigger display.
    • Focus on the customizer as the primary action for your current theme.

    The installing themes screen was left as a prototype for the future.

    User Testing

    Early user testing clearly showed understanding and interacting with the screen is not easy. One user eloquently said, “I was thinking I would have a screen with a bunch of themes to look at.” For install-themes, filters proved to be hard to use paired with the fact the words users think of to describe themes aren’t present in the theme keywords we offer.

     
  • George Stephanis 5:11 pm on October 23, 2013 Permalink
    Tags: , , core plugins,   

    Omnisearch / Global Admin Search, Final Pitch 

    Plugin: http://wordpress.org/plugins/omnisearch/
    Diff: https://cloudup.com/cC6IbXxoHXN

    Previous posts:

    http://make.wordpress.org/core/2013/08/14/present-your-3-8-feature-idea-at-tomorrows-meeting/#comment-9948

    http://make.wordpress.org/core/2013/08/30/omnisearch/

    http://make.wordpress.org/core/2013/10/08/omnisearch-user-testing/

    IRC chats in #wordpress-core-plugins:

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-08-30&sort=asc#m21304

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-12&sort=asc#m23506

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-19&sort=asc#m24911

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-26&sort=asc#m25942

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-10-10&sort=asc#m27386

    We were a small, but scrappy group. It was mostly myself, @japh, and @lessbloat.

    Omnisearch currently adds three ways to search.

    • A Dashboard Widget:
      Omnisearch Dashboard Widget
    • An admin page under the Dashboard:
      Omnisearch Admin Page
    • And as a search box on  the adminbar — when you’re on the admin side of the site:
      Omnisearch Admin Bar

    All three turn up the same results page:

    Omnisearch Results Page

    And all is happy with the world.

    We were trying to solve the proliferation of different search forms for different data structures in the admin.  When trying to find content, it’s inconvenient and difficult to always navigate to the right data structure and then search it — especially if you’re unsure if something was in a comment or a post (all too frequent in p2s)– and you just want to pull in all relevant results.

    Other things we’d considered were potentially adding an Alfred-like pop-up modal where you could enter omnisearches, and see results from the menus on the page that happen to match — very much like WP Butler’s current functionality.  We opted not to add it in this pass, though, figuring better to keep a slimmer implementation.

    Our user testing confirmed that this was a definite win.  In fact, the user even remarked that there should be a centralized search when we had them running through the initial steps where they were to search each data structure independently, before activating Omnisearch and seeing how that compared.

    We’re eager to hear any feedback on code, methods, or even name.  I’ve had some people mention that they’d prefer it have a less ‘marketing’ name, and more of a generalized “Global Admin Search”.  I prefer Omnisearch for brevity, but would love to hear some discussion on the pros and cons of whether it would be better to use a more general name.

     
    • Andrew Nacin 6:43 pm on October 23, 2013 Permalink | Log in to Reply

      My suggestions on UI: The search tool in the toolbar is very likely sufficient placement for this. Drop the dashboard widget and the menu item. Add a “Search everywhere” link to each individual search results page in the admin, next to “Search results for “%s”. There’s no reason to force this onto people — just let it be naturally discovered in times of need.

      If no results are found for a section, it may be okay to omit that section entirely, rather than showing an empty table and taking up 100+ vertical pixels. If no results are found at all, it could just be a simple single line of feedback, rather than scrolling through a bunch of empty tables.

      Is the “Search Pages” button/link helpful? They see all of the results here (presumably with pagination). Maybe clicking the name of the section should take them to that particular page (with the search conducted) to allow for filtering and such. Otherwise, it seems like clutter.

      I see that plugins is searchable, along with posts, pages, and media. What about themes? Custom post types? Taxonomies? Settings? Importers? Admin screens & keywords? Etc. (A lot of this came up with @markjaquith was kicking around this exact idea a year or two ago.)

      My suggestions on naming: simply call it “search”. When discussing it in code, call it an admin search or the dashboard search or whatever. “omnisearch” sounds like (and, in Jetpack, is) a gimmicky product name. There’s no need for a tagline. “Search” is a pretty natural and common feature; let it speak for itself.

      Will note that comments are also searched on P2s. Would be more interested in hearing additional use cases for this. I think a lot of it comes down to increasing uses of custom post types. As of right now, since it only supports posts/pages/comments/media/plugins, it’s not really “everywhere” yet.

      I think the feature implementation is pretty close for core — certainly could be smoothed out over the course of a merge.

      • George Stephanis 7:25 pm on October 23, 2013 Permalink | Log in to Reply

        My suggestions on UI: The search tool in the toolbar is very likely sufficient placement for this. Drop the dashboard widget and the menu item. Add a “Search everywhere” link to each individual search results page in the admin, next to “Search results for “%s”. There’s no reason to force this onto people — just let it be naturally discovered in times of need.

        Good call. Depending on how DASH goes, if it ever migrates to a fixed column of static stuff like in this older mockup, it may be worth including this there as a search field. The primary reason for all the avenues was to have them available, then pare them down in the merge.

        Agreed on sacking the widget and probably the menu item. I’m not sure if it would make more sense to have the menu item there if you’re on that page at the time, but hide it if you’re not? Or if that would be confusing from a UX perspective.

        If no results are found for a section, it may be okay to omit that section entirely, rather than showing an empty table and taking up 100+ vertical pixels. If no results are found at all, it could just be a simple single line of feedback, rather than scrolling through a bunch of empty tables.

        I’d prefer the line of feedback, it might play nicer with results sections that load in results after dom.ready via js for latency reasons.

        Is the “Search Pages” button/link helpful? They see all of the results here (presumably with pagination). Maybe clicking the name of the section should take them to that particular page (with the search conducted) to allow for filtering and such. Otherwise, it seems like clutter.

        Actually, just to keep it short, it only displays the first five results (adjustable via a filter) (and possibly would be wise to have customizable in Screen Options). To dig deeper into a given section they need to click the link for that specific section. This also avoids a large degree of confusion as to results page refreshes when paginating — which list table is it paginating? They all use the same query argument!

        A potential down-the-road enhancement would be to enable pagination via js on specific tables, but for the moment, it’s just capped at five.

        I see that plugins is searchable, along with posts, pages, and media. What about themes? Custom post types? Taxonomies? Settings? Importers? Admin screens & keywords? Etc. (A lot of this came up with @markjaquith was kicking around this exact idea a year or two ago.)

        Themes could be, I excluded it initially, as it seemed to me to be a much more infrequent task.

        Custom post types aren’t included by default, as they can have such disparate data structures, that forcing them into a single custom list table may not end well. They’re easy to include, though, like so: https://gist.github.com/georgestephanis/6926206

        Taxonomies, settings, and importers are all feasible, this is just the baseline that was felt to be most useful to the most people, while still keeping the UI reasonably simple. We could always offer them, but have them hidden by default in Screen Options. If that’s the consensus, I’ll add them in.

        My suggestions on naming: simply call it “search”. When discussing it in code, call it an admin search or the dashboard search or whatever. “omnisearch” sounds like (and, in Jetpack, is) a gimmicky product name. There’s no need for a tagline. “Search” is a pretty natural and common feature; let it speak for itself.

        Maybe Global Search then. There’s so many searches in the admin already, that a ‘Search’ label without context could be more confusing than helpful.

        • Raam Dev 7:32 pm on October 23, 2013 Permalink | Log in to Reply

          Maybe Global Search then. There’s so many searches in the admin already, that a ‘Search’ label without context could be more confusing than helpful.

          I also vote for ‘Search’. Putting ‘Search’ on the Dashboard tab provides the necessary context and helps indicate that we’re not searching any one particular section but rather the whole site.

    • Sam Sidler 6:48 pm on October 23, 2013 Permalink | Log in to Reply

      A few questions:

      • What was the rational for putting Omnisearch under “Dashboard” in the admin? Not saying it’s the wrong place, just curious if other places might make more sense, especially since it’s permanently located on the top right of the admin interface.
      • Why only show the search box when you’re on the admin side? Other than “Edit Post”, it would be the only thing that changes between admin side and not.
      • Related: Why show the entire box instead of just a search icon? Whoops, I realized I misunderstood this. :)
      • Does this search custom post types? I’d take off the “search everything” tagline if it doesn’t search literally everything.

      Otherwise than those questions, looks like good work. I’m on the side of Omnisearch being a bit too gimmicky, but would love to hear what others think.

      • George Stephanis 7:32 pm on October 23, 2013 Permalink | Log in to Reply

        RE: under Dashboard in the admin, it’s legacy that I worked up initially. In Jetpack, it’s under the Jetpack menu item, but when merging it into WPCOM, I didn’t have that available, and put it under Dashboard. I’m not particularly attached to it, and would be happy to drop it from the menu as mentioned above.

        RE: why only the admin side, that was because the search in the admin bar is already there on the front-end, and I didn’t want to change that form’s behavior. If other folks would rather have adminbar search be Omnisearch at all times, I’m fine with that as well — we’d just need a fallback or capability check if logged out users had it displayed to them.

        RE: CPTs: It can, I had just intentionally left them off initially due to the disparate data structures they can represent, with the bulk of it potentially in postmeta — I wasn’t sure how well it would search them, and if displaying them in the list table would look in any way reasonable or representative of what they’re storing.

        • Sam Sidler 7:53 pm on October 23, 2013 Permalink | Log in to Reply

          RE: why only the admin side, that was because the search in the admin bar is already there on the front-end, and I didn’t want to change that form’s behavior. If other folks would rather have adminbar search be Omnisearch at all times, I’m fine with that as well — we’d just need a fallback or capability check if logged out users had it displayed to them.

          It feels like strange behavior for the search icon in the admin bar to have two different behaviors, depending on the view. I’d be interested to see what user testing would say on that. Easy enough to change anyway.

          RE: CPTs: It can, I had just intentionally left them off initially due to the disparate data structures they can represent, with the bulk of it potentially in postmeta — I wasn’t sure how well it would search them, and if displaying them in the list table would look in any way reasonable or representative of what they’re storing.

          I think they should get included, but you said above (and showed!) that it’s not hard to add. Perhaps we can wait for feedback post-merge.

    • Bryan Petty 7:20 pm on October 23, 2013 Permalink | Log in to Reply

      As far as the admin bar search goes, what are your thoughts about the fact that there is already currently a search bar on the admin when browsing the frontend on a site, which pulls up the regular search results page on the frontend. I know you’ve stuck with keeping the search on the frontend the same as it is now, but do you think that behavior should change for an admin/editor/author? How might that be affected by roles and capabilities?

      @sams Does your theme you tested with this not have search?

      Also, not just “gimmicky”, but I think calling it “Omnisearch” instead of just “search” is actually detrimental once it’s considered the official built-in search functionality (as opposed to begin able to identify it as an add-on provided by Jetpack).

      Also, I get this fatal with the plugin (with *multisite* WP trunk):
      “Fatal error: Call to undefined function wp_is_mobile() in /home/bryan/Projects/wordpress/src/wp-content/plugins/omnisearch/omnisearch-core.php on line 14″

    • memuller 5:11 pm on October 24, 2013 Permalink | Log in to Reply

      About the name, I think just “search”, as nacin suggested, might work.
      @georgestephanis, while I agree that it may be confusing given the presence of many “search” functionalities, I believe that’s an issue with the other search functionalities, not with this one. Since this search will be the de-facto admin search – that is, it will be enough in most cases – it makes sense for its name to be just “search”. The “global” here is unnecessary – the name “search” should be reserved to the most general and useful case possible, and this plugin is that case. Aditionaly, “global” implies the existence of more types of search – which is the case, but the user does not need to be exposed to that confusion so early.

      The issue, them, is to make sure that all other search functionalities are named differently; that all instances of “[custom post name] search” or “theme search” are always named in such way as to make clear that they are more limited in scope or functionality.

      Omnisearch is inadequate for the same reasons – the name won’t be a selling point for this feature, so a descriptive, simple name wins. That name would – for example – be a pain to I18N teams.

      Otherwise, this is awesome – it will greatly help finding stuff in huge sites; and the API for including custom posts is looking good. I really hope to see this on 3.8.

    • George Stephanis 9:01 pm on October 24, 2013 Permalink | Log in to Reply

      Okay, got two changesets in just now.

      http://plugins.trac.wordpress.org/changeset/793194/omnisearch
      http://plugins.trac.wordpress.org/changeset/793196/omnisearch

      To-accomplish yet, based on feedback from above:

      • Drop the table output from empty result sets.
      • Add in the links to “search globally for %s” to the end of the normal archive tables when a search has been performed.
      • ???

      Current version is 0.9, installable from http://wordpress.org/plugins/omnisearch/

    • Gregory Cornelius 7:35 pm on October 27, 2013 Permalink | Log in to Reply

      Nice work.

      I wasn’t exactly sold on the idea initially, but seeing the search a bit more tightly integrated with the admin UI instead of just hanging out under Dashboard, its potential is starting to emerge. UX-wise I sorta wish that the results were more unified and less of a direct reflection of the data schemas. Perhaps, all post-like content could be combined into a single group in a manner not unlike how search results are handled in the Link modal in the visual editor. It would also be nice if the results could be re-ordered by clicking the table headings or maybe even experiment with removing the headings.

      Thinking about the search field, I wonder if some sort of autosuggestion of results built from matches on post titles across post types with a “Show All Results” link at the top of the list. This would make the dashboard feel a lot more responsive for power users that are used to using search tools like Spotlight, Alfred, Quicksilver, or even the new Window 8 thingy. Eventually, I could even imagine the results including the results from the content of the various admin screens, especially the settings. It would be kind of neat if searching “Disable comments” included a link to the Discussion Settings.

      Maybe the search bar could also be integrated into the new DASH dashboard if/when that component is integrated. And, as the tool becomes more refined and useful, I think it would be nice if the field somehow became a bit more prominent in the admin bar. At the very least, it would be nice if the animation to open the field was a lot faster.

    • George Stephanis 8:37 pm on October 27, 2013 Permalink | Log in to Reply

      Just upped the plugin again. Posts/Pages are now decended from the WP_Posts_List_Table class, which lets a lot of stuff like custom columns and displaying taxonomies work out of the box. I’m about to auto-include custom post types as well, if their UI is exposed in the admin.

      Also switched it so it displays a blurb, instead of an empty table, if there’s no results. Also skips the link to search that data type in more depth if there was no results.

    • sandeepbagchi 7:48 am on October 31, 2013 Permalink | Log in to Reply

      Is it possible to add filters for searching?
      Date Search: “Search To And Search From”
      Search In Category: dropdown with multiple selection
      Search In Posts or Search In Pages or Search In Available Custom Post Types (drop down with multiple selection)

      After taking all the inputs a query can be formed to refine the search?

    • Sarah Gooding 8:02 pm on November 11, 2013 Permalink | Log in to Reply

      Is it possible to include an auto-suggest while typing and load results via AJAX instead of whisking the user away onto another page – similar to how it’s done in the http://wpjarvis.com plugin (see demo on that page)? This seems like a more elegant implementation. I understand that there’s a lot of data to show in the results but if there was any way to make it more compact I think the experience would be improved. Of course, I may be missing a lot of the complexity involved here…

  • samuelsidler 11:27 pm on October 22, 2013 Permalink
    Tags: , core plugins   

    Preparing your feature for the 3.8 merge 

    Now that 3.7 RC has shipped – and the final release is coming soon – it’s time to talk a bit more about how merging to core will work for feature plugins. First, let’s talk about decisions.

    Decisions

    I’ve been asked a few times “who decides” what goes in core and variants of that question. There’s actually three decisions that need to get made. In order:

    1. Does the feature belong in core?
    2. Is the feature ready for core?
    3. Should the feature be in this release?

    Core contributors and members of the community are strongly encouraged to help inform and guide each of these decisions. You may even want to offer some of your feedback in the form of answers to these questions. Each question is ultimately answered by a different group.

    1. Project leaders determine if a feature belongs in core.
    2. Contributing developers determine if a feature is ready for core.
    3. The release lead – for 3.8, @matt – determines if a feature belongs in a particular release.

    We’re now at the point where these questions need to get answered. To do that, it’s time to present your feature plugins.

    Present Your Feature

    If you remember back when we first started the feature plugin process, each team had to present its feature idea and answer a few questions. We’re going to do that again, but with a bit more information. If your project thinks it’s ready for core – and specifically for 3.8 – your team lead should make a post to make/core with the following information:

    • A visual and written overview of your feature plugin, along with a link to your plugin.
    • What problem is your feature plugin trying to solve?
    • What brought you to this solution and what other potential solutions did you explore?
    • Have you done user testing of your feature plugin? If so, what were the results? What worked and what didn’t?

    In your post, be sure to include links to previous posts and even specific comments that have helped form your decisions.

    Be ready for feedback from across the WordPress community – especially UX and code quality  – and be ready to defend your decisions or change your mind if a better idea emerges. Everyone will be reviewing the make/core posts and feedback in their discussion threads to determine if the answers to the questions above are all “yes”. If so, the feature can land when the merge window opens.

     
  • samuelsidler 7:15 pm on September 30, 2013 Permalink
    Tags: , core plugins   

    Making preparations for 3.8 

    As mentioned previously, 3.8 development officially opens shortly after 3.7 ships. With the first beta of 3.7 behind us and the final release scheduled for mid-October, it’s time to talk about what’s expected of feature plugins.

    @nacin mentioned at last week’s dev chat that 3.7 will likely branch at the WordCamp Europe contributor day, on October 7. At this point, most core developer focus will be on shipping 3.7. However, feature plugins that want to be considered for 3.8 should be ready by October 14 to give everyone time to review them.

    What does being ready mean? Here’s what will be examined:

    • a strong and well-tested user experience
    • fully-baked design
    • positive feedback from the community
    • core-quality code
    • no major bugs or issues
    • a belief that the feature belongs in WordPress core

    Some of the above is subjective and will vary from feature to feature. If you have questions, look to a lead developer for guidance.

    Of the feature plugins listed, the furthest along are MP6 and global admin search, with Dash not far behind. Plugins in the “feedback” stage should be prepared to answer the question “Why should we include this in core?” As of today, they should prepare their code for core, removing anything unnecessary and making the feature into a patch that can be easily merged with core.

    tl;dr

    • Feature plugins wanting consideration for 3.8 should be ready for presentation and inclusion by October 14.
    • Feature plugins will undergo review shortly after 3.7 ships.
    • Plugins must be ready to merge when the merge window opens.
     
    • Weston Ruter 7:24 pm on September 30, 2013 Permalink | Log in to Reply

      We’ve also been making great strides with the Widgets UI Refresh, specifically with the customizer integration (from my perspective). The plugin project for this is Widget Customizer, and development is happening on GitHub. I’m hoping that we’ll have the remaining issues addressed by October 14th.

      /cc @shaunandrews

      • Bryan Petty 8:06 pm on September 30, 2013 Permalink | Log in to Reply

        Hi Weston, it appears like the widgets team working on this decided to switch the plugin being used for development on this effort entirely just 6 days ago… this shouldn’t happen honestly. If your team has decided on a direction to go in, it should be integrated back into the officially tracked plugin as listed on the core plugin tracking page.

        That aside though, it’s usually a good sign that the plugin is not really “ready for core” when major decisions like that are being made even in the last week here. Nothing new there has had time to be discussed, tested, and generally baked – and it’s really hard to get that feedback when development isn’t even being done on the official plugin where it’s supposed to be.

        • shaunandrews 11:57 pm on September 30, 2013 Permalink | Log in to Reply

          We haven’t switched. We’re developing multiple concepts and testing them simultaneously.

          That being said, I don’t think we have (or will have) “a strong and well tested user experience” by October 14.

        • Weston Ruter 5:28 am on October 1, 2013 Permalink | Log in to Reply

          OK, thanks. I’m obviously over eager. Sorry to jump the gun.

    • Jonatan Santos 8:32 pm on September 30, 2013 Permalink | Log in to Reply

      One point that could be seen would be a button to turn the text to uppercase and minuscule vise versa in menu text editor

      • Mark-k 3:43 am on October 1, 2013 Permalink | Log in to Reply

        As far as I know non latin langs, which are used by more people then latin ones, don’t have uppercase/lowercase distinction, therefor IMO this kind of feature should not be in core

    • Mufasa 4:22 am on October 2, 2013 Permalink | Log in to Reply

      It’d be really great if there was a way to collapse menus in 3.8 (or 3.7). If you look at the following image you can see that in order for me to drag the menu at the bottom to the top I have to do quite a lot of dragging.

      If I could collapse the encyclopedia menu so that I can’t see all those children it would be useable… well if the page didn’t grind to a halt with that many menu items it would ;)

      So I was thinking you could either have a button to collapse them OR when the user starts dragging they close. Which is something we executed in another app and its quite nice to use. I’ve thought the same UI would be nice on the widgets admin page too.

      Thoughts?

      Menu Pain: http://files.kiwijs.org/dan/arghhh.jpg

      • Sam Sidler 5:01 am on October 2, 2013 Permalink | Log in to Reply

        I’d recommend filing a ticket (perhaps there’s already one on file). Fixing that in the way you suggest isn’t something that would be covered by a feature plugin, though there was a (now on-hold) proposal for merging pages and menus.

  • samuelsidler 6:12 am on August 27, 2013 Permalink
    Tags: , core plugins   

    Features, Plugins, and WordPress 3.8 

    At the dev chat last week, we talked a bit about WordPress 3.8 and the features-as-plugins process. Here’s a recap of what was discussed:

    Expectations

    A lot of features are in development right now, at varying stages. Given the huge list of new features, there’s no way they’ll all be in WordPress 3.8. That’s okay, and it’s by design.

    The features-as-plugins model makes it easy to wait for a feature to be ready before including it in a release. It also allows for a lot of experimentation. Some ideas might not otherwise be developed into potential features, while others are large and complex, and might take multiple cycles to complete. But experimentation can lead to a fully scoped or even fully developed feature that never makes it into core because, after hashing out the details, it’s realized it isn’t something that belongs in core. Don’t let that discourage you — trial and error is part of the process and will result in better features and a better WordPress. Features that don’t get included in core can continue to live on as awesome plugins, and the whole ecosystem benefits. In the past, the core team would have suggested that a feature start as a plugin anyway; this formalizes that process.

    Ultimately, the decision on whether a feature makes it into core rests in the hands of the core team. To ensure you’re on the right track, keep in contact with the next release’s lead and the lead developers. The release lead should understand what problem you’re trying to solve and why the direction you chose is the appropriate one to solve that problem.

    Timeline

    For features to be included in a release, they must be ready for the release’s first meeting — that is, day one when the development period begins. At that point, the release lead will review current projects, and along with core developers, determine if they’re fully baked and ready for merging into core.

    They’ll be looking for a number of things, including a strong and well-tested user experience, fully-baked design, positive feedback from the community, core-quality code, no major bugs or issues, and a belief that the feature belongs in WordPress core. Every feature is different, so “ready” will mean different things depending on the specific feature, but a release lead must feel comfortable taking on primary responsibility for a feature and the core team must be comfortable taking on responsibility for the long term.

    If the core developers decide a feature isn’t ready for core, they’ll let the feature lead know why and what can be done to prepare the feature for a future release.

    Features that have been approved for inclusion will have a merge window of about two weeks (timeline still being decided) to get their code into core and wrestle with any latent issues getting it merged. However, as stated above, features must be ready for merging at the start of the merge window.

    Who’s responsible for features?

    After a feature gets merged into core, the feature team remains responsible for the feature, with added support from the core team. As with any part of WordPress, feedback comes from the entire community. However, after merging into core, a feature will receive a lot more visibility than in the plugin phase. Focus is important to ensure the feature ships.

    Keep in mind that while the team remains responsible for the feature in core, ultimate decision-making rests in the hands of the core team, as with any part of core. The release lead will obviously work closely with the feature lead and entire team.

    tl;dr

    • Sometimes features won’t end up in core. That’s okay! Not everything belongs in core. It’d still be a great, community-built plugin that helps to improve the ecosystem. Maybe it serves as a prototype, or lessons learned, or even a base for a future initiative.
    • Don’t expect your feature to make it for 3.8. These are features being built with the potential for inclusion in a future version of WordPress. They are not “3.8 features.”
    • To be included in 3.8, features must be “ready,” as defined by the core team, at the start of 3.8 development, shortly after 3.7. Be sure to keep in close contact with the release lead.

    Questions? Comments? Ask away!

     
    • Tom Auger 1:43 pm on August 27, 2013 Permalink | Log in to Reply

      I’m having trouble wrapping my head around features-as-plugins for one specific reason: many of the features we want to roll out require core modifications! How do you implement big changes to the way, for example, the Media Library or the Widgets work, without requiring changes to core, whether it’s additional hooks, or complete rewrites of certain sections?

      I may have missed something important here, but are we allowed to submit plugins that have core patches as required components?

      • Andrew Nacin 9:39 pm on August 28, 2013 Permalink | Log in to Reply

        I think this is a great question. Essentially, our plugin architecture is so rich that it’s really easy. On occasion, a team may “fork” a JS or CSS file (don’t try this at home), or override an entire admin screen. There is also a procedure in place now for the leaders of these teams to ask a lead developer for a temporary hook as necessary. Basically, we don’t see this as much of an issue, especially since these plugins are going to be developed against trunk. Once the merge begins at the start of a release, we’ll massage things as necessary to make sure it is as much a part of core as it should be. But, it should be mentioned, a substantial amount of core just hooks into itself as if it is a plugin, including many newer features.

  • Konstantin Obenland 6:59 pm on August 16, 2013 Permalink
    Tags: , core plugins,   

    Featured Content Office Hours 

    As my last task as acting lead for Featured Content, I’m happy to announce our first IRC chat on Monday, 1700 UTC in #wordpress-dev, led by @wonderboymusic.

    We will talk about the project organization and intended functionality for the plugin (on a high level!). Goal of the meeting is that everyone has a clear understanding of where the project is headed, what the next step in the process will be, and who is working on that.

     
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