SOLVED: Drupal Features will not revert if the .module file does not contain the include_once statement for the features.inc file
Problem/Motivation
Further to the comment #80 at this link (http://drupal.org/node/744450#comment-6320242), there are many reasons why a feature might not revert. However, described here is one very common reason. You might be working on a new piece of functionality but it's getting close to the end of the day, so you featurize what you've got and commit it. All you added was a field or a permission (or something that did not generate a .features.inc) file. This means that the .module file was generated WITHOUT a ".features.inc" file (which is fine for now - the feature works). Tomorrow, you continue your work and add a bunch of other stuff to the feature, such as a view and then re-create your feature. You notice this time that a *.features.inc file is generated - great; this is expected. What you might not notice today is that the .module file never got updated with the includeonce 'mymodule.features.inc' line that is necessary in order to have this feature revert properly should it ever become overridden.
This is completely expected based on the code currently in the stable release of features (7.x-1.0). Lines 276-310 of features.export.inc describe the behaviours that occur if the module is being newly created or being re-created and it does NOT add in the missing line. It will only be added if the feature is being freshly created; otherwise it just leaves it alone.
Proposed resolution
A manual addition of the missing includeonce 'testfeature.features.inc'; statement at the top of the test_feature.module file will rectify this for anyone who cannot use a patch but it would be preferred if features did this by default in code.
There seem to be 2 ways to resolve this issue:
1. Add the include statement into the .module file if a subsequent re-creation of a feature requires the features.inc file.
2. Always include a features.inc file, even if it is empty.
I chose the first approach for two reasons. I assumed that because the features.inc file is not included unless certain types of components are featurized, that there is a reason for that. Secondly, my approach touches less code in the module than the second option would, and therefore less possibility for error and/or regression.
The patch checks for the position of the first docblock at the top of the .module file and then inserts the includeonce statement after that. This patch has been purposely created to be slightly lenient and not search specifically for a @code docblock in case a developer has removed this. Instead, a search for the first generic multi-line comment is conducted. Should this fail to find a result, it simply inserts it at the top of the file after the first opening <?php tag. If for some reason the .module file has been completely ravaged and is just empty, it resorts to the same featureslog error that the current stable release uses and does not modify the feature code being generated whatsoever.
The following are the steps to reproduce the problem without a patch in place.
- Generate a very simple, new test feature with something very simple in it that does not generate a *.features.inc file (like a permission and a field). This exact example will produce a feature that contains something very similar to:
- a test_feature.info file
- a test_feature.module file
- a testfeature.features.userpermission.inc file
a test_feature.features.features.field.inc file
Deploy and enable this feature in an active environment.
Go back to this features page and go to the "Recreate" tab.
Add an additional component that does generate this test_feature.features.inc file such as a view.
Download a new copy of testfeature. You will see a testfeature.features.inc file this time as part of the download.
Update your deployed feature to this new version.
On the next page load of your UI, you will see a message "testfeature.module does not appear to include the testfeature.features.inc file".
Double checking the contents of testfeature.module will indeed confirm that it was not updated to have the includeonce statement that includes the test_feature.features.inc file.
The feature may already be in overridden state just as a result of doing this but if not; make a change to the view in order to place the feature in overridden state. Attempts to use the UI or drush to revert this feature will fail and the feature will remain in overridden state.
Want the patch to fix this? Available at http://drupal.org/node/1875888#comment-6884362. Maybe it'll make it into the next stable release of the features module!
