 Hwyl. OK, mae'n gwneud. Rydych chi'n cymryd. Hei, hon. Mae gennych amser ar y front. Nid yn ei gwaith. Mae'n gwybod. Mae'n gennych. Mae'n gweithio. Rwy'n gweithio i chi ddim yn gweithio. Mae'n gweithio'n 5.2 oed. Mae'n gweithio'n 5.3 oed i'n gweithio'n 5.2. mae'n oeddo i'r cyfnod i gyn supportersau pan i gael y ddweud y cyfnod. Fe wnaeth eich ffordd. Yn ymwyaf yma ymweliadau, bydd fydd yma'r ymddangos. Ymwyaf yw'r ffondasig yw casmar. Mae'r cyfnod yw'r cyfnod yw'r cyfnod yw'r cyfnod yw'r cyfnod yw'r cyfnod yw'r cyfnod. Mae'n fwyaf yw'r cyfnod yw'r cyfnod yw'r cyfnod, ond yw'r cyfnod. We don't really have Wordpress as we expect it today. There are three current supported versions of PHP 7.1, 7.2 and 7.3. And if you go on the php.net website, you'll be able to see what the road map of these supported versions are. I want to highlight one particular thing on here, which is the way they talk about active support and security support. So, once a version of PHP is released, it has active support for about two years, which means that bug fixes will happen and there are small increments. And then it turns into security support for one year, where only security critical things happen. And that's quite important because even today, security releases for PHP 7.1, 7.2 and 7.3 were released, I think, this morning or last night. Now, you've probably noticed that 7.1 is in orange and I've highlighted it even more here. And that's because the active support, if everyone remembers what today's date is, ended last December. And the security support has started, which means we've got eight months before that is also end of life, which makes me feel like this cat. So, if we're going to talk about WordPress and PHP, we should actually look at what versions of PHP people are using to run their WordPress sites. And there is a pie chart for that because there always is. On the WordPress.org website, there's a lovely page called Stats. And you can find out lots of information like WordPress Stats and PHP Stats. And this is the stats from not today, but yesterday. And I doubt they've really changed that much overnight, unless you've all gone and upgraded PHP, which is fantastic. And I can just get off stage. What you can see from this is over half or just under half of versions of PHP people are using are 5.6 and 7.0. Now, the end of life for those two editions of PHP was December last year. So, these are not getting any of the security updates that were released this morning, which makes me feel like this. The whole greyed out area is all the unsupported, non-secure versions of PHP. And it makes me just cry a little bit inside. And it's not just one zombie. It's really a whole army of them. It's funny. And I have done this talk multiple times in different iterations. And the pie for supported versions is getting bigger, but we all have a hand in this. We need to check if we have a zombie PHP lurking in one of our websites. How many of you here can be confident that you have a current version of PHP running your websites? That's not all of you. So, some of you have homework to do, but it's really easy. There is always a plug-in for everything in WordPress, and this includes PHP. You can download the Site Health Check plug-in, and that will tell you what version of PHP you are running. So, you don't have to try and work out where it is in C-panel. You can just look on the inside of WordPress, and it will tell you in the dashboard, which is fantastic. The good news, WordPress works on all the latest versions of PHP. It's one of the first projects to run on the latest versions of PHP, so we are doing good in that sense. But it's always the custom code, the plug-ins, the themes that we actually need to check. There's a tool for it, like all good things in the tech world. There's a tool for everything, and there's a tool called Static Analyzers in the tech world, and basically, they're spell checkers. They check for your spelling mistakes in your code, and they'll check against different versions of PHP, but they do not check that this code makes sense. So, the sentence might be gibberish, and it will pass. So, if you're not a developer, but you want to see whether your website can be running on a later version of PHP, there are solutions for you. Like all good things in WordPress, like I just said, there is a plug-in for it. The lovely people at WPA Engine made a plug-in of PHP Compatibility Checker, and so you can download this. It gives you a screen like this. Unfortunately, it doesn't do 7.3 at the moment, but I did talk to them last night. And it does go up to PHP 7.2 at the moment. And you can also scan between active plugins and themes, or scan all plugins and themes. I recommend all plugins and themes, and I recommend 7.2, because 7.0 is already dead. You end up with a search result page like this, and it means that you will know which plugins and which themes are compatible and which are not, and which you're going to have issues with. Scenario two, you're a developer, or you're a techie person, and you're working on a project, and you want to check if your code is actually going to work on 7.3 as you go along. There are tools for this. Now, there's 12-minute talk. I'm not going to explain how you do this, but there's a good thing called Google, and other search engines are available, so you can just search these tools. It is pretty simple for somebody who doesn't write that much code anymore. I even managed to do it yesterday, so you can all do it too. I would like to highlight PHP Compatibility WP, because that actually removes some of the false positives that you'll see in the regular PHP Compatibility one that the whole PHP community uses. Where in your development workflow you might do this, you might do this locally, manually, on your terminal. You might do this as a pre-commit hook, and you might do this as a pre-deployment hook as well, depending on what kind of system you're using in your company or on your own workflow. I tend to do it locally just because I'd rather see my mistakes myself before the rest of my colleagues see it, but it's up to you. If you run it locally on the terminal, this is one of the first things you'll see, which if you're not a developer or you don't like the terminal, it can be a bit daunting, but it's not too bad. It's just a graphical representation of what's going on. It tells you the number of files it's checking. This was a very basic version of WordPress. If it's got any dots, that's a good sign. If there's letters, that's a bit more problematic, and what you want to aim for is no letters, basically. Especially no ease, no errors found. Warnings. You can get away without it, but I recommend listening to them. Ss, I haven't actually worked out why that happens, so someone can tell me later. That's great. After it does all the scans, you end up with a report of all the errors and the warnings, and it ends up like this. This is really useful, too. You end up with information about which file the error or the warning was in. It tells you exactly what line in that file they found the error. It doesn't mean the code was there. It might be somewhere else. It also tells you what type if it's a warning or an error. Most importantly, which is what I think is important, is this piece of information at the bottom of each one in the brackets, which is the rule that the error broke on. You can actually take that rule, put it into search engine of your choice and find out what's going on. Lots and lots of people have documented how to fix these things because a lot of people have already migrated up to later versions of PHP. I also mentioned WordPress coding standards, which will tell you about deprecated functions in WordPress as well as in PHP, so please also use that. If you have a site which has errors, then you need to migrate. It's like moving home. Your best friend will be the PHP.NET manual. In there, the documentation is very verbose, and they have examples of how to move stuff. They'll tell you the backwards compatibilities, what's deprecated, new functions that you can use, and also the changes, which are important. If you're going to start migrating your code base, depending on where you are, the larger the numbers of PHP you're having to migrate from and to, the more work it's going to be generally. If you're having to migrate from anything which is five points something to seven, that's where the most of the work is, and the lower the number, the more work you need to do. Start out your current PHP version. Use the static analyzer to work out where the problems are going to be. Check PHP.NET for what you need to do, and then do it, and keep repeating this until you get to where you want to be. On the appendices to the side here, it actually has every single migration from 4.0 all the way to 7.3, so you can do the whole entire migration. They are some caveats because it's technology, and it wouldn't be technology without caveats. Some functions, outputs in PHP have changed their outcome, which means if you're expecting a particular thing, it might be something else, which is fun. A static analyzer or spellchecker is never going to find that for you, so you might end up with quirks when your client is working on it or you test things, and those are runtime errors, and they can't be detected by spellchecker. There are lots of upsides, though. Better performance. If you're on a small site, it's not going to see much significance, but if you're on a big site, you're going to see at least the benchmarks around double the amount in terms of performance. If you want to save polar bears by upgrading to anything higher than PHP 7, you're going to be using less computing resources, which means more polar bears happy. It means that bugs that we have been hashing together and putting plasters on and outfix, especially things like PHP datetime, it also means we get security support, so that's always a win, and there's lots and lots and lots of other new features and functions, but 12 minutes and one minute to go. If you care about keeping your WordPress site up to date, then you should also care about keeping your stack up to date. The foundations of your house are super important, and this is no different. Developers and hosting companies are your friends. Yes, we charge you because we need to eat money, eat and pay our mortgages and live, but if you're a plug-in author, there's way more information. There's lots of work in the community that we've been doing, so we can actually set the standard for everyone, and there's a whole bunch of resources on the internet, but my favourite is the Lorna Jane talk at Workup London in 2015, which was a long time ago, and also a whole bunch of stuff there. My slides will be online. Kitas.