When working with multiple WordPress installations – that is, having to manage an array of wp-content
directories for whatever it is you’re working on, it seems that it’s more often not common to suggest creating a new WordPress installation for each project.
This isn’t something necessary assuming the nature of your work can operate off of a single database and the same version of WordPress. This may or may not work for multi-site projects; I don’t deal with them so don’t count on this as being applicable.
Multiple WordPress Projects in One Installation
Assume the project is set up this way:
- MySQL / MariaDB database
- Apache or Nginx webserver
- WordPress
Then within WordPress, you have your wp-content
directory which, as always, includes the following:
plugins
mu-plugins
themes
And regardless of the work you’re doing – be it themes, plugins, or mu-plugins – the entire wp-content
can be considered as “a development box” or “a box” to shorten the terminology.
Furthermore, WordPress projects that are managed on GitHub can be done so in a number of ways:
- An entire project may exist as a
wp-content
directory, - A standalone plugin or mu-plugin may exist (if it’s Composer-based, that’s outside the scope of this article),
- A theme may exist as a single project in WordPress.
Depending on how the project is managed, you can triage how you want to set up the project on your local machine and in your current box to handle the project.
1. 🔌 A Standalone Plugin
Remember, this assumes these are non-Composer based projects.
If you’re downloading a standalone plugin from GitHub, odds are the name of the repository will match the name of the plugin. This means that you take the default box, or the default wp-content
directory, and then place the repository in the plugins
directory.
For example, you’d checkout the repository without updating its name and then work with the code right from the plugins
directory.
In this case, you’re working with the default box and a plugin with which you may be developing, testing, or to which you may be contributing.
2. 👔 A Standalone Theme
Remember, this assumes these are non-Composer based projects.
Similar, let’s say you want to work on a theme, contribute to a theme, or a develop a custom theme. If this is done within the default WordPress installation or, again, the default box then you can simply clone the repository from GitHub.
The repository can be cloned directory into the wp-content
directory. This means that you can work with it with the default box and the software that’s included out of the box or can you clone it into a custom box with a specialized set of plugins or utilities.
And this is where custom boxes come into play.
3. 🗃️An Entire Project
Remember, this assumes these are non-Composer based projects.
A custom box can be thought of as a non-standard WordPress installation where the wp-content
directory is heavily customized. This means there may be a suite of unique plugins
, custom mu-plugins
, or themes that are not installaed out-of-the-box
.
This means the wp-content
directory will be stored in a repository that looks like this:
mu-lugins
plugins
themes
And when we clone a repository like that, we’re not going to be directly cloning the repository as-is nor will be cloning it into the default wp-content
directory. We can, however, continue to use the same database and web server that we have.
To that end, this is the where the concept of different boxes really becomes helpful.
First, move the wp-content
directory into its own subdirectory so it can be easily restored later. Something like this would suffice:
~ mkdir `@boxes` && mv wp-content @boxes/
Second, clone the repository into the root of your WordPress installation but make sure you name the directory wp-content
so that it effectively becomes your new working directory.
~ git clone [address of repository] wp-content
Now you have a copy of your default box located in the @boxes
subdirectory and your working box. And since you’ve created a subdirectory into which you’re able to move copies of your wp-content
directory, you can hot swap boxes out of a single installation whenever you need to work on something new.
Conclusion
It’s easy think about all of the ways working with multiple installations can be managed or automated but the purpose of this article is not that. Instead, it’s to introduce to concept of boxes and how they can be used, managed, and swapped within an existing, single-site WordPress installation.
Take what you will from this, incorporate it as you want, but for what it’s worth my set up is:
- Laravel Valet
- MariaDB
- PHP (version 7.4 up to 8.1 depending on the project)
- The latest version of WordPress
And if this seems like something that’s too simple or it’s something that wouldn’t work with your existing set up, maybe it won’t. But I can speak from experience that this is part of my day-to-day workflow and it works on sites that operate on a large scale.