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
Comment | File | Size | Author |
---|---|---|---|
tmp.tar_.gz | 662 bytes | spouilly |
Comments
Comment #1
star-szrAt 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.
Comment #2
spouilly CreditAttribution: spouilly commentedHi 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!
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedThis 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.
Comment #4
Damien Tournoud CreditAttribution: Damien Tournoud commentedDependencies 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.
Comment #17
larowlanI think module_set_weight is what you need here, from an install hook