We're attempting to roll out this module on a larger site. Large sites tend to need more granular cache control to avoid resource dogpiles. Unfortunately, drush en and drush dis — which this module calls as subcommands — clear all caches.

It'd be nice if it was possible to somehow regulate this. Maybe even something as simple as defining a custom cache-clearing callback, which Master would call after enabling/disabling.

There would also need to be non-cache-clearing variants of drush_enable_modules() and drush_disable_modules().

We could either have a callback each for enable, disable, uninstall or one callback passed $op (enable, disable, uninstall) and $modules (array of module names).

If you have any better suggestions on how to avoid the cache-clearing problem, I'd love to hear them.

Comments

derhasi’s picture

derhasi commented

Hm, I really would like to avoid duplicating drush en & co. But therefore we'd need to implement a --no-cache-clear flag into drush core. We then could use that to build a wrapper option to skip cache clear.

How did you manage that task without master? Did you write your own drush command for disabling and enabling? Maybe we can build on top of that approch to build a suitable wrapper.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Right now, we are simply not running the task on our production deployments. It is OK to clear the cache on staging when there are new modules.

I think getting something into Drush itself is the way to go. If you open an issue on GitHub, maybe you could link it here.

Some level of cache-clearing management (or integration with a better tool) would be cool. For example, maybe master could return a parameterized list of the modules that it has enabled which could then be piped or backticked into another command from some other plugin. e.g. theoretically drush prune-cache `drush master-ensure-modules --pipe --yes`.

Thank you for the quick reply!

derhasi’s picture

derhasi commented

There's already an issue on github dealing with that: I posted a comment on the quite generic discussion: https://github.com/drush-ops/drush/pull/308

derhasi’s picture

derhasi commented

As a site note: setting $conf['features_rebuild_on_flush'] = FALSE; might also help and will avoid problems with late enabling of modules (e.g. module is not active yet, but feature containing module dependency gets already reverted).

derhasi’s picture

derhasi commented
Status: Active » Fixed

Implemented the "--no-cache-clear" option in commit f138f7429eafd12f5b96d04c50049c8febe556d3.

@wizonesolutions, feel free to test the latest dev :)

Status: Fixed » Closed (fixed)

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