WordPress behavior on multi-site installations with nginx

About a month ago I built a test site on nginx with fastcgi caching in preparation for moving our main production site to nginx as well. As part of the optimization process, Redis Object Cache was installed as well, running on database 0. (Database 0 was to be reserved for the production site later.) All worked smooth and I was pleased with the end-result after tuning the nginx configuration to be secure as well as fast where possible.

Yesterday night I migrated the production site to the new target platform and all was working fine until I enabled Redis Object Caching. First I had switched databases for the test site to database 1 and rebooted the server to clear the object cache. However, after enabling Redis Object Cache, all requests were redirected by WordPress to the test site.

This is the configuration for the production site. For the test site, the database had been switched to database 1.

/** Sets up WP Redis Cache */
define( 'WP_REDIS_CLIENT', 'phpredis' );
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis/redis.sock' );
define( 'WP_REDIS_DATABASE', 0 );

After rebuilding the site, I noticed my error, at least so I thought. The instructions to configure Redis, were stored after the line:

/* That's all, stop editing! Happy publishing. */

/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
        define( 'ABSPATH', __DIR__ . '/' );
}

/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';

A rookie mistake, I’m ashamed to admit. In the back of my mind I was thinking, there’s something with this line stating that I should stop editing but I had forgotten an important lesson once learned: https://wordpress.stackexchange.com/questions/353887/why-edits-to-wp-config-php-must-come-before-thats-all-comment

The problem with my configuration was, that the settings were never applied to the WordPress installation because after the ‘require once’ WordPress loads with all its plugins. So, the Redis Object Cache plugin was running on defaults, the same defaults as the test site.

So, I thought, that’s it. That’s the error the user reporting multisite issues with Plesk may have experienced too. So, I went through the steps of dropping the database, deleting the folder with the WordPress installation for the production site. To be absolutely sure their would be no interference while rebuilding the production site, I temporarily disabled the test site in nginx and rebooted the server again. Next, I recreated and restored the database, restored the WordPress installation for production and all was working again until I enabled the Redis Object Cache plugin again…

So, something was off and it was not possible for it to be caused by a database conflict. I left the matter for a while and went to sleep on it, leaving the production site running without object caching.

Today, I went back to task of getting Redis Object Cache installed and, although well prepared to have the site back on-line in 5 minutes, I encountered the same problem which is when I revisited one of my assumptions, namely that I thought that I had setup Redis Cache on my server to be on volatile storage… It turns out that a simple:

redis-cli
127.0.0.1:6379> select 0
127.0.0.1:6379> keys *

Was all that was needed to see the error of my ways. In order to solve all my problems, all I needed to do was:

127.0.0.1:6379> flushall
OK
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> exit

Instead of having the Redis cache stored on volatile storage, my configuration was storing it on disk. Hence the reason why a reboot never cleared my cache.

Anyway, multiple lessons learned and all is working well now. Just wanted to share my learnings to help any others who may find themselves in a similar situation in the future.