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:

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.

Comments

nancydru’s picture

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.

nancydru’s picture

Component: Code » System module field closer
Assigned: Unassigned » nancydru
salvis’s picture

For 2.3 it's simple (just add the if):

function 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...)

nancydru’s picture

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.

nancydru’s picture

nancydru’s picture

Component: System module field closer » Module weights
Status: Active » Fixed

Right idea - wrong module.

Committed to 6.x-3.x-dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.