Allow altering the post_update run order

1. +++ b/core/lib/Drupal/Core/Update/UpdateRegistry.php
   @@ -130,6 +130,39 @@ protected function getAvailableUpdateFunctions() {
   +   * This function is similar to \Drupal::moduleHandler()->invokeAll(), with the
   

   This comment is outdated. There are no enabled/disabled modules anymore.

   Also, the function below doesn't do that. It loops through the extension list and it simply skips the uninstalled ones.

2. +++ b/core/lib/Drupal/Core/Update/UpdateRegistry.php
   @@ -130,6 +130,39 @@ protected function getAvailableUpdateFunctions() {
   +   * @return callable[]
   

   It doesn't return anything.

3. +++ b/core/lib/Drupal/Core/Update/UpdateRegistry.php
   @@ -130,6 +130,39 @@ protected function getAvailableUpdateFunctions() {
   +   * @see hook_post_updates_alter()
   

   See where? We should add documentation to the hook in the module.api.php file next to the others.

4. +++ b/core/lib/Drupal/Core/Update/UpdateRegistry.php
   @@ -130,6 +130,39 @@ protected function getAvailableUpdateFunctions() {
   +  function alterAvailableUpdateFunctions($updates) {
   

   Missing protected.

5. +++ b/core/lib/Drupal/Core/Update/UpdateRegistry.php
   @@ -130,6 +130,39 @@ protected function getAvailableUpdateFunctions() {
   +    // Get a list of installed modules, arranged so that we invoke their hooks in
   

   I would rephrase this comment to something a bit more relevant to what the code does below, if needed at all. Not to mention that you are loading all extensions, not just modules :)

6. +++ b/core/modules/system/tests/modules/update_test_postupdate/update_test_postupdate.post_update.php
   @@ -79,3 +90,16 @@ function update_test_postupdate_removed_post_updates() {
   +  $updates[] = 'update_test_postupdate_post_update_last';
   

   Can we get a patch that contains the failing test that proves this actually works (the fact that the post update function goes to the end from another location)?

Please be aware that the tests are also failing.

Looks good to me. We have been using this for quite some time now.

Thank you for getting this to RTBC.

Doing a 'light' review to make sure this ready for a committer. I found a few things that should be addressed so setting NW.

• The proposed resolution in the Issue Summary show two options but does not indicate which one is implemented and why.
• Testbot shows that there are coding standard errors.
• Shouldn't this be on 9.2.x?

Fixed CS issues of patch #7.

Rerolled patch for 9.1.x

Rerolled the patch for 9.2.x

Fixing phpcs issue.

Fixed the test.

In #3262036: Convert hook_update_dependencies() to PHP attributes I propose using PHP attributes instead of a separate hook to determine hook_update_N() dependencies.

Perhaps we could do the same here, although this would mean this was PHP 8 and 10.0.x only.

Rerolled patch for 9.4.x

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Rerolled over 11.x.

Patch for 10.5.x version of core.

I'll be honest, I have strong reservations about this.

We do have a way to order them already just by numbering them.

This looks suspiciously like hook module implements alter that was a monumental effort to replace.

Can we get a description of the scenarios where ordering is necessary here and why alpha numeric isn't sufficient?

I'd also want to review hook update dependencies in depth to see if that can be applied.

In the patch made for 10.5.x in comment #27 I realized that one function call is missing and the feature doesn't work as expected. Uploading the correct patch.

@nicxvan Our use case that requires this is the following:
We have an install profile and we need to make sure, that all dependent components/modules run their post_update functions before the install profile post updates, hence why the existing solutions are not enough, like it is described in the issue description.

Fixed the patch for 10.5.x.

Added the missing part in the 10.5.x patch.

    public function getPendingUpdateFunctions() { ...
    return $this->alterAvailableUpdateFunctions($not_executed_update_functions);

Patch for 11.2.x

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies. Thanks.