WordPress across many installs, not one at a time

The WordPress toolkit is worth reaching for at the moment your workflow stops being about one site. Installing WordPress once is trivial anywhere. Keeping thirty installs consistent, patched and accounted for is the part that quietly consumes an afternoon a week.

The problem it addresses

A network built over time drifts. One install is two major versions behind because nobody dared update it. Another runs a plugin the rest do not. A third was set up by someone else and nobody is certain what is on it.

None of that is visible while you work site by site, because site by site everything looks fine. It becomes visible only when you can see the installs side by side, which is the toolkit's actual value.

What to use it for

1. Inventory. Which installs exist, on which accounts, at which versions. Start here on any estate you inherited.
2. Deploying across a domain list. Standing up many sites with the same starting configuration, rather than repeating a manual setup and introducing small differences each time.
3. Updates. Seeing what is behind, and moving it forward deliberately instead of discovering it during an incident.
4. Cloning to a staging copy before a change you are unsure about.

The discipline that matters more than the tool

Anything applied across many installs at once follows the same rule as every other bulk operation: one, then a few that differ, then the rest.

For WordPress specifically, the "few that differ" should include the awkward ones on purpose. Pick the site with a shop, the one with a busy form, and the one pinned to an older PHP version. The install that breaks is never the plain one.

Take a backup immediately before, not the night before. The wider treatment is in WHM and Accounts.

Two settings that undo the network if you sweep them

Be careful applying these estate-wide:

• Identical admin usernames or passwords. Convenient during a bulk deploy and the single fastest way to turn one compromised site into all of them. Isolation between accounts counts for nothing if one credential opens every install.
• The same plugin set everywhere, unreviewed. Your sites already share a recipe, which means they share a weakness. That is normally acceptable, but it is worth being a decision rather than an accident. A vulnerability in a plugin you put on thirty sites is a vulnerability on thirty sites.

Staging copies are not free

A clone consumes disk, inodes and backup weight on whichever account it lives on, and inodes run out well before bytes do on a WordPress network. Delete the copy once the test is over. Where a staging site has to stay, refresh a single one in place; dated clones pile up unnoticed.

The quota side of this is in cPanel in Practice, and the practice of testing before rolling out is in Running Your Estate.

What it does not do

It does not make sites fast: that is caching, covered in Speed and Caching. It does not alter what the network looks like from outside: that is decided by the addresses and the nameservers. And it does not remove the need to look at an individual site occasionally, because an inventory view tells you what is installed, not whether it is working.

If your network is entirely WordPress and you would rather not administer the platform layer at all, managed WordPress hosting ships with this already configured.