Best dealt with as an example:

Download og and og_vocab modules, but don't download views yet. og depends on Views and og_vocab depends on og. On the modules page I can select og_vocab but og is greyed out. Select og_vocab and hit submit. You'll see...

Some required modules must be enabled

* You must enable the Organic groups module to install Organic groups vocabularies.

Would you like to continue with enabling the above?

Click okay and you'll be sent to admin/build/modules/list/confirm where the grayed out og box is now checked, along with og_vocab but really neither is installed as we're missing the Views dependency. But there is no error to tell the user this and you can keep clicking Submit to go through this cycle infinitely.

Possible direction for a solution: Before sending the "You must enable the Organic groups module to install Organic groups vocabularies." message we should check if the user has even downloaded the dependencies for these unchecked required modules. If not, we need to notify the user to download those. If we have them, include them in the list of required modules along.

Comments

RobRoy’s picture

RobRoy commented
Version: x.y.z » 5.x-dev

Correct version.

danbh’s picture

danbh commented

This bug is related to this other report you filed:
http://drupal.org/node/93780

danbh’s picture

danbh commented
Priority: Normal » Critical

Enabling and disabling modules seem to have different behavior. With enabling, dependencies are handled automatically, but it looks like there are problems with enforcement (this bug). With disabling, dependencies are NOT handled automatically, but the dependencies are enforced ( http://drupal.org/node/93780 ).

Consistent behavior is the way to go IMO.

I'm thinking this is critical, because this is a new feature, and you probably want to have it working before the next version is "shipped."

moshe weitzman’s picture

moshe weitzman commented
Priority: Critical » Normal

we do want it right, but that has nothing to do with priority.

ricabrantes’s picture

ricabrantes commented
Status: Active » Closed (duplicate)

Duplicate http://drupal.org/node/93780

ricabrantes’s picture

ricabrantes commented
Status: Closed (duplicate) » Active
kenorb’s picture

kenorb commented
Version: 5.x-dev » 6.9
Component: update system » system.module

Marked #364732: Confirmation of installing depending module appearing all the time. as duplicated.
This bug also appears in Drupal 6.9

Tested with Referral Userponts:

Some required modules must be enabled
You must enable the User Referral module to install Referral Userponts.
Would you like to continue with enabling the above?
Continue Cancel

And it's infinite loop.

_POST sent:

array
  'status' => 
    array
      'referral_userpoints' => string '1' (length=1)
      'userpoints' => string '1' (length=1)
  'confirm' => string '1' (length=1)
  'op' => string 'Continue' (length=8)
  'form_build_id' => string 'form-97b8a5016f3058480031abfa1135e405' (length=37)
  'form_token' => string 'c22def9cb0563e436afa3ff9186b1582' (length=32)
  'form_id' => string 'system_modules' (length=14)

In my case I couldn't reproduce it on the fresh Drupal, so there is problem with some contributed module or it's related to some configuration.

kenorb’s picture

kenorb commented
Status: Active » Fixed

In my case it caused by partially by cache.
Sometimes I've got too big queries, so I've got #361967: Increase MAX_JOIN_SIZE and MAX_ALLOWED_PACKET settings in system.install.
To prevent that (especially the error messages on half screen), I've disabled some menu and form caches: #321154: can I disable cache_menu? how?
Drupal rely on cache to retrieve submitted forms and Drupal thought that form is retrieved by following condition:

    if (isset($_POST['form_id']) && $_POST['form_id'] == $form_id && !empty($_POST['form_build_id'])) {
      $form = form_get_cache($_POST['form_build_id'], $form_state);
    }

in function drupal_get_form().
In my opinion Drupal should check what he received from the cache and if he could get it.
If he will get the empty form and nothing will be in $form['storage'], form will be rebuilded second time:

  if (!empty($form_state['rebuild']) || !empty($form_state['storage'])) {
    $form = drupal_rebuild_form($form_id, $form_state, $args);

So all post variables will be replaced by second call of drupal_process_form().

I said I've fixed partially, because sometimes it's working even with disabled cache.
And the same issue was when I've tried uninstall some module.

kenorb’s picture

kenorb commented

Following module I've created for those who have problems with MAX_JOIN_SIZE:
http://drupal.org/node/361967#comment-1255111

Status: Fixed » Closed (fixed)

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