 Did everybody already have a great day today? This is the last talk, I hope you don't fall asleep. I will do my best for that. To start, who are the developers in this room? Who considers themselves a WordPress developer? That's awesome, I can talk some geeky things. Who considers themselves a PHP developer? Ah, yeah, yeah, yeah. And who considers themselves a full stack developer? This is really good. So I'm going to need to up my level a little bit here for the talk. That's great. Good. Automating WordPress. But first, my name is Johan Janssen, and I'm a Juma co-founder. Now you would ask yourself, what does a Juma co-founder kind of formerly developed for us in work camps? Well, this is us, part of the 70 co-founders of Juma. There are two Dutch people here, Arno and Tringy. So Juma, in a sense, is also a little bit of a challenge. We started this 20 years ago. And we were most known or still most known for document management extension called document. You might know or you don't, but I started as a volunteer working on this 20 years ago. When I started writing my first little lines of free software. And recently, the last couple of years, more and more people started asking us, can you also make this for WordPress? So that's what we did. This is not a talk about that. But if you want to check it out, there's the URL. So we have also built our document management extension for WordPress. You can find that there. That's what brings me here. I want to learn more about the WordPress community. And I'm just trying to do that with the talk about automating WordPress. I send in, I think, five or six different topics. And this was the one that chose it. I'm not sure why. But then again, this was the one. So I was like, okay, let's do something with that. How do you automate WordPress? And when I talk about people about that, I always feel like a little bit earlier, I was talking about, yeah, I'm going to do this talk about automating WordPress. And the first thing that I told you was, that you all want to talk for that, you don't want to have plugins for it. Plugins on the plugin directory, you can find an enormous amount of plugins that help you to do exactly that. It's true. So I'm not going to talk about any of those plugins. You can find them there. You can check them out. But what if you want to automate WordPress without any plugins? And why would we want to do that? Why is it actually sometimes better to do automation without going for plugins? Well, because less is more, and less is also a little bit profitable more. As you've seen from the first couple of talks this morning, as I understand it, a lot was about sustainability and performance and optimizing your sites and dealing with all of that. You've learned that the more plugins you install in your site, the slower the site will eventually become. You need caching and optimizations to help solve that problem, right? With automation, that's a different problem because you cannot cache automation. But that doesn't really work. So if you start adding automation plugins to your site, eventually the site is going to become quite slow with all the background tasks that it's going to start doing in the background. Now why is that? All PHP developers among you. Oh, this is the speaker who asks questions. Question, why is it not so good to do automation tasks with WordPress? It's a PHP question. It clips once, it dies after the execution. It could die. No state management. No state management. Yes, another one. We're personally not made for command-line by itself. Automation is usually done here on command-line. Good one, another one. Doesn't have like a queuing system? Yes, no queuing system, definitely. Another one. ChromeJob could be executing during the report. Exactly, you need to go to ChromeJobs and they need to be available. Then you also, if you don't do ChromeJobs, you're ending up with 30 seconds problems. You have a scheduler, all right. So a little bit of context. I'm calling this, this is a little bit of history. Five minutes of web history, how do we get here? Like how do we go to this place called WordPress? Maybe because I come from a very different background that I can try to bring this to you a little bit. So very in the very beginning, there was nothing but HTML. And everybody was a front-end guy. The world was simple. There was no PHP developers, there was no full-stack developers, there was no viewing coach. Yes, it was all HTML. And it was pretty simple. We had this thing called the URL and in 1991, the web was born. And this was the first ever web page. You can actually still go to it, it still exists. Now it looks like that, but I'll go one back. This is the first ever web server. Who created this? Who set it up? Strange guy called Tim. Super easy. Exactly, right? So this is a picture of Tim, his first web server. It was actually running on his desk. He sat on his desk and turned. And he had this sticker. It's not completely clear here, but it says this machine is a server. Do not power down. Because if you powered it down, you would take the website down. No, the website, the entire time. Exactly. The whole internet in 1999 was basically running from that single machine. And this was, well, it's a copy of it, but this is the first web page. And this is what it looked like. A little bit of information about web servers, people history, and first web page running at CERN. This is how it started. And we had this thing called HTML. Hypertext market language would be used to create our websites with it. And the first spec you can find there and it looked like this. Are there still designers here that remember HTML 2.0? Ever worked with us? Who did? Yes, there. Sure. And the great thing about HTML 2.0 is that. Tables. Ah, tableless. That's a good thing. The mighty tables. Whenever we were doing websites in Dreamweaver with mighty tables, and we were putting everything in there. Iframes. Iframes, yes. The great thing about HTML 2.0 is that it actually still works today. You can still build something in HTML 2.0 and it will still work in your browser. This website, or this page, still works. At that time everything was in capitals and looked a little bit different, but this is actually a working HTML 2.0 site. And if you go to this little URL here, you can actually find the whole history of HTML and how it has evolved over the years here. It's quite interesting to see how this living standard that we have today is constantly evolving. And it constantly evolves faster and faster. We went from a version standard, calling it HTML 2.0, 3.0, 4.0, 2.0, 5.0, and now a living standard, which basically means it will constantly continue to evolve. That also makes us now front-end developers and back-end developers, basically meaning those who understand the evolution of HTML and those who became clueless. Right? I became clueless. This is as far as I go, this is it. All right, you're good. This is all great, but then you have the stable problem you were talking about, right? So you were using Dreamweaver or Frontpatch or Notepad? Dreamweaver? Are there front pages among you? Yeah, of course. Yes? Node-patterns or text-editors or Vimbers? Any Vimbers? Yes, some Vimbers there. Hardcore in the back. It's all Vim HTML, we love it. Love it. This is great, but then, you know, it's really slow. We need to find a way to build those pages faster. We need to have something we call dynamic so that we can put some sort of logic in between and it's not all static HTML we craft, but we can start doing something more dynamically. Call it the dynamolitic area. 1995. And this is where PHP comes in. In 1995, PHP FI was announced. With question, what does PHP FI stand for? Formal state. And FI? Oh, click. And the FI? Form FI, I don't know. Form simple. Form simple. Forms interpreted. So in 1994, Erasmus started working on PHP, which in the beginning was a simple CGI script he had a couple of CGI scripts for the hackers of my year. This is how we used to do these things like long ago that still work. And the problem that he was trying to solve was how can I extend my web forms and how can I easily communicate with a database? So how can I start getting data from a database and putting data into a database? That was where PHP was originally built for. That's the idea behind the language. So creating simple dynamic web applications. That's all great. And it looked a little bit like this. So I can probably zoom here in a little bit, so you see here. So this is how PHP started originally in the PHP 2 version. It's very, very much like a templating language, which was also the idea. You would be putting little scripts, little instructions in between your HTML to make it dynamic. That's the original idea. So what you see here, a method if substring from a variable. You could get an environment variable from, go back, you could get an environment variable, and you had an and if statement here, a little includes to include an additional file. Very, very much template language. Now that was not sufficient. So in 1993, in 1997, Zeef and Andy started and built PHP 3, which was the base of the model in PHP that we know today. And that looks a little bit like that. If you go back to PHP 3 script and you go back to very early WordPress, you go back to very early Joomla, this was basically what it looked like. It was getting data from a database and then at some point generating some HTML and then outputting a page. It was a mix of database calls generating HTML. Why am I getting here? Because this is the key to how PHP works and it's also the key reason why PHP isn't really good at automation. And it goes a little bit into the direction of the stateless, but there's another reason for this to our question. Yes, and it does what? It needs to wait, but you're almost there. So it goes top to bottom and each time it does an IO call, selecting the database, carrying the database, fetching the data from the database. Each time it does that, it's waiting. It's not doing anything. PHP is not an async language. It cannot do multiple things at the same time. And then when you're rendering HTML like that, that's not a problem because we need to wait until all the HTML is rendered anyway before we can send it out. Unless we do the jumping coding, things like that, it gets a little more complex there, but normally render the whole page, send it out. So this works perfectly for this use case. But when you're automating, you don't want that. You don't want to need to wait for each thing to happen. You want to have multiple things happening at the same time, which is a lot harder with default PHP. So PHP is not a async language. It's a sync language. Each IO call that you make takes time to execute and you're waiting. Okay, some points. The more database queries you represent makes, the slower the page will render it. The more data it needs to fetch, the more files it needs to reach, the slower that page will render it. So we went from making dynamic pages into something dynamic pages are great, but we don't, our customers can't edit them. We need to have something that is dynamic, that is easy to use so that a customer can easily edit our site and update it. Why is that great? That's the profit part and the fun part of the talk. Come on, guys. It basically means that you can go to the Bahamas and you need to worry about it and the customer can do the stuff, right? And then you can basically reply to your support email from the Bahamas saying, no problem, just click that button, click save and it will be all great. This is us optimizing our time, right? Being smart about it, making more profit and having more fun. Exactly, we're getting there. In essence, WordPress was not created well. It was created by Matt because he believes in everything GPL he does. He's also a really smart guy, he was optimizing his time. And the same thing for Driz, if you look at why Driz created Drupal, which was called Drop in the beginning, he was like, yeah, I don't wanna do all that work myself. Let somebody else do it, I'll let them pay me for not doing anything at all. Right? I was sitting in the meeting room earlier and I was sure there were ever two guys talking and he was like, yeah, so yeah, I'm just gonna do a little bit of support and then we're gonna tell the customer to do this and this and that, so I don't need to do it. And I was like, yeah, case in point. This is why you're working with WordPress. You don't need to do it. So there we go, 2003, WordPress was created. Making it easy, and you know all of this, making it easy to create websites and making it easy for your customers to update them. What I found very interesting is this link, 2015, where WordPress is described as a factory that makes web pages. And that's again why it's not ideal for automation because that's not the intent. The intent of WordPress is to make it easy to generate and update web pages. And that's something that PHP is really, really, really good at because it was specifically built for that but it was not really built for automation of tasks. So WordPress has a template, a web template system using a template processor. That's the core of it in a sense which in essence is the core of PHP. A little bit of HTML, some instructions in between generating HTML. Of course, in the meantime, you have built how many plugins already? 60,000 plugins. It's the same, right? 60,000 plugins to do all sorts of things which in some way have something to do with that. But a lot more too. So you went from solving that problem to solving a lot more problems at the same time. So, case in point, yes, you can use one of these to have a WordPress and there's probably a lot of good ones out there. I don't know them. I'm not a WordPress expert. But it's not always ideal. It's not always ideal because PHP isn't really built for that purpose. And you're slowly, if that automation process becomes more mission critical, are going to jump against the limitations of it. If you don't have Chrome, everybody knows a little bit about Chrome is, if you don't have Chrome, you need to go to the WordPress scheduler which is this built-in mechanism to at least do a little bit of automation. That's a very crude workaround for the problem. It works for small things, definitely. But for mission critical processes, not always. And when it starts failing, it's really, really hard to debug that part. Understanding why and where it fails. All right. If you don't agree with that, I'm happy to have a beer with you later over it. We can have a little fight and see what I can learn from you about it. But at least this is where I get it. Good. So, so now you guys conquered 40% of the internet? Yep. Yep, yeah. You guys conquered 40% of the internet? Oh, yeah. Yeah. Yeah. So humble. So cute. Conquered 40% of the internet? Yes, of course we did. So it's 40% of the internet, that's a lot of size. And the great thing about so many sites is that there's a great thing about it and then it's also you can maintain all of them. So you need to have some more automation to get all that done, right? So you're now coming at a point that you have this new problem. You have so many sites and you need to automate and you just need to integrate them with other tools. So there we go. Now I want to introduce a couple of tech topics. I need to figure out how deep we're going to go here. So if I start going too deep and you start drowning, start yelling, put your hand up, please. So how do you do this? How do you automate and make systems on the internet talk to each other? How does that work? We created something for that called REST. Ever heard about it? Who knows what it is? All right, who has no clue? Not good? So what do I think? Something new. So the guy who created this is Rorty Fielding. Roy is also the founder of the Apexing Foundation. If you know that, he's one of the people that helped to create the HTTP 1.0 and 1.1 specs. So he really knows his stuff. When Roy created the REST in 2000 and he did a dissertation on it, it was called the Representational State Transfer. Meaning, how do I transfer states from A to B? Because on the internet, you don't transfer data. You transfer a representation of that data. Still following? That's the idea. If I have data in my database, right, and I render that into HTML, that HTML representation is not the actual data anymore. Because I can send that HTML around. And in the meantime, the data on my database is changing. So the representation is only valid for the time it was created. Are we still following? All right, good. So how do we solve that on the internet? We're sending data around and we add in additional information called headers, the ECDP headers. And one of those headers is called the date header, which includes the actual date that that piece of information was generated. The Representational State Transfer. We are transferring the state at a specific point in time. Basically, the internet is one big, solid state machine in that sense. All right, but that's maybe a little bit too far. So how does this work? How does REST work? What is specific about REST? What makes two systems over the internet to be able to talk to each other? Why can't you open up a web page on your browser? Connection, ACDP, what does the ACDP do? The method. A method, which method? Yeah, mostly get. Get, right? So we have a number of standardized methods that are part of the ACDP protocol and that are also described because REST is basically, it's not a protocol itself, it's a way of using the ACDP in a uniform way. That's basically what REST tries to do. It says to use it like this and if everybody starts doing it, then systems can start talking to each other. So when we have a browser, the browser will send a request to a server and the server can have resources and ACML page and image or additional information like user information, for example. It will have different methods, get, post-boot leads, and which other ones we also have for the geeks among you. Patch? Hat? Options. Options? I was also connect, but... So the most important ones are get, post, put the lead and then there's also a patch now, which is a little bit hard to explain, so I'm not gonna go there. Get basically means, tell a server to get me something. Get me some information. It could be an HTML page, it could be something else. Post means updating data. Right? And put means? Create. Create and post means? Update. Update. How is that different? Create something that doesn't exist on the receiving end. Okay, and we do that with? Post. With put? Post. Post, post. See, this is like geeks starting to like, oh my God. And then you can have this long-wided discussions over a beard. It's post. It's put. And then we have a team meeting, then we go, yeah, we should do this with put. It should be post. And nobody seems to agree, but you're almost there. So, post is done against a URL that doesn't exist yet. I can post against a collection. I can say articles. I can post, yeah, slash articles. All right, that. So this is me going a little bit geeky for the geeky guys here. I'll take one more minute and then we're gonna be back on track with the less geeky stuff. Because otherwise their minds are gonna start becoming dull and they get like, you know, they start falling asleep. So you have articles, like this. I can do a post against this to add an article. Right? If I have articles one, I would. You usually just take one for one. If I do a post against this, an article one doesn't exist.