Ok.

So we have a live database which we dump and load into a dev copy. The dev copy *code* has a feature (module) with a change to a variable value (via strongarm). Since we have a live database copy in our dev copy we want to clear out the caches - after all it has just been dumped from the live site.

The problem is this:

Calling 'drush cache-clear all' causes a revert which creates/sets the variable in the database.

Why should a 'cc all' cause Features to kick off reverts? As much as anything - this is really confusing. You look in the features lists expecting the feature to be overridden and it is not - the cc all has already done the revert.

The problem looks like it is with the hook function 'features_flush_caches()'.

Comments

bailey86’s picture

Couple of thoughts - looking weirder/worser.

It may be more related to the pathauto module - this is the one I've been testing with - the settings of pathauto for content types are stored as variables.

Secondly, it looks like the 'rebuild/revert' happens just by visting the site as an anonymous user. Steps taken:

Load the database from the live DB dump file.
Don't run any cache clearing code:
Visit the site without being logged in.
The settings are reverted - i.e. the variables in the database are set.

bailey86’s picture

I'm still looking into this.

On a vanilla D7 with only Features, Strongarm and Pathauto installed I am not getting the problem.

bailey86’s picture

Something around L298 in features.module.

For the feature the $state=-1 and $restore_states=-1 so this is triggering a 'rebuild'. I'm still not sure what a rebuild is - but it is then updating the database from the code.

bailey86’s picture

Title: Calling cache-clear all causes Features to be reverted » Calling cache-clear all causes pathauto strongarm feature to be reverted
bailey86’s picture

Title: Calling cache-clear all causes pathauto strongarm feature to be reverted » Loading site page causes pathauto strongarm feature to be reverted
bailey86’s picture

Looks like this is only affecting a variable used by pathauto.

hefox’s picture

Category: Bug report » Support request
Priority: Critical » Normal
Status: Active » Fixed

rebuilding can be disabled during cache clear via the settings tab now.

rebuild is features detecting the code has changed since last revert/rebuild and changing the database to reflect that.

bailey86’s picture

'rebuild is features detecting the code has changed since last revert/rebuild and changing the database to reflect that.'

How does it work out if the code has changed? Is this from the features_codecache variable in the database? In which case this is going to be triggered every time by our setup because we reload the live DB to test the feature will work - so there can be a mismatch between the feature code datetime and the database variable features_codecache - and so the rebuild gets triggered.

What may be very difficult is figuring out if it only reverts features where there has been a code change - or if it is for features which have new vars added.

bailey86’s picture

I think - from other answers by hefox - that a rebuild adds to the database variables/settings which are in code but not (yet) in the database. (I presume this is just for enabled features).

This seems to happen when:

* drush cc all - unless turned off in the features settings.
* View Features list.
* Save modules list.

Status: Fixed » Closed (fixed)

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