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.

Comments

moshe weitzman’s picture

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.

sun’s picture

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?

sun’s picture

StatusFileSize
new3.33 KB

#623992: Reduce {system} database hits makes this much more easy now.

sun’s picture

StatusFileSize
new3.37 KB

Fixed PHPDoc.

Status: Needs review » Needs work

The last submitted patch failed testing.

dave reid’s picture

Status: Needs work » Needs review
StatusFileSize
new9.75 KB

Revised 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.

Status: Needs review » Needs work

The last submitted patch, 624848-system-list-by-info-D7.patch, failed testing.

sun’s picture

Status: Needs work » Needs review
StatusFileSize
new11.12 KB

Hm. 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.

sun’s picture

Feedback/RTBC, anyone?

sun’s picture

Looks ready to fly for me.

sun’s picture

#8: drupal.system-list-by-info.8.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, drupal.system-list-by-info.8.patch, failed testing.

jacine’s picture

I can't review the code itself, but this seems like a nice improvement.

sun’s picture

Status: Needs work » Needs review
StatusFileSize
new6.98 KB

Completely 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().

sun’s picture

sun’s picture

StatusFileSize
new2.76 KB

@jacine? @moshe?

jacine’s picture

Gonna test this again now :)

jacine’s picture

Maybe I'm not using this correctly, but I'm not getting any data when I try to test this with Skinr.

Instead of:

$themes = system_get_info('theme');
...
if (!empty($theme['skinr'])) {
  $info = (array)$theme['skinr'];
...
}

This way, I get my array w/8 elements.

I'm just tried this:

$themes = system_get_info('theme');
...
if (!empty($theme['skinr'])) {
  $info = system_list_by_info('theme', array('skinr'), '', FALSE);
...
}

This way, I get nothing.

Shouldn't that return the same array?

jacine’s picture

StatusFileSize
new41.96 KB
new8.43 KB

I'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 ;)

sun’s picture

StatusFileSize
new2.99 KB

Sorry, 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.

jacine’s picture

Ah, 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 of NULL I get nothing. Is that correct?

sun’s picture

Yes, 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.

jacine’s picture

Status: Needs review » Reviewed & tested by the community

Ok, cool. Well, I think this is ready then ;)

sun’s picture

StatusFileSize
new3.07 KB

phpDoc was outdated.

dries’s picture

Version: 7.x-dev » 8.x-dev

This looks like it should wait until D8.

sun’s picture

Project: Drupal core »
Version: 8.x-dev »
Component: base system » Code
chx’s picture

Project: » Drupal core
Version: » 8.x-dev
Component: Code » base system

sun, stop destroying the issue queue.

sun’s picture

Project: Drupal core » Edge
Version: 8.x-dev » 7.x-1.x-dev
Component: base system » Code

This issue will be moved back into the D8 queue, after it has been tackled, resolved, and committed to Edge 7.x.