So let's start this conference about plugin development and more importantly, good practices.
I would like to start this conference by asking you a few questions.
Raise your hand if you use it.
Who here when he is creating WordPress plugin is using Composer?
Who here is using namespaces?
And finally, who here is using dependency injection?
So you might be wondering why I ask you these questions and the answer is quite simple.
Today when we go out of the WordPress ecosystem, actually these bases are the ground base of
any PHP project.
But it's not the case in WordPress and that's the question we're going to ask ourselves.
Why it's not the case in WordPress and we're going to try to propose a solution to that.
And so I want to say the first thing first.
The problem is not you.
You are not bad.
It's more with the tool.
Like WordPress at its core is actually a CMS.
It's not a framework.
And so there is a difference on who is the central user here.
On the CMS, the central user is actually the end user.
It's not like Symfony where it's a developer which is at the center.
And that gives a couple of situations where plugin developers are actually left aside and instead,
we privilege the end user.
Sorry.
And that leads to a lot of problems.
But I would like to focus with you on problems we do have leverage.
And so the first problem is actually the fact that the documentation is fragmented.
You know, the WordPress documentation for plugins is actually really good.
But there is an issue.
When you go to advanced topic, you will have nothing.
If you search for dependency injection or architecture for your plugins, you are on your own.
And that is an issue because it's then up to the developer to search for his own documentation
or to search for the notion.
And when you are learning, you are not always at the right time.
And so you are not sure to find what you want.
Then the second problem is about the investment.
You know, when you work with good practices, there is always a moment where you have actually to set up these good practices.
And this is time where actually you're going to focus on the good practices and not deliver output to your client.
And that's exactly why I love to call it investment.
You can do it.
You can do that investment at the beginning of the plugins, but you're not really sure that that's going to be worth it.
Or you can do it later, delay it.
But the more you're going to delay it, the more tasks you will have to do.
And so there is no good answer to that question.
And finally, the last issue is that using good practices inside WordPress plugins today, it's complex.
It's complex because you don't have only to use it.
You also have to create a current all with it.
Why?
Because today, boilerplates are not up to date with the PHP good practices.
And so you have to build your plugin from scratch and then like make a current all of the good practices.
And that's what allows you to master it.
And so that's why today I can say that good practices inside WordPress plugins, it's for an elite.
An elite because each time we face one of these problems, we actually excluded a part of the developer community.
We excluded the people that didn't know how to search for the terms.
We excluded the people that didn't know when to invest in the good practices.
And finally, we excluded the people that were not senior enough.
And actually, excluding people in the WordPress community, it's a huge deal.
Because by its core, WordPress is inclusive.
Remember, the main goal of WordPress is actually to make the creation of website accessible to the most.
And so inclusivity is within its value.
And then excluding is actually clashing with one of its main value.
And that's why I actually started to develop an open source framework called Launchpad, which actually tries to tackle this problem.
And it does that by lowering the requirements that you need to have to start working with good practices inside WordPress plugins.
And for that, I use a couple of methods that I didn't invent.
I went to search in the other communities, the other PHP communities, if they got the same issues as we do today.
And simply, I adapt their solution to the WordPress ecosystem.
So the first issue I had to solve is the issue about the investment.
And actually, that's the easiest one to solve.
Because we already have the solution here in the WordPress community.
I said that the boilerplates were not up to date.
So an easy solution was actually to make a boilerplate that was up to date.
And so within two comments with Launchpad, you are able to start a project on good practices.
And you are able to start working on the business logic.
And then the next problem is that it's too complex.
And that's where actually we start to step out from the WordPress community.
And I have to present you a framework that you could know, which is called Laravel.
What is great about Laravel is when you start to work with it, you just have to know three notions.
Model, View, Controller.
And what's even greater about these three notions is that it's touched in most of the development classes.
And so virtually, Laravel is accessible to any developer.
And that's exactly what I wanted to reproduce with Launchpad.
But the Model View Controller doesn't fit into WordPress.
Because WordPress is an event-based system.
And so that's why actually I picked the subscriber, which is a pattern that fits the best that way of programming.
And on top of that, I had to add another notion, the provider.
The provider, as you can see on the side, is just here for a beginner to declare the subscriber you implemented.
So then the framework can actually load them and you are able to have your logic running.
That's all, nothing more.
And that's how we make Launchpad accessible to the most.
But that's not all.
You know, the problem about the fact the documentation was fragmented is actually the problem of allowing user or developer to progress.
And for that, actually we have to come back again to Laravel.
Laravel is really good because you can enter as a beginner and exit as an expert.
And the keystone that allows that is actually their documentation.
You know, their documentation, they arrange it by level.
That means when you are a beginner, you start only with the beginner documentation.
You have only what you need to start and you are not bothered with advanced notions.
And that makes it easy to start.
But that's not all.
Inside the beginner documentation, there is also some links that link to the medium documentation.
And that way, they're going to play with your curiosity to bit by bit learn new notions and progress.
And that's exactly what we wanted to reproduce on Launchpad and what we tried to reproduce inside the Launchpad documentation.
So then what was requirement to know all of the notion before being able to program became a linear progress.
And now that you understood how we are tackling all of the issues with Launchpad, I think you are starting to see a problem coming.
We don't have one type of developer in Launchpad.
We have a various type of developer from the junior developer that wants something fast and easy to the more senior developer that wants to bend actually the solution to his needs.
And so we will have to satisfy both of them.
And I think you already heard about like a software that fit the needs of various users.
It's WordPress if you don't guess it.
And to similar problem, we can apply similar solutions.
And that's why Launchpad comes with a modular architecture.
We have a core that makes the base for the framework to run.
And then we're going to have some modules on top of it that are going to adapt the experience to each plugin.
And so if we take a step back, Launchpad will look a bit like that.
At the core of the onion, you're going to have the core.
And the core will be here to have all the necessary tools to actually make the framework run.
And we try to keep the minimum there.
Why the minimum?
For two reasons.
First, we want the core to be really light.
Because like if we start to put too much feature on the core, then it's going to make the core heavy.
And the core is used in all of the plugins.
So then all of the plugins that will be created with the core will be slow.
And the second thing is like each time we add a notion in the core, we are actually imposing it to the developer.
And WordPress always keeps you free.
And that's like a vision we want to keep.
And that's why everything we can't fit into the core, we actually fit it inside the modules.
Because the modules is the strict opposite of the core.
If you don't like something in the module, you can disinstall it.
And you can reuse the WordPress API.
Or if you have really a specific need, you can actually implement your own module.
And that's how actually we fit the needs of the more senior developer.
But you notice there is like a layer in the middle, the framework.
The framework is here actually for the more junior developer.
It's the layer that going to simplify everything.
First, it's the layer that provides you a base so you don't have to configure anything.
And second, it's also the place where most of the automation happens.
You know, like Launchpad try actually to hide its inner working so you remain with a simple interface.
And that way, when you are not that much experienced, the framework stays simple.
A good example from that is actually the fact that Launchpad is not a plugin itself.
It's a development environment.
And so you will have both code that you will run into the plugin at the end.
And also code which is just there to help you to ease your development experience.
And we will rely on a build command that will actually split apart like both kind of code and remain only with the valuable code inside the release that you're going to use on the website from your clients.
And that's how we actually fit from both developer.
But when you are developing a framework, architecture is not everything.
You need your developer to understand you, or at least the most.
And that's where simplicity kicks in.
We need to be simplistic.
Sorry, to be simple, not simplistic.
And that's where lies the real complexity.
Because if you're simplistic, you will look simple, but you won't be.
And the only way to know that is to interact with your developer.
And that's also why in Launchpad, most of the problems we tackle were related with developer experience and not with purely technical problems.
And so developer experience, it's a bit the equivalent of user experience, but for the developer.
And it reflects into two ways into Launchpad.
First, it doesn't have to be complex.
We are not anymore in the old ages of assembly code.
And we can express ourselves with variables.
And so when something is actually complex, is that we express ourselves bad.
And the second way is actually to learn to delegate.
You know when you are driving, 100% of your brain is on the road.
But if you start taking a call while you are driving, you only have 50% of your brain on the road.
When you are developing, it's the same.
When you are trying to develop a task, if you have little things that start to bother you, then you won't have 100% of your brain on what matters.
And that's why you need to learn to delegate to your IDE or to your framework this little task.
So let's look at one example for each of these efforts.
The first example is actually about something that here everyone knows.
The action and the filters when we register them.
Like there is always an issue when you are a WordPress developer of where do I register it.
In the course of my plugins, but so it's hard to make the link between the event and the callback.
Or next to the callback, but then it's hard to test my plugins because I will have to mock the fix function each time I have to write a test.
And that's why actually we went in Launchpad with the subscriber again.
And we solve that issue by actually writing the logic inside the subscriber.
And the subscriber in the background can actually send the mapping with the event and the callback to an event manager.
That will register for you on the WordPress API all of your events.
And you will tell me, so okay, that's finished.
Actually not.
Because this is a function that writes the mapping.
And as you can see, it's really complex.
It's really complex for multiple points.
First, like you have a big block of text.
So if you are searching something, it's quite hard.
Second, like you have like multiple syntaxes next to each other.
Like you can use a string, you can also use an array, or you can use an array inside an array.
So it's really error-prone.
And finally, the last thing, it's that like it's really variables.
There is a lot of information here that actually we could actually find back.
And so that's why I went in like the Laravel environment if there was a solution.
But there was no solution there.
So I moved again to another PHP environment, Symfony.
And here I found actually something that fit our needs.
The annotation syntax.
And so I just reused it into Launchpad.
As you can see here, we have not anymore a big block.
Each callback can have its own event.
And so it would be really easy to find to which callback, to which event a callback is actually registered to.
Then we don't have anymore like the number of parameter or the name of the function.
So actually, it's way less variables.
And finally, we solve the original problem.
Like we don't have to mock anymore the function addFilter and addAction.
And we also have a syntax where our event is really close to our callback.
So it's actually really easy to find back which callback is related to which event.
And so that's exactly what I mean by when I was saying it doesn't have to be complex.
We always have an easy way to write things.
So that's the second problem.
Actually, I want to remind you the last time you actually started to work on a new framework.
And at that time, you feel a bit like the guy on the image.
You were a bit in the smoke and you were searching like for new notion and always coming back between your project and the documentation.
And that was really a frustrating experience because actually your brain wasn't focused on delivering the value to your client,
but actually on how to make things in the framework way.
And so that is really time consuming and it's not something I wanted for Launchpad.
And that's why I wanted to teach the developer that you'd learn that, but it's okay to fail.
And for that, I wanted the developer to be able to first write the WordPress code the way they want and then have feedback.
And for that, I use something that we call PHP stand.
It's a tool that normally is used to check the typing, but I use it in a different way.
I use it to actually analyze the code from that developer wrote and actually give some hint to the developer on how he could take advantage of the framework.
And that way, Launchpad is not only a tool you are using, but a body that is giving you hints.
And I want to finish on something.
Here you saw a lot of notion.
I talk about a lot of things, but I invent nothing.
I learned this notion the same way you do right now by people sharing it to me.
And so that's why it's important today to be one community.
One WordPress community, yes, but more importantly, one PHP community.
And that's also why it's important to go to not only WordPress event, but also PHP event.
So then we can share some notion together and we can advance.
That's all for me.
I'm Cyril Coquard, a software engineer at WP Media.
And if you are interested about Launchpad, there is a QR code to the project.
And now it's question time.