 Thank you guys so much for showing up for the last session today. I know it's been a long day. It has been for me as well. Thanks again. Shiny Updates is what I have in store for you. I don't have a whole lot of content prepared. I thought that if we finished early today, we either all go have a beer, or I can answer some more questions about either Shiny Updates or feature plugins or Core in general. I'm sure we will find something to talk about. So Shiny Updates is going to be a feature plugin in 2x, like I say on the screen. You could also say it is the freshest feature of WordPress 4.6 coming up in August of this year. WordPress 4.5 is in its final days of the release cycle. Actually, the picture of the beer with a cat, I shot that at Mike Shorter's house when we were working on the release candidate for 4.5 a couple of weeks ago. So 4.5 is scheduled to drop next Tuesday, April the 12th. And after that, 4.6 is coming up next. And Shiny Updates, I'm really hopeful that this will be part of the next release and we can share it with the community. One of the things that feature plugins need to have is a statement of purpose, the goal that you try to achieve with that feature plugin. And for Shiny Updates, the biggest goal we have was to get rid of the bleak screen of sadness. A term coined by Michael Arsad, he's a designer automatic and he's been helping tremendously with Shiny Updates. And I'm going to show you what I mean with the bleak screen of sadness. The goal is to make that disappear and make it a lot easier to manage plugins and themes from WP Admin across WP Admin. One of the things that we see all the time when there is new updates available is that users react kind of like this, you know. It's really not a great experience. We all know that. So updating is one part. Another part is installing new plugins and themes. So this is an example of how it looks like when we install a new plugin. We hit install now and we are greeted with the screen of sadness. You have information that no one needs, no one knows what we're talking about here. People don't understand. They're confused by it and we need to get rid of that. It's not something that provides a lot of value to users. And so improving updates is something that can go a long way in that WordPress Core has been trying to do for the last two or three years more than ever. WordPress 3.7 introduced the possibility for WordPress to ship automatic minor updates to your WordPress installation. That was about two years ago when we started doing that. So every install since can be updated automatically unless there is an edge case that prevents that. Like you have a test site that runs on SVN, right? So we couldn't update that, for example. The major goal for that was to combat update fatigue, something that if you're a plugin developer and you ship new versions, you probably experience yourself. When users just reluctantly update your plugin and don't enjoy or get to enjoy your bug fixes and new features. By pushing out background updates across work presses around the world, the core team is really able to close security holes within 12 to 24 hours, even faster if need be. So that has been a major milestone for WordPress in terms of keeping WordPress installations up to date. Updating themes and plugins and languages is just another step in that direction. Or improving that, rather, is another step in that direction. And so when WordPress 4.1, I just asked actually John Blackburn. He was the release of 4.1. And I just asked him how did it actually come about? Who had the idea to start shiny updates? And he doesn't remember either. So it just happened. There were people who came together and they thought we should improve updates. So that happened to 4.1. Due to time constraints, there wasn't really anything that went into version 4.1. But in WordPress 4.2, which is Act 1, if you want, we had smooth updates or smoother updates from the plugin screen, so the list of installed plugins on your site, and also from the plugin install screen. So if you look at the install screen and you browse popular plugins, for example, and plugins that you have available on your site already that are in need of an update, you can then go ahead and update them from that screen as well. So we have updates. At the time that people worked on shiny updates for 4.2, we briefly had smoother installations as well as bulk updates available. But we needed to cut that in order to make the feature ship with 4.2 limited in scope in order to make it happen in the first place. And so we're ready for the second act. But before I want to talk about that, I want to dive real quick into the concept of feature plugins. We do feature plugins. And what does that mean? In WordPress 3.6, the core team was working on an updated user interface for post formats. And it was something that dragged on for a while longer than anticipated. It eventually delayed the release by over a month. It was a pretty painful experience for everyone involved, especially Mark Jacobith, who was the release lead of 3.6. He actually talked about his experience here at WorkCamp London two or three years ago, sharing his lessons learned. And one of the lessons learned was that we needed to find a solution to how we can work on features without having them delay releases. And so feature plugins was the first attempt in doing that. It had the advantage of being asynchronous to release development. It could be developed anytime. Also it allowed us to iterate faster on those plugins because we removed the committer bottleneck. We have a limited amount of people who are allowed to commit code to WorkPress Core. And with feature plugins, we kind of get rid of that. We can allow pretty much anyone to commit code to that plugin and we don't delay releases with that. So there was a lot of wins on that front. We had a bunch of good examples of features that went into WorkPress that were developed as a feature plugin first. For example, menus in the customizer that were introduced in 4.3 and many, many others. I think Ombed was also something that was developed as a plugin first. Most recently, a selective refresh for the customizer was something that was also developed as a plugin first. So pretty much in every release, we had something that was developed as a plugin where we drew things that other people contributed to core outside of core committers necessarily. This is a process that we continue to iterate on. So Helen Hussendi, one of the lead developers of WorkPress, she recently published a post on Make WorkPress Core suggesting a new term for feature plugins, which is feature projects, to kind of show that it doesn't necessarily have to start with a plugin. You can do some experimentation, do some research. And you might end up at a point where it doesn't need to be a plugin to develop that feature. It could be just a small core patch or something else that doesn't necessarily need a plugin to work. And so we continue to iterate on that and an experiment with feature plugins. Shiny Updates is one that originated out of my desire to finally finish the feature of smoother management for plugins and themes, and also a desire of the core team, really, to find another plugin that could be used as an example for how future plugins should be developed, right? Someone is waving in the back. Not me? OK. Cool. By the end of November last year, right before WorkCamp US, we had a committed meetup in New York. And we talked about pretty much everything around WordPress, the projects, WorkPress Core, and also, of course, the concept of feature plugins. And as I said, people asked, could we have one plugin that could serve as an example for other developers and other feature plugin authors? And so I suggested Shiny Updates as that feature. And the people who have contributed to the plugin so far and I, we put a lot of effort into building it by the book, if you want, making sure that we have regular meetings. We have user tests. We have documentation. We have give people access to the plugin, commit access to the plugin as soon as they start showing some kind of interest. Have it sync over to the WorkPress.org plugin repository for people to install on their sites and test. So we made sure that all of these requirements were met. And it helped a lot in terms of keeping the quality high and getting people interested in helping out with the plugin. One of the problems though was the lack of participation from the general community. It was pretty much me and two or three others who worked on or have been working on Shiny Updates so far. There were all augmentations, too. So most of them are actually did that during their daytime jobs more or less. And so one of the things that I'm really looking forward to is having more people involved from outside of automatic. I think I lost my mic. OK, I don't. From outside of automatic, just to get more community involvement and represent a bigger part of the community with that feature. So I want to talk about it real quick in terms of theoretically before we start doing a demo, which I'm really looking forward to because is what could go wrong. So these are the things that we wanted to improve with plugins and themes. These are the actions, installing a plugin, installing a theme, bulk updating plugins, since we can already update single plugins, update themes, delete both. We decided to not do bulk actions on the theme side because we figured out that it doesn't matter if you select every theme and then an action or rather perform the action when you click on the theme. So we went with that and just queued regular updates instead of doing a bulk update, for example. And also activation and deactivation is something that we decided not to do in a way that doesn't require a page refresh. The reason for that is that especially plugins have the tendency to redirect you to a settings page, for example, on the next page load. And so what would happen would be you would activate a plugin. And since there is no page load, you just go to, I don't know, you want to write in a post. So you'd go to the post section. But hey, you're being redirected to the settings page and held hostage by the plugin, which is a really bad experience. So we decided not to do that. Also, there's currently not a way to make sure that if you activate a plugin that way, that it doesn't fatal your site. So it might end up in a situation where you activate the plugin and you can't access your site anymore, which is also not something that we really enjoy. So we decided not to do that, but rather do all the rest of that. Another challenge that came with that was that you can manage plugins from six different places in WPF. You can manage them from the plugin list of install plugins. You can manage them from the plugin install screen. You can do both for multi-site. So you have two more, which is four. And then you can manage them from the details iframe. So when the plugin is hosted at the .org repository, you have a link that says more details. And it brings up a modal with its page in the repository. And from there, you can also install or update your plugin. And that is also duplicated for single and multi-site installations. And the same goes for themes, where you have the themes page, the theme install page, and the modals of the preview of a not yet installed theme. So there's a bunch of places where you can manage plugins and themes, probably places that most people have not even discovered or thought of. And all of those had to be covered by shiny updates. And we had to make sure that the JavaScript who handles all that is versatile enough to be able to handle that from all these different areas. But I think it went pretty well. I have a couple of quotes, a couple of testimonials, if you want. Jeff Chandler, he said he loves it. And he can understand how they are so fast, the new way of updating it. He wonders if it was magic. He thinks it's amazeballs. We have Srinivas. I think that's how you pronounce that name, of course. He commented on a WP Tavern post about shiny updates. And he liked how professionally it looked. So I'm very glad about that. And I want to show you how professionally it actually does look. OK. So this is how it looks. We have a brand new color scheme for your update notifications right here. You all know how that works now. It's pretty much the same. It works the same way as it does in 4.2. In your work since relations already, this is how it works. If you want to delete a plugin, let's delete ThemeCheck and ask you if you're sure. And basically, it works like deleting a comment, right? It just disappears. This is where you cheer, by the way. No worries, no worries, no expectations. Let's add a new plugin. I just deleted, oh, I hope my internet doesn't, there you go. Perfect. Reactions is an amazing plugin by my dear friend Garry Penagast. Installing it looks like this. And it's done. Thank you. All right. This is going really well. Themes. Themes, this is how themes look. Let's see. We have a new version available. Right now, if you want to update a theme, you would open the modal and you have the update link now. And it would create a page refresh. Going forward, you will have the opportunity to do it through this link, as you know, or as you've known. But you can also now update it directly from the theme index, just like that. And I don't know how long it will take. It has to download the, okay, not too long. You guys are awesome. Thank you. This is great. Deleting a theme is really fast as well. Gone. All right. Gone. Don't need that theme. Adding a new one. And this is going to be the last example. Let's see. I have no idea. This looks really pretty. I see that. Install it. This might take a little bit longer. You can also install a theme from the preview, as I said, just like this. And once you have it installed, it also shows up as being installed right there without any page refresh. So it's a lot faster. It's prettier. You don't see the bleak screen of sadness. And I'm really proud of the results so far. There's also something that we've been working on in terms of the updates page right here. We're thinking about adding a setting. I don't know if that is even available. Yes. A setting to enable automatic updates for plugins and themes and also for major versions of WordPress. So you wouldn't have to worry about updating things any longer. It would just happen automatically. Pretty much. Great. So, WordPress 4.6. It's going to be amazing. I'm pretty confident that we'll be able to get that into 4.6. As you can see, or as you just saw, it's pretty far in terms of implementation. We will do a couple more user tests just to make sure that we got things right. But overall, it's pretty much ready to go. So 4.6. Now, I'm looking forward to that. It's going to be released in August this year. If you do want to get involved with Shiny Updates, please do. We'll have chats every week, every Tuesday, starting the week after next. Please go to github.com slash openland slash Shiny Updates to see the source, to open pull requests, to open issues if you find any bugs. That would be greatly appreciated if you don't feel comfortable with that. Please download the plugin. You can either go to repost.org slash plugin slash Shiny Updates, or you can search for Shiny Updates from the plugin install screen in your WordPress admin. And, yeah, activated. Test it, use it, see how you like it. If the colors are pleasing. If the actions are not as jarring as they were. Things like that. That would be greatly appreciated. Yeah, any help would be great. My name is Konstantin Ovenland. I'm available on Twitter, or github, or pretty much anywhere under at Ovenland. Please feel free to follow me on Twitter if you want. I have a blog at Konstantin.Ovenland.it with pretty pictures. I work at Automatic on a team that is dedicated to contributing to WordPress and the WordPress infrastructure. Currently, besides working on Shiny Updates, I'm also working on a new plugin directory, which is scheduled to be released within the year. So you can look forward to that as well. I'm from Germany originally. I now live in Southern California, where it's actually usually pretty nice. I really like the weather. I don't surf. And if you have any questions about any of these topics, now is the time. First question. That's exciting. It's going to make life so much easier. One thing that in the back of my mind is that, yes, Automatic Updates for WordPress Core is brilliant, but is it going to be an emphasis on getting people to update plugins on a more frequent basis to make them compatible and also secure with the changes in WordPress Core? Right. Do you mean in terms of the screen that I just showed you? One of the challenges I think we face is that WordPress updates very, very regularly, and that's brilliant, but the plugins don't update so regularly. So the concern is as WordPress moves on, are the plugins going to leave holes behind because they're not updated as regular? So is there going to be an emphasis on encouraging plugin developers to keep up effectively? Right. So there already is. The plugin team does a lot of to, first of all, educate plugin developers about new changes that are coming up in a new release. So we write field notes on make.wordpress.org. We send out emails to every plugin author, I think twice per release. I think once is just after RFC and one is before we release. If I'm not mistaken, at least once, right? Yeah. We'll let them know that there is a new release. We link them to those field notes. We encourage them to update the tested up to version, right? So we do all that. If there happens to be a plugin that has a known vulnerability, we have, or that the core team has in the past already shipped out automatic updates for those plugins. Jetpack, for example, has received one of those updates where it's a forced update, more or less, to make sure that we close that security hole. So RFC is able to do that. And they do do that if necessary. The fancy shiny updating, is that back then? No. What is it? It's just a JavaScript object. It's vanilla. There's no jQuery. No. It uses jQuery, but it's not in backbone. Okay, cool. Okay, that was it. I have two questions, if that's not too selfish. They're quite unrelated. We've got plenty of time. The first one is, are you doing any work on the upload of themes and or plugins? Because that choose file button is looking a bit dated now. And there are quite often times where I want to upload multiple plugins in one day. Oh, you mean in the admin? Yeah. This would be a great opportunity for version three. So yes, it's something that has been brought up before, but it's not part of that iteration on updates. But I agree, it is overdue. It is ugly. Just having a drag and drop uploader would help so much in making it less of a pain. And I'm sure that that is something that could be done fairly easily if someone puts some time and effort in it. Which leads nicely to my second question, which is do you have any idea why this particular feature project as it is now has received so little contribution? Is there something about it that you think puts people off contributing to it? I wish I knew. If I knew I might be able to mitigate that. I don't know. I honestly don't know. I don't know what it is. Maybe we've not communicated enough that we're looking for more contributions and more contributors. Maybe people didn't know that the effort was going on in the first place. It was something that I also experienced with a custom logo which I worked on for 4.5. And now with the plug-in directory as well. The plug-in directory, there are so many people who have a stake in the plug-in directory and an interest in having it be as great as humanly possible. And yet, when we do plug-in directory chats, there's two people who show up. And boys their opinion, which is me and someone else. I wish I knew what I could do to get more people involved. I mean, especially with the plug-in directory, it's something that so many people use on a daily basis. And where now is really the time to make it shine and make it behave the way that plug-in authors and users want it to behave. So if you're interested in helping out with the plug-in directory, please do let me know. A great opportunity to have a big impact on the WordPress plug-in ecosystem and WordPress history, I want to say. Well, first of all, thank you for a great demo. Thanks. No, seriously. I didn't even practice. Yes. Okay. The question is simple. If you update the plug-in the regular way, it enables the maintenance mode. So does it happen when you update the plug-in or theme with shiny updates? Yes, it does. So yes, it does. The way it works is that we send an AJAX request currently. This might become a REST API endpoint where we do that. So we send a request to our press, and WordPress checks if the request is valid and then goes ahead and uses the regular updater, the WordPress updater, that you would also use when you reload or refresh the page. And that is the mechanism that enables the maintenance mode. So it's not something that you would have to enable manually every time that you do something with it. It's just something that gets enabled automatically when you update a plug-in or theme and use the proper API for it. Maybe just a follow-up question with the maintenance mode. When you install two plugins in parallel with the shiny update, does that work good without deactivating the maintenance mode before the other one is installed? No. So right now it's two separate requests. So it would get activated. The maintenance mode would be enabled, disabled, enabled, and disabled. No. It's just a queue of plugins or themes that wait to be updated, and we send that request after the old one came back. Does this work in the background? I'm sure that I remember back in the day navigating away from a page whilst it was updating, and then my site went belly up. So I've learned not to do that, and I probably wouldn't ever do it again even if this does work in the background, but there you go. That's my question. Yes or no? So we kind of prevent you from doing that, right? So right now if you enable, if you click update and you then want to leave the page, you would get an alert box saying, if you leave now, you may lose information or whatever, and kind of gives you a warning to not do that. So you kind of prevent it from doing that. This is something that we added just to make sure. If you would have just one plugin that you would update or one item that you would update, theoretically you could probably navigate away without any harm being done, or any other requests that will complete, and it doesn't matter what the return value is really, right? It's just like making the UI, the user interface look pretty and give you a notification of how it went, if it was successful or not. The thing is though, as soon as you have more than one item that you want to update, since we have a queue, you would have to wait for the last item to start being processed before you could move away, right? Yeah, mine is about uploading files into the media section of WordPress. When uploading so many files, of course, they become cluttered, like within the media where you upload them. Could there be a way, like in the future, where you can upload them into folders, for example, within that section so that you can easily manage them? There are plugins that help you do that. I'm pretty sure that there's a core ticket that would help you organize media items. I'm not aware of where that is at, but I'm 100% certain that there's plugins that would allow you to add that functionality. Yeah, currently not something that is in core. Just a question about the plugin directory. Is there anything from a design point of view plan to really make the plugins that haven't been updated for a while stand out a lot more and possibly even demote their priority in the directory search results if they haven't been updated for a long time? I mean, I still see a lot of, you know, it hasn't been updated for two years. Is it time to review that? I may even reduce that to a year, given that how fast everything's moving with WordPress. Just wondering whether there's any discussion over... There has been discussion, and now is a great time to change that if we wanted to change that. One of the things that we were thinking about was to not... That go away from a hard two-year cut and move towards the last version number that they reported to be compatible to, saying, okay, so if you're not compatible with the last five versions, you're outdated, right? In terms of making them less accessible or, you know, findable, I want to say, that is currently already the case. So if you use search, outdated plugins don't show up in search anymore unless you happen to write their slug exactly, right? So that's the only time where it would show up. We're currently in the very beginning of thinking about the new user interface or the new layout for the plugin directory. So I can't say what that notice will look like if we just, you know, color the background red across the page or something. I don't know. But it's definitely something that, you know, you could get involved if you have an opinion there. We have on make... There's a post about wireframes and just a general idea of how the plugin directory could look like. So if you want to follow along there, because, yeah, that's where, you know, we're going to be discussing design and, you know, as it gets into more detail. Yeah, and you could talk about that there as well. Can you explain what is the React plugin and why it is a featured plugin? Yes. So the reaction or React plugin by Gary Penagast adds the possibility for you to add reactions to a paragraph of text, right? Or to a post. And why is it a featured plugin? Because Gary thought it might be hilarious to propose it as a featured plugin. And see what people think. And, of course, it was outraged, like with pretty much any other plugin that he suggests. It probably won't end up in core in the way that it is currently written. But it's a nice way to explore, you know, how you could integrate custom common types in WordPress. Thank you so much, you guys. Okay. Thank you, everybody.