As per the title. I wonder if this is undesirable? As a workaround I have uninstalled comment.module completely to remove the existing variables.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Simon Georges’s picture

If comment module is not installed, the variables do not exist. The only case concerned here is when you disable comment module after having it for some time. I think in this case you could want to retain the values in case you enable it again.
Strongarm is a tool for developper, I suppose it's easy enough to remove the comment related lines of your Feature.
I'm proposing this for "won't fix".

Alexander Allen’s picture

Category: bug » feature
Status: Needs review » Active

Proposing this "for fix".

The comment module is enabled by default in Drupal 7 when you don't do the "minimal" installation.
I did not do the minimal installation in my site.
When I exported my content types into Features for the first time, Comment was still on.
Upon noticing that Comment was on, I disabled it.

When I re-exported the Feature I noticed that the comment strongarm variables where still present in the physical Feature. I went to the Feature UI and removed the comment variables, re-exported, and the comment variables where still being exported into the physical Feature files (*.info and *.strongarm), even though they where no longer present in the Features UI.

When going back to the Features UI you see that the comment variables are no longer marked for export, yet they appear as "overriding" the Feature. At this point I'm confused as to why these comments variables are being exported after disabling the comment module. This confusion alone warrants a fix.

Since I'm working on a production site, I wanted to make sure that my Feature is being properly exported, so just like Simon Georges described, I proceeded to manually remove the comment variables from the Feature files themselves, reverted the Feature, then cleared all the caches.

After going back to the Feature UI to confirm that it was no longer marked as overridden, I noticed it was still marked as overridden by the comment variables that where now no longer marked for export, or present on the physical Feature.

The fix is simple, all it would require is checking to see if the comment module is enabled on the strongarm_features_pipe_node_alter() function, strongarm.module. Assigning to myself, will post patch.

Alexander Allen’s picture

Calling module_exists('comment') verifies if the comment module is enabled.
If the developer decides to re-enable the comment module, he needs to recreate the Feature after re-enabling the comment module. I was able to verify that running drush fu -y [name_of_the_feature] adds back all the appropriate comment variables to the Feature. When comment is disabled, the Feature is no longer overridden, and no extraneous variables exported. Everything works now as I expected.

FYI, it appears that the order in which the comment variables are added is relevant. I did notice a change in the amount of comment variables exported depending in the location of the comment variables within strongarm_features_pipe_node_alter(). After applying the attached patch the amount of comment variables exported equal the amount of variables exported without the patch, which is the desired behavior.

Also now that I think about it, strongarm_features_pipe_node_alter() does not differentiate between developers that install their site using a barebones configuration and those that perform the regular install. This issue might be affecting them as well. For that reason I think this should be classified as a bug report.

Thank you!

Alexander Allen’s picture

Assigned: Unassigned » Alexander Allen
Category: feature » bug
Status: Active » Needs review
FileSize
1.46 KB

Patch re-roll against latest 7.x-2.x-dev version.

bblake’s picture

Category: feature » bug
Status: Active » Needs review
FileSize
1.41 KB

The above patch seemed to work great if the comment module was disabled, but if it was enabled I was only getting the comment variables output ( omitting the node_, menu_ etc vars ). Attached patch appears to output the correct variables with comment module both enabled and disabled. Please verify, and I'll commit once it has been reviewed.

( Note: as before, if the comment variables are already in the feature, and you disable comment, you'll need to manually remove the comment vars before trying to re-export. The re-export should not add them back )

bblake’s picture

Can someone help verify the above patch solves the problem, then i'll go ahead and commit.

bblake’s picture

Status: Needs review » Fixed

patch committed

Status: Fixed » Closed (fixed)

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