Hi there,

I observed a weird behavior on my drupal installation ... started from scratch to avoid any weird behavior related to obscur modules.

On a stock install of Drupal 7.10 (minimal profile), I added the og modules (but it is not yet installed/enabled), as well as 2 dummy modules that simply define some constants using existing constants from og_access. Both dummy modules are identicals, except for the name of the module (and its folder). Both modules have the same dependencies on "og" and "og_access".

You would expect that installing either would generate the same result on the website, unfortunately it is not. The first one generate a "Notice: Use of undefined constant OG_GROUP_FIELD ..." while the second one does not generate the error (and remember, both modules are identical except for their name).

So it seems that at install time, the dependencies[] clauses in the module.install is not enough to ensure the order in which modules will be installed. Isn't it a weird behavior? While searching on drupal website, I noticed a lot of issues related to the install and dependencies, but could not find a bug description addressing that issue.

Note: I am using a hierarchy to store my modules ... here is my structure (wondering whether it may have an impact):

drupal->sites->all->modules
  clean
    og
      og_access
  project
    tmp
      a_module
      z_module
CommentFileSizeAuthor
tmp.tar_.gz662 bytesspouilly
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

star-szr’s picture

Status: Active » Closed (works as designed)

At least two things:

1. You can't define the same constants in both your custom modules. Constants have a global scope, please see the PHP documentation for more information.

2. You are assuming that you have access to the og_access constants at all times, but this is not the case. You could require_once() og_access.module in order to access those constants from your custom modules.

One other minor tip, you do not need to set two dependencies for your custom modules. You only need to set the og_access dependency, Drupal will realize that og_access depends on og.

spouilly’s picture

Hi there,

Thanks for the update.

For the first point, I did it on purpose, to show that both modules are strictly identical, the only difference being the name of the module (which impact when the module.install will be executed).

I am well aware you are not suppose to define the same constant in several modules, and I am providing these modules just to demonstrate the (IMHO) weird behavior.

If you change the variable names in one module (to avoid the global collision when both modules are enable), you will still get one 'Notice' (from the module that will be installed before the og_access).

In other words, the dependencies[] in the info file only indicate that the dependency will be installed, but it does nothing to ensure that the hierarchy of dependency will be respected (e.g that the modules you are depending on will be installed and ready before you start your own installation). It was a bit of a surprise for me, but I have setup a way of working with it.

Your point number 2 is quite interesting, and I guess it would work. This is probably the best way to handle such scenario. I noticed that most module developpers don't use much constants and use hard-coded strings instead, which is much easier to read in the code for sure (but on the other hand, it is not very flexible when you need to change the value of the constant).

Thanks for your input!

Anonymous’s picture

Version: 7.10 » 7.x-dev
Status: Closed (works as designed) » Active

This bug was mentioned in an issue three years ago and someone says they raised a feature request. I haven't been able to find the feature request, but here is the reference to it #191977: Dependency on profile.module does not ensure hook_install for profile.module is run before dependent module's hook_install.

I'm having this problem with an installation profile I'm writing.

Damien Tournoud’s picture

Title: Modules dependencies specified in module.info are not fully respected at install time (and name of the module is being used) » Consider using the dependency tree to weight modules
Version: 7.x-dev » 8.x-dev
Component: install system » base system
Category: bug » feature

Dependencies are fully respected during installation in Drupal 7 (it was not the case in previous versions). But dependencies is an *install time* concept, it doesn't impact the runtime at all. If you want hooks of your modules to run after the hooks of another module, you still need to set the weight of your module higher.

We could consider using the dependency tree to weight modules (and as a consequence their hook invocation), but that would be a feature request.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

larowlan’s picture

Status: Active » Closed (works as designed)

I think module_set_weight is what you need here, from an install hook