 Thank you for being here. As you said, as you see in the title of the slides, it means to be provocative. So if it is, it did work. And it's meant to be. You're doing it wrong is an expression that you find throughout all of WordPress code base. So it should be familiar for any one of you. You can find the slides for this talk just in case you want to follow up because I've got many code examples. And so you might want to follow up with the code using the slides and you can find those here. You can find the slides link in the footer to of the slides. So it's not a problem. As Justina said, I've been developing with WordPress and PHP as well for about three years, not much more. So you have got to take that into account while I make my presentations because as the title is very provocative. I know many of the people that is here has been developing with WordPress for much more time than that. I'm not a senior developer. I'm not probably senior to any one of you, any one in this room as well. So I just want to express some opinions and give you some some ideas. Okay, let's start with something which is quite a common theme these times, which is I don't care about PHP JavaScript is the way to go, which is a justified fashion at the moment due to the release of the REST API plugin and the implementation of the REST API infrastructure since WordPress 4.4. I totally understand the hype, but I do not think that PHP has said it all. Another thing to say when you make this kind of reasoning is that sadly, all your bad practices, the one you used to have in PHP will follow you across code. So it's not JavaScript, it's not PHP, it's not Ruby, it's not Python, it's not C. Whatever bad habits and practices you do apply in your code every day, you keep applying, you will do exactly the same. And that kind of expression can be used about some anything. So I don't care about Star Wars, Star Trek is the way to go. I'm not even entering this discussion because of course Star Wars is the way to go. Let's tackle another big issue, which is it seems to not make any difference, but it actually does, which is do you think about WordPress as a PHP framework or as a CMS? Because in the first case, so as a PHP framework, which is the way I think about it, it provides me with a lot of functions that I do not have to code again. So I am a developer. So as any developer in this room, I love reinventing the wheel every day, every time. Okay. I take that for granted, but that's not good practice because someone has to pay you and they don't want you to go over the same stuff over and over again. So to me, it's a PHP framework and a CMS. And if you think about WordPress as a CMS alone only, sorry, then you probably will keep doing stuff the way WordPress does it, which is called in short, the WordPress way of doing things. Okay, the WordPress way is it's kind of like an Ipsedix it, which is used throughout code, code forums, which is meant to say, you know what, you have to do it this way. It's a way. It's not the only one. Okay. The WordPress way of doing things. So the way that you find, for example, many examples on the codex is meant to be easy to understand, easy to maintain and back compatible. Okay. That's why it's done like that. It's not because it's the only possible way you can write code in WordPress. So it's not the only way. Then we can, during the question time, we can have a polite discussion about this difference about being a PHP framework or a CMS disclaimer. In this presentation, I will make a lot of code examples. I, my purpose is to give you ideas. I'm not here to give you truth. So, and I'm expressing my opinions and I'm not expressing axioms. So I'm not saying I hold the truth and you should listen to me because someone higher than me told me this is the right way to do it. So this disclaimer made. Let me enlighten you. Okay. Another disclaimer, which seems quite a strange one because one of my, the second word in my presentation title is modern and I will talk about PHP 5.2. And you have to know if you don't know, you probably live under a rock. PHP 5.2 has been unsupported since January the 6th, 2011. So it's quite sometimes. But I will use PHP 5.2 examples in the code that I will show you and I will tell you why in a second. But you should use the latest possible supported version of PHP. You can put your hands on in your project. Okay. That's my example. My purpose of this presentation is not to tell you, hey, you should use PHP 5.2 because it's cool. No, if you can use PHP 7, do it. PHP 5.5, do it, please. Okay. This is kind of, we, this is kind of kicking a wasp nest. I hear these over times, which is PHP 5.2 does not allow me to express my amazing development skills. I can talk for myself, that's not the case 95% of the times. Okay, that's not happens to me so much and so often that I can actually use this justification. Another thing, it's your PHP code. It's you that are writing the code. It's not WordPress code. So it's your PHP code. And you have to keep in mind that the version of the language and the techniques that you use in your language are completely different matters. And you have to keep that in mind because if you think that moving to JavaScript will allow you to have new language version, you're right. If you think that it will give you new techniques, you're wrong. That's not happening. Techniques comes from you, language version comes from the server. And this is kind of sounds like not having a Millennium Falcon limits my driving skills and this is not the excuse you're looking for. Okay. So I will make a lot of Star Wars puns in this and I hope you get those. Another thing I wanted to say is that developing is like going to war and if any one of you has got any kind of knowledge about history, everyone knows that during World War I and II, the second one, a common belief was that everyone was going to be home by Christmas. You won't be home by Christmas when you develop software. It will escalate. So what was meant to be a small project will become a big one if you're good at it. And you will lose the public support when things go wrong, which happens because when as a developer you come across a glitch, you come across a bug, clients will not like you. It's very easy to go to someone and say, hey, you know what, we did what we thought we would have done in 100 hours in 10. Well, fine. You know what, we will probably take 100 hours to do what we thought we would do in 10. That's not going to buy you so much support. So probably keeping this in mind, try to think how you could make your code more modern and kind of proof it against escalation. And yes, when you talk about time, you have to talk about project managers. So you probably talk about the old seeing guy of Sauron. So let's go into code and let's talk about solid and dry principles versus it just works, which is an approach that is fine that many developers take. And it's I do test driven development, which I will not talk about in this presentation because I've been forbidden to do it. And I'm fine with it. I think that the job, it just works. So why should I take more effort, more time, more thought than I have always done just because it should be done differently? So why should I care? Or probably I am the wrong room. Yeah, I think you can still leave the room, not to me if it's not true. No, you can leave the room. Sorry. Okay, let's go over solid principles. If you look on Wikipedia, you will find many definitions of the solid principles, which is an acronym. So it's actually five principles. And definitions can be very abstract, very vague. If you look inside the schoolbook or textbook, you will find those expressed in a way which is so abstract and so high level that you probably won't be able to understand how does that apply to my PHP code. So I took the effort and time to come up with something short. I got like a goldfish memory. So if something is long, I'm not going to remember it. So single responsibility, which means do one thing well. That's it. Hoping colors principle means extending in place of modifying the least curve substitution principle, which is that's a great name. Essentially means it should work as a parent. It's nothing more than that. Interface segregation principle. If you call something manager, you probably are doing it wrong. Okay, because it means that you have created a class which is doing so much stuff that you're encountering one of the two big issues of development, one being naming the second one being cash invalidation. You just struck the first one, which is naming stuff. Manager, is it called a manager? Is this the first name you can think about describing your class? That's probably wrong. And dependency version in PHP means type in interfaces. That's it. Okay, this is, as I said, the only way I can remember those. So let's go into code and make some examples. We've got a class which is called a custom post types. And this is added two actions and a filter, one action on init, which is registering the custom post types, the second action on safe post, which is on safe post probably do something. And a third one, which is a filtering the title template tag on a function which is called a title. This class is actually, it's just three methods, but it's doing three very distinct and different things. Okay, so the single responsibility principle tells you do one thing, not three, one thing, and do it well. So we can change this class to make it better. So I have created a fourth class which is called the hooks class and I was telling a joke before that I want to repeat about me naming stuff and naming a class that hooks stuff. So this class is taking care of instantiating three client classes, so a custom post types register one, a save operations one, a template tags one, and hooking each one on the hooks. So before we had one class with three methods, now we have four classes each with one method. That seems to be an overkill and over engineering, but in the long run you will never be damaged by small classes. You will always be damaged by large classes. Okay, and if you use a modern ID, and if you use a tool like an ID that makes the idea of creating four classes, a chore and a burden for you, you probably should change your ID. Okay, so I'm going to use an ID which allows me to, with two combination, create a new class. That's all. So that's not going to take so much time. And in this case, each class does one thing. So what does save operations does? It deals with save operations. As a rule of thumb that I use every time is that if to describe what a class does, I have to use and or probably that class is doing too much stuff. I can describe one of these classes with just one sentence that does not contain an or or. Okay, so the open close principle, this is one that's usually difficult to understand when you don't see an example. So we've got a class which is a stupid one, template tags. And what this does it takes probably either return or filters the title and what it does it that prepends something before the title and ends something to the title. Okay, it's easy to understand as class. I mean, it makes absolute sense. Then probably some project manager comes to you and says, Oh, you know what, that's not going to apply every time because when we are dealing with a bad news post type, we want you know, we want to append a smiley faces to make things better because it's a bad news. Okay. Okay, so this that's a very easy modification because you just go inside your code and you say that if the post type that we are working with is bad news, then you have to return title and a smiley face it appended to it, otherwise return exactly stuff as you did before. So with a prefix and a post fix. But what you know as a developer is that probably that's just the first of many modifications to come. Okay, so today is bad news and a smiley face tomorrow will be bad news and maybe not our face and so on. So you could do things better, which is you could take another approach, which is in the first place, outsource inside the class that prefix and post fix to different methods and you just return the prefix method, the output of the prefix method to title the post fix method. Okay. And then when you do have to make that modification, if you remember the definition of the open code close principle is extending in place of modifying. So what we did before was modifying in existing class, which for any one of you that has used test driven development knows that it means you have to rewrite at least one or two tests. Okay. So test driven development makes you very lazy. I'm very lazy as a developer. I don't want to rewrite any kind of test. And so when I do that, I've got this class and I extend it in the case of a smiley smiley face class and I just have to change the prefix and post fix methods. Okay. And that's all. If I have to undo that change that modification because that case where the bad news post it does not apply anymore, I simply have to change the class. I do not have to get back and modify my code again because this is the thing you have to think about. Every time you modify your code in one direction, there is a very high chance that you have to modify the code again back. So you're changing the code one time when you make it, second time when you modify the third time when you revert it. Okay. And if you know something about patterns and you can use the decorator, then this example, you will understand that this example can be extended without limit. So you can extend the functions of this class really without limit. Okay. Let's go with list code substitution. And if you remember the short definition of this is it has to work as its parent. Okay. So this is the parent. We've got a class which is called a save operation that during construction takes a published counter. And when you save a post if the post is a new one, so not one which is being updated then this class is going to increase the count on that published counter. Okay. So that published counter is counting published posts. Then you've got another class which is extending this original one which is called a filtering save operation that takes a post counter. If you remember before it did take a published counter. So I'm overriding both the construct method and the on save post method in this class which is extending the first one. So it's now taking a post counter and when the post type is post I'm increasing the count of that post counter. Okay. The problem is that this class which is an extension of the previous one is actually not doing what its parent is doing. You can take as we used to do in all days of hardware plug and play this class in place of its parent. It's not going to work. It's not going to perform exactly as its parent. It's construct method. It's not taking the same arguments and the on save post method. It's not doing the same things. Okay. So you are violating the list code substitution principle. What you can do is that you can modify this class in this way. So if you're dealing if that class is being used as if it was an instance of its parent it's going to work as intended. Nothing breaks. Okay. But if you know that this class is an instance of the filtering save operations one then you can use that using its new methods and possibilities. Okay. So this is the list of substitution principle in application. And this is a very simple application but if you think how many times you even the act of overriding a constructor and not calling the parent construct means that you're probably violating this principle which means that you have the truth is no more in the code. Because many developers take as granted so someone which is not you or someone that might be you three months in the future might use that class thinking that it will work as its parent and it doesn't. So if I have to look up the source code of your class to make it work as intended that's probably wrong. Okay. Interface segregation. Okay. We have a perfectly legitimate post repository which is a post repository interface. So here we are talking about interfaces. Okay. So it has a function which is called a get post an insert post one update post delete post regenerate post cache because we're cool we've got a cache and we can get cached post and we even listen for events. So when a post is inserted updated or deleted we are probably doing something. So this is an interface so tells client classes how the post repository our post repository interface is meant to work. Okay. But interface segregation tells you that that is not the right approach. You should segregate which means split the interface in sub interfaces each wine doing small things. Okay. If you think about the description of this class what this class does is query posts and deal with post caching and listening for post events. You see I'm using the and word which is forbidden while describing a class or an interface okay. So what we have here now is that you have got a post repository interface which queries posts. Okay. You've got a post cache interface that deals with post cache okay. You've got a post events listener interface which listens for post events. So this you will ask yourself why one reason is client classes using those classes can now depend on smaller abstractions because for example to make you a very stupid example you might have a caching system which is separate from the post repository you might want to decouple those in the future and having clients rely on that function being done in the same class binds you. Okay. You're going to change a lot of code when you want to do it. So you can change implementations as the code evolves and the class can be now split the interfaces and the classes using those can be now split into smaller classes. So this is about abstractions okay. The first letter in solid the S which is the single responsibility principle is about implementations. So it's telling you classes, concrete implementations should do one thing well. The I in interface segregation is dealing with abstractions okay. So when you describe the functions of a class using an interface that interface should be you should be able to describe not using an or or this is my this is not the official interface segregation but okay the last one the dependency version sorry code is a bit small at least on my PC. So we've got maybe a route handler like handler. So this is taking a post repository during its construction and it's handling a request that essentially when we find a post we want to create a new like post okay. That's not that's not very difficult to understand. Okay and what it does is that after we have inserted this new like post we are regenerating the post cache okay. Okay dependence inversion. Dependence inversion is the formal expression is abstractions should not depend upon implementation its implementations that should depend upon abstractions okay. So what's the implementation you are relying on here post repository okay. In this code you are making an assumption that post repository class which is an instance of post repository is going to allow you to do two functions one which is about post operation inserting a post the second one dealing with a cache which is regenerate the post cache okay. You it's your implementation your abstraction is depending upon an implementation details. What you do when you type in interfaces which is the short version that I use to remember the dependence inversion principle is that I am now supplying this class with an instance of the post repository interface and an instance of the post cache interface. That class is never going to assume that this like handler class is never going to assume that the same class will both deal with inserting a post and regenerating its cache. So it might be the same class I don't care if it is the same class okay. I really don't care it's not my problem as a client I don't want to know I don't need to know how the implementation works I don't care. I just know that you give me something that deals with inserting a post and something that deals with caching posts and then I will deal with it okay. Okay why go all the trouble first one is that you build layers of functionalities instead of silos. So this is a difference which tends to pay off in the long run when you've got large code bases you will always notice that there is some kind of vertical dependency so there is something at the top that depends on something below it that has to be done exactly that way to work that should not happen classes should depend upon each other in communication in an horizontal way not in a vertical one okay. If you follow this principle this will happen and you're putting information about what a class does in its interface not its implementation. Again if I have to look up the class code to understand what it's doing I am doing it wrong I have an interface and I know that a class which is implementing the post cache interface as a regenerate cache I know that's going to regenerate the post cache method that's all it's not complicated. And this is about abstraction again and the last letter in the solid acronym so the D the dependency version one opens the stage again for the S1 which was concrete implementations classes should do one thing and one thing well. If you go circles on the solid principles you will find yourself that the last letter the D the dependency version principles applies to the solid one. Then simple one I will not repeat myself. Don't repeat yourself don't do it. If you stick to the principles in solid it should not happen if it happens you are doing it wrong and you probably have classes that do too much or methods that do too much. Copy and pasting your code around is not reusing code that's not the way it works the way it's meant to be. Then we go on another big big issue which is outloading versus require include which is if anyone of you is familiar you probably all do outloading means a class file is included in the code base just and only when it's needed and not any moment before okay. The biggest coasting development is the developer time so the time it takes to a developer to change something it's not the time it takes to PHP to read and process your code. When you change the dependency and you're using require or include you have to change any one of those by hand so developer time and performance may vary if you've got a project which is made of two files don't use outloading okay that goes without saying if you've got a project which is meant to scale and be 1000 classes I wouldn't go with require include okay I would go with outloading all the way. So as I was saying what I've done until now is making PHP 5.2 compatible examples because as I said in the beginning I don't want any one of you to mix the techniques that you use in development with the language version okay. Composer is a dependency manager for PHP written in PHP Composer runs on PHP 5.4 so I'm talking about PHP 5.2 and telling you about a tool that runs on PHP 5.4. Just yesterday I heard someone saying you know what you can't use Composer in PHP 5.2 that's actually not true. Composer is a building tool okay and it has a building tool you can use this library which I will not try to pronounce to say because my tongue would just wrap on itself and Composer will give you an autoloader which is fast, reliable and optimized for big projects out of the box and it will give you two versions in autoloader if you include this library and follow the instructions which is like pasting two lines of code. You're going to have a PHP 5.2 compatible autoloader. This is a configuration file again followed on the slides and this is all it takes for you to have your classes PHP 5.2 compatible classes autoloaded with Composer which includes the Ventor autoload 52 PHP file. That's all. So dependency injection versus our coded dependencies. So the solid principles made it clear that dependencies should be injected. A dependency is a variable, typically an object instance and injecting a dependency means that you are passing a class a variable either in the construct method or using a setter method which is set something then you pass it an instance of that object and it is set on a private or protected variable. What's an our coded dependency what you see happening in this code is that when I need a publish counter instance I create a new one inside my code that's what a hard coded dependency is called. The problem with it is that if you need to change that dependency you've got to change every single line of code that's using it. Again developer time, it's going to take a lot of time I'm not even going inside the idea of using globals so you might say yeah but I could have that dependency as a global no, no, no. And what we have seen before is that now we are injecting an instance of a class which is implementing the publish counter interface inside the construct method and using it. Why that? Because we can now replace that dependency anytime in test and we have code which is way more flexible. So any dependency should be injected, any dependency should type in an interface and I should be able what concrete implementation a class is bound to an abstraction so an interface in PHP terms. So that's why you have dependency injection containers because if you try to do dependency injections up front so probably in a file which is called a bootstrap.php or main plugin file, you're going to create a new instance of any class you need and then inject it inside your objects. So you've got these injections all in one place which is good. You can change those injections, those dependencies just in one place which is good but you're building all of those up front and you have to keep those up to date and you have to specify by hand any single class you have to instance. And just instancing any one of those dependency classes up front is going to take a huge amount of time because you might not need those. So let's see what things go like with the dependency injection container. This is kind of larval like dependency injection container syntax you've got a container and you say that container when someone requires a published counter interface instance give it back an instance of published counter. Same way when someone needs a post counter interface give it back an instance of post counter when someone needs the post repository interface give it back a caching post repository instance. Please do just that one time. So singleton means back the same exact instance every time. Then you see I'm building just the hooks class because the dependency injection container is going to take care behind the lines of creating anything it actually needs for that class dependencies. And I'm using a package which is called TI 52 which is a PHP 5.2 compatible dependency injection container. So you can provide bound implementations only when needed you're not using singleton methods anymore and you have automatic class resolution and you always know what depends on what and you've got very lean bootstrap files that allow you to really control the way your code works. So are we control freak? Yes and as a developer you're meant to be I do not know what's happening inside that class is not a legitimate developer answer you can say that as a developer. So one other thing I see a lot is that oh you know what in PHP 5.2 I don't get closures so I can do a lot of stuff which is very good and fine. On the other hand I see people that is using not PHP 5.2 that tends to use closures even when they should not use closures because for example if you're hooking a closures to a filter good luck taking it out. And so you can have code like this okay so you're thinking yeah that's the reason why I would not like to write PHP 5.2 compatible code then again this is the way you can do that. This is quite common pattern which was used way before PHP 5.3 came out and it's a way to go around that using this method cleans up many times array map and array filters of functions are very fast. Test-driven development is a developer tool that will reflect upon the final users because it will shorten your release time and the time it takes you to fix stuff up. And if you use test-driven development the magic is that all of this I've said it's going to happen in your code just because you use it okay it's very difficult to write cowboy coding which is a way of writing code and trying it out by searching a browser page that's what cowboy coding is like I don't do it because I'm a crappy cowboy coder as Clint Eastwood says you're a crappy cowboy and a crappy coder. So very quick you can do you can test your PHP 5.2 compatible plugins in WordPress yes you can you can do test-driven development in WordPress all the way you should do it and you can use many there are many libraries I use WP browser and function you can do that and you know what I heard that PHP 5.3 is coming so you know all of the amazing stuff you will be able to do when PHP 5.3 comes out. Okay this is the closing so I am almost in time thanks to two developer peers of mine Jonathan Brille and Daniel Dworkin from Modern Tribe that did review this speech bashing me all the way to it thanks to Modern Tribe which is a web agency I work with that have been very supportive of me and very cool you for being here and anyone the organizers for allowing me to have this speech thank you