Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I'm wondering if we can add "reroute_email" as a Developer module that can be disabled via the 1 click disable in the admin_menu? I've attached a patch that does this.
reroute_email is only something that you would want running on a dev site so it would be nice to have a simple way to disable it.
Comment | File | Size | Author |
---|---|---|---|
#17 | admin_ui_623544_17_hook_devel_module.patch | 1.28 KB | johnv |
#7 | admin_menu.devel-modules.7.patch | 5.93 KB | sun |
#1 | admin_menu.devel-modules.patch | 3.46 KB | sun |
admin_menu_add_reroute_email.diff | 219 bytes | designerbrent | |
Comments
Comment #1
sunIt is starting to get messy.
Instead of doing that, let's simply turn this into a hook.
Comment #2
Dave ReidCrazy idea...let's have people put developer = TRUE in their module's info.files.
Comment #3
sunActually, I thought of that too while implementing the hook. ;)
But would it be better?
Comment #4
Dave ReidI 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.
Comment #5
sun? :)
Comment #6
Dave ReidHeh, 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.
Comment #7
sunSo this is what it would look like.
Comment #8
sunBetter title.
Comment #9
dman CreditAttribution: dman commentedHey, 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.
Comment #10
Dave ReidYeah, 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.
Comment #11
designerbrent CreditAttribution: designerbrent commentedThis looks like a great addition. Thanks for making it so versatile.
Comment #12
sunI 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.
Filter by tag:
Oh, and of course, also search for modules having a certain dependency:
I'm on crack. Are you, too?
Yes, I am. :)
Comment #13
sunSo let's try it!
#624848: Allow to retrieve a list of modules defining a certain .info file property
Comment #14
sunI 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.
Comment #15
Dave ReidShould we commit #12 in the meantime?
Comment #16
sunGood 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...
Comment #17
johnvAttached 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.
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.
Comment #18
johnvP.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.
Comment #19
Dave ReidThe 'disable development modules' functionality has been removed as of #2392519: Remove 'Disable Development modules'.