WordPress.org

Make WordPress Core

Updates from Andrew Nacin Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 8:02 pm on May 20, 2015 Permalink |
    Tags: ,   

    New committers for 4.3! 

    Please join me in welcoming three new guest committers for WordPress 4.3 — Ella Van Dorpe (@iseulde), Konstantin Obenland (@obenland), and Weston Ruter (@westonruter)!

    Ella has been one of our very top contributors of late. She started with a front-end editor plugin, which parlayed into substantial core editor contributions, including inline image editing in 3.9, inline oEmbed previews and improved editor scrolling (“focus”) in 4.0, distraction-free writing (“focus v2″) in 4.1, and a few dozen other things I am sure I am missing (like this). She’s a powerhouse.

    Obenland, well, is also wearing the release lead hat for 4.3. I said plenty of nice things about him there. 😄 While there’s no requirement for a release lead to be a committer, a) it does help with housekeeping, and b) Konstantin has unquestionably earned this in his own right, regardless of his other role.

    Weston has been essentially leading the customizer component since his work last year on bringing widgets into the customizer. His body of work there is nothing short of incredible and we’re lucky to have had him spearheading this important work.

    The lead developers review and appoint new committers to serve each release cycle, often to work on a particular component or feature. This guest commit access comes up for review after each release and can be renewed — Aaron Jorbin and Jeremy Felt have both been renewed for 4.3.

    We (well, I) neglected to announce that John Blackbourn (@johnbillion), Boone B. Gorges (@boonebgorges) and Gary Pendergast (@pento) were made full, permanent committers at the start of 4.2. John, Boone, and Gary all destroyed it in 4.1 (which is perhaps more obvious now that some of Gary’s work has been trickling out into the open).

    Congrats all! 🎉

     
  • Andrew Nacin 7:35 pm on April 1, 2015 Permalink |
    Tags: , 4.4,   

    Release leads for WordPress 4.3 and 4.4 

    Since WordPress 3.5, we’ve had a rotating release lead. Because of the ever-present demands of the current release’s development cycle, we’ve found it tough to make these appointments well in advance. We’ve always wanted to give leads opportunity to prepare, so they can hit the ground running. (Long term, we’d love for release development to overlap pretty significantly, aided primarily by feature plugin development, but also by branching.)

    A release lead determines all important parameters for a release, like schedule, deadlines, which feature plugins are merged; and more generally, scope, goals, vision, and process. They take point when it comes to holding meetings, shepherding contributions, and writing announcement posts and updates. A release lead is a connector and facilitator, identifying bottlenecks and friction wherever they may be. They’re in frequent communication with the developers and plugin teams that are aiming to have something in a given release. The release lead follows what’s being committed, and sets the tone for prioritizing and gardening tickets. Given the constraint of time in hitting deadlines, help with prioritization and ensuring good communication lines are two of the most valuable things a lead can contribute.

    Today, I’m excited to announce release leads for both WordPress 4.3 and 4.4.

    Konstantin Obenland will lead WordPress 4.3, currently planned for August. Many of you may know @obenland (twitter) from his early work on default themes, but his contributions span across WordPress core. More recently, he shipped the new WordPress.org theme directory. Obenland is a native of Germany and lives in southern California. He’s a code wrangler at Automattic, which donates all of his time to WordPress core and WordPress.org.

     

    Scott Taylor will lead WordPress 4.4, due at the end of the year. A committer since 3.7, @wonderboymusic (twitter) has been plowing through major changes to media and pretty much everything else he can get his hands on. Scott is a Tennessee native and lives in New York City. He’s a senior software engineer on the interactive news team at The New York Times.

     

    You’ll hear from both of them in the coming days and weeks as they start to plan out their releases, including potential features, deputies, and strategies. Congratulations 🎉 and best of luck to both!

    Not an April Fools’ joke.

     
  • Andrew Nacin 8:57 pm on February 4, 2015 Permalink |  

    New chapters for Ryan and Westi 

    WordPress lead developers Ryan Boren (@ryan) and Peter Westwood (@westi) started contributing to WordPress more than a decade ago. Ryan and Peter, along with Mark and Matt, served as the foundation for much of the early years.

    For some time now, Ryan and Peter have avoided weighing in on technical matters. Very simply, when you aren’t able to be active in development, you know you’re not up to speed, and you realize your words shouldn’t carry the weight that they do. Being able to make this judgment is one of the things that makes both of them such great leaders.

    We’ve all been there, at least for particular features or releases. It’s worth noting, for example, that my own time on core has been cyclical for years, as sometimes I end up working full time on the security team, maintenance releases, the WordPress.org site, or related projects.

    The great thing is, there are a lot of fantastic developers who have stepped up over the last few years to seamlessly fill in the huge holes they’ve left. Some of that culminated in promoting Helen and Dion to lead developer yesterday, and my own promotion three years ago.

    When I started contributing, I received a lot of advice and learned a lot from both of them. Peter reviewed a lot of my code and was the guy who would revert my code when I broke something. :) Ryan became my mentor and pushed me to become the engineer I am today.

    And so, it is with mixed emotion I share that Ryan and Peter have stepped down as lead developers.

    Peter will be moving into a dormant/inactive/emeritus status. We hope to have him back when his life and work allows. In the meantime, you may see him committing a bug fix here and there, as he is wont to do.

    Ryan has been focusing all of his energy on improving UX for more than a year, especially for mobile and touch devices, and especially for workflows like media management. So I’m pleased to say he’ll continue to do that: Ryan will be spearheading UX for WordPress in 2015. It’s been a while since we’ve had someone truly focusing on just UX, so this is really exciting.

    Along with yesterday’s announcement, the active lead developers are @markjaquith, me, @azaozz, @helen, and @dd32.

    Please join me in congratulating Ryan and Peter on an epic run. :)

     
  • Andrew Nacin 9:22 pm on February 3, 2015 Permalink |  

    New lead developers: Helen and Dion 

    I’m pleased to announce that Dion Hulse (@dd32) and Helen Hou-Sandí (@helen) are now lead developers of the WordPress project.

    The two are already highly respected leaders in the community. Dion has architected some of the most important code in WordPress over the years. He started by building the plugin updater way back in 2007, helped lay the foundations of custom post types and taxonomies, and more recently, designed and implemented automatic updates. He has essentially been one of core’s main architects for years, all while providing advice, code review to newcomers (myself included, long ago).

    Helen’s tremendous impact on the project is surely known to all of you. She champions the project’s philosophies, she’s been a key leader on dozens of features large and small, including the media UI, CSS architecture, and the jam-packed WordPress 4.0 release. Her strong engineering skills are backed by her natural leadership, sound judgement for user experience design, and the mentorship of countless contributors.

    Please join me in congratulating Helen and Dion!

     
  • Andrew Nacin 8:54 pm on January 21, 2015 Permalink
    Tags:   

    Drew Jaynes is the 4.2 Release Lead 

    I’m pleased to share Drew Jaynes (@drewapicture) is the release lead for WordPress 4.2.

    Drew will be kicking off 4.2 today in about 7 minutes in #core on Slack (the regular weekly meeting). This is a follow up to yesterday’s excellent chat that I led on feature plugin development, which has highlighted a few things:

    • Menus in the customizer need additional development and user testing, and may or may not be a 4.2 candidate. Extra time here is not a bad thing.
    • Theme switching in the customizer needs user testing. It is a possible 4.2 candidate.
    • Press This has been in the wild for some time and is a possible 4.2 candidate.
    • Update improvements initially discussed for 4.1 is gonna get started in 4.2.

    As you may know, Drew led the massive year-long effort to document every hook in WordPress. This showed off his impressive management and organizational skills that we know will translate nicely to running a release. Also, don’t be fooled — while his focus has been inline docs, he’s an engineer at 10up.

    Additionally, Scott Taylor (@wonderboymusic) will be taking point as a core feature lead for a lot of media and image efforts underway, including two feature plugins (image flow and also responsive and HiDPI images), media on mobile, and such. This effort spans not only 4.2 but also 4.3 and really 2015. There will be more on all of this in the coming days.

     
  • Andrew Nacin 7:46 am on December 24, 2014 Permalink
    Tags: ,   

    Let’s cancel today’s weekly meeting, since the holidays are starting for some of us (and ending for some others).

    It can be open office hours* if anyone is around (I doubt I will be), but everyone (@johnbillion especially!) deserves a nice break for a great WordPress 4.1 release. It’s already been downloaded 2.5 million times, there’s been a lot of great feedback, and I also haven’t seen anything major reported. I just triaged about 40 recent tickets to be sure. Check out the 4.1.1 ticket report.

    Please check that report when you have time to see if there’s a ticket you should be giving feedback on. For example, I see stuff for @azaozz and @avryl (#30696), @helen (#30813), and @obenland (#30831). Again, nothing important, so enjoy any break you may be taking. Happy holidays!

    I suspect next week (New Year’s Eve) will be an informal meeting, as it’ll be only the afternoon for those in the U.S.

    * Keep in mind people are in the #core channel on Slack all the time, so it’s really 167 hours of office hours per week, plus one meeting.

     
  • Andrew Nacin 12:07 pm on December 11, 2014 Permalink
    Tags: ,   

    If you’ve written a child theme for Twenty Fifteen, please note that some of the new pagination functions have been renamed for a bit of clarity:

    • the_pagination() is now the_posts_pagination()
    • get_the_pagination() is now get_the_posts_pagination()
    • These two functions now emit a “posts-navigation” HTML class, instead of “paging-navigation”

    @obenland‘s original post on new template tags in WordPress 4.1 has been updated with these changes.

     
  • Andrew Nacin 2:29 pm on October 21, 2014 Permalink
    Tags: summit,   

    There’s a community summit next week after WordCamp SF for those who don’t know. During this day we break into small meetings to discuss big picture items. These topics touch the entire community. In this case I’m specifically looking at adding more core development topics to the list, because it’s pretty barren right now.

    Here’s some thoughts we covered two years ago at the last official summit. The timing of this, for reference, was about three months after 3.4 came out, and two months before 3.5 came out. I pulled this off the schedule:

    I think most of these could benefit from a revisit in some way. A lot of specific and big improvements have been made in a number of areas (e.g. bug tracker, updates, i18n, JavaScript, multisite), but even then there’s a lot to cover and a lot has changed in two years.

    Here’s some potential topics that have been proposed:

    Some other ones that I’m now proposing:

    • After PHP 5.2
    • i18n/multilingual roadmap
    • multisite roadmap, 2.0
    • next steps for updates (or: how can we auto update everything)

    And now I toss it to you: what else should be on this list? Quick, you have a few hours before the initial schedule is built.

    I’m reading through all of the relevant documents from the summit in 2012, and attendees for this year’s summit, you should too. I linked all of them above in the first set of bullets.

     
    • Drew Jaynes (DrewAPicture) 2:34 pm on October 21, 2014 Permalink | Log in to Reply

      I think it’s worth throwing in an obligatory update on inline documentation in core. Where it’s been, where it’s going, what goals we’ve completed since the action items were published from the 2012 summit. This would include the “adopting a JavaScript inline docs standard and how to best make our inline docs serve the wider developer community.

    • Daniel Bachhuber 2:43 pm on October 21, 2014 Permalink | Log in to Reply

      Because I don’t see it on the list, and not because I necessarily want to open up the can of worms: what to do about the plugins directory.

      For those of us using “plugins” as components to larger sites, the quality of the plugin is paramount. Quality could be defined as health of development, extensibility, compatibility, etc. Choosing a bad plugin can break a project.

      One could argue the current plugins directory is oriented towards users, and we could use one oriented towards developers. Yes, I’m aware of the stereotypes I’m perpetuating.

      • Jeremy Felt 3:59 pm on October 21, 2014 Permalink | Log in to Reply

        +1

        I’d love to have something in place where I could see what other developers are using a plugin, code reviews with enterprise in mind, whether it makes proper use of caching APIs, and how it handles security. Etc.. etc… etc…

        Anything to reduce the amount of effort required to start to trust a plugin in an enterprise environment.

      • Weston Ruter 5:22 pm on October 21, 2014 Permalink | Log in to Reply

        +100

        I was just talking with Bryan Petty (tierra) about this. He’s the developer behind Plugin Mirror, which does an SVN sync of the .org plugins to GitHub for read-only forking.

        I’d love for the WordPress.org plugin directory to start including scores from automated tests, for instance PHP_CodeSniffer WordPress Coding Standards, JSHint, YUI Compressor check, and any other static analysis tools. Then to take it a step higher, to actually activate a plugin on a vanilla WordPress site and see what kind of footprint it has, namely whether database tables get created and whether errors/warnings/notices get generated. Just knowing the latter, whether there are PHP notices, would be a huge indicator in terms of knowing the level of quality for a plugin.

        These automated checks would tie in well with manual code reviews by enterprise agencies/developers. Plugin reviews written by developers with more WP “clout” should get ranked higher in the overall plugin rating.

        In addition to scores, the WordPress.org directory needs to make it easier for people to contribute and to keep plugins from languishing. I had an idea about how to leverage the Plugin Mirror on GitHub for this, if nothing was to be done on WordPress.org itself: the Plugin Mirror could have its own WordPress.org account, and plugin authors could add this user to their plugins as a committer. If the Plugin Mirror then started taking pull requests, the author could then merge them on GitHub and Plugin Mirror could push them to the WordPress.org SVN repo. This would allow people to open pull requests on .org plugins and have a straightforward path for contributing.

        I suppose .org wouldn’t want to marry to close with GitHub, even if it is the de-facto platform for open source software platform nowadays, so the specific external Git repo used by a plugin could be configurable: GitHub, BitBucket, Google Code, etc.

    • Mario Peshev 2:48 pm on October 21, 2014 Permalink | Log in to Reply

      In addition to “After PHP 5.2″ and what Daniel said above, I’d like to discuss further the metadata work and focus on it, and probably discuss WordPress as an application framework and how could it incorporate the current APIs, the JSON one coming soon and possible optimizations and plans over the next few releases.

      From my perspective other frameworks or Drupal for example focus on enterprise clients, and WordPress is used by quite a few large corps already. This would also support the process of finding new contributors by increasing the circle of larger companies using WordPress as one of their main platforms and dedicating team members to core.

    • George Stephanis 3:04 pm on October 21, 2014 Permalink | Log in to Reply

      Two Factor Authentication for Core?

    • Scott Kingsley Clark 3:08 pm on October 21, 2014 Permalink | Log in to Reply

      Can’t make it to WCSF this year due to budget limitations personally, will there be a way to participate in some way for those who can’t make it physically but will be around virtually?

    • Aaron Jorbin 4:30 pm on October 21, 2014 Permalink | Log in to Reply

      I just added a topic for SASS and WordPress Core.

    • Weston Ruter 5:35 pm on October 21, 2014 Permalink | Log in to Reply

    • kraftner 3:45 pm on October 22, 2014 Permalink | Log in to Reply

      Thinking about how we can improve the situation with the omnipresent coupling of content and layout. Less WYSIWYG and more pure content vs. styling in themes to make switching or just modifying themes a smoother experience.

  • Andrew Nacin 7:24 pm on October 8, 2014 Permalink
    Tags: , ,   

    Ideas for plugin/theme install/update UIs 

    In the last few releases, the theme and plugin installers received new UI. But the actual procedure of installing a plugin or theme is still old-school: a JavaScript alert confirms you actually did want to install something, then you get taken an ugly screen that prints out sentences of “Downloading package,” etc. If there is an error, everything stops. If it succeeds, you can activate what you just installed or go back to where you came from.

    To say this is not the best experience is an understatement. We can streamline this entire flow while also adding some new functionality. Here’s the goal: Installing or updating a plugin or theme should not block you from continuing what you were doing. Secondarily: unnecessary and sub-par user interfaces should be eliminated.

    Some ideas:

    • You should be able to install a plugin/theme without leaving the installer screens.
    • You should be able to continue searching and browsing for other plugins (or themes).
    • Multiple plugins/themes should be able to be queued for installation at once.
    • Progress is shown directly inside the installer. Details are only shown if there is an error.

    How are we going to do this?

    • Once an install starts for an item, we can “lock” that item to the top left of the results, even if the user keeps browsing or searching for other things.
    • The plugin installer is not yet dynamic, so we’ll need to add infinite scroll and such to allow for continuous browsing (something we avoided doing in 4.0 due to time constraints).
    • We’ll need to come up with a UI for installing a plugin, such as a card-flip, a subtle progress bar, or button changes (“Install” “Installing…” “Installed!”).
    • Updating plugins, themes, and core (from the Dashboard → Updates, Plugins, and Themes screens) should be seamless and happen inline, which will be a completely different UI from installing.
    • We must make sure a user abort (leaving the page) is prevented and/or doesn’t stop the update. We must probably make sure that updates are queued (only one actually happening at once), as we have to take into account maintenance mode, conflicts, I/O operations, and such.
    • If the user is forced to enter FTP credentials, we can request it once in a modal, then send it with each Ajax request — much nicer experience.

    The tracking ticket is #29820. Thoughts, ideas, challenges, suggestions, questions welcome.

     
    • Rafael Ehlers 7:29 pm on October 8, 2014 Permalink | Log in to Reply

      Can we also please add Drag’n’Drop to the installer (upload case): https://core.trac.wordpress.org/ticket/24579

    • demoman2k10 7:47 pm on October 8, 2014 Permalink | Log in to Reply

      Replacing the Install display with a progress bar, or changes should also include an option to debug the install incase of error’s as well. So one does not end up with a Plugin that hasn’t installed and no details as to what went wrong and where to start working to fix it.

    • Radices 7:57 pm on October 8, 2014 Permalink | Log in to Reply

      I’d like to see the ability to delete plugins without having to deactivate them first (auto deactivate when deleting). I’d also like to be able to delete themes from the main screen without having to go into the details screen first.

    • Rene Hermenau 8:18 pm on October 8, 2014 Permalink | Log in to Reply

      > Multiple plugins/themes should be able to be queued for installation at once.

      Nice feature but could be dangerous for newbies who install all end everything. If only one plugin breaks the site, user do not know which one causes the issue.

    • WPMUDEV 8:43 pm on October 8, 2014 Permalink | Log in to Reply

      At WCEU there was a talk about options, and how each option is a decision that has to be made.

      Apologies if this has been covered before, one feature/update I’d love to see is getting rid of the separate theme and plugin upload area (not where you search for themes or plugins), the number of times I’ve seen end users complain that their theme doesn’t install and they get “The package could not be installed. No valid plugins were found.” or that their plugin doesn’t install and they get “The package could not be installed. The theme is missing the style.css stylesheet.” and that has been down to them using the wrong area.

      Those two upload areas are like options, it’s a decision on where to go and one a user has to make, to a new user they don’t always read the labels or know what theme or plugin is and how they differ. Seasoned users may roll their eyes when they see people make this mistake, and then we happily set them on track but this situation and choice could be avoided by having a single smarter upload that basically says:

      • This is a theme, unpack it in the themes folder.
      • This is a plugin, unpack it in the plugins folder.

      This way it’s one upload area, no confusion.

      Not sure how many times other companies see this, but we get this question in both emails and our own support forums a bunch of times each month.

      Thanks for reading :)

      • Timothy Bowers 8:46 pm on October 8, 2014 Permalink | Log in to Reply

        Sorry, I intended to post this under my own account rather than the company one. :)

      • Captain Theme 2:19 am on October 9, 2014 Permalink | Log in to Reply

        Strongly agree. In a support position I’ve seen this done countless times and it’s a very unpleasant experience for the user.

        Not sure the best way to approach it but even keeping things the way they are now but doing a check for if it’s a theme/plugin and then moving it to the appropriate location, etc. would be a huge improvement.

        • Timothy Bowers 12:35 pm on October 10, 2014 Permalink | Log in to Reply

          :)

          You’re right, it is an unpleasant experience for end users, and the warning they get is also so meaningless, all they know is something isn’t working and in most cases I’ve seen them blame the plugin/theme developer.

          The main path to get there is the add button within the theme or plugin admin area, and from the menu. I was thinking it would be a case of changing those links to direct to one upload area that handles this but your idea would work just as well so it detects and passes it off as needed.

    • MRWweb 10:24 pm on October 8, 2014 Permalink | Log in to Reply

      While maybe the user-facing feature doesn’t make it into this work, I would hope that the technical foundation could be laid for the update-by-zip-upload feature as described in #9757. This seems like the right time to consider it again since it was first opened 5 years ago!

    • daveshine (David Decker) 7:43 am on October 9, 2014 Permalink | Log in to Reply

      Just yesterday, I released this plugin: https://wordpress.org/plugins/cleaner-plugin-installer/screenshots/

      I mostly tweaks the start page of the install admin page (?tab=featured) and replaced its content with a large search input field, among other little tweaks.

      Already got lots of feedback, that other developer & users like the approach of starting with a search box.

      • Netzialist 7:59 am on October 14, 2014 Permalink | Log in to Reply

        Thank you for this, David!
        I felt completely lost the first time I saw the new interface. I had a certain plugin in mind, but there was no searchbox. Instead I saw big bold icons cluttering my browser window. Stuff I didn’t need and I didn’t look for.
        From a usabilty point of view I consider the new interface as a big step back. WordPress desparately needs to become simpler. Much more simple as it is now.

        • virgodesign 10:57 pm on October 19, 2014 Permalink | Log in to Reply

          Plugins has grown so much in the years, and sometimes you can install and manage dozens. I would love the ability to group installed plugins using categories, just like posts with taxonomy. This will help admins having a better organized plugins page

    • Primoz Cigler 9:34 am on October 9, 2014 Permalink | Log in to Reply

      Maybe we could consider implementing the plugins/themes/core updates/installs utilizing the Web Workers (at least progressively enhance the experience for the users that use browsers that support that): https://developer.mozilla.org/en/docs/Web/Guide/Performance/Using_web_workers

      To be honest, I am not super familiar with the Web Workers, but I have a feeling that they would fit perfectly for that task being discussed. The support is very good among the browsers as well: http://caniuse.com/#feat=webworkers

      • Primoz Cigler 9:38 am on October 9, 2014 Permalink | Log in to Reply

        The main benefit would be (at least how I understand the web workers) that the user could even leave the install/update screen (for instance go wiring a new post) while the process will not be interrupted.

    • Cliff Seal 11:50 am on October 9, 2014 Permalink | Log in to Reply

      This isn’t fleshed out, but reading this brought at least one quick interaction to mind.

      Clicking the {refresh icon}{number} area in the admin bar could dropdown to show basic information:

      Plugin Name
      Current Version -> Available Version

      There could be a link to see details (where the user could choose what plugins to update, read descriptions, etc.) along with a link to just ‘Update All’. You could set the entire updating process in motion without leaving changing screens or anything else like that. And, instead of a fugly JS alert, you could add a cancellation timer: “Updating all in 10 seconds… [cancel]”

    • Hugh Lashbrooke 6:59 pm on October 9, 2014 Permalink | Log in to Reply

      Something that’s always stuck out in my mind is the fact that there are two separate actions for getting a new plugin running on your site: install & activate. In almost all cases, I would say that plugins are activated immediately after installing. To non-technical users, the differentiation probably doesn’t even make all that much sense.

      My thought is to rename the ‘install’ button and turn it into a 1-click ‘activate’ button. That way, after searching for a plugin, users simply click one button and the plugin downloads, unzips and activates. This gives the impression that WordPress and the plugin repo are all one cohesive system, instead of the segmented systems that they really are. Technical users would still know what’s going on of course, but the average user really wouldn’t care that now there is a new folder on their server with the plugin files in it – they just want it to work.

      Along with that and 1-click delete action like @radices suggested above – together that would go a long way to giving a much more cohesive and stable feel to WordPress itself and the plugin repo.

    • alexis_hancock 7:22 pm on October 9, 2014 Permalink | Log in to Reply

      I would really like to see some prompts around the errors that occur when a plug-in is unsuccessful. It’s very vague on what exactly went wrong and if error messages are provided, and sometimes they are, it would be nice to see prompts on how to debug for that message.

    • AMEEKER 11:56 pm on October 9, 2014 Permalink | Log in to Reply

      I don’t know if this is the right place to put this or not, but it’s related to the searching for plugins. When you type in or paste in a plugin name or query in the plugin search box, you have to hit ENTER to actually perform the search. There is no search icon anymore that allows you to click to complete the search. Can we add that back?

    • Josh Visick 8:48 pm on October 10, 2014 Permalink | Log in to Reply

      I think improving the experience and options available when something goes wrong with plugin updates is important. I’ve been thinking if it makes sense to have an easy revert to last installed version for plugin updates that happen to break a site. That could also possibly tie into an automatic support ticket for the plugin.

    • Graham Armfield 6:37 am on October 11, 2014 Permalink | Log in to Reply

      Some ambitious changes and additions to functionality listed here. Please can I ask that during the design and functional design stage that thought is given to how we can make this accessible.

      Every time there’s a change on the screen we need to be thinking about what feedback that screen reader users are getting. It’s important also to ensure that everything can be operated just by using a keyboard, and obviously that keyboard focus is always visible and that the tab order is logical.

      Thinking about accessibility at the design stage is a key step in ensuring that everyone can use the functionalty.

    • Matthew 1:06 pm on October 11, 2014 Permalink | Log in to Reply

      Add folders in the Media section.

    • owcv 8:40 am on October 14, 2014 Permalink | Log in to Reply

      Besides these layout changes, there are more essential questions I think.
      The plugin and theme installer of the future, should be able to completely deinstall a plugin or theme, not only the data on the webspace, but first and foremost all the stuff in the database (e.g. wp-options).
      In my opionion, this is a major problem of the plugin/theme-installer, because it can harm your wordpress site by bloating it with relics of deleted plugins/themes.

      • Timothy Bowers 12:46 pm on October 14, 2014 Permalink | Log in to Reply

        I’ve always been torn on this, whilst I’m favour of a better way to remove unneeded stuff from the DB, I’d worry about it’s use on the uninstaller where people simply deactivate, perhaps whilst testing for potential conflicts for example.

        I think if it’s implemented then it’s important to ensure it’s a conscious choice, something that forces the the user to acknowledge it’s irreversible. The number of times over the years I’ve seen users delete something that isn’t backed up, is custom, and they can’t get it back, even when a prompt asked “Are you sure?” and possibly even stated they can’t undo this action.

        With great power comes great responsibility. :)

        • owcv 3:27 pm on October 15, 2014 Permalink | Log in to Reply

          Of course and I’m very cautious when installing new plugins (testing them before and so on), but over the years, some times you change plugins for some reason and in worst cases you can’t ged rid of the old stuff. That’s why I think it would be great to have an app-like plugin and theme installer in WordPress.

  • Andrew Nacin 11:25 am on September 27, 2014 Permalink
    Tags: , ,   

    John Blackbourn is leading WordPress 4.1 (and announcing new committers!) 

    I’m pleased to share John Blackbourn (@johnbillion) is the release lead for WordPress 4.1. But please hold your applause until the end, I have a few announcements to get through!

    WordPress 4.1 will be kicking off at WordCamp Europe this weekend. As noted yesterday, the first meeting will be at 1400 UTC on Monday, September 29.

    You’ve probably seen John in action over the years (his first contribution was more than seven years ago). I’ll also add it’s pretty awesome that @simonwheatley and @s1m0nd of Code for the People (a six-person shop) jumped at the chance to donate a large chunk of John’s time through the end of the year back to the WordPress project. (See also this post for more on the release lead role.)

    New committers for WordPress 4.1

    As many of you know, the lead developers review and appoint new committers to serve each release cycle, often to work on a particular component or feature. This guest commit access comes up for review after each release and can be renewed. I in particular work closely with every guest committer, providing feedback.

    I’m pleased to announce our largest guest committer class ever: Gary Pendergast (@pento), Boone B. Gorges (@boonebgorges), Konstantin Kovshenin (@kovshenin), Aaron Jorbin (@jorbin), and Jeremy Felt (@jeremyfelt).

    Konstantin and Gary both enjoy diving into internals and getting their hands dirty with tough bugs and regressions. Jeremy will be continuing to push multisite forward. Jorbin will be focusing on testing and tooling. Boone has been working on a set of great improvements to tax, date, and meta queries, with test coverage to come with it.

    These five should be strangers to no one — they’ve all been around the community for years, and not only are they top-notch contributors who embody the project, but they’re generally just really good people.

    This will also be John Blackbourn’s third release as a guest committer. I’d also like to welcome back Ian Stewart (@iandstewart), who previously was a committer during the development of Twenty Eleven, and will be back to take the commit reins for the next default theme, Twenty Fifteen.

    Scott Taylor (@wonderboymusic) was on fire during 4.0, especially if this terrific post is any testament, continuing a great run. Scott’s WP origin story is pretty great — right as he was getting ready to leave the WordCamp San Francisco 2011 after-party, @koop convinced him to stick around a little longer. We were introduced, and not long after (from the party) his first patch got committed. A thousand contributions later that have made an indelible impact, Scott is now a permanent WordPress committer. We hope to have him around for a long time.

    About a year ago Drew Jaynes (@DrewAPicture) was given commit access to lead the hook documentation effort. This was hugely successful. After the effort was complete, Drew’s role evolved into maintaining all inline docs, which has just been wonderful. We appreciate his attention to detail and his dedication to this never-ending effort. Drew is now a permanent committer.

    Congratulations to John, Drew, Scott, Gary, Konstantin, Jeremy, Jorbin, Ian, and Boone!

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar