Erik Bernskiold

Do you have WP_DEBUG turned on by any chance?

Thanks!

Hi,

On your site it loads fine on desktop for me. What browser and version are you using when it doesn’t show?

On the proper wording, can you let me know what the expected wordings are that isn’t showing?

This is now fixed in 3.0.2.

For sure. We’ll take care of that.

Great, thanks! ??

Version 3.0.1 fixes this issue. Many thanks @headwall!

Hi!

Thanks for reporting. Can’t believe we missed that in testing…
Will push an update today. ??

That would’ve been my first idea at a solution too.
I did give it some thought, and I can’t see why one would ever want to correct relative URL on an ID. Just one of these things you never think of until it happens. ??

Hi,

I’ve been through the source code for the .htaccess class and the only .htaccess file we have available now for this project.

My conclusion is that the # END LSCACHE line must have been lost. This could easily have been a user error, I’m sure. That would’ve meant that you recognised everything as being part of the LS Cache rules and cleaned it.

Another conclusion of it is that this is one part user error, another part “could be better prevented” by dev. Since there are a bunch of (important!) comments that you add, they could perhaps be better flagged as important in the actual code. In this case the next-to-final row (## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##) suggests that it is crucial. But the one after does not, while it is in fact the latter that IS important.

I’d also suggest attempting some sort of safeguard against this. You could perhaps try and detect non-LS Cache related rules (say redirect rules), and at the very least, the core WordPress rules.

Whether it is feasible or not to try and “fix” this automatically, I’m not sure. But at the very least throw some kind of warning. The current detection/wrapping is perhaps a bit too idealistic?

The whole point is that this seems to only happen in this very case. We haven’t seen it before on any multisite config that we run.

It’s a bunch of proxy rules mixed with standard redirects. But ideally you shouldn’t parse them at all? You should allow us to do what we want with our .htaccess and just adjust as you need. Or give an option to disable updating the .htaccess and do it manually.

In this case deactivating the LS Cache plugin results in a completely empty .htaccess.

What are you doing to it?

We have it running successfully on several multisite installs without this. The most major difference is that this one contains a lot more custom .htaccess rules than just the default WP rules. If that would matter.

I can constantly reproduce on this site if I reactivate the plugin, deactivate, or in between, modify any setting.

S? bra @emmalindahl92. Antar att du hittade det under Utseende > Anpassa och sektionen Cookiebanner. ??

Version 2.0.4 just hit the repo which fixes this bug. Thanks for reporting it Anders!

Hi Anders!
Its supposed to be set for 30 days.

But when looking at this to confirm for you, it seems as though we introduced a bug when refactoring the JS so that we’re not getting that setting correctly. Resulting in what you describe.

I’ll get an updated version out hopefully during the day today.

Apologies for the issue!