Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Currently all the enabling and disabling code for features lives inside the submit handler for the features form. It'd be nice if these were broken out into separate functions so that if one needs to override the submit handler they can still ensure that they are using the most up to date functions and methods for enabling/disabling features. ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | features-616222-4.patch | 2.64 KB | q0rban |
| #3 | features-616222-3.patch | 2.63 KB | q0rban |
Comments
Comment #1
yhahn commentedThere is an api for enabling/disabling features...
http://api.drupal.org/api/function/module_enable/6
http://api.drupal.org/api/function/module_disable/6
Comment #2
q0rban commentedheh. I'll try and make a patch for this so you can see what I mean. module_enable doesn't check to see if anything needs to be installed.
Comment #3
q0rban commentedOk, here's a quick (and completely untested) patch so you can at least see what I mean. The point of all this is so that if anything ends up changing in how features are enabled and installed (for instance, maybe _features_export_maximize_dependencies() gets replaced or removed or something), other modules that may make use of the API don't have to care. All they are doing is passing an array of features they want installed. Right now I have a few modules that have a lot of duplicate code from the current features_form_submit() function that would be completely gone if this features_features_install function existed. Every time a new version of features comes out I wonder if something I've copied and pasted has changed in features_form_submit(). Hope you can make sense out of all that... ;)
Comment #4
q0rban commentedWhoops, saw a mistake with that one. (still untested)
Comment #5
yhahn commentedPoint taken. It pains me that features needs to implement an API function for installing a module and all of its dependencies (I hope there is one in D7 core?) but it's certainly something we can make happen.
Comment #6
q0rban commentedYeah, I was definitely surprised the first time I wanted to programmatically install a module that module_enable didn't check to see if anything else needed to be done (installation tasks, check dependencies).
I agree it is a bit silly to have to do this, but at the same time, I consider it good practice to pull out as much actual functionality from all submit handlers and get them in separate functions that just take arguments. There's a bunch of instances in core that in order to do something programmatically, you have to copy and paste most of the code from the submit handler to your own function. Off the top of my head, I think deleting menu items is an example. IIRC, there is no menu_item_delete() function.
Comment #7
yhahn commentedCommited: http://drupal.org/cvs?commit=290574
I renamed the API function to
features_install_modules()since it will work with any array of modules and also because the function name parallelsdrupal_install_modules()which it improves upon.Comment #8
q0rban commentedNice! :)
Comment #9
q0rban commentedI think this may still need work, as it currently doesn't check to see if features conflict before enabling/installing them. Not sure the best way to go about this, b/c drush enable wouldn't check for this either. We may need a 'drush features enable' command.
Comment #10
yhahn commentedOk, one more shot. I've moved the conflict detection API functions into features.module proper (http://drupal.org/cvs?commit=290914) so you can make use of them prior to calling an install function.