I have never heard of or seen this before I’m afraid. Have you tried disabling JS or CSS or HTML optimization to see which one triggers this behavior?
I found this thread here where you stumbled upon this issue apparently:
https://wordpress.org/support/topic/autotimize-is-returning-406-error/
How would I disable JS/CSS/HTML when I can’t accept wp-admin of the sub-sites with Autooptimize enabled?
I have a feeling this issue is not local and affects other installations on multisite. Can you please verify if it works on multisite environment for you?
EDIT: The error only appears when you try to access wp-admin of a sub-site, with this plugin enabled.
-
This reply was modified 6 years, 1 month ago by
iamonlythird.
-
This reply was modified 6 years, 1 month ago by iamonlythird.
Although that other topic is also concerning AO & 406 errors, it is different in other senses; older version of AO (which worked for you), probably not multisite, not when logging in but “retrieved randomly on pages” and this was probably due to a specific issue with IIS setup.
I can confirm that multi-site does work OK in my tests, so this most certainly is not a generic multisite-problem (in which case there would have been more people encountering this problem).
Upon searching a bit I learned that “406 not acceptable” typically is a mod_security triggered error, can you check (with your hoster) if that module indeed is running and if so look at the mod_security logfile to see which mod_security rule is blocking access?
frank
Checked the logs with my host (this is a dedicated server so I have access to everything), the mod_security rule that is broken is the brute force one. The login screen reloads a few times and the rule is triggered.
After countless of testing, my host advised to stop using this plugin.
Obviously, I don’t want to unless if it is the only way. This has been a great reliable plugin until now. =)
Is there anything else I, or we, could do to resolve this issue?
Hmmm … the only context in which I have seen this (login reloading) is when using domain mapping. so I guess you are you using domain mapping as well, can you try the workaround described in https://wordpress.org/support/topic/redirection-loop-with-2-4-1/#post-10798468 ?
frank
Frank, we are indeed using domain mapping via the “WordPress MU Domain Mapping” plugin. I have implemented the fix (posted on the other thread) and it is working, and files appear to be compressed properly.
Is there any way you could implement this fix into the next update of this plugin?
Is there any way you could implement this fix into the next update of this plugin?
no and yes 🙂
no because changing the hook for all users is likely to break stuff, so we won’t do that
but yes, for AO25 we’ll check if a constant is set and only if not set we’ll use plugins_loaded, so as of AO25 you’ll simply add this to your wp-config.php to work around this (nasty) domain-mapping specific issue;
define( 'AUTOPTIMIZE_SETUP_INITHOOK', 'init' );
frank
I guess that means you’re happy, feel free to leave a review of the plugin and support here! 🙂
have a nice day,
frank
