 Okay, my name is Krzysiek Druszt and I will be speaking today about updates. It will be a rather hard presentation with a lot of technical stuff, so don't worry. You don't have to remember everything that you will see today. The slides will be online, so you can always go through them later on. You know, who am I? My name is Krzysiek Druszt, not Jana Maliszowa. I'm the owner of WP Magus. It's a software house where I develop websites and so on. I'm also doing some stuff for WordPress itself. For example, I'm a core contributor. I'm also a translation contributor. I've organized two WordCamps in Poland. I'm also a speaker at WordCamps, for example, something like 7 or 8 for now. I'm organizing WordUp Wroclaw. It's a local event for local community of WordPress. You may know me if you use WordPress Tag Exchange. I'm a moderator in there. I've done some work for Prochnik, Skalmet or Polish Ministry of Education. Updates. We all know this screen, right? One question for you. Are you developers, bloggers? How do you use WordPress? Do you use WordPress at all? Okay, so maybe this way. If you are a developer, hands in the air. Yeah, okay. Let's wake up. Great. We all know this screen, but have you ever think about where does it come from? I mean, not the screen, but this part, right? The actual part that says that there is a new version of a plugin. Well, from my experience, not many people ask this question. It just is as it is, right? So, first thing, WordPress sends a request to a server. It is a WordPress server which holds a WordPress plugin repository, right? This is the server that is storing the info about updates. How does it send this request? Using Kron. When I'm saying Kron, I mean, of course, the WordPress Kron, so WP scheduler, right? The same tool that is used for publishing future posts and so on and so on. Okay. So, how does it send it? And how often? So, first of all, WordPress sends, when I mean sends, it uses HTTP API, right? So WP remote posts and so on. And it sends every 12 hours, so twice a day, right? So, if there is a new update, then you will know about it after 12 hours at the worst case, right? And these are the events, event names that are used for WordPress Kron, right? WP version check. This is the event for checking the version of WordPress itself, core version. WP update plugins. This is the event for checking if there are new versions for plugins. And WP update teams. This is the event for checking if there are new versions of teams. Okay. And how? What next, right? So, there are three functions in WP includes dash updates, slash updates, right? The first function is WP version check. The name is the same as the event, right? So, it's easy to find. WP update plugins. And WP update teams. These are the three functions that are used for checking the info about the update, right? All of these functions are documented so you can read more about those functions. And here are the URLs that are sent by those functions, right? So, WP version check uses, asks API WordPress org, slash core, slash version check, slash 1.7, right? So, if you want to know the newest version of WordPress, you can always go there. And there's the information about the newest version. If you want to know newest version for plugins, you can ask this endpoint. Of course, you have to send some data to it, right? Okay. Notice, and it's important, these functions have some plugs, have some hooks in their code, right? Because all of these requests are sent with HTTP API. It means that we can use this and this filter, right? So, HTTP request arcs. This filter we can use to modify the arcs that are sent to the server. And HTTP response. This is the filter that is run just before returning the response, right? So, we get the response. And then fire this hook. And then do something with the response, right? So, for example, we can delete all the response content, right? So, no updates will be sent. And of course, there's an action, HTTP API debug. So, we can debug and log and so on. Okay. So, we have the info about the newest version. What then? We have to display it in the dashboard, right? So, the response is stored as a transient. Do you know transients? Yeah, of course. Great. Transients are some options that are valid only for some time. For example, we say that this option should be stored only for, should be valid only for one day. After one day, we won't get the value. Okay? It's invalid, so we have to get it one more time. Okay. So, the response from the server is stored as a transient. So, it can be displayed without sending the request all the time. And these are the names of the transients. Update core. This is the info about core. Update plugins. And update teams. And once again, this part is boring, right? Because, okay, those are the names and so what? Well, it's not so boring because if these are transients and we know their name, we again can use some filters to modify it. Okay? And these are the filters. Press a transient and transient name. This filter allows us to modify the transient, the value of the transient, just before it is stored in the database. Okay? So, we get the answer from the server, we can modify it and store in database the modified version. Okay? And transient underscore transient name. This is the filter that is fired every time the transient is checked. So, every time when you check what's the value of the transient, this filter will be fired and return the value, right? So, we can modify... We can store original value, but modify every time we want to, right? Okay. This is the boring part because now I will show you some parts of WordPress code itself. How does it look? You know, the story that I've told you already, how does it look in the code? You don't have to remember it. So, just, you know, you may go to sleep for five minutes or so. Okay. So, this is the function WPversionCheck. I've already told you about this function. As you can see, it takes some parameters, but they are not important for us. And what does it do? Well, first of all, it takes current knowledge about updates, right? It checks the transient. It checks some translation and so on, and so on, and so on. Then it checks if the check is... If it's a false check, right? If it is, then it always will be checked. And not ignored. Here are the locales for your site. Here's checking when it was checked, and so on, and so on, and so on. Some checking if it's a multi-site or normal site, right? Here is the query. So, as you can see, there is a version, PHP, locale, maysql, local package blocks, users, multi-site enabled, initial DB version. What does it mean? All those values will be sent to the server, WordPress server. So, these are the usage statistics of your site, okay? They are sent to the server, so WordPress knows it. Here is the filter that allows you to modify the parameters that will be sent. Yeah. Here is the URL. I've already showed you this URL, right? This is the address that will be responding to our request. Here is checking if we're using SSL and so on. And here is the WP remote post, right? So, this is the function used that is sending the request to the server, waiting for the response. Yeah. Here we're checking some errors and so on and so on. Then there's a lot of info more. And as you can see, here's the set site transient update core updates. Update is the object that contains all the data about new version, right? And there are some more stuff done later. Here's the WP update plugins, and it's more or less the same code. So, I won't go through this part. As you can see, it's almost the same. It just goes and goes and goes. Okay. And there is also WP update teams. Again, the same code. Request. So, what data is sent to the server? And how does the response look like? Okay. This is the important thing. Because this describes what WordPress server knows about our site and what we can learn from the server. This is the request, the content of the request that is sent to plugins update check. Okay. So, this is the data that is sent to the plugin repository just to check what are the newest versions for our site. And as you can see, here is the body of the request, plugins. And here goes the list of plugins that is used on our site. What is important is that, as you can see, Contact Form 7 is the plugin you all know, I guess, right? WP Magus FAC, it's not a plugin from repository. It's my custom plugin. But my WordPress sends info about this plugin to the plugin repository just to check if there's a new version for that plugin. Okay. And all the info is sent. So, you know, name, plugin URI, version, description, and so on and so on and so on. Okay. There's also information about which plugins are active. So, if you go to the plugin repository, and there is an info that saying how many active installations given plugin has, right? So, for example, Contact Form 7 has, I don't know, 1 million installations active, right? So, this is where WordPress knows how many. Because your site, twice a day, notices WordPress plugin repository, which plugins are you using? Okay. And also, there's info about translations that your site is using. Okay. Here's the response. And as you can see, again, there is a plugins, right? That contains information about newest version of plugins, right? So, WordPress SEO, here's the idea of the plugin, Slack plugin, new version. So, you know that the newest version is 11.3. Here's the package. This is the URL to the package, package with new version of the plugin, right? So, if you go to that link, you will get the zip package for the plugin. Here are the icons, banners, and so on and so on. And there is also translations, all right, and no update. This is the list of plugins that doesn't have newest version. So, there's no update for them, for now, right? Okay. Again, teams, almost the same case, right? So, there's an array with teams, 2017, 2019. Active is 2017, right? And again, the response, team 2017, there's new version and so on and so on. Right. So, okay. This was the part that we were checking how WordPress checks the new versions and what data is sent and what data is get from the server, right? So, if we're already wiretapping and listening and checking our WordPress, do you know where this comes from? You know, all that information. You know, when you're on the plugin screen, you click more info about the plugin, right? And there's this screen, your cell, the banner, the description and so on and so on. Anybody? Yeah. Yeah, it's from WordPress repository. Here's the response you get from the WordPress repository. And here is the request you're sending, right? So, if you want to check the newest version and get the data about, I don't know, contact form seven, then you have to go to api.wordpress.org, slash plugins, slash info, slash 1.2, this is the appy version, slash action, plugin information, request, blah, blah, blah, Slack, WordPress SEO. So, for example, Slack, contact form seven, right? Locale PLPL, because I was checking for Polish version of the description. And here is the response, right? So, you're getting the name of the plugin and so on and so on. You can always get, you can also get rating of the plugin, how many support threads are on the forum, what else? Active Instals, the number of active instals, last updated and so on. So, it's pretty nice info, right? And you get it in JSON format, so it's easy to parse. Okay. There are also, as you can see, links to all, well, not all, but to all the versions of the plugin. So, for example, if you updated some plugin and you have problems, you can also downgrade by going to the link like that, downloading the plugin and replacing the files. Okay. So, what happens when we click update? We have all the info, we have seen the notice, we push update. Well, an instance of one of these classes is constructed. There are three classes, four classes that WordPress uses. Core Upgrader, Plugin Upgrader, Team Upgrader and Language Pack Upgrader. Again, all of these classes are well documented in the codex, so we can check it later on. The important thing for us for now is that all of these classes are using pre-auto-update and Upgrader pre-download and Upgrader process completed filters and much, much more. Okay. So, we can hook our code in there. Okay. So, this was the boring part. So, how can we use this knowledge? Okay. So, we spent around 15 minutes listening some boring, boring technical stuff about how WordPress does it, but what now? Well, this wasn't useless. Okay. You can really use this for your projects. For example, one of the applications is you can hide some or all update notices. Okay. How? Well, as I've shown, you can modify the response from the plugin repository. Right? So, if you write some code, use the hook, for example, press Transient, press Transient Set. Right? Then you can modify the response. So, you can empty the response. So, no updates will be shown. This is one usage. I don't recommend it. This is the part I might recommend. Notify users, but prevent them from doing updates. So, if you go to the dashboard, you will see there is a new version of Contact Form 7, but you won't be able to click Update. Why? Because, for example, I'm doing maintenance for the site, and the site has many users that are just using this site. Right? And there is some guy or girl in the, you know, office that always wants to click everything. Right? So, this is the way. She will know that there is a new version. He can call me and say, hey, we have to update this plugin, but he won't be able to click it himself. How? Well, it's pretty easy. All you have to do is to use again the filter to setting Transient and delete the information about the URL of the package. If the plugin info won't have that URL, it will show that there is a new version, but it won't show the Update plugin because it's unable to update. Right? And we can use Preset Transient filter. This will allow us to modify the information in the database. Right? But we can use also Transient name filter. This will allow us to modify this value every time it's read. Right? So, for example, we can check which user is logged in. So, for example, we can show if I am logged in, the button will be shown. But for example, if Peter is logged in, the information won't be shown. He won't see the button. Right? Another usage. Allow updates for custom plugins themes. How? Well, you can also hook to the Preset Transient, send your request to your own server, get the same response that WordPress plugin repository is sending, and show that there is a new version of your custom plugin that is not in the WordPress repository. Right? Well, another usage. Log who updates what and when. So, for example, if Peter is clicking Update, then we know that Peter is the person who we have to blame for the not working site. Right? Okay. Any other ideas? Come on. What else would you like to do with updating, with the knowledge you've got today? Come on. Okay, maybe later. Last part. Problems, tricks, and so on. Anything we should be careful about. May this cause any, this way of doing it, cause any problems? Can you think of some problems that may occur during the update and how it works? The main problem is name conflicts. Because as you've seen earlier on, even custom plugins are sent to the plugin repository. Right? For example, let me say it this way. Let's say I've wrote a custom plugin that's called Hello Dolly. What will happen? WordPress will send the request to the plugin repository. Hey, this site is using Hello Dolly plugin. What's the newest version of that plugin? WordPress repository knows a plugin that's called Hello Dolly. So it will respond. Well, the newest version is 10.1. WordPress will say, okay, I have version 1.0. So I have to update. If you click update, what will happen? Your custom plugin will be deleted and replaced with the plugin from repository. Right? So you have to be very careful when you write your own plugins and teams. You have to be very careful how do you name them. Right? Because the name conflicts is pretty dangerous because it may be overwritten. But of course, you can prevent it from happening. How? Again, you can check. You know that this site is using this plugin. Right? And it's a custom plugin. So you can use all the filters and so on to make sure that WordPress repository won't know, won't get the request for the newest version for your custom plugin. And even if WordPress repository will send any information about that plugin, you can ignore it. Right? No update will happen. Right? Okay, so that's all. Thanks. Does anyone have any questions? Any questions, please? Yeah, don't be afraid. I don't bite. Sorry, so your presentation will be available online? Yeah. Yeah, it will be published online. I will send it to... Well, I've already done. So you may publish it, the link to it on the Facebook fan page. Yeah, and the video, it will be on WordPress TV. Yes, always. At least, I always try to. Right? Because the worst thing in the world is that you do update the site crashes and then you have... It's Friday evening and then, you know, the owner of the site is calling and he's calling your names and he's angry and you don't want it. Right? Yeah. Well, I always check the code differences between versions. So I have all the sites in the Git repository. So when I do update, I can always check what are the differences between those two versions and try to check what they do. Okay? So, yeah. Yeah. Yeah. It's not easy. Some time ago, there was some software called Perfect Dashboard. They've been sold this year, I guess, so I'm afraid they are not available for now, but it allowed you to do the update for the remote site. There was something like WPManager or something like that and it was doing some automatic checks how the site looked before and how it looks after the update. So you had image before after and if the images were different then you could check what's the difference, right? So you know that this button is deleted or something like that. Okay, I think no more questions. Thank you. Thank you very much.