 Hi, everyone. I hope you enjoyed your lunch today and you're all full of energy and you're going to have lots of questions for me at the end of my presentation. Yes, so I'm John. I am one of the core contributors to WordPress and I'm on the WordPress security team. Like Justino said there, I work for Humanmade which is a WordPress specialist development agency over in the UK. I'm going to be talking about WordPress as a mature platform today. My talk might be a little short so hopefully we can get some good questions and answers after the talk and have a bit of a discussion going so get your brains going. So WordPress is 13 years old now and the software that it runs on, MySQL and PHP is even older from 1995. So we're running a stack of software which is 20 years old and that means WordPress is a mature platform. But what do I really mean by that? Well, WordPress is well established. Depending on which stats you look at, WordPress now powers 25% of the whole internet and we've got about 40,000 plugins available for download and we've got thousands of themes. And it's proven. It powers some of the largest and most visited websites in the world as does MySQL and PHP. And it's stable. It's got a commitment to backwards compatibility that's probably not matched by any other web software out there at the moment. The WordPress core software evolves. It doesn't change quickly so that makes it a mature piece of software. But the internet is a fickle place so some people who are proponents of more modern software might call WordPress old or bloated or boring or some other rude words. I can't say up on stage. So if this is the case, if WordPress is old and it's boring, then how can WordPress move forward and how can it stay relevant in the face of competition from much more trendy JavaScript and PHP libraries? Well, let's start by taking a look at some places where WordPress already does do this. Now, responsive images aren't really a new thing anymore but good browser support for responsive images is relatively new. Google Chrome has only recently added support for the source set attribute, the full range of support, and WordPress has added support for this in version 4.4 which shipped in December. So if you're running WordPress 4.4, you now get responsive images out of the box. You haven't got to do anything, you don't have to configure it, you don't have to change your images, you just get it out of the box. And due to WordPress' popularity, powering over 25% of the sites on the internet, it's actually had an effect. This is Google Chrome's data usage for the source set attribute on all the websites across the world. And that point right there is where WordPress 4.4 was released, and due to the scale of WordPress it's had that impact on the percentage of sites that use the source set attribute. Now it's still a low number, 0.2%, but it's growing and it's growing really quickly as sites update to WordPress 4.4. And the REST API, I'm sure many of you have heard of the REST API. The infrastructure is now in WordPress 4.4 and the aim of the REST API is to provide a modern, powerful, standards compliant JSON powered API and to provide that to all WordPress websites. The REST API will probably become the single largest distributed API on the internet once it gains in popularity. And HTTPS, we're doing a lot of work on improving support for HTTPS in WordPress and a lot of the web is moving to HTTPS, so we're going to try and keep on top of that. And support for HTTPS means that we can start working on support for HTTP too, which means pipelining and server push and lots of modern performance technologies that will push the web forward. So these are the things that we're doing already. So from a technical point of view, it turns out that even though WordPress is a mature piece of software, it's perfectly capable of implementing modern technologies. But there's a bigger picture beyond just the technology. It's made up of many parts and we'll have a think about what those parts are shortly. Let's take a look at some of the parts where WordPress is already starting to implement non-technological changes to move the platform forward. But before we look at those, we just need to answer a quick question. What is WordPress? Well, if you go on to WordPress.org and read a description, it's a suitably vague description. WordPress is a web software that you can use to create a beautiful website, blog or app. You know, a bit of vague. What I prefer to think of WordPress as is WordPress's mission, which you can read on the WordPress Foundation website. WordPress's mission is to democratise publishing through open source GPL software. Now, if you bear that statement in mind, we'll take a look to see what other areas WordPress is moving forward in. Internationalisation and localisation. At the contributor today yesterday, we had a really great turnout from a whole bunch of people who were interested in translating WordPress and helping out of the whole localisation process. This is actually one of the most important areas of WordPress with regard to moving it forward. It's the area probably where WordPress can grow more than others, more than all others. Only about 45% of WordPress installs now are used in English. 55% of those are non-English. And that number can only continue to grow as WordPress expands to more non-English speaking countries and non-English speakers. But the quality of the translations is important as well, not just the quantity. We're doing quite well with this. Has anyone heard of this? This is the Global WordPress Translation Day. It's happening on the 24th of April. This is a one-day event over a period of about 24 hours, and there's going to be 30 events, more than 30 events around the world in various locations. We're going to have online training sessions in hour-long slots, as well as in-person. The aim of this day is to help people get involved, not only from a technical point of view, but also from a point of view of localising WordPress and generally getting involved in the whole translation and internationalisation process. No doubt we'll also have people translating WordPress 4.5, which will have been released a week before the event. So they'll be busy. But a lot of the localisation process falls outside of software. Local word camps and local meet-ups are really important because they make WordPress accessible to non-English speakers, so they can learn about WordPress. Now we're quite good at word camps and local meet-ups, but, of course, being a piece of software which has originated from America, of course, it's primarily popular in the US and in Europe. In South America, Africa and Asia, we've still got a lot of work to do to increase WordPress's usage and reach in those areas. The entire process of discovering and learning about WordPress and getting around to installing it and finding plugins and themes can actually all be achieved if you can't speak English. The WordPress.org website is now available in quite a few different languages. Unfortunately, some of the translated sites are somewhat cut-down versions of the English site, but they're there. The aim is that you can discover WordPress, you can find out more about it, you can find plugins, you can find themes, you can install WordPress and start using WordPress without necessarily having to understand the word of English. Fully translated themes and plugins are now on the theme and plugin directories on WordPress.org. This integrates nicely in the WordPress admin area as well if you do a search. The results will be restricted by the language that you're using, so the ultimate aim there is to remove the need for you to speak English or to be able to understand any English. The only way for us to keep improving this is to keep appealing to people who can contribute translations and contribute other localisation services to WordPress, so we really need to work on that a lot, but we're doing quite well. Closely related to localisation is accessibility. It's an important part of enabling as many people as possible to be able to access WordPress so it can increase its reach across the world. Generally, the accessibility of WordPress is regarded as good, but it can only get better. We need to make it better. It's an ongoing process and accessibility teams in the WordPress project do a really good job there, but it is a very small team compared to the core teams and the localisation teams, so we're doing okay, but we can do better. The core standards, the core coding standards were recently updated and this clause was added. All new or updated code released into WordPress core and bundled themes must conform with the web content accessibility guidelines level AA. This has just been implemented. Now, level AA is actually not a particularly stringent set of standards. It's generally common sense, such as clear headings, clear labels, consistent navigation, and those things actually improve the accessibility of the application for everyone, not just people with disabilities. By improving accessibility, you not only improve it for people with disabilities, but you improve it for everyone as a whole. Reminding developers of this, of course, helps us move the software forward by making it better for everyone. Talking of developers, developer relations, so this is an area where we're not doing so well. I'm actually going to start by talking about Drupal. Dris, the lead developer of Drupal, recently published a blog post last week called Why the Big Structural Changes in Drupal 8? Here's a choice quote from his article. The reason Drupal has been successful is because we always made big forward-looking changes. Now, Drupal is a developer-oriented platform, unlike WordPress, which is typically a user-oriented platform. So modernising Drupal's code base is their approach to maintaining relevance and pushing Drupal platform forward. In Drupal 8, they're throwing out tons of old code from Drupal 7 and just widespread completely replacing it new APIs. They're implementing Symphony 2. The whole process of developing for Drupal 8 will be considerably different from developing for Drupal 7. But if you read this article by the lead developer there, it's become apparent that maintaining relations with existing Drupal developers who are used to developing on Drupal 7 is actually really tough because there's such a steep learning curve from moving from Drupal 7 code to Drupal 8 that it's actually putting off Drupal developers. And Drupal are looking into ways that they can maintain their current developer crowd and also make Drupal 8 appeal to developers who want to use much more modern platforms in order to move the platform forward. I'd encourage everyone to go and read that article if you give it a Google afterwards. It's a really interesting article. It covers topics about development that you might not immediately think would come to mind. So on WordPress, on the other hand, has a very strong commitment to backwards compatibility. We don't break things like Drupal does. As a general rule, plug-ins and themes that were written years ago for WordPress will still work in the latest version of WordPress. And the whole aim is to make automatic updates for users. A painless exercise, they needn't fear updates. And that's one of the ways that we can move the platform forward by encouraging users to keep up with the latest versions of WordPress and not have to worry about the fact that their site might break when they update. But for this same reason, WordPress also maintains compatibility with a version of PHP that's now nine years old, PHP 5.2. And the reason is it's PHP 5.2 is still in use on 5% of all WordPress websites, which doesn't sound much, but when you are talking about 25% of the entire internet, that's actually a large number of websites. So breaking that compatibility with PHP 5.2 is a hot discussion topic at the moment in the WordPress community, but it's not something that the core team are too keen on breaking, basically. We don't want 5% of 25% of the internet to be stuck on a version of WordPress because they can't update because they've got an old version of PHP. But what this does mean is this makes it difficult to modernise the WordPress code base because the restrictions that PHP 5.2 put in place means it's really difficult to rewrite old code in WordPress and bring it up to modern standards without breaking backwards compatibility. It also makes it difficult to attract new developers to WordPress, especially younger developers who have primarily come into web development via modern PHP and JavaScript frameworks that are much better structured than WordPress. They come along and look at WordPress and go, whoa, I'm not going to deal with that mess. The newer APIs in WordPress are much more modern, but there's still the restriction caused by WordPress 5.2. This is something that we really need to work hard on the developer relations as well as finding out how we can modernise WordPress code base without outright breaking backwards compatibility. Talking of developer relations, this is something that we need to work on fairly hard to. How do we modernise WordPress's code base without breaking backwards compatibility? We've got a lot of technical debt in WordPress from years and years of code that hasn't changed, especially around the multi-site code. We need to remain a user-first platform. This is one of the key parts of WordPress. It's a user-first platform. We can't expose users to complications such as PHP version requirements, dependency management, all that kind of thing. If somebody barely knows what WordPress is, they've got a website running but somebody's set them up. If they barely know what WordPress is, how can we expect them to understand what PHP is, what a dependency management system is? This is the stuff that we need to abstract away from users and put the burden on developers, but it's tough. We need to do a lot of work in this area. It's a process that the whole community really needs to work on. Developer contribution to WordPress. This includes writing code, testing new features, testing bug fixes, that kind of thing. The general process of contributing development to WordPress over the last couple of years has taken the form of feature plugins. These are plugins that are built first as an independent standalone plugin. It gets developed to a mature state. It gets tested, and then it gets proposed as a feature which could be merged into WordPress once it's complete. This process has been fairly successful, or partially successful maybe. We've got a bunch of features in WordPress such as the new theme browser and various other things that have come about as the result of featured plugins. We've also got some projects which started out as featured plugins and never came to fruition either as a positive result of testing the function, and it turned out that actually it was a terrible idea or as a negative result of a breakdown in the whole development process. Helen, who is one of the lead developers of WordPress last week, well, actually only a few days ago, you can tell how long ago I wrote my slides, only a few days ago introduced a change to the development process of WordPress. We're not going to call them feature plugins anymore. We're going to call them feature projects. The entire process from idea through the planning stage and the design phase and the development stage and the testing phase and the implementation phase is going to be approached as a whole, now as a project instead of just a plugin. The aim is to attract and retain users who have got much more of a widespread set of skills. So they're not just PHP developers or CSS or JavaScript developers, so we can get more designers on board. We can get user experience experts on board. We can get testers on board. The aim of this is just to get a much wider range of skills brought into the WordPress community. This is a really positive change. I'm actually looking forward to seeing how this is going to work. I haven't got my choice quote up. Most feature projects will start as ideas that need exploration to be more fully formed or fleshed out before implementation. You can read Helen's article on make.wordpress.org if you're interested in how this new process is going to work. That's a real positive change. Where does that get us so far? We've got localisation, we've got accessibility, we've got developer relations and developer contributions. Well, WordPress is a platform as a whole. If we can nail all of these, if we can get all these right, then WordPress actually becomes really compelling for a large number of users that would otherwise potentially look at more modern platforms. Very few modern platforms are mature enough to have things such as a mature localisation platform that we're lucky to have in WordPress. They don't have mature accessibility standards and they potentially don't have mature contribution standards and a platform for doing so. If we can get all of these right, even though WordPress remains a piece of software that might not have the latest tech in it, it's actually a really compelling platform. That means that the reach of WordPress increases greatly across the world basically where WordPress isn't being used so much at the moment. These four points really, really let us increase the reach of WordPress in those areas. Let's get on to something a little bit more controversial now. The project direction or lack thereof, WordPress has never really had much direction. This stems from the fact that it started off as a piece of blogging software. If we remember back to the description of WordPress from the WordPress.org website, you can see that the description is very open-ended. It looks a little bit like all things to all people. It's not very well-defined. Does that mean that there's a risk that WordPress will become a jack of all trades? I think without direction, without strong leadership in the WordPress project, there's a real danger that WordPress becomes a jack of all trades. WordPress now powers lots of large websites. It competes in the enterprise industry and it's now got a REST API that allows WordPress to be a headless CMS to completely decouple the admin area from WordPress completely. You could use a WordPress website without even seeing the admin area at some point in the future. This does mean that there's a potential for features in WordPress to become mediocre and we've got some already. The WordPress import and export system. This doesn't get much love because it's completely useless to anyone who has a large-scale WordPress website. It just doesn't scale. It's slow. It's inefficient. It will crash. It will run out of memory, all those kind of things. People who are building large-scale websites on WordPress don't use the built-in importer and exporter. Conversely, small bloggers who have got a site that maybe has been around for quite a few years, they can actually end up with a lot of content on their site. If you're publishing a couple of articles a day over the period of five years, you're going to end up with a lot of content, but the importer and exporter still doesn't work for you. The importer and exporter doesn't work for large-scale websites and it doesn't actually work for small-scale websites either. It's a mediocre feature. We've already got a mediocre feature in WordPress. If WordPress had more direction, if we were to make a decision and say, hey, we're going to do a release that focuses on making migrating to WordPress much easier, then the importer and exporter would get a lot of development input from people who want to fix it and it would get better and then it would have direction and it would be a good feature. It's not a good feature at the moment. Another area, a slightly more modern one, the REST API, or is it a WP admin API? By default, even though we've got the infrastructure for the REST API in version 4.4 of WordPress, you can't do anything with it unless you install a plug-in which provides the endpoints for interacting with the data and the structure on your website. The reason for that is because the endpoints that are needed for that are still under development. The introduction of these endpoints was delayed recently due to the lack of clear direction about the REST API. Is it an API that provides a simple means for users to consume the publicly accessible content on a site? Or is it meant to be a complete replacement for the WordPress admin API? The lack of direction from the REST API there has actually put the project in jeopardy because we're now questioning what we're building for the REST API and it's caused a lot of tensions within the WordPress community. We need a plan, a grand plan. We need some longer term goals. We need to decide on the direction of WordPress and we need to allow those decisions and those plans to drive future enhancements and new features in WordPress. WordPress lacks some leadership that it's never really had since it was started in 2003. I think it's time for that to change and the community needs to have some strong leadership that it hasn't seen for a long while. I'd like to start that discussion and I'd like to start it here and I'll be publishing an article about it, maybe on my blog or something in a few weeks time about my in-depth thoughts on leadership within the WordPress community so look out for that. I'm going to leave that there for now and I'm going to finish up on a slightly more positive note. The open internet, so we all love the open internet and WordPress has long supported open data standards such as RSS and our embed and more recently JSON in the REST API. These open data standards enable the open freedom of exchange of information across the open internet and it's important for WordPress's future that we maintain an open internet. The governments of the internet as well is important to the future of WordPress because it's important to the future of the internet as a whole and if we haven't got an open internet then we haven't got much of WordPress. So a big thing that the WordPress community can do to help the project move forward in the future is to start to get involved with some of the organizations on the internet which promote open standards, they develop open standards, they fight for net neutrality and campaign against unnecessary regulation and surveillance. So in a few weeks time I'm going to announce an outreach program for WordPress and the idea is to get more people from organizations such as Mozilla and the Open Rights Group to get involved with WordPress and vice versa. Hopefully we can attract some people from those groups to word camps to local meetups with the idea of giving these kind of organizations much more exposure within the WordPress community than some cross collaboration. So look out for an announcement on that within the next few weeks. Now I'm a little bit short on time so we've got some good time for questions and discussions. If anybody's got a question we've actually got a good 10 minutes for questions. OK, just a small question about APIs. So you told it has been postponed. Do you know any plan, any thoughts about dates, discussions? A short answer is no. So for those who don't follow WordPress core development closely the original aim was that the infrastructure for the API would go into version 4.4 which it did back in December and it would go into version points which are required for actually dealing with the interaction of the API with data and structure on your site would go into WordPress 4.5. Now that hasn't happened due to like I said, the lack of direction around the rest API. So it's not going to arrive in WordPress 4.5 which is due out in a few weeks time. If I'm honest there's a very complex question of what the API is has been raised. That means that we're potentially looking at nine months or a year away from now for the rest API unfortunately. Now the WordPress rest API plugin is still in development so you can have your WordPress 4.4 or 4.5 site and then install the rest API plugin on there and then you get the endpoints that are under development so then you can build rich admin API as a whole but by default users who don't understand that kind of thing aren't going to have that kind of functionality available on their site for I'll be surprised if I'm honest to see that in the next nine months unfortunately. John can you tell us a little bit more about the controversy around the API. I know you talked about it a little bit but for people that have not been following you can just sum up what are the different positions regarding the API being included or not I think or. Yeah okay so it kind of comes back to the question of what is WordPress. It's a publishing platform but most end users maybe users who aren't technically minded when they think of WordPress they think of the admin area they go and log in they've got their menu at the side posts and pages they might have a settings screen and a user screen but there's quite a lot of stuff that you can do in the admin area on top of your content so for example there's a there's a terrible feature in WordPress that nobody likes which means you can edit plugins and you can edit your live theme right from within the admin area in WordPress and you can also change a bunch of settings on the site and you can manage users and you know everything that you can do in WordPress through the admin area. The question that was raised was should the REST API provide everything that the WordPress admin interface provides so should it have feature parity with someone who just logs into their WP admin area or is it actually just a feature which provides an easy way for third party sites to consume the public content on your site so is it something that's just meant for reading posts and pages and getting lists of categories and tags and that kind of thing and that question there whether it should be basically a replication of the admin area via the REST APIs is the core is the core issue there because the original plan was for that not to be the case nobody has worked on a plugin editor that works via a REST API because nobody would think that was a good idea in a million years and a lot of the settings in WordPress aren't necessarily things that you would want to set through the REST API so so yeah that could be a path forward so we could maybe continue sorry that gentleman said maybe we should split those into two so we have a REST API that provides the ability to consume public content and then maybe an advanced API that provides all of the admin features that we would otherwise expect in the admin area the problem there is that nobody is working on the latter nobody is working on these features that would bring it to feature parity with the admin area could well be that the decision is made actually to continue with the REST API as it was planned and bring it to a good state for developers to use and then look at feature parity with the admin API at an unknown point in the future it's basically an unknown at the moment when we need to make a decision on it and by we I mean everyone any other questions or discussion points thanks very much