Let’s get salty!
Because I’m on a roll today, so far I’ve broken 4 things today, including wp-cli, and Local by Flywheel.
However I want to talk about what salts are, and why they are important, and how I found out about them.
The below tweet, and its thread, has all the info, tldr follows after.
For whatever reason when I tried to install a multisite via wp-cli, from a totally new codebase, to a totally new, non existent database at the time, it would do a half job.
— Gabor Javorszky 🇪🇺 (@javorszky) July 10, 2018
It would tell me that the single site tables are already installed.
"Strange, the db is empty..."
2/
The short is that multiple WordPress installs on the same host machine which has one Redis installed will step over each other’s caches, which will bleed data from Site A to Site B and vica versa, which can lead to VERY interesting results.
Redis out of the box has 16 buckets, and the plugins providing Redis object caching to WordPress usually use the first one. All of them.
The keys WordPress use usually begin with the table prefix, which won’t change on a local install, so all my installs have wp_ as their prefixes.
Which means every local WordPress install shares the same Redis bucket, and the same keyspace.
Enter salts
Both the redis plugins (Redis Cache and WP Redis (I prefer this one)) use the constant WP_CACHE_KEY_SALT to make sure that the key prefixes are unique.
Therefore in order to wall off each install from the others, you should set the salt to something unique.
You can visit https://wpsaltdotenv.herokuapp.com/ (might take a while on first visit while heroku spins up), reload a few times, and use one of them as such:
define( 'WP_CACHE_KEY_SALT', '<random string>' );
Context: WordPress 4.9.7, WP-Redis 0.7.0, Redis-Cache 1.3.8
Photo by Tanya Nevidoma on Unsplash