modules list confirmation page is broken
salvis - October 10, 2009 - 15:54
| Project: | Utility |
| Version: | 6.x-2.x-dev |
| Component: | System module field closer |
| Category: | bug report |
| Priority: | normal |
| Assigned: | NancyDru |
| Status: | active |
Jump to:
Description
If you enable a dependent module but not the one it depends on, then Drupal asks for permission to also enable the second one. The confirmation form has the same $form_id as the modules list, and Utility blindly tries to form_alter that page, creating a complete mess.
Actually, I much preferred the layout of the 6.x-2.3 version (where the weights were in a column of their own). There, the error was much less severe, only displaying an out-of-context string:
<?php
function system_module_form_alter(&$form, $form_state, $form_id) {
switch ($form_id) {
case 'system_modules':
//a neat idea to allow access to the important module settings directly from the modules page, saves page loads from navigting to site configuration etc etc.
$form['#theme'] = 'system_modules_theme';
$form['description']['system_module']['#value'] = t('<a href="@url">Set default</a> collapsed/expanded state for system modules fieldsets', array('@url' => url('admin/settings/util/sysmods')));
break;
}
}
?>The trick is pretty neat, but you should check for !empty($form['description']['system_module']) before assigning $form elements.
#1
Thanks. I will look into this. I don't suppose you have a patch?
The weights come from a different module, so that should be a different issue. However, the way it is now the weights will show up for core, this system_modules module, and the Module Filter module, so it is more flexible for other users.
#2
#3
For 2.3 it's simple (just add the if):
<?phpfunction system_module_form_alter(&$form, $form_state, $form_id) {
switch ($form_id) {
case 'system_modules':
if (!empty($form['description']['system_module'])) {
//a neat idea to allow access to the important module settings directly from the modules page, saves page loads from navigting to site configuration etc etc.
$form['#theme'] = 'system_modules_theme';
$form['description']['system_module']['#value'] = t('<a href="@url">Set default</a> collapsed/expanded state for system modules fieldsets', array('@url' => url('admin/settings/util/sysmods')));
}
break;
}
}
?>
After a very brief look at 2.x-dev I went back to 2.3, so I don't have a patch... The symptoms of the bug are much more dramatic, but the same if should let you decide whether to alter the form or leave it alone.
I wasn't able to see any advantage in 2.x-dev over 2.3. It complained about modules that had records in the {system} table but weren't there anymore. Why should it care? 2.3 solves a simple problem in a straight-forward way (which is, as I understand, the general idea behind this module, at least according to the front page) — 2.x-dev looks like a more complicated and uglier solution to the same problem. (Please forgive me for being so frank, maybe I just don't understand what 2.x-dev is all about...)
#4
It's probably the same "if". BTW, it's no longer 6.x-2.x-dev; it is 6.x-3.x-dev because of all the new (check the project page) and correctly functioning features. And 2.3 module_weights did not function correctly; it produced extraneous weight fields at the end of the form. As far as this issue goes, this problem will be fixed in 6.x-3.x and will remain in 6.x-2.3 (one cannot alter an existing release). The more testing 6.x-3.x gets, the sooner it gets an official release.