How to categorize a module as developer module

It is starting to get messy.

Instead of doing that, let's simply turn this into a hook.

Crazy idea...let's have people put developer = TRUE in their module's info.files.

Actually, I thought of that too while implementing the hook. ;)

But would it be better?

I could this having much more re-use for other things than an admin_menu_developer_modules hook. Of course in the meantime, admin_menu could implement admin_menu_system_info_alter() for the specified modules. Also if the module has specified package = Development, it should be included.

tags[] = developer
tags[] = administration
tags[] = ...

? :)

Heh, yeah, it would be nice if module's .info and project pages on d.org were better linked, this approach probably makes the most sense.

So this is what it would look like.

Better title.

Hey, that could make sense! The project groupings in .info have always been a little ad-hoc.
Not quite sure what to use them for yet, but it looks like fun.

Yeah, this is a great approach. Doesn't require us to hard-code all modules, and maybe we can help get a jump start on improving the module page as well as integration with drupal.org project pages. I was thinking about also checking substr($module->name, -3) === '_ui' but that might be a little over the top.

A few modules (at least the ones I know about) we shouldn't need to include in the admin_menu_system_info_alter() since they already use the package 'Development':
coder
demo
devel
devel_node_access
devel_themer

Overall, ++++++++++100 to this and doing it sooner than later.

+++ admin_menu.inc	4 Nov 2009 23:46:47 -0000
@@ -277,6 +268,28 @@ function admin_menu_theme_settings() {
+function admin_menu_developer_modules() {
+  $modules = array();
+  $result = db_query("SELECT name, info FROM {system} WHERE type = 'module'");
+  foreach ($result as $module) {
+    $info = unserialize($module->info);
+    // Add all modules in the "Development" package.
+    if (isset($info['package']) && $info['package'] == 'Development') {
+      $modules[$module->name] = $info['name'];
+    }
+    // Add all modules tagged with "development".
+    if (isset($info['tags']) && is_array($info['tags']) && in_array('development', $info['tags'])) {
+      $modules[$module->name] = $info['name'];
+    }
+  }
+  // Sort by human-readable module name.
+  asort($modules);
+  return $modules;
+}

I wonder whether we should consider to put a function like that as a last-minute attempt into Drupal 7 core.

Of course, without the wishy-washy package name checking. But very possible also supporting simple info variables, i.e. strings. And taking the thing to search for as argument.

That would allow us to retrieve, for example, a list of all hidden modules, or all required modules, or all modules in a certain package.

module_list_by_info($search = 'hidden', $parent = NULL);

Filter by tag:

module_list_by_info($search = 'development', $parent = 'tags');

Oh, and of course, also search for modules having a certain dependency:

module_list_by_info($search = 'views', $parent = 'dependencies');

I'm on crack. Are you, too?

Yes, I am. :)

So let's try it!

#624848: Allow to retrieve a list of modules defining a certain .info file property

I badly need some more traction/discussion/feedback/support in #624848: Allow to retrieve a list of modules defining a certain .info file property, so please comment over there to help flesh out the core version of this function.

Should we commit #12 in the meantime?

Good question. So, no love for the core patch and we give up on that idea? I'm quite certain that we could still squeeze that no-brainer in, 'cause it really doesn't break anything. Point being that it will be hard to propagate any new .info file property/categorization/whatever throughout contrib, if each and every single module needs to re-implement an own function to actually parse that information...

Attached patch Is a remake of #1. It introduces a new hook_admin_menu_devel_module().
IMO a hook is better then using the info file or parsing the module name.

1. ITMT, this feature request should already be possible - I've found the following clue in de code:
// Allow site admins to override this variable via settings.php.
But I'm a mere site builder... :-(

2.

let's have people put developer = TRUE in their module's info.files

This will generate loads of feature requests in all sorts of queues. Lots of them will not make it to a stable release within noticeable time.
Using the 'package' tag won't work for modules with an 'Admin UI' submodule.

3. With this hook, each contrib module can declare itself as a developer module. Moreover, each custom module and distribution can declare a list of used developer modules. There is no problem with adding duplicate module names - the current code already handles that well. Ideally, each contrib module with an 'Admin UI' submodule adds this to the codebase.
But the hook also allows each site to create your own list of modules in your project or distribution.

P.S. An additional feature request for this hook would be to exclude certain modules.
IMO it is best not to do this in this hook. A solution would be:
#1996082: "Disable Developer Modules" needs a confirmation
See the following request for an example:
#1516574: "Disable Devel Modules" disables Rules UI ignoring modules dependant on it like "Commerce Cart" Module - Add dependency Check.

The 'disable development modules' functionality has been removed as of #2392519: Remove 'Disable Development modules'.