Deprecate module_set_weight()

Can someone explain to me how you can control the order of hooks when two modules both implement hook_module_implements_alter()? I have tried making one module a dependency of the other but it didn't help. It seems the only thing I can do is to set the weight of my module to ensure my hook_module_implements_alter() runs before the other module's hook_module_implements_alter().

The #7 still points to other issue to fix first - #1808132: Move module_set_weight() into ModuleHandler::setWeight(), add ModuleHandler::getWeight() to replace missing functionality →

I don't think #7 is saying that other issue has to go in before this one. I think it's just saying it's wrong.

• I rerolled #38 for 11.x
• removed a few more usages which can be handled with hook_module_implements_alter()
• added the trigger error for the deprecation
• added a legacy deprecation test

Fixed phpstan issue.

The last submitted patch, 45: 2968232-45.patch, failed testing. View results →

Fix page cache tests.

The last submitted patch, 47: 2968232-47.patch, failed testing. View results →

Once again a non-sense no value adding issue to kill a function. Why? Why the whole discussion, wasted man-hours? The suggested alternative hook_module_implements_alter is not a replacement, you cannot have control of the module weights/

Please re-read TR's comment #2968232-6: Deprecate module_set_weight() → . He listed imported use cases.

I'm not convinced that this function should be removed. I also don't see any reason. Why remove something that doesn't break anything, only to break things?

I'm not convinced that this function should be removed. I also don't see any reason. Why remove something that doesn't break anything, only to break things?

It's not because you disagree with an issue that it should be closed, I mean I think it needs to be discussed still.

I agree with @alexpott and @dawehner in the initial patches here, that having an explicit weight system is not the most robust and that it would be a lot better for modules to decide what other modules they should be fired after/before as that is a lot more explicit, manually setting weights can lead to conflicts and if I understand this issue correctly, we should see if we can module weight system not have explicit numbers but rather be configured on their dependencies instead, as the research by @dawehner suggests.

Back to needs work for a reroll and to fix the remaining test fails.

Hi added a reroll using patch #2 as @borisson said. Please revise.

For CC failures.

we should see if we can module weight system not have explicit numbers but rather be configured on their dependencies instead

Is that work being done somewhere? If so, that work should block this, right? If not, this work definitely shouldn't be merged, right? Until that refactor is done, module_set_weight() is critical functionality with no replacement.

Right? I'm not missing anything?

Fixed issues in #53 according to https://www.drupal.org/pift-ci-job/2690801 →

Seems to have test failure.

I took #47 and turned it into a MR. I'm going to look at some of the test fails.

I think we need sign-off from a framework manager that we want to remove this API.

This patch removes some another uses of the function module_set_weight

Needds to review more in deep testing fail for d7 migration

Note hook_module_implements_alter() will not work if you need your hook_preprocess_HOOK() to run after some other module's preprocess hook. Preprocess hooks are not invoked by the module handler and are not present in hook_module_implements_alter().

So removing this API will be problematic if you have a soft dependency on another module's preprocess hook, ie the module is not a requirement, but if it is present you need to preprocess something it also preprocesses, after it has done so. You don't want to declare a hard dependency in module .info. Altering module weight is the only way this will work, right?

It needs some rework in context of landed 📌 Hook ordering across OOP, procedural and with extra types Active

@johnpitcairn I am pretty sure you're supposed to use this https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21... for preprocess.