I get this exception when I try to install the upgrade status module on a new Drupal 9 installation. I simply downloaded the module with composer

composer require 'drupal/upgrade_status:^2.0'

and when I visit /admin/modules or I try to activate via drush drush en upgrade_status I get this exception.


Drupal\Core\Extension\InfoParserException: The 'core_version_requirement' constraint (9.0.2) requires the 'core' key not be set in modules/contrib/upgrade_status/tests/modules/upgrade_status_test_contrib_error/upgrade_status_test_contrib_error.info.yml in Drupal\Core\Extension\InfoParserDynamic->parse() (line 88 of core\lib\Drupal\Core\Extension\InfoParserDynamic.php).
Drupal\Core\Extension\InfoParser->parse('modules/contrib/upgrade_status/tests/modules/upgrade_status_test_contrib_error/upgrade_status_test_contrib_error.info.yml') (Line: 554)
Drupal\Core\Extension\ExtensionList->createExtensionInfo(Object) (Line: 316)
Drupal\Core\Extension\ExtensionList->doList() (Line: 154)
Drupal\Core\Extension\ModuleExtensionList->doList() (Line: 282)
Drupal\Core\Extension\ExtensionList->getList() (Line: 260)
Drupal\Core\Extension\ExtensionList->get('help') (Line: 243)
Drupal\Core\Extension\ExtensionList->getName('help') (Line: 712)
Drupal\Core\Extension\ModuleHandler->getName('help') (Line: 52)
Drupal\Core\Block\BlockManager->getProviderName('help') (Line: 34)
Drupal\Core\Block\BlockManager->processDefinitionCategory(Array) (Line: 67)
Drupal\Core\Block\BlockManager->processDefinition(Array, 'help_block') (Line: 286)
Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 175)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 22)
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('local_tasks_block') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('local_tasks_block', Array) (Line: 76)
Drupal\Component\Plugin\PluginManagerBase->createInstance('local_tasks_block', Array) (Line: 62)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->initializePlugin('local_tasks_block') (Line: 57)
Drupal\block\BlockPluginCollection->initializePlugin('local_tasks_block') (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection->get('local_tasks_block') (Line: 45)
Drupal\block\BlockPluginCollection->get('local_tasks_block') (Line: 83)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->setConfiguration(Array) (Line: 99)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->addInstanceId('local_tasks_block', Array) (Line: 55)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->__construct(Object, 'local_tasks_block', Array) (Line: 34)
Drupal\block\BlockPluginCollection->__construct(Object, 'local_tasks_block', Array, 'seven_secondary_local_tasks') (Line: 156)
Drupal\block\Entity\Block->getPluginCollection() (Line: 145)
Drupal\block\Entity\Block->getPlugin() (Line: 118)
Drupal\block\BlockAccessControlHandler->checkAccess(Object, 'view', Object) (Line: 105)
Drupal\Core\Entity\EntityAccessControlHandler->access(Object, 'view', Object, 1) (Line: 314)
Drupal\Core\Entity\EntityBase->access('view', NULL, 1) (Line: 56)
Drupal\block\BlockRepository->getVisibleBlocksPerRegion(Array) (Line: 137)
Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build() (Line: 259)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 78)
Symfony\Component\EventDispatcher\LegacyEventDispatcherProxy->dispatch(Object, 'kernel.view') (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 705)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Maybe related to https://www.drupal.org/project/upgrade_status/issues/3152280 ?

The strange thing is that core key is not defined in the info yml:

type: module
name: 'Upgrade Status'
description: 'Review Drupal 9 readiness of the environment and components of the site.'
configure: upgrade_status.report
package: Administration
core_version_requirement: ^8.7.7 || ^9
php: '7.1'
dependencies:
  - drupal:update

# Information added by Drupal.org packaging script on 2020-06-20
version: '8.x-2.9'
project: 'upgrade_status'
datestamp: 1592678579

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tobiberlin created an issue. See original summary.

tobiberlin’s picture

Issue summary: View changes
tobiberlin’s picture

Ah I see... the exception fires caused by a submodule's info yml not the "core" module info yml: upgrade_status_test_contrib_error

The submodules still have the core key in there info yml and therefore are not Drupal 9 compatible?!

tobiberlin’s picture

Ok, I see that usually it makes no sense to install Upgrade Status on Drupal 9 but I wanted to test if a patch for a (Drupal 8) module works - and if all problems which may be found by Upgrade Status are solved. As the core_version_requirement key in the info yml of Upgrade Status indicates I thought I could use a Drupal 9 installation to test the newly patched module and to check again with Upgrade Status module.

Wouldn't it be better to keep core key in info yml?

s_leu’s picture

