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
Comment #1
bailey86 commentedCouple 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.
Comment #2
bailey86 commentedI'm still looking into this.
On a vanilla D7 with only Features, Strongarm and Pathauto installed I am not getting the problem.
Comment #3
bailey86 commentedSomething 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.
Comment #4
bailey86 commentedComment #5
bailey86 commentedComment #6
bailey86 commentedLooks like this is only affecting a variable used by pathauto.
Comment #7
hefox commentedrebuilding 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.
Comment #8
bailey86 commented'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.
Comment #9
bailey86 commentedI 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.