Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi Guys, just wondering what is the best practise to disable the auto configured advagg module as it broke one of our clients sites after upgrade and I can't seem to disable it easily. Doesn't seem to be documented in the INI platform file nor could I see it in the release notes.
Thanks in advance.
Comments
Comment #1
snlnz CreditAttribution: snlnz commentedUpdate:
The site in question is Drupal 6.13 core
I tried to disable advagg and got:
Call to undefined function lock_acquire()
According to this issue: https://drupal.org/node/1122036
I downloaded the module to foo.bar/modules/advagg and applied the patch then I was able to disable and uninstall advagg correctly.
While it is disabled now, I'm concerned in future upgrades of this being auto enabled again.
It would be nice to know how to override the default behaviour (auto configured) so this could have been disabled in a cleaner manner.
Thanks
Comment #2
omega8cc CreditAttribution: omega8cc commentedYour problem has nothing to do with BOA features or configuration, it seems.
1. The AdvAgg module is *not* on the auto-enable list (plus there is now _MODULES_SKIP variable)
2. Using sites/foo.com/modules space is a *bad* practice.
3. AdvAgg is now included in the o_contrib space, but again, *not* enabled by default.
That said, we have an obvious gap in our auto-config in the global.inc because if the module is present (and it is now always present in the o_contrib) it will trigger Both D6 and D7 specific settings.
While it is not a problem with D7 version, which forces Drupal own aggregation to be enabled (which is OK), it is a problem with D6 version, which requires Drupal own aggregation to be *disabled*.
The result is that all D6 sites will now have CSS/JS aggregation completely disabled, if the AdvAgg is not enabled. That is a serious oversight we need to address quickly.
Comment #3
omega8cc CreditAttribution: omega8cc commentedChanging issues category and title to emphasize the real problem here.
Comment #4
omega8cc CreditAttribution: omega8cc commentedMoving to the correct queue.
Comment #5
snlnz CreditAttribution: snlnz commentedAh yes I see your points and clearly advagg must have been enabled on this site prior to the upgrade but it may have been overlooked.
Re: 2.
I understand using foo.com/modules is a bad idea but when you have to apply a patch to the module without effecting other sites in the platform, how else would you recommend testing this? The live site was down and I need it back up quickly.
Re: 3. Will this cause issues if the advagg module resides in sites/all/modules already or does the auto config point to the o_contrib space first? I forget which location takes precedence.
Comment #6
omega8cc CreditAttribution: omega8cc commentedIt is explained in the docs: https://omega8.cc/extra-modules-available-in-all-platforms-123
Comment #7
omega8cc CreditAttribution: omega8cc commentedFixed in http://drupalcode.org/project/octopus.git/commit/c5bda2d (and also in stable)
Some docs for reference: https://github.com/omega8cc/nginx-for-drupal/blob/master/aegir/tools/sys...