5 Of The Most Useful WordPress CLI Commands

Over the past couple of years I’ve gotten more involved with WordPress site management. One of the tools I seem to find very useful is the WordPress CLI.

WordPress CLI is a command line interface for interacting with a WordPress site.

Below is a small list of the commands I use most frequently.

WordPress logo primarily for presentation purposes.

Plugin updates

First up is a really quick command to run all plugin updates. I find this to be a pretty reliable and easy way of just running updates for all plugins in the repository. Due to the locked down nature of WordPress and the reliance of paid for plugins this command may not get all update but it does work with the vast majority of them.

Theme updates

As above this command is very easy and quick to just run any pending theme updates required on a site.

Core updates

Although updating Core in WordPress can be quick in the cms, I find running this alongside the above 2 commands is good practice and can be quite speedy.

Translation updates

This is one that often catches me out when running updates and pulling translations into the language folder. This is another 3 quick commands to just get it done.

Update User Information

Quickly running a password reset on a local or staging environment is something I do frequently. I find this command to be a quick and simple way of doing this.

There you have it, 5 of the most useful commands from the WordPress CLI. Often I am running plugin updates or making tweaks to users but let me know what your favourites are in the comments.

The best way to develop PHP websites locally on MacOS

Over the past few years I’ve been on a quest to find my perfect Local Development stack. I finally found it!


When you look into the grand scheme of things, web development is still a fairly new industry. It’s only been a consumer thing for a few decades and we are very much in an age where things are moving rapidly. For web developers you could argue that it’s gotten easier to build a website over time. However the tools we use and newer workflows seems to have made things much more complicated.

I’ve been working as a developer professionally now for over 8 years and there have been a whole host of new frameworks tools and evolutions within that space of time. Over the past year or so I’ve been looking into making my development workflow simpler and leaner. During this time I’ve experimented with a number of different solutions. Rather than keep those to myself I thought I’d share my experience with each one and weigh up the pros and cons.

Before I start a little disclaimer

Before I get down to the nitty gritty of what I’ve used, new tools come out each day along with new ways of working. Over the past year or so I have been trying to find something that fits in with my personal workflow and provides the best support for the tooling I require on my day to day basis. This is just my opinion and I’m keen to hear your thoughts and favourite tools in the comments below.


A few years ago AMPPS was my go to piece of software for developing locally. It had a web based UI akin to XAMPP and MAMP and was rather customisable. It had support for a number of different PHP versions and had the ability to easily configure and switch between them on a site by site basis.

What I really liked about it was its ability to configure PHP and over time I began feel familiar and confident with it.

Starting in around 2018 – 2019 however AMPPS has been very slow in getting updates out to support some of the more recent versions of MacOS. Currently the app is not working on MacOS Big Sur with forum posts going back to last July requesting support for it. It currently only supports PHP 7.3 with no easy way of allowing other PHP versions to be installed. We have a number of sites which use different versions of PHP so this doesn’t well work for us.


Back in the day when I first got into Web Development MAMP was a pretty popular tool. It leans heavily on simplicity and allowed you to get local sites up and running in a few minutes.

It had a user friendly dashboard and allowed you to do handy things like switch PHP and Database Versions pretty quickly.

I recently gave this a go earlier in the year and found myself feeling a little disappointed with it. The app and database kept crashing on my 13″ 2017 MBP to a point where I had 5 in one day. Rather than mess around and spend a few hours trying to get to the root cause of the issue, I got my refund for my MAMP Pro License and proceeded to find another alternative.

Brew Packages

After the issues I encountered with AMPPS I decided to take a look at just installing native brew packages on my Mac. This is perhaps the most customisable way of setting up a development environment. You have fine grain control over every piece of software in the stack and can upgrade and change them however you see fit. This guide written by the guys over at Grav is one of the most comprehensive and recommended ways of getting it setup.

One of my biggest gripes with this method however is just how involved and long winded the setup process can be. Setting up new sites can be a bit more difficult than other process’ too and you need to have some basic knowledge of apache in order to do it. It is however a great learning experience for new people to web development but for more junior developers, it feels quite involved.

For someone with more experience though I think this is one of the goto ways of running PHP sites on localhost. It’s fast, customisable and ticks a large number of boxes for development.


DDEV is currently I am using to develop locally. I’ve been using it now for around 4 months or so and I have to say, I’m extremely impressed with it. DDEV ships with all of the tools you would need to develop websites right out the box. Difficult things like SSL Certificates, Mailcatchers and PHP Version Switching is all taken care of within its ecosystem.

DDEV projects need 4 questions initially before a site can be setup with it. Behind the scenes it creates sites within docker containers and uses a CLI tool with a very readable set of commands that just make sense. The one major downside of this tool over the other methods in this list is that Docker containers are obviously slower vs running it on physical hardware and tend to eat a lot more memory. Overall though for me, those two downsides are massively outweighed by just how easy DDEV is to get up and running and how customisable it is.

Conventional Commits – Adding meaning to your git commit messages

Recently I saw came across a link to a git specification known as “Conventional Commits”. I’ll discuss my opinions of it in this short post.

What is it?

Recently I saw came across a link to a git specification known as “Conventional Commits”.

A specification for adding human and machine readable meaning to commit messages


Upon taking a glance through the specification I liked the idea for having commits store more useful information. We’ve all seen git commit messages like “a fix” or “fixes bug” but they vaguely tell you what is in it. This lacks detail about why the change was made though.

Structuring Conventional Commits?

The conventional commits specification aims to improve this by providing a simple set of rules to commit messages that explain what changed. When looking through a repository, you often can see a list of vague commit messages. These state what has changed but not why they have and what it means to other users.

You can find an example of the basic structure for a conventional commit below. In short you should have a type of commit fix or feat (but these are optional) which correlate to Patch and Minor changes in Semantic Versioning (Semver). Then an optional scope which “MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):”.

The short description covers a change that has been made e.g. “array parsing issue when multiple spaces were contained in string.”.

Describing the change in the optional body part of a conventional commit is where is see the key benefit. Putting a reason for making the change is extremely useful when collaborating on a project.

So this is all great but where else are conventional commit messages useful?

Why use them?

Ultimately the thing that still excites me about being a developer is the satisfaction with automating a task.

One of the best uses I have found for Conventional Commits is with this PHP Library: https://github.com/marcocesarato/php-conventional-changelog

Essentially this library will go through your git repository and build up a changelog based on the conventional commits. The library can handle things like automatically bumping your version numbers and generating a dynamic changelog. Paired with tools like Github actions and gitlab pipelines this is incredibly useful to automate releases of your libraries. The best part about the Conventional Commit workflow is it’s ability to support automation of various tasks.

I am currently using it for a plugin I recently built in Craft. So far it has helped me save a bunch of time keeping my changelog up to date and managing my releases.

What do you think about conventional commits, how do you manage your repositories and versioning. Drop a comment below to let me know, I’d love to hear and discuss other approaches so we can all learn from each other.