Problem/Motivation

#2917600: update_fix_compatibility() puts sites into unrecoverable state was committed to 8.8. In the process of reviewing the backport for 8.7 there were some nits that could still be fixed.

Proposed resolution

  1. Remove reference from $theme_extension_list in anonymous array_filter callback
  2. Fix typo "Date provider" (should be "Data provider")
  3. Use immutable config instead of editable in assertInstalledExtensionsConfig
  4. Use $assert_session consistently in assertUpdateWithNoErrors and assertErrorOnUpdates
  5. Remove t() from clickLink
  6. Remove unnecessary @throws annotations
  7. Use $i instead of $reload in for loop
  8. Change DataProvider to Data provider for consistency
  9. Move DRUPAL_CORE_REMOVED_MODULE_LIST and DRUPAL_CORE_REMOVED_THEME_LIST constants to SystemRequirements class

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork drupal-3122116

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

tim.plunkett created an issue. See original summary.

tim.plunkett’s picture

Assigned: Unassigned » tim.plunkett

Here's what I removed from my review of the backport.

  1. +++ b/core/modules/system/system.install
    @@ -839,6 +888,115 @@ function system_requirements($phase) {
    +    $is_missing_extension = function ($extension_name) use (&$extension_list) {
    ...
    +    $extension_list = \Drupal::service('extension.list.theme');
    

    Why is $extension_list by reference?
    Ohhh no, is that doing what I think it's doing? Is that so it can reuse the anonymous function but with two different objects?
    Ew.

    Let's not do that, please. It's not worth the DRY effort when it's that tricky and involves references.

  2. +++ b/core/modules/system/tests/src/Functional/Update/UpdateScriptTest.php
    @@ -161,6 +172,227 @@ public function testRequirements() {
    +   * Date provider for testExtensionCompatibilityChange().
    

    s/Date/Data

  3. +++ b/core/modules/system/tests/src/Functional/Update/UpdateScriptTest.php
    @@ -426,4 +658,69 @@ public function getSystemSchema() {
    +    $extension_config = $this->container->get('config.factory')->getEditable('core.extension');
    

    Not a big deal, but why getEditable? Just catches my eye when I see that without a save()

  4. +++ b/core/modules/system/tests/src/Functional/Update/UpdateScriptTest.php
    @@ -426,4 +658,69 @@ public function getSystemSchema() {
    +    $assert_session = $this->assertSession();
    ...
    +    $this->assertSession()->pageTextNotContains($unexpected_error_text);
    ...
    +    $assert_session->pageTextContains('No pending updates.');
    

    Either use the local variable (+1) or don't, but not both.

  5. +++ b/core/modules/system/tests/src/Functional/Update/UpdateScriptTest.php
    @@ -426,4 +658,69 @@ public function getSystemSchema() {
    +    $this->clickLink(t('Continue'));
    

    Nit: not t() in tests like this

  6. +++ b/core/modules/system/tests/src/Functional/Update/UpdateScriptTest.php
    @@ -426,4 +658,69 @@ public function getSystemSchema() {
    +   * @throws \Behat\Mink\Exception\ExpectationException
    +   * @throws \Behat\Mink\Exception\ResponseTextException
    ...
    +  protected function assertErrorOnUpdate($expected_error_text, $extension_type, $extension_machine_name) {
    

    Don't usually put these on our assert helpers.

  7. +++ b/core/modules/system/tests/src/Functional/Update/UpdateScriptTest.php
    @@ -426,4 +658,69 @@ public function getSystemSchema() {
    +    for ($reload = 0; $reload <= 1; $reload++) {
    

    Nittiest of nits, but
    for ($i = 0; $i < 2; $i++) {
    is a lot more legible IMO. Then I know that $reload isn't a magic number, and also I can tell it runs twice instead of thinking about it.

  8. +++ b/core/tests/Drupal/Tests/Core/Extension/ExtensionListTest.php
    @@ -206,9 +206,77 @@ public function testReset() {
    +   * DataProvider for testCheckIncompatibility().
    

    Let's be consistent with the others: "Data provider for ..."

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.

tim.plunkett’s picture

Assigned: tim.plunkett » Unassigned

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

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mstrelan made their first commit to this issue’s fork.

mstrelan’s picture

Status: Active » Needs review

Addressed all the items in #2, except #2.5 which was already fixed. I also converted the anonymous functions to arrow functions at the same time.

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

Can we update the summary.

Thanks!

mstrelan’s picture

Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs issue summary update

Transcribed the proposed resolution from #2

smustgrave’s picture

Title: Nitpick follow-up to update_fix_compatibility() fix » Code cleanup from update_fix_compatibility() fix
Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs Review Queue Initiative

Thanks! Seems like a good clean up to me

smustgrave’s picture

Appears to need a rebase.

catch’s picture

Status: Reviewed & tested by the community » Needs work
mstrelan’s picture

Status: Needs work » Needs review

Rebased and swapped !in_array($extension_name, array_keys(DRUPAL_CORE_REMOVED_THEME_LIST), TRUE) to !array_key_exists($extension_name, DRUPAL_CORE_REMOVED_THEME_LIST).

Wondering if it makes sense to move DRUPAL_CORE_REMOVED_MODULE_LIST and DRUPAL_CORE_REMOVED_THEME_LIST constants to this class while we're at it. It's not part of the original scope, but not sure that matters. The only place they are used is in SystemRequirements and UpdateScriptTest.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Seems like a good rebase

catch’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs followup

I'm fine with doing the constants here or a follow-up, but if we do them in a follow-up let's open an issue for that prior to commit.

mstrelan’s picture

Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs followup

Moved the constants here. Had to make them public because they are access from UpdateScriptTest.

There are no usages of them in contrib projects (outside of core/modules/system):

https://git.drupalcode.org/search?group_id=2&scope=blobs&search=DRUPAL_C...

https://git.drupalcode.org/search?group_id=2&scope=blobs&search=DRUPAL_C...

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Probably be good to get this in before the next batch modules I'd imagine.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 0a65712 and pushed to 11.x. Thanks!

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

  • alexpott committed 0a657124 on 11.x
    Issue #3122116 by mstrelan, smustgrave, tim.plunkett, catch: Code...
alexpott’s picture

I checked for usages of the constants in system.install and there are none in contrib. Also as the constants are not always available and very internal I don't think a CR is necessary.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.