Further to the comment #80 at this link (, 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 * file. This means that the .module file was generated WITHOUT a "*" 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 * file is generated - great; this is expected. What you might not notice today is that the .module file never got updated with the include_once '' 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 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 include_once ''; 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 file.
2. Always include a file, even if it is empty.

I chose the first approach for two reasons. I assumed that because the 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 include_once 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 features_log error that the current stable release uses and does not modify the feature code being generated whatsoever.

Remaining tasks

This patch needs to be reviewed by the community. The following are the steps to reproduce the problem without the patch in place.

- Generate a very simple, new test feature with something very simple in it that does not generate a * file (like a permission and a field). This exact example will produce a feature that contains something very similar to:
- a file
- a test_feature.module file
- a file
- a 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 file such as a view.
- Download a new copy of test_feature. You will see a 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 "test_feature.module does not appear to include the file".
- Double checking the contents of test_feature.module will indeed confirm that it was not updated to have the include_once statement that includes the 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.

User interface changes


API changes


Original report by [mpotter] indicates the module maintainer is aware of the issue and that it requires a new issue summary so it can be resolved.


timfernihough’s picture

Here is the patch rolled against the current stable version (7.x-1.0).

Everett Zufelt’s picture

Version:7.x-1.0» 7.x-1.x-dev

Code looks good, did not execute.

DamienMcKenna’s picture

Wasn't this supposed to have been resolved via #994140: Modify .module file when a is added?

timfernihough’s picture

Hmm, thanks DamienMcKenna. I didn't see this other thread. I see there are three patches in this thread - the first two I would argue work towards the solution but aren't as comprehensive as mine. The third ( at quick first glance looks like it is trying to accomplish the same goal and appears to have already been committed.

In my experience I have found that the .module file of a custom feature can be manipulated pretty heavily by developers as they add in custom hooks. I would argue that my patch respects the current contents of the feature and all custom commenting that a developer may have added (whatever they are) more so than the patch that got committed. The current patch removes any messages at the top of the file should they exist.

That being said, I don't want to suggest that I've done a better job than @hefox - his patch definitely works and we're both just trying to make the module better. =)


betz’s picture

Status:Needs review» Closed (duplicate)

Guess this is resolved then?

crutch’s picture

omg, mind blown. I'm able to use features, but had to manually delete some tables already existing in database from the target site. Was then able to resolve the overridden issue. Next, had to manually remove any deleted fields from the front end to match up content types on target site to match source site. Then import data back into correct tables from source site to target site. This worked but was a heavy process.

crutch’s picture

Issue summary:View changes

corrected a typo.