Status: Active » Needs review
FileSize
3.1 KB

Here's a patch for this. I guess sooner or later this module will also have to work on D9 (think update to D10), thus i thought it makes sense to do this patch quickly. Btw. It applies on both, 8.x-2.x and 8.x-3.x.

Status: Needs review » Needs work

The last submitted patch, 5: cannot_install_module_on_d9-3159285-5.patch, failed testing. View results

s_leu’s picture

Missed some files in the previous patch and accidentally duplicated some definitions while search and replacing...

Status: Needs review » Needs work

The last submitted patch, 7: cannot_install_module_on_d9-3159285-7.patch, failed testing. View results

Gábor Hojtsy’s picture

As you can see we are testing for the lack of core_version_requirement key, so to fix this problem, we would need to find another way to do that.

If you would not get that warning on Drupal 9, the module's hook_requirements() would kick in anyway to tell you not to install it. See https://git.drupalcode.org/project/upgrade_status/-/blob/8.x-2.x/upgrade...

s_leu’s picture

@Gábor Hojtsy thanks for the heads up. This happened to me while updating a site do D9 while still having the upgrate_status module activated after the update. Also, as I mentioned above, I thought the module may some day be used to check "old" D9 code for upgrade readiness. So this is at this point not intended, right?

we would need to find another way to do that.

Does it even make sense to find another way around this? Because it looks like the module is not intended to ever be used on D9 as the message in hook_requirements() suggests.

If it does make sense though I'd be happy to create a new patch, given you could point me in the right direction for this.

Otherwise I guess this issue can be closed?

Gábor Hojtsy’s picture

I think it would be great to make it fail gracefully on Drupal 9 which was the intention with hook_requirements.

s_leu’s picture

Should i move the requirement check for D9 out of the install phase then?

Gábor Hojtsy’s picture

@s_leu: we are not even reaching it here, so that would not solve this problem.

szeidler’s picture

I also ran into the issue while being on the upgrade process. So upgrade_status is an awesome helper tool to step by step update all dependencies to the Drupal 9 compatible version. Then I started the upgrade to Drupal 9 and with upgrade_status still being enabled. This will lead to the error.
I will not do this mistake again, but I would wildly guess that the majority that uses upgrade_status will do this mistake at least once.

My naive question is: Why is the module declaring Drupal 9 compatibility, when it's actually not the case? As an alternative I would suggest to add a warning/message to the overview page, that the module should be uninstalled before the upgrade.

carolpettirossi’s picture

I made the same mistake. Upgraded to D9 without disabling upgrade_status. In my case started to see the error when running Functional Tests.

Gábor Hojtsy’s picture

Version: 8.x-2.9 » 8.x-3.x-dev
Issue summary: View changes
Status: Needs work » Needs review
FileSize
1.71 KB
79.8 KB

So drush will not require hook_requirements() for install, neither would site updates do that. All in all I think we should do away with our pretend-Drupal 9 support which was meant to avoid problems for people moving to Drupal 9 and keeping the module on. But they still have problems. So better make it more explicit then. Adding a specific warning to the Relax step as well which on the 3.x UI is the best place to let people know final steps.

Gábor Hojtsy’s picture

FileSize
1.71 KB

I wrongly picked 2.x for the test. Even retesting on 3.x does not seem to make it run against 3.x, so maybe this way it will.

Status: Needs review » Needs work

The last submitted patch, 17: 3159285-16.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Gábor Hojtsy’s picture

Status: Needs work » Needs review
FileSize
2.83 KB

This does of course put the module itself in the collaborate bucket instead of the relax bucket. (This only shows up in testing as the main module is filtered out on normal runtimes to avoid the errors showing up for nothing).

Gábor Hojtsy’s picture

Title: Cannot install this module on Drupal 9: InfoParserException » Cannot install this module on Drupal 9: InfoParserException, undo semi-support for Drupal 9 for now
Status: Needs review » Reviewed & tested by the community

  • Gábor Hojtsy committed 012963d on 8.x-3.x
    Issue #3159285 by Gábor Hojtsy, s_leu, tobiberlin, carolpettirossi,...
Gábor Hojtsy’s picture

Version: 8.x-3.x-dev » 8.x-2.x-dev
Status: Reviewed & tested by the community » Needs review
FileSize
1.09 KB

Rolling for 2.x now. Going for test.

Gábor Hojtsy’s picture

FileSize
1.09 KB

Some problem as above backwards. Reposting for 2.x testing since retesting above on 2.x does not seem to work.

Gábor Hojtsy’s picture

Status: Needs review » Fixed

Fixed on both versions now, thanks all!

Status: Fixed » Closed (fixed)

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