Welcome Guest. Please Login or Register  


You are here: Index > Softaculous Auto Installer > General Support > Topic : WordPress: Incompatibility between SQLite Object Cache and Softaculous Login



Threaded Mode | Print  

 WordPress: Incompatibility between SQLite Object Cache and Softaculous Login, cPanel WordPress admin bypass login fails with persistent object cache active. (12 Replies, Read 9841 times)
OllieJones
Group: Member
Post Group: Newbie
Posts: 5
Status:
I develop the SQLite Object Cache plugin for WordPress. wordpress (dot) org/plugins/sqlite-object-cache/

I have a defect report from a user here.  github (dot) com/OllieJones/sqlite-object-cache/issues/84

They say this:
Quote
On a shared hosting provider using a Softaculous-installed instance of WordPress, installing and enabling SQLLite3 Object Cache breaks the ability to use their admin login bypass (Wordpress redirects to the homepage and WP Cerber will show "deleted invalid cookies" as an underlying action).

Logging in manually via /wp-admin still works in this case, and all site functionality appears normal (and snappier) until logging out and then trying to log back in via the cpanel/Softaculous link.


Can you suggest a modification I can make to the plugin to avoid this?
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
colombiacloud
Group: Member
Post Group: Newbie
Posts: 5
Status:
try excluding /wp-login.php and /wp-admin requests from the object cache  :angel:

-----------------------
Hosting Colombia
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
OllieJones
Group: Member
Post Group: Newbie
Posts: 5
Status:
Page caches allow the exclusion of particular pages. That is not the way the WordPress persistent object cache works, however.



IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
landonpierce
Group: Member
Post Group: Newbie
Posts: 2
Status:
It looks like Softaculous’ login bypass relies on very specific authentication cookies and redirects, and a persistent object cache can easily interfere with how those values are stored or validated. Since excluding /wp-login.php isn’t how object caching works, the safest workaround on the plugin side would be to skip caching any auth-related keys, especially anything tied to session tokens, cookies, or nonces. In short: make sure the cache never stores or serves stale authentication objects. That should prevent Softaculous’ auto-login flow from breaking while keeping the rest of the cache intact.
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
OllieJones
Group: Member
Post Group: Newbie
Posts: 5
Status:
Quote From : landonpierce November 22, 2025, 7:37 am
... the safest workaround on the plugin side would be to skip caching any auth-related keys, especially anything tied to session tokens, cookies, or nonces. In short: make sure the cache never stores or serves stale authentication objects. That should prevent Softaculous’ auto-login flow from breaking while keeping the rest of the cache intact.


For what it's worth, such things are not in the cache, leastways not in ordinary WordPress. Auth tokens and nonces are HMAC hashes of the parameters that went into creating them, and don't typically have transients or other persistent data structures behind them other than user_id.
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
KylieGray
Group: Member
Post Group: Newbie
Posts: 2
Status:
I’ve noticed the same issue with SQLite Object Cache on a WordPress site installed via Softaculous. Activating persistent object caching seems to block the admin login through cPanel, likely due to how sessions are handled. For now, the workaround is to temporarily disable the cache before logging in, but it would be great if the plugin could automatically handle this incompatibility.
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
SamuelBerry
Group: Member
Post Group: Newbie
Posts: 1
Status:
It sounds like the issue may be related to how cookies are managed when the SQLite Object Cache plugin is enabled on Softaculous installed WordPress. One potential solution could be to adjust the plugin's cookie handling logic to ensure it doesn’t conflict with login redirects or WP Cerber's cookie validation. You might try adding a check to ensure proper session management and cookie consistency with both SQLite and WordPress login mechanisms. Let me know if you'd like further details on this approach!

-----------------------
???? Web developer & hosting expert passionate about WordPress, cPanel, and Softaculous automation. Sharing tips on web apps, SEO, and cloud optimization to help build faster, smarter websites.
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
OllieJones
Group: Member
Post Group: Newbie
Posts: 5
Status:
Quote From : SamuelBerry December 4, 2025, 10:53 am
...  adjust the plugin's cookie handling logic to ensure it doesn’t conflict with login redirects or WP Cerber's cookie validation.

...

Let me know if you'd like further details on this approach!


Yes please! Object cache plugins don't do anything at all with cookies. They replace the core implementation of WP_Object_Cache with one that includes persistence. It's not clear, to me anyhow, what stale cached data interferes with the Softaculous login workflow.

