Make WordPress Core

Updates from Samuel Sidler Toggle Comment Threads | Keyboard Shortcuts

  • Samuel Sidler 2:32 pm on April 25, 2015 Permalink |

    WordPress 4.1.3 Released 

    Shortly after we shipped WordPress 4.2, we shipped WordPress 4.1.3 to fix an issue caused in WordPress 4.1.2.

    Specifically, WordPress 4.1.3 fixed database writes for esoteric character sets, which were broken in the WordPress 4.1.2 security release. However, neither UTF-8 nor latin1 were affected. More information on this issue can be found in #32051.

    Additionally, we shipped WordPress 4.0.3, 3.9.5, 3.8.7, and 3.7.7 to fix the same issue on other branches.

  • Samuel Sidler 8:13 pm on September 16, 2014 Permalink
    Tags: ,   

    Feature Plugin Chat on September 23 

    Last week we mentioned holding a feature plugin chat today, but that didn’t happen. Let’s have it next week on September 23 2014 20:00 UTC.

    We’ve done this before, but just to recap…

    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.

    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 are 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!

    • Nikola Nikolov 10:08 pm on September 16, 2014 Permalink | Log in to Reply

      The meeting is going to be held in #wordpress-dev channel right? I’m adding the time & date to my calendar :)

    • Caspar 5:35 am on September 17, 2014 Permalink | Log in to Reply

      Added to calendar, thx!

    • Peter Luit 7:35 am on September 17, 2014 Permalink | Log in to Reply

      In general the installation of plugins will have to be done on a site-by-site base. It would be very nice to have the possibility to have pre-defined sets of plugins for certain applications. Now we can just ‘favorite’ a plugin at wordpress.org, in others words ‘you make one set’. Would it be a nice idea to be able to make more sets?

      It could be done in wordpress.org, but it would also be great to have one plugin-installer (as a plugin) in which you can choose one of your own pre-defined sets and then download them all…..

      I am sure the WordPress community would love such a feature.

      Kind Regards,

      Peter Luit
      The Netherlands

    • Siobhan 1:13 pm on September 17, 2014 Permalink | Log in to Reply

      Image Flow is a project focused on improving the the image editing experience in WordPress.

      Current status: UX and wireframes
      Already involved: siobhan, @mor10, @sonjanyc, @markoheijnen, @dh-shredder, @pablo-perea, @edwerd, @klosi, @teamadesign (also less active ppl in the chat room and lots of feedback from people on the UI blog – apologies if I’ve missed anyone).
      What we’d like help with: development (particularly JS), ui design, research, labelling, testing

      • Ryan Boren 12:59 pm on September 18, 2014 Permalink | Log in to Reply

        You know how desperately I want to improve media flow. I’ll be around for research and testing, particularly on mobile.

        Usability as a feature. A featured flow for each release. Each screen of that flow and every tap and click gets attention, on all devices and across all interfaces. 4.1: Starting on your blog’s home page, create and publish a captioned gallery of edited images.

      • Andy Mercer 1:24 pm on September 22, 2014 Permalink | Log in to Reply

        Given that we have Featured Images, would anyone else be interested in the concept of Featured Galleries? Being a metabox, like the Featured Img metabox, which would allowed a user to select multiple images, and be called in a theme template the same way?

    • Nick Halsey 5:08 am on September 18, 2014 Permalink | Log in to Reply

      I have a class during the meeting, so I won’t be there. But I’d like to officially introduce the Menu Customizer as a feature-plugin seeking contributors.

      Menu Customizer is my GSoC Project that I’d now like to build out as a feature-plugin with the help of anyone else who’s interested. The goal is to merge navigation menus into the Customizer. Ideally, this should be done in a feature-complete and backwards-compatible way that allows the mess that is nav-menus.php to go away entirely for users who have access to the Customizer. In addition to leveraging the live-previewing framework that the Customizer provides, this project seeks to improve the user experience of menus as well as fixing several significant technical issues with the current implementation (particularly, scaling). The project is similar to the Widget Customizer project that landed in 3.9 in many ways.

      Current plugin status: development. The plugin is mostly functional, implementing the entire menu-management experience in a Customizer panel and allowing menus to be live-previewed. However, significant work remains to make things scale even better, improve the add-menu-item experience, improve the handling of sub-menus, and make menu-addition and deletion work more smoothly. Many improvements to WordPress core have already come out of this project, including the panels API, and those will need to continue before the plugin is ready to be merged (in particular, for 4.1, #29572 and #28709).

      To date, I’m the only developer working on the project, per GSoC regulations. But the project is now officially open to contributions. I’m in the process of getting set up on plugins trac with @samuelsidler and will be scheduling weekly meetings soon. @ethitter and @obenland are also familiar with the project, as they were my GSoC mentors.

      We need help with the following: development, particularly some JS-heavy components, but also on the PHP side. UI/UX, workflow research, and user testing. Changing the relationships between pages/posts and menus is not in scope, but for the first iteration we’d like to offer a much-improved UI/UX that fixes many issues with the current workflow. This particular project requires significant dev work regardless, which is why formal UI/UX work is happening mid-development. If you’re interested in helping out in any way, please leave a comment here or say something at the meeting (I’ll read the logs), and we can try to schedule the weekly meetings at a time that works for everyone.

    • Aaron Jorbin 9:17 pm on September 22, 2014 Permalink | Log in to Reply

      WP Session manager is a UI around user sessions. We aim to provide users with controls on the user profile screen and user editing screen for managing logged-in sessions.

      Current Status: Under development at https://github.com/johnbillion/wp-session-manager

      Current Team: @johnbillion, @DrewAPicture, @nacin, @jorbin

      What we want help with: Development, design (our UI/UX is currently functional and inline with core, but can always be improved)

    • M. Gage Morgan 11:38 pm on September 23, 2014 Permalink | Log in to Reply

      I think we should bring the post formats UI back again, this time with the new steps added to the process (3.6 “Oscar”).

      Current Status: Needs extracted from the old core files, we’d need somebody to do that. Still in the technical “idea stage.”

      Current Team: Myself, as a student, plus anyone who would be willing to volunteer.

      What I Need Help With: Porting the old files to WP 4.0.(Plus plugin development, I’m new here.)

      • Samuel Sidler 11:40 pm on September 23, 2014 Permalink | Log in to Reply

        There was some interest in this previously, but I’m not sure there’s enough to get it off the ground. If you’re willing to work on it, feel free. Things will have to be quite a bit different for it to be incorporated into core, so keep that in mind. I’d recommend starting from scratch design-wise, going through the steps that the Image Flow team is doing.

    • M. Gage Morgan 12:34 am on September 24, 2014 Permalink | Log in to Reply

      I would think it’s more than possible to do, but it would likely not be ready by 4.1, rather 4.2 or 4.3. I’ll try to work when I can, but scheduling is complicated.

      • Samuel Sidler 12:36 am on September 24, 2014 Permalink | Log in to Reply

        Keep in mind that feature plugins aren’t targeted at specific releases. Inherently they’re flexible and can ship when they’re ready. It’s also possible that a feature plugin never gets into core. That’s fine too. Experimentation is good.

    • Daniel Bachhuber 10:20 pm on September 29, 2014 Permalink | Log in to Reply

      A pretty consistent problem I run into is shortcode UX. Specifically:

      1. Remembering what shortcodes are available to a given site.
      2. Remembering what attributes each shortcode supports.
      3. Preview disconnect (shortcode ain’t WSYWIG)

      It would be neat to have UX in WordPress for selecting from available shortcodes, filling out required vs. optional attributes, and TinyMCE preview framework for registering a display callback for a shortcode.

      I’d be interested in working on this. I’d be best supported with UX help. And I’m pretty curious as to why this problem hasn’t been solved yet (e.g. what big gotchas we’re going to run into).

  • Samuel Sidler 4:37 pm on April 28, 2014 Permalink

    Feature Plugin Chat tomorrow 

    As mentioned at the dev chat last week, we’re having a feature plugin chat tomorrow, April 29, 2014 20:00 UTC in #wordpress-dev. That’s the same time, same place as the dev chat on a different day. (The dev chat will take place on Wednesday, like normal.)

    Just like we did before, post your feature ideas here in one comment 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).

    Again, 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.

    We’ll go through current feature plugins at a brisk pace, then talk about the new ones that are forming.

    See you tomorrow!

    • mttktz 6:38 pm on April 28, 2014 Permalink | Log in to Reply

      I think WordPress lacks a feed reader.

      If you look at the most popular new blogging platforms: Facebook, Twitter, Tumblr, etc, they all have a way for you to see what others are writing and then re-blog or re-share that info. It’s a key feature that lets people communicate with each other. I’d like to see WordPress do this well, to have a feed reader integrated into the admin site with the ability to blog and comment on what you are reading in the world. It’s a feed reader with integrated “PressThis!”

      I’ve made a rough edged version of this plugin that works and people have started using it without me promoting it at all.
      See: http://mattkatz.github.io/Orbital-Feed-Reader/

      It’s just me working on it so far.

      I’d love help with design and development. Any advice appreciated – I think this is a big feature for WordPress-as-blog rather than WordPress-as-CMS.

      • Tomas Mackevicius 3:03 pm on May 1, 2014 Permalink | Log in to Reply

        Good idea! Are you using internal SimplePie library to produce the feed? I noticed that if it takes a bit more time to get the complex feed (I was trying to parse Yahoo Pipes feed), SimplePie would render an empty page with an error message :(

    • Ryan McCue 3:12 am on April 29, 2014 Permalink | Log in to Reply

      The JSON REST API is marching towards 1.0, with all the pieces beginning to fall into place. We want in on 4.0, and we’re determined to merge this cycle. :)

      For anyone who hasn’t seen the project, we’re working on providing a JSON-based API to access all your data in WordPress. Work on the project is happening over on GitHub, and we chat about the project over on our o2.

      We’re always seeking people to help, and we’d especially love some designers to help out with some UI pieces. If anybody’s using the API, we’d also love to hear about that and your experiences with using it!

      (I’ll endeavour to be present at the meeting tomorrow, however if I don’t make it, Rachel Baker will be present on the team’s behalf.)

    • Manny Fleurmond 3:58 am on April 29, 2014 Permalink | Log in to Reply

      I know the that the last time the post formats feature was proposed to get an overhaul there were kinks and setbacks to be had. My proposal, which might be a bit controversial, is this: instead of post formats being lumped together with the main post type, I believe they should be split up into their own post types.

      I wrote a blog post a few months ago about this a few months ago but to sum it up: I think post formats are an arbitrary distinction that causes confusion to WordPress users. They are technically types of posts, so why can’t they be post types? My proposed set of features is as follows:

      1. The ability to allow individual formats to be enabled/disabled
      2. The ability to allow individual formats to be included or excluded from the main loop.
      3. Rework the quickdraft meta box on the dashboard to allow the choosing and quick posting of different post formats, using some of the old code/interface from the last attempted redesign
      4. They should be extensible, via the new meta field initiative
      5. Stricter definitions of said post formats.

      I’ve only done some brainstorming, specifically with the more media based formats, which I plan to enhance via some of the new media modals now available since WP 3.9 (audio, video and playlists). That being said, I would love feed back in planning and developing such a plugin. I think that this would help make post formats a lot more accessible and less confusing.

    • trishasalas 12:24 pm on April 29, 2014 Permalink | Log in to Reply

      Admin Help is in the initial stages of project scope and planning. Our goal is to make the WordPress Admin area easier, and more intuitive to use and to hopefully reduce the attrition rate in the process. The focus is on the existing Admin Help documentation with the knowledge that it could be completely re-written or morphed into a more intuitive UI. The idea of a tour has been mentioned many times in the past, but we are beginning with user testing to make sure that we solve the correct ‘problem’.

      We are currently in the planning stage doing user-testing, personas, storyboards and discussion. Project scope is also a focus because we want to keep the initial idea at a manageable level (i.e. we do *not* want to re-do the entire admin area!)

      Those currently involved include myself (@trishasalas) and @clorith as co-leads, @jazzs3quence, @ubernaut, @brainfork and @jerrysarcastic. @designsimply is helping with user testing.

      Our biggest need is to have more people familiar with user help/user support and those who are familiar with UI/UX design. The more input we have during the initial planning stages, the more successful we’ll be.

    • Svetoslav Marinov 12:58 pm on April 29, 2014 Permalink | Log in to Reply


      Plugin: Orbisius Quick Nav
      Info: This plugin allows you to quickly switch between pages, posts, or any other custom post types from a dropdown.
      Status: up and running at https://wordpress.org/plugins/orbisius-quick-nav/
      Who is involved: just me (but I am both using my personal and company WP accounts)
      Need help with: ideas people, testers and programmers.


    • Michael Arestad 6:50 pm on April 29, 2014 Permalink | Log in to Reply

      Press This is a redesign with a focus on automation and speed. It will have a simplified interface, efficient media upload, and site switching.

      The plugin is currently in the idea stage You can see discussion and progress at corepressthis.wordpress.com

      I am the project lead (@michael-arestad) and those who are involved or have shown interest are:
      @melchoyce, @bilalcoder, @danielbachhuber, @folletto, @georgestephanis, @helen, @ryelle, @morganestes, @ryan, @stephdau

      If you’re interested in contributing, ping one of us on IRC and we’ll add you to the Skype Group and blog.

    • Dave Navarro, Jr. 7:51 pm on April 29, 2014 Permalink | Log in to Reply

      Native support for mobile platform detection is critical, in my opinion. Check out the Mobble plugin (https://wordpress.org/plugins/mobble/) which adds functions for detecting the OS and device characteristics.

      Mobile web sites and Responsive web sites are NOT the same thing and right now we can create responsive sites with CSS, but we can’t create Mobile sites without help. A mobile site doesn’t just HIDE elements on mobile devices, it never even sends the data (like unregistering widget areas on mobile to prevent data from widgets being sent).

    • John Blackbourn 8:46 pm on April 29, 2014 Permalink | Log in to Reply

      I know I’m late but I’d like to look into improvements to user profile editing in core. I’ve recently looked at quite a few plugins which add the ability to upload an avatar in addition to Gravatar, and I’ve been looking at how WordPress.com does this, as well as how it separates the screens for managing your profile and managing your user settings.

      Current status: Idea and research stage.

    • shaunandrews 8:47 pm on April 29, 2014 Permalink | Log in to Reply

      Sorry for the late reply, I wasn’t sure if I could make the meeting today (which is in progress), but I wanted to mention that there’s a group of people working on the media-grid plugin: https://make.wordpress.org/core/2014/04/22/remember-the-media-grid-project-it-was-original/

      We had a single meeting (which I also missed, due to being a fool and confusing timezones), and are just gearing up. I’m @shaunandrews) planning to lead the project, and we have @helen, tillkruess, caseypatrickdriscoll, jcastaneda, kopepasah, klihelp, and ericlewis all showing interest in helping.

      We’ve got a GitHub repo: https://github.com/helenhousandi/wp-media-grid-view/

      I’m considering setting up a WordPress.com blog and/or a group Skype chat to help keep us all connected. Hit me up on Skype (shaun.andrews) or email (shaun@automattic.com) if you’re interested in helping.

      • Dave Navarro, Jr. 9:31 pm on April 29, 2014 Permalink | Log in to Reply

        Would love to see the ability to use a Taxonomy (separate from categories) to better organize media. I have sites with 10’s of thousands of media items and it’s a PITA to browse all that.

        • shaunandrews 12:22 am on April 30, 2014 Permalink | Log in to Reply

          Some sort of grouping (or, collecting) is in our plans, but its too early to know how that’ll shape up. If you have any specific thoughts on the matter, please feel free to share :)

    • pressupinc 9:13 pm on April 29, 2014 Permalink | Log in to Reply

      I’d like to build a version with more consistent written tone that is less colloquial–especially around error messages (e.g. “Are you sure you want to do this?” and the default 404).

      I have a few people interested in work on the project, and have done a survey to see what tone most community members would like to see.

      • John Blackbourn 10:17 pm on April 29, 2014 Permalink | Log in to Reply

        This has been brought up before. If you have a search through Trac you’ll probably find a couple of tickets relating to changing of phrases in core. Do you have a link to your survey?

        That said, this isn’t related to feature plugins. A better place to discuss it would be in a ticket on Trac.

    • vivekgounder@gmail.com 1:53 pm on May 1, 2014 Permalink | Log in to Reply

      Congrats Helen :)

  • Samuel Sidler 10:22 pm on March 19, 2014 Permalink

    GSoC Chat Tomorrow 

    For those interested in Google Summer of Code, we’ll be holding a chat tomorrow on IRC in #wordpress-gsoc, March 20, at 18:00 UTC (2pm EDT, 11am PDT). Bring your proposal along and you’ll have five minutes to talk through your proposal with mentors. We’ll try to fit everyone.

    If you haven’t already, be sure to submit your proposal as soon as possible. There’s not much time left to get feedback prior to the submission deadline! Keep in mind that you can modify your proposal up until the deadline.

    See you all tomorrow!

    • Andrew Nacin 10:25 pm on March 19, 2014 Permalink | Log in to Reply

      The deadline is Friday, March 21 at 19:00 UTC..

      Worth pointing out that you can edit your proposal after it is submitted, up until the deadline. After that, you can still comment on your proposal, such as if any mentors ask you questions.

  • Samuel Sidler 4:40 pm on February 27, 2014 Permalink

    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.

    • Avryl 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. 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.

  • Samuel Sidler 11:27 pm on October 22, 2013 Permalink
    Tags: ,   

    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.


    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.

  • Samuel Sidler 7:15 pm on September 30, 2013 Permalink
    Tags: ,   

    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.


    • 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.


      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.

  • Samuel Sidler 9:35 pm on August 27, 2013 Permalink
    Tags: ,   

    WordPress 3.8 agenda for tomorrow 

    Our next WordPress 3.8 chat is tomorrow, August 28 at 21:00 UTC, following the 3.7 dev chat. Here’s our agenda:

    • Answer questions/comments about the features as plugins process (see yesterday’s post).
    • Review projects with no lead or weekly chat.
    • New feature presentations. Is there a new feature you want to work on that’s not being tracked? Now’s the time to present it. Bring as much information as possible and comment on this post beforehand.
    • Office hours.

    Hope to see all of you tomorrow!

    • Charleston Software Associates 3:24 pm on August 29, 2013 Permalink | Log in to Reply

      I am new to the make/core process but would like to start contributing to improving WordPress. I have some “contributor newb” questions:

      • Is creating a Trac ticket the best way to log new concepts for the admin UI?

      Assuming the answer is yes…

      • Is there a way to get Trac to show me more than 10 results at a time?

      I want to log my “wish list items” while working with WordPress over the next couple of weeks. For example:

      • Admin tables Infinite Scroll
      • Adding “delete permanently” w/ “are you sure?” confirmation to bulk actions (skipping trash = one less step in some cases)
      • Adding a page length option to admin tables v. the fixed 20 items limit.

      I’m not clear on the process, but thought it should start with a formal enhancement ticket in Trac. That at least organizes the wish list so myself, or another code geek, can come back and create a MP6-like plugin for a future release of WordPress.

      My other thought was a GitHub / Bitbucket project with an independent issues list, but that just feels wrong as it fragments the community and efforts to improve core. However I can see the benefit of not filling up trac with concepts, many of which do not belong in core.

      Maybe a new “wishlist” Trac?

  • Samuel Sidler 6:12 am on August 27, 2013 Permalink
    Tags: ,   

    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:


    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.


    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.


    • 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.

  • Samuel Sidler 3:47 am on August 16, 2013 Permalink

    WordPress 3.8 Chat Wrap Up 

    The WordPress 3.8 chat ran a bit long today, but we got a ton of information on the projects people are interested in. I’ve compiled a list of features-as-plugins from the chat today to get a better handle on the status of each project. I may have missed some details, so let me know and I’ll update that page.

    If your group hasn’t already, do the following things before next week’s chat:

    • Setup a weekly IRC chat – ideally these should occur before the weekly 3.8 chat.
    • Use your weekly chat to select a lead. Keep in mind that your lead can change later if it needs to, just as MP6 has switched hands.
    • Create a wordpress.org plugin and use that page to list your group’s members, what you’ll be working on, and a link to all the relevant docs (including mockups). Add “wordpressdotorg” as a contributor to your project.
    • If you’re not yet at the stage where it makes sense to create a wordpress.org plugin, make sure you create a thorough overview document.
    • Each week you’ll want to post the status of your project to the relevant make P2.

    Other than that, see you August 22 at 18:00 UTC for the next 3.8 chat.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar