Allow to retrieve a list of modules defining a certain .info file property
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | task |
| Priority: | normal |
| Assigned: | sun |
| Status: | needs work |
Last-minute spin-off from #623544: Use .info file tags[] to categorize a module as developer module:
# module_list_by_info('taxonomy', array('dependencies'));
array(3) {
["default"]=>
string(6) "Drupal"
["forum"]=>
string(5) "Forum"
["taxonomy_test"]=>
string(20) "Taxonomy test module"
}# module_list_by_info(TRUE, array('required'));
array(11) {
["default"]=>
string(6) "Drupal"
["field"]=>
string(5) "Field"
["field_sql_storage"]=>
string(17) "Field SQL storage"
["filter"]=>
string(6) "Filter"
["list"]=>
string(4) "List"
["node"]=>
string(4) "Node"
["number"]=>
string(6) "Number"
["options"]=>
string(7) "Options"
["system"]=>
string(6) "System"
["text"]=>
string(4) "Text"
["user"]=>
string(4) "User"
}Our goal is to introduce the new .info file property "tags" in contrib during the D7 release cycle to build some awesomesauce - especially for admin/structure/modules (and more):
tags[] = administration
tags[] = development
tags[] = ...The first module that will actually use this function is Administration menu (see above mentioned issue). It provides a setting that allows to enable/disable all "developer modules" in one click (to save a lot of performance when a site is not under active development).
If we want to, we could additionally remove/convert all calls to http://api.drupal.org/api/function/drupal_required_modules/7 to this new function, i.e. make it conditionally parse .info files in the filesystem instead of querying the database, in case the database is not yet available (primarily targeting the installer). However, that wouldn't strictly be necessary.
There are countless of use-cases for this thingy, and the purpose for now is to just allow contributed modules to gather that info easily without having to re-implement this function all over again.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| drupal.module-list-by-info.patch | 2.72 KB | Idle | Passed: 14683 passes, 0 fails, 0 exceptions | View details | Re-test |
#1
Yeah, I can see this being very handy. The themers in particular have found mad uses for .info files (e.g. skinr). Lets give them this tool.
Ideally, this comes with unit test.
#2
Hm. I guess that requires quite some changes:
1) Add a (first) $type argument to allow to specify 'profile', 'module', or 'theme'. I can't think of a use-case where you'd want more than one $type, so this should be fine.
2) Make it fallback to the filesystem in case the database is not available. (similar to drupal_required_modules()) I already wanted to implement this, but I wasn't able to find a piece of code somewhere that implements this condition already -- i.e. what is the exact condition when we have to fallback to the filesystem? The most obvious seems to be MAINTENANCE_MODE == 'install'. -- Or should we simply go with a try...catch control structure? I.e. try to query, and if that fails, fallback to the filesystem?
3) I also realized that we want to switch the $parents and $value arguments, because it's more natural to invoke by mlbi(array('dependencies'), 'taxonomy').
4) Tests, sure - should be trivial.
5) Due to 1), we probably want to rename the function to drupal_not_sure_how(), perhaps drupal_system_info() or similar. Ideally, it should be self-descriptive and match an existing pattern. The returned result of the function is similar to module_list() and system_get_info(), but contrary to those functions, its purpose is to search/filter/find "extensions" that match a certain criteria. Thus, I called it module_list_by_info(), but that is no longer suitable due to 1). -- Simply rename to drupal_list_by_info()?
Ideally, I'd like to flesh out those points before continuing with coding. Thoughts?
#3
#623992: Reduce {system} database hits makes this much more easy now.
#4
Fixed PHPDoc.
#5
The last submitted patch failed testing.