Enabling a Feature via Drush

I have this same problem. drush pm-enable fails to enable certain of things related to my feature. permissions, for example. I have to go in through the UI to do it, which is a drag since the rest of my migration script is scripted.

If this on Stack Overflow is the same Kevin as @Kevin Quillen, then the answer might be a conflict between two features.

I've never had permissions work terribly reliably with features. See if you can reproduce it on a completely new site, and also give us more details of precisely what permission, what roles, in what way it fails to enable (just doesn't check that checkbox in permissions?)

I'm having the same or a similar issue. My Drupal and drush versions are as follows:

# drush status
 Drupal version                :  7.15
 Site URI                      :  http://drupalvm
 Database driver               :  mysql
…
 PHP configuration             :  /etc/php.ini
 Drush version                 :  5.4

My features module version is as follows:

# drush pm-info features
 Extension        :  features
 Project          :  features
 Type             :  module
 Title            :  Features
 Description      :  Provides feature management for Drupal.
 Version          :  7.x-1.0
 Package          :  Features
 Core             :  7.x
 PHP              :  5.2.4
 Status           :  enabled
 Path             :  sites/all/modules/contrib/features
 Schema version   :  6101
…

Steps to reproduce

I have a features generated module that contains a single view definition named peak_xml_feeds.
If I enable this module at the command line using drush pm-enable, like this:

# drush en peak_xml_feeds

…then it is enabled in features but is listed as Overridden.
Using…

# drush features-revert peak_xml_feeds

…does not work to stop it being Overridden.
Doing a diff on the feature with…

# drush features-diff peak_xml_feeds

…shows that the view defined in the peak_xml_feeds module is never actually created.

The only solution is to disable the peak_xml_feeds module, then go to the features admin interface in a web browser and enable the peak_xml_feeds feature there.

Suggested solution

Perhaps a drush features-enable command is required, that will enable a feature in the same way as the features browser interface.

I'm curious in the above case. When you add your feature, can you go into the Modules page UI and enable it there? Does that act like enabling it from the Features page, or does it act like enabling via drush?

I don't think the solution is to add another drush command. I think the solution is to ensure that enabling the exportable module itself properly enables the feature. So the problem is likely more in the depths of the hook for module enables.

I have a similar issue happening, with field creations. I just tested it using two clean Acquia installs. When I install my feature using the admin > structure > features interface, my fields on my bean come in fine. When I install via drush (using drush en my_feature), the bean type is installed but none of the fields are associated with it.

Steps to reproduce:

1. Use two clean Drupal 7.15 installations
2. Install features, bean, entity and uuid
3. Enable features, bean, bean_admin_ui, bean_uuid, ctools, entity and uuid
4. Create a new Block Type, with name and description in one installation
5. Add two fields (in my case, one just a text field and one as a long text field). Make sure they are new fields, not existing fields
6. Export the Block Type as a feature named my_feature
7. Unpack the feature to the other installation
8. Run drush en -y my_feature
9. Go to admin > content > blocks.
10. Add a new block
11. You will see that the fields are missing. You can also confirm in the database that field_config and field_instance_config have no mention of this field, nor have data or revision tables been created for them.
12. Run drush dis -y my_feature
13. Go to admin > structure > features.
14. Check My Feature and enable it
15. Repeat steps 9 and 10
16. You should see the two fields you specified in step 5.

Since Bean relies on the field export (it just adds dependencies) it shouldn't be anything specific to Bean causing this. And because it behaves differently between doing a drush en and installing via the features interface, something different must be happening.

If, after step 16, you disable the feature (from the interface) and uninstall it (via drush), you'll see no block type. If you check the database, the field definition and field instance are still present in the appropriate tables. When you re-enable the feature (via drush) the bean type appears fine.

If you replace step 8 with enabling it via the admin > module page, it does not change the results of step 11 (ie enabling the module via the module page also does not work).

Since we were going to use features to provide certain elements by default in an install profile (and I imagine the installer uses something similar to drush en instead of the features interface), this is going to be a problem for us.

I'm going to look more at the differences between just enabling the module, to see if I can pinpoint what's going wrong.

Alright, I have some updates.

1. Running "drush cc all" immediately after the installation fixes the problem I outlined above. If you look at the redirect after the admin form for features is submitted, you'll see that they rebuild the cache and then also re-rebuild the menu cache. This is likely why it's working in their test scenario and not in mine. In my more complex use case, I had to clear the cache twice in order to get the menu items to work.
2. However, there are some circumstances where I encountered issues. Specifically, if I delete the fields involved manually (I did this by creating a small module that simply runs field_delete on those fields on command), run cron to clear out the database of the field definitions, then re-enable the module, I get an "Overridden" state on the fields component when I drush cc instead of the normal Rebuildable state I get the first time I run it. For some reason, once I've deleted the field (and nothing remains of it in field_config or field_instance_config, nor do the tables exist), it's detecting it as still existing (?????).

I imagine the View problem above in #3 might be similar.

Anyways, really not sure how to fix #2. It might be in particular pieces of code, that they're generating a weird signature for a non-existent item (which really should trigger a rebuild, not flag it as overridden).

After you enable the module, use "drush cc all" to clear cache. Drupal is stingy about clearing cache itself since that can be slow, so when you have these kinds of problems it's usually fixed by clearing cache at some point.

Strongarm is not applied to my site as well.

Using drush cc all does not fix it either.

The only work around for now is:

# Starts the drush clean dance.
drush --nocolor --yes cc all
drush --nocolor --yes features-revert-all
drush --nocolor --yes cc all
drush --nocolor --yes features-revert-all

Really not appealing.

Need works implies there's a patch that needs work

Try #1572578: Rethink the way features are enabled / disabled

This bug might be filled against strongarm then maybe.. not sure.