Problem/Motivation

jibran in #2528178-172: Provide an upgrade path for blocks context IDs #2354889 (context manager) suggested adding a test module that does a contrib module update for block contexts.

This would ensure it's actually possible for the test module to do the update.

Extra points would be for the update to handle and be tested for the two different scenarios it can run in:

In between block_update_8001() and block_update_8002()

After block_update_8002() has run (which will happen if a contrib modules adds an update hook after the core update has already run on a site).

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Berdir’s picture

So I was trying to implement this for a custom module in my project and it doesn't work..

The problem is that we drop the whole visibility condition but only store the missing context mappings in the backup values. So a module has no chance to actually restore the whole thing.

I don't think this is a critical problem since as far as I know, I'm only case I know of where someone actually wrote a block context that needs to be upgraded (not aware of any contrib module doing it), but we should probably update it and make this test work to have a good example of how it should be done.

I can see two ways to do that.

a) The easy limited way: Move the removal of visibility conditions to 8002(). If there is a module that provides a mapping in the meantime and removes it from backup_values, then we don't need to drop it and can just move on. The limitation is that this won't work for updates that run after 8002, so we should be honest and just drop the backup values in 8002. In case a module update runs later, it will just be a no-op and the user will have to figure it out manually (probably already has).

b) Store the full visibility condition in the backup values. While this sounds like an obvious choice, at first, it actually not that easy. First, it would be quite complicated to implement correctly if there are multiple contexts from different modules in the same condition. Second, as discussed, it would be quite hard to write an update function that would work both between block 8001 and 8002 and after and I'm not actually sure that they are still supposed to run after 8002. If it didn't run in the same update, then we have to assume that the user already manually reconfigured is blocks.

Given that, I think a) is the correct way to go about this.

dawehner’s picture

Are you sure that this is just a major issue? It sounds for me to block the update path of an actual contrib module, right?

Berdir’s picture

It blocks the update of such a module, but I very much doubt that any other module other than mine exists and the worst case is that users will have to manually re-configure their blocks.

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.

quietone’s picture

Status: Active » Postponed (maintainer needs more info)

Is there anything to do here?

In #1, @Berdir states that they were not able to implement a test. And later, in #3, that the "worst case is that users will have to manually re-configure their blocks."

quietone’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

There has been no response to confirm that there is anything to do here. Therefor I am closing this as works as designed.