• Resolved Erik Bernskiold

    (@erik-bernskiold)


    Hi!

    Love the plugin generally, but have just run into a couple of major problems.

    We manage a pretty large multisite install. After updating to the latest version (I think this was 2.x to 3.x) and tweaking some settings, every page on the site showed a 404.

    A quick inspection showed that the .htaccess was empty, save for the LS Cache rules. All our custom rules, as well as the WP core rules were gone.

    The only way we could get rid of this was to disable LS Cache completely. It did not matter whether we had it network installed or just for a single site.

    Seemingly, it doesn’t seem to matter which settings were on/off. The same thing happened on every settings save.

    On deactivation, the .htaccess was also completly cleaned to a blank file.

    On another multisite note, when enabling on multisite, I’d like to selectively enable cache on certain sub-sites. However, toggling the enable cache setting from “Off” to “On” does not save. Any option I set toggles back to “Off” automatically.

    Thanks,
    Erik

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Support qtwrk

    (@qtwrk)

    Hi,

    I can not reproduce the .htaccess

    but I did reproduce the individual site cache on off thing.

    will report to dev to further check.

    Best regards,

    • This reply was modified 4 years, 5 months ago by qtwrk.
    Thread Starter Erik Bernskiold

    (@erik-bernskiold)

    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.

    Plugin Support qtwrk

    (@qtwrk)

    Hi,

    Could you please try on a clean WP site ? maybe something else gets in way.

    I can not reproduce this on default WP

    Best regards,

    Plugin Support Hai Zheng?

    (@hailite)

    Maybe its caused by the conflict in those custom rules when LSCWP tried to parse the rules. Can you paste the rules so @qtwrk can try w/ them to reproduce?

    Thread Starter Erik Bernskiold

    (@erik-bernskiold)

    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?

    Plugin Support qtwrk

    (@qtwrk)

    Hi,

    By design , it only remove the rules with the marker

    # BEGIN LSCACHE
    ## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
    <IfModule LiteSpeed>
    RewriteEngine on
    CacheLookup on
    RewriteRule .* - [E=Cache-Control:no-autoflush]
    ...
    ...
    ...
    ## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
    # END NON_LSCACHE

    That’s why we think it could be a bug somehow , but we still need a way to reproduce it first.

    Best regards,

    Thread Starter Erik Bernskiold

    (@erik-bernskiold)

    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?

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Multisite settings update clears .htaccess’ is closed to new replies.