features cause 'illegal choice' error from drush enable or disable

I should add, the error also goes away if I remove the features from drush's list of active modules before it calls drupal_execute() on the system_modules form.

And "cerforum" is the feature name - meant to fake that up, sorry.

I can confirm this. We have had this error popping up for some time, and I have been attributing it to Drush. Now that I think about it, its since Features has been installed. It does cause incomplete installation of various modules, Iv found that the DB Tables for Webform aren't inserted amongst other modules. What I then have to do, is disable the module and go to /admin/build/modules and then enable it.

In pm.drush.inc, line 300, drupal_execute('system_modules', $form_state) is called.

The $form_state contains a list of the enabled modules, including the features modules, which are not normally included when going to admin/build/modules and submitting the form.

That's where the error originates.

If you run drush enable on a module that does some of it's configuration during the module page submit process, then it will definitely not get setup properly.

Unsure about who's to blame... why does Features hide it's modules from the modules page in the first place?

Hmmm. i don't know if this helps or not but I tried to disable features because i was getting the same error message.

I got the white screen of death and here is the error:

array(4) { ["type"]=> int(1) ["message"]=> string(63) "Call to a member function get_access_callback() on a non-object" ["file"]=> string(107) sites/all/modules/contrib/views/plugins/views_plugin_display_page.inc" ["line"]=> int(78) } n/a

there might be a conflict with another module. In this case views_plugin_display_pace.inc. Not sure though.

Chris

Thanks for the reports. Sounds like this alter will need to do some intelligent checking for whether the form is being accessed through the browser.

Re: why is features hiding feature modules, this was a request from someone who thought that it would help usability wise and conceptually for users to think of modules as backend "libraries" and features as more user-targeted "apps." Maybe it would be better to just show the features on admin/build/modules anyway because admins back there know what they are doing?

Would love to get people's feedback.

I like putting them on the modules page.

It could be under the header feature.

I like the idea of having one place to goto to view all things that ened to be installed.

I don't think you need to get rid of the admin/build/features page though. I think it also has it's place.

Chris

Agree, it seems to be consistent to me for features to appear under the heading "Features" on the modules page.

Especially if it can solve this issue!

Thanks,
John

I like the features separate. There was some initial confusion for me when i saw spaces_blog in the admin/build/modules which disappeared after i installed features. (found it again in the features section.)

Im pretty new to spaces, context, and features though. Still trying to get my head around it all. oh and looking for a solution to

$ drush enable audio
Audio was enabled successfully. [ok]
An illegal choice has been detected. Please contact the site administrator. [error]
An error occurred at function : drush_pm_enable [error]

Subscribing to this, I'm running drush via. a shell script to upgrade 5-6 with features as part of the upgrade process, and the red message makes it hard to distinguish from actual errors as the updates zip by.

The ppl have spoken: form_alter() to admin/build/modules has been removed. Should be fixed.

http://drupal.org/cvs?commit=285248

Will there be a dev version of the features module?
how do I pull a new version from CVS?
Will it be re-rolled sometime soon? There have been a number of CVS check ins.

EDIT: Maybe you could add the dev version to the project page. Just noticed that it is available under releases:
http://drupal.org/node/401392/release

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