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.

WordPress wouldn’t be WordPress without your enormous efforts. You helped build 23% of the internet with your fingertips. You helped build an ecosystem. Several companies. Careers. You helped complete strangers put their children through college.

I am thankful to you both personally for your guidance, encouragement, and friendship. I know you’re not disappearing, but this seems like the place to remind that you’ve made an enormous difference in not just my world personally, but millions of others’.

Wow, seeing Peter go is something! I am glad to see that he’s not completely disappearing from the picture.
As for Ryan, no one could not notice his frequent UX/mobile involvment, so I’m happy to see that becoming his mainstay for the moment

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.

I think I originally met Helen at SXSW, and likely said some embarrassing things I should now regret; maybe best I can’t remember. Fast-forward to working together at 10up, where her ability to juggle client-work and core priorities was her super-power. Congratulations, Helen. Super dope.

I think I met Dion either at WordCamp New York, or an Automattic meet-up. His ability to imagine a complete solution to just-about any problem is eerily impressive. Congratulations to you too, Dion.

It’s really great to see this type of formal recognition again. Release leads are great, and the make-teams provide a nice structure to help concentrate efforts, but continuing to have ranks to rise is acknowledging a volunteer job well done, and goes a long way towards motivating others to continue to do their best.

Well deserved and again, my sincerest congratulations to the both of you.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

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.

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

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

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.

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]”

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

Congrats to John on being named the 4.1 release lead, to Scott and Drew for being given permanent commit access, and to Gary, Konstantin, Jeremy, Jorbin, Ian, and Boone for being given the “keys to the car”!

If you’re at WordCamp Europe’s contributor day (GMT+3), this will be 5pm.

More to come with regards to 4.1 over the weekend, but I wanted to make sure everyone saw this (as it was decided at this week’s dev meeting). But please think about what you’d like to work on or what you’d like to see. This comment thread is also open.

This initial post said Monday, September 28. Monday is September 29, and that’s the day of the meeting.

The sought after solution would allow the developer for example to define an option, custom field or term to be language specific (default) or not.

Even if a theme or plugin wouldn’t be built to be multilingual ready it would still be.
The editing user would simply set the edit language (in admin bar) to the required language and WordPress would automatically retrieve/save the correct data based on the current editing language and the defined language specificness.

Of course all relevant API functions and hooks would need to incorporate the language into their logic too. For example, this way when a non-multilingual prepared plugin retrieves an option value it would get a language specific value!

Many theme and plugin developers who only used to and familiar with single language sites don’t understand the need for and problems and needs of multilingual sites. This probably won’t change for the majority of them. They don’t want to put the extra afford in to find out what’s needed and how to implement it. The ones that do are put off by the lack of a standard. With the above proposed solution they wouldn’t even have to! It would work out of the box!

@ bvl and @nacin
I fully agree with most of your notes about multilingual features. As data-designer, author of free xili-language plugin since more than 5 years based on taxonomy and other core wp features (no new tables, no cookies,…) only cms data model… i can say that few features in WP core (api, filter) (and time) will be necessary to ship an easy to use plugin. Based on the initial data model, this architecture remains reliable during the succession of version since 2.3 to 4.0 and the amazing power of the wp core (loop and UI). But we must be also prudent about the users target – multilingual activated in a simple single instance of WP (targeted by xili-language) or multilingual activated on a multisite installation (purpose of xili-language ms or multipress -MultilingualPress- by a german group.

Plugin xili-language was the first to follow the WP data model and to use a taxonomy (language).
It is because WP and a theme is translation ready that xili-language can works.
Since more than 5 years, it was an opportunity to discover gradually the core of WP and to use as possible the core available functions especially for the dashboard side or CPT or CT.

Without commenting yet, I will list below some subjects that can improve internationalization (and bi/multilingual opportunities):
A) textdomain
creation of a default text domain for theme:
Example: default comment form and WP_locale class use default domain and need to be re-instanciated to be core independant and current language dependant.
Because (recently and not for all) declared textdomain et language files sub-folder are not reliable, plugin continue to detect these datas.

B) .po / .mo files (theme and plugin)
as for core since recently, separation of file for frontend and admin sides. Adding a text domain when data saved in options can be translated.

C) WP_table taxonomy columns in admin UI:
If you add a column, no problem to adapt the content of a cell.. But first default columns (like description) are not filterable. So impossible to, per example, add a displayed translation.

D) taxonomy and xili-tidy-tags
As you can imagine, I read and read again taxonomy.php.
The original approach, of xili-tidy-tags (one of the three plugins in xili-language trilogy) is that: it is possible since 2009 to create a taxonomy of terms. It is not exactly like alias features used also in multilingual data model. It need few special queries to do that type of grouping/taxonoming of terms… As wished formerly in tracs, I think it can be a very powerful tool if these queries (with good rules) can be incorporated in Core.

I am ready to work and detail subject by subject here described or those of the internationalisation topic…
Cheers,
M.

We’ve moved the SVN and Trac firehose mailing lists to lists.wordpress.org, from the legacy lists.automattic.com. If all goes well, we’ll move the rest of them over as well.

The one side effect is this is likely to break your existing mail filters. The new mailing list emails are wp-trac@lists.wordpress.org and wp-svn@lists.wordpress.org. If you’re using Gmail’s mailing list filters, those would now look like list:wp-trac.lists.wordpress.org.

For those of you who use Gmail, I’ve also added basic styling to the SVN commit emails. Hooray for reading diffs with red and green. (For those who don’t use Gmail, you’ve already been seeing styling that Gmail strips out.)

Just a reminder you don’t *need* to use the Trac firehose. You can also subscribe to individual tickets, milestones, components, focuses, new tickets, etc.