Wordpress LScache Plugin: Critical bug (multisite superadmin)
Last Updated on: Wed, 15 Apr 2026 00:00:02 Hi, there is a critical bug in your plugin which I just found. in public function finalize_default_vary() it does a get_role(). If the user is a superadmin, it will cache the page for that users superadmin data, but it will save it as guest data ? this is because the role returns empty for superadmins. I think in public static function get_role() you need to add something like if (! $role) if (is_super_admin()) $role = super_admin You also have a whole host of other issues like the _ls_cache_vary not being cleared if the user is only logged in for the session and just a host of issues that you guys should notice just using the plugin. Ill add that debugging this is very difficult because theres 1) no indication of the varys in the headers. Eg its impossible to tell whether its public or private, and which vary is being invoked (if at all) 2) completely contradictory information in your documentation ? any cookie with _lscache_vary is meant to trigger a vary, but in practice it appears that it needs to be setting both a clean _lscache_vary AND an additional vary cookie eg _lscache_vary_mycustomvary . please correct me if I understand it wrong so this is what I tried set up a sub-dir network install and network activate LSCWP , enable network cache go to site 1 as super admin , visit frontend page as / checked HTML source output with timestamp create a new user as normal user , visit the same page , checked HTML source again they are showing different timestamp , which means they are not same page each one got its own private cache. The repro is: 1) Create a new subdomain site 2) Do not add the superadmin user to this site. The functions I mentioned check user role against the current subsite. Super Admins can be logged in WITHOUT being a user on the site, so it checks the users roles and finds none, therefore assumes the user to be a guest. Cheers on debug log , I can see with super admin to / , 05/04/22 16:55:17.697 [111.111.111.111:51499 3 y3x] Cookie _lscache_vary: admin_bar:1 logged-in:1 role:99 05/04/22 16:55:17.697 [111.111.111.111:51499 3 y3x] X-LSCACHE: true 05/04/22 16:55:17.775 [111.111.111.111:51499 3 y3x] [Ctrl] X Cache_control -> private ( logged in user ) 05/04/22 16:55:17.775 [111.111.111.111:51499 3 y3x] [Router] get_role: ` then with normal user , I got 05/04/22 16:57:10.551 [111.111.111.111:56787 3 pGv] Cookie _lscache_vary: admin_bar:1 logged-in:1 05/04/22 16:57:10.551 [111.111.111.111:56787 3 pGv] X-LSCACHE: true 05/04/22 16:57:10.566 [111.111.111.111:56787 3 pGv] [Ctrl] X Cache_control -> private ( logged in user ) 05/04/22 16:57:10.566 [111.111.111.111:56787 3 pGv] [Router] get_role: subscriber then with guest user, I got 05/04/22 16:59:54.062 [111.111.111.111:57588 3 BOB] Accept Encoding: gzip, deflate, br 05/04/22 16:59:54.062 [111.111.111.111:57588 3 BOB] X-LSCACHE: true 05/04/22 16:59:54.117 [111.111.111.111:57588 3 BOB] [Router] get_role: without cookie vary , but yes , it doesnt give role assignment on super admin I think its more like small flaw instead of critical bug though , since the cache does not get messed up between super admin and guest user will advice our devs to check it further.` Super_admins also arent considered for cache_varys in the admin page. You might need to look at this. Also in other caching plugins theres a really clear header showing which vary is active. This would make debugging this kind of thing infinitely easier than trying to read through debug logs. Thanks
LiteCache Rush: Speed comes from using less, not from doing it faster
Reference