Today I opened my WordPress dashboard, ran a Site Health check, and saw a warning that said: "You should use a persistent object cache."
To be completely honest, I had no clue what a persistent object cache actually was. As you probably know from my previous post, I’m still a wanna-be developer learning the ropes. But after reading up on it, it became clear that saving database queries in the server's memory would make my site much faster. It sounded like a mandatory tweak, so I decided to turn it on.
Since I already had the LiteSpeed Cache plugin running on my site, I figured I’d handle it directly through there. I went to LiteSpeed Cache > Cache > Object tab, toggled the Object Cache option to ON, and selected Redis as the method. At this point, I totally didn't realize I had to change the host and port settings as well, so I just clicked save.
That’s when everything went south.
Instantly, my WordPress admin panel froze. Every time I clicked a menu, the page loaded indefinitely until it finally timed out and hit me with the dreaded "critical error on this website" screen. I couldn't even load the settings page to toggle it back off. I was completely locked out of my backend.
I even tried deleting the plugin files through my hosting file manager and reinstalling it from scratch, but it had absolutely no effect. The moment I activated it again, the error returned because the broken settings were permanently stuck inside the WordPress database. Out of options and completely stuck, I asked AI for help, and it gave me the advice to bypass the broken WordPress UI entirely using code.
Here is what actually happened under the hood. By default, LiteSpeed Cache assumes your server runs Redis over a standard network port on localhost. But my hosting provider (JetHost) isolates environments and uses a UNIX socket path instead of a network port. Because WordPress kept trying to talk to a network port that wasn’t listening, it got stuck in an endless connection timeout loop on every single page load.
Following the AI's advice, I logged into my hosting client area, opened the File Manager, and edited my main wp-config.php file. Right before the line that says /* That's all, stop editing! Happy publishing. */, I added these two lines to force the object cache off at the root level:
define('LITESPEED_CONF', true);
define('LITESPEED_CONF__OBJECT', false);
The moment I saved the file, my WordPress dashboard instantly unlocked and loaded normally again.
Next, I went back to my hosting control panel and opened their native "Redis Manager" tool. I turned the Redis status to Active and copied the unique connection socket path they provided. It looked like this:
/home/example/.jethost-redis/redis.sock
With the dashboard now accessible, I went back to the LiteSpeed Object Cache settings page. It was loading perfectly fine because my wp-config.php code was keeping the broken cache script asleep.
I filled out the configuration fields using the exact data from my host:
In the Host field, I deleted localhost and pasted the UNIX socket path.
In the Port field, I changed it to 0. This is crucial because UNIX sockets don't use network ports, so the value must be zero.
I clicked Save Changes.
Finally, I went back to my wp-config.php file and deleted the two temporary lines I added earlier so the plugin could actually do its job.
I refreshed the WordPress settings page, flipped Object Cache to ON, and hit save one last time. The connection test immediately changed to a green "Passed". No more dashboard freezes, the Site Health warning is gone, and the site is running exactly how it should.
After that, I fixed the exact same issue in the blog section of the Romanian version of the Eduboom website. This time, I edited the host and port fields right from the beginning, which saved me an extra hour of fixing self-created problems.
Top comments (0)