Any wisdom you can offer would be great.
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
landonpierce
Group: Member
Post Group: Newbie
Posts: 2
Status:
It might not be cookies directly, but Softaculous’ auto-login flow depends heavily on very short-lived usermeta and auth-related lookups that normally bypass persistent storage. Even though WordPress doesn’t persist nonces or auth tokens, Softaculous creates (and expects) fresh user session state at the moment the bypass link is clicked. If the object cache is persisting any part of the user’s last session especially get_user_meta(), cached capabilities, or the WP_User object it can cause WP Cerber to treat the Softaculous-issued cookies as “invalid” because the underlying user state doesn’t match what WordPress recomputes during a normal login. In shared hosting, this becomes more visible because Softaculous and WordPress aren’t always running under the same PHP worker, so stale cache keys linger longer. A possible fix on the plugin side would be to avoid caching usermeta and capability lookups during authentication requests. Checking for wp-login.php, wp-admin, or is_user_logged_in() during the login handshake only might be enough to force fresh reads on those keys without disabling caching globally. Not a perfect solution, but it narrows the issue to where Softaculous’ bypass actually fails.
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
OllieJones
Group: Member
Post Group: Newbie
Posts: 5
Status:
Quote From : landonpierce December 9, 2025, 7:33 am
... but Softaculous’ auto-login flow depends heavily on very short-lived usermeta and auth-related lookups that normally bypass persistent storage. Even though WordPress doesn’t persist nonces or auth tokens, Softaculous creates (and expects) fresh user session state at the moment the bypass link is clicked. If the object cache is persisting any part of the user’s last session especially get_user_meta(), cached capabilities, or the WP_User object it can cause WP Cerber to treat the Softaculous-issued cookies as “invalid” because the underlying user state doesn’t match what WordPress recomputes during a normal login.


OK, that is helpful. I can try a few things in the plugin.

Quote From : landonpierce December 9, 2025, 7:33 am
In shared hosting, this becomes more visible because Softaculous and WordPress aren’t always running under the same PHP worker, so stale cache keys linger longer.


BOOM! If the object cache plugin has the APCu level-2 cache enabled this is certainly going to foul things up.

Quote From : landonpierce December 9, 2025, 7:33 am
A possible fix on the plugin side would be to avoid caching usermeta and capability lookups during authentication requests. Checking for wp-login.php, wp-admin, or is_user_logged_in() during the login handshake only might be enough to force fresh reads on those keys without disabling caching globally. Not a perfect solution, but it narrows the issue to where Softaculous’ bypass actually fails.


I'll give this a try.
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
davidhasting
Group: Member
Post Group: Newbie
Posts: 2
Status:
This sounds like a conflict between the SQLite Object Cache and Softaculous login handling. Try disabling the object cache temporarily to see if login works, then look for an updated plugin or alternative caching method compatible with cPanel/Softaculous.
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
Mahesh-Softac
Group: Softaculous Team
Post Group: Newbie
Posts: 6
Status:
Hi,

Thank you for details.

We tried to replicate this issue on our test servers, however we were not able to replicate the same.

If you or the client is still facing the issue, please open a support ticket with us.

support email : support@softaculous.com
Or use this link : https://softaculous.deskuss.com/open.php
IP: --   

WordPress: Incompatibility between SQLite Object Cache and Softaculous Login
defriska
Group: Member
Post Group: Newbie
Posts: 1
Status:
Hi Ollie, I ran into something very similar on a shared host with Softaculous a while back, so this doesn’t surprise me. The issue wasn’t the cache “breaking” login itself, but how Softaculous does its admin bypass using temporary auth cookies and redirects.

From what I saw, the object cache was persisting or validating auth/session data a bit too early in the request cycle, so those one-time Softaculous cookies got treated as invalid and wiped. That lines up with WP Cerber reporting “deleted invalid cookies” and the redirect back to the homepage.

What helped on my end was bypassing object caching for auth-related keys and early login actions. In practice, that meant not caching anything during wp-login.php and admin-bypass style logins, or explicitly excluding auth cookies / user session data from the object cache layer.

Another workaround was detecting Softaculous admin logins (they usually pass a specific query param or cookie) and disabling the object cache for that request only. After login, everything worked fine again.

Manual /wp-admin login always worked for me too, which made it clear this was more about how the bypass works than a general auth problem.

Hope that helps narrow it down. It might be worth documenting this edge case too, since shared hosting + Softaculous is still pretty common in 2026...
IP: --   

« Previous    Next »

Threaded Mode | Print  



Jump To :


Users viewing this topic
1 guests, 0 users.


All times are GMT. The time now is January 22, 2026, 7:55 am.

  Powered By AEF 1.0.8 © 2007-2008 Electron Inc.Queries: 11  |  Page Created In:0.008