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

snlnz’s picture

Status: Active » Needs review

Update:
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

omega8cc’s picture

Your 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.

omega8cc’s picture

Title: Disable auto configured advagg module » AdvAgg (D6 version) presence in o_contrib should not auto-disable standard aggregation
Component: Documentation » Code
Category: Support request » Bug report
Status: Needs review » Active

Changing issues category and title to emphasize the real problem here.

omega8cc’s picture

Project: Barracuda » Octopus

Moving to the correct queue.

snlnz’s picture

Ah 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.

omega8cc’s picture

omega8cc’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.