Last-minute spin-off from #623544: How 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.
Comment | File | Size | Author |
---|---|---|---|
#24 | drupal.system-list-by-info.24.patch | 3.07 KB | sun |
#20 | drupal.system-list-by-info.20.patch | 2.99 KB | sun |
#19 | 960gs.skinr_.txt | 8.43 KB | Jacine |
#19 | skinr-data.png | 41.96 KB | Jacine |
#16 | drupal.system-list-by-info.16.patch | 2.76 KB | sun |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedYeah, 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.
Comment #2
sunHm. 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?
Comment #3
sun#623992: Reduce {system} database hits makes this much more easy now.
Comment #4
sunFixed PHPDoc.
Comment #6
Dave ReidRevised patch that includes using drupal_system_listing as fallback if the database is not available and also uses sytem_list_by_info() for drupal_required_modules(). Also splits the *huge* system_info cache into separate cache entries for each array.
Comment #8
sunHm. There were a couple of critical performance considerations for the current cache.
Revamped that to keep the current caching for the regular case, and only support the additional types, too.
Comment #9
sunFeedback/RTBC, anyone?
Comment #10
sunLooks ready to fly for me.
Comment #11
sun#8: drupal.system-list-by-info.8.patch queued for re-testing.
Comment #13
JacineI can't review the code itself, but this seems like a nice improvement.
Comment #14
sunCompletely revised patch. Most of the changes actually belong to #887870: Make system_list() return full module records.
What effectively remains here after #887870 landed is the addition of system_list_by_info().
Comment #15
sun#887870: Make system_list() return full module records is in.
This is what remains.
Comment #16
sun@jacine? @moshe?
Comment #17
JacineGonna test this again now :)
Comment #18
JacineMaybe I'm not using this correctly, but I'm not getting any data when I try to test this with Skinr.
Instead of:
This way, I get my array w/8 elements.
I'm just tried this:
This way, I get nothing.
Shouldn't that return the same array?
Comment #19
JacineI'm testing with this 960.gs skin in Bartik's .info file, btw. Also, this is what I get with the old method. Screenshot and Skinr code attached ;)
Comment #20
sunSorry, I didn't properly update the patch for the new signature of system_get_info(). Fixed that.
Also updated the phpDoc + made $value optional, which is a nice use-case - thanks for providing your example.
Comment #21
JacineAh, so $info_value is never expected to be returned and basically, I'm just supposed to be doing this:
$themes = system_list_by_info('theme', array('skinr'), NULL, FALSE);
instead of this:
$themes = system_get_info('theme');
One thing I'm not sure about... You said you made $value optional, but if I use
''
instead ofNULL
I get nothing. Is that correct?Comment #22
sunYes, if you pass '', then you are filtering for the value ''. Only NULL is no value.
I actually considered whether it could return $info_value instead of the full $info, but figured that calling code can easily work with both, and there may be use-cases, where you want to get $info for all $type that have a certain $property/$value, but you don't necessarily want to work with $property/$value afterwards, but something else in $info.
Comment #23
JacineOk, cool. Well, I think this is ready then ;)
Comment #24
sunphpDoc was outdated.
Comment #25
Dries CreditAttribution: Dries commentedThis looks like it should wait until D8.
Comment #26
sunComment #27
chx CreditAttribution: chx commentedsun, stop destroying the issue queue.
Comment #28
sunThis issue will be moved back into the D8 queue, after it has been tackled, resolved, and committed to Edge 7.x.