Tag: Better WordPress Code

In the most recent post of this series (which is admittedly some time ago), I talked at length about Composer and its lock file.

I recommend reading the previous two articles because Composer is eventually going to play a role in this material that this and future posts are going to share. But if you opt not to catch up on them (or are already familiar with Composer) then the gist of the previous posts are, respectively, as follows:

I don’t recommend checking the vendor directory into your repository. That can become a huge directory later, and it can undermine the whole purpose of Composer.

Composer

The goal is to make sure that every one is running the same version of the dependencies of the project – not older versions, not newer versions – but the same version.

The Composer Lock File

With that said, there are numerous dependencies or packages that we can install that help us to make sure that we’re writing the highest quality code possible.

Sure, some of these may be in the form of something like coding standards, but those are really more rules than they are elements of writing high quality code (though I don’t think they should be left out of the discussion – just left out at this time 🙃).

Back to the tools in question: What are some tools that help write high quality WordPress code? I’m going to share a few of my favorites and them I’m going to talk about how we can run them all against a code base.

First, let’s take a look at static analysis with PHPStan.

Before wrapping up our discussion on Composer, we have one important thing left to discuss: The vendor directory (and by extension, the Composer lock file).

Specifically, we need to talk about why we don’t need to commit the vendor directory to the repository but how our contributors can be sure they have the latest version of the software needed to work with our code base.

Using code quality tools to write better WordPress code is important, yes, but understanding how to properly manage dependencies and our repository is important, too. So before looking at said utilities, let’s review the lock file, the role it plays, and why we don’t need to commit the vendor directory to our repository.

Continue reading

Although I think the title of this series and the articles for each are clear enough, there are other things I’m aiming to do with this series in contrast to the other series I’ve written up to this point, too.

Specifically, two of the things that I’m trying to do is to two:

1. keep each article relatively succinct (in comparison to how previous articles have been),
2. focus on one thing at a time and keep the description of it short.

Since this is membership content, I don’t mind it being a bit longer than usual, but I also don’t want it to be so long that it’s hard to follow. I’d rather it be a short read with something practical that you can implement after reading each post.

And one of the things that greatly helps with writing better WordPress code is Composer.

Continue reading

Over the last few years, I’ve talked a lot about the nature of code quality and various tools, processes, and libraries that I recommend using when it comes to writing code for WordPress.

I’m also open that that majority of the work that I do is in backend development. This means that I work predominately on WordPress plugins using object-oriented programming and don’t work much with templates nor as much with front-end technologies.

It’s by choice, and I’m really happy with where I am. But I digress.

If you’re in the business of doing the same thing (or doing it as a hobby), it’s not just about writing the code. It’s about having proper tooling in place.

I’ve alluded to a few in these in previous posts, but I’ve not walked through the tools I use and the set up I use whenever I’m building a solution for myself or someone else.

At least not in an organized manner.

In this series, I’m going to do exactly that:

I’m going to cover the tools I use, the libraries I use, and how I use them.

Ultimately, the goal is that those of you who read this can incorporate them in your day-to-day work to write better code.

Continue reading