confirmed, this is by design. the compatibility logic was off on “old” installations” but there is no need for that really 🙂
ok how can i restore it in the old“old” installations”
in database the autoptimize_installed_before_compatibility se to on ?
if you insist; yes 🙂
or use the autoptimize_filter_init_compatibility filter 😉
May I ask, what are things to look for when considering to permanently enable this? Is the additional compatibility logic code query intensive or heavy?
I see the release notes for v3.0, and I do have non-aggregated inline JS requiring jQuery and such.
I assume it’s low-risk, but there must be a reason it’s left to the user to enable or not.
Cheers!
Nate
well, back in the 3.0 days the assumption was that for existing and thus confirmed working installations the compatibility logic brought no advantages and *could* cause regressions, hence compatibility was disabled for those (there are no complex/ heavy queries in the compatibility code).
this new option gives users of “older installations” the option to enable compatibility anyway, but as it is only useful in case of problems, I would advice to keep it off unless something is broken and only then to enable it to see if is automatically fixes the issue 🙂
Thank you for the clarification!
