Warn about package_manager errors and warning on the status report page

💯 Glad to finally see this happen.

I have long argued that automatic_updates_requirements()'s

    // Check that site is ready to perform automatic updates.
    /** @var \Drupal\automatic_updates\Validation\StatusCheckRequirements $status_check_requirement */
    $status_check_requirement = \Drupal::classResolver(StatusCheckRequirements::class);
    $requirements = $status_check_requirement->getRequirements();

should happen in the package_manager module instead. The reasoning not to do this was that Package Manager was an API-only module. But it's going to be used by both Automatic Updates & Project Browser, so it makes sense to let it handle infrastructure-level validation checks.

Which is why I'm not sure I completely agree with

Automatic Updates should implement hook_requirements_alter. It just unset the package_manager entry and run the requirements like it does now in automatic_updates_requirements.
[…]
This will still trigger all the validators that don't care what type of stage instance it is, all the package_manager ones, in addition to the Automatic Updates specific ones that only apply to automatic updates, such as VersionPolicyValidator.

👆 How will Project Browser than interact with this? Will both Project Browser & Automatic Updates show the Package Manager-generated validation errors?

I think part of the reason initially for just putting the notifications in Automatic Updates and not Package Manager is that AutoUpdates in is focused on security and your site needs to be ready to implement updates regularly whether you are currently using AutoUpdates or not.

UI's like Project Browser are not as critical that they be ready to use at at any time. If you can't install a new module that is not necessarily a security issue. If you can't install an update an existing module that is a security issue.

For Project Browser and other UI's these messages should be show up on their forms because they should run the status checks. So it is not like they will never see them if they don't see them on the status report page.

One problem I see with putting the Package Manager requirements on the page in general is we don't have a good way of notifying the user what parts of the site use Package Manager. If a user installs Project Browser are they going to remember that when they installed it that Drupal asked about installing Package Manager and make the connection that problems in Package Manager will affect Project Browser. If you weren't the user that installed Project Browser I don't think there would be good way to know. If we want to help users how are not familiar with Composer the "Package" is not going mean much to them.

We could have package_manager_requirements add an item or items detailing the problems and then modules like AutoUpdates and Project Browser implement hook_requirements_alter, check if Package Manager added an item and then add their own with a messages like

Automatic Updates will not work properly until Package Manager problems are fixed. See the problems detailed....

The problem with this is that specifically for Automatic Updates we want run status checks with the UpdateStage or CronUpdateStage, depending on whether cron updates are enabled. This because we have validators like VersionPolicyValidator that only apply to Automatic Update's own stage classes. We want them to know ahead of time if the version they are currently on will be supported as a "from" version in cron updates.

Actually I think maybe one way around would be to simply

1. package_manager_requirements run status checks with a generic stage
2. Then have automatic_updates_requirements run them again with UpdateStage or CronUpdateStage, depending on whether cron updates are enabled. This will duplicate message but it shouldn't to many unless you have many problem the system. For instance if your codebase is not writable you would only see that message duplicated
3. Project Browser would then implement hook_requirements_alter, check for the Package Manager item and add it's own item
   

   Project Browser will not work properly until Package Manager problems are fixed. See the problems detailed....

   Project Browser only has 2 validators and they don't take effect in StatusCheckEvent when there not a current stage directory. So it would not have messages specific to Project Browser on the status report.

   I think most modules that extend Package Manager would be like they so they could put similar "will not work properly until Package Manager problems are fixed." message. Modules like Automatic Updates could just run the checks again.

@Wim Leers would do you think about that suggestion?

not Package Manager is that AutoUpdates in is focused on security

… but with Package Manager requiring PHP-TUF too per a decision of Drupal core release managers, is that distinction really still true?

[…] then modules like AutoUpdates and Project Browser implement hook_requirements_alter, check if Package Manager added an item and then add their own with a messages like […]

+1! 🤩

The problem with this is that specifically for Automatic Updates we want run status checks with the UpdateStage or CronUpdateStage, depending on whether cron updates are enabled. This because we have validators like VersionPolicyValidator that only apply to Automatic Update's own stage classes.

D'oh, right!

Actually I think maybe one way around would be to simply

I like that plan a lot.

With one change: → I think we can avoid this by simply omitting the messages for AU & PB that are already shown for PM?

Re #5

With one change: This will duplicate messages → I think we can avoid this by simply omitting the messages for AU & PB that are already shown for PM?

I think it might be better user experience this to just see all the message in 1 place rather than, "here is a list of all AutoUPdate problems but also look at the Package Manager list too."

So think seeing them all in 1 place to solve unattended updates might just be easier. But actually setting up some errors and seeing what the status report looks like is a start. I think we start to work on all of this and figure if we want to remove the duplicate messages after we see what the report actually looks like.

But if automatic update is going only show messages that Package manager did not also find then I think we will need to implement hook_requirements_alter instead. Also in hook_requirements_alter would will be able to guarantee that Package Manager errors would appear just before Automatic Updates?

Updated the summary with the plan from #3. I think this is actionable now

I have implemented the no. 1 from proposed solution and I needed modules/contrib/automatic_updates/src/Validation/StatusCheckRequirements.php, modules/contrib/automatic_updates/src/Validation/ValidationResultDisplayTrait.php and modules/contrib/automatic_updates/src/Validation/StatusChecker.php in package manager and I have to make some tweaks in them for them to work, So I am thinking of replacing the original classes and change the methods to override the methods from package manager?

for the no. 2. part we already have the Requirement implemented on automatic updates so I need to know what should we do with the duplicate messages we will get. Below is the screen-shot of the duplicate message when the site is multisite and one other error/warning:

filed an issue in Project browse 📌 Should Project browser also display errors and warning on the status report page Active

trying to fix tests.

I think this issue is not related to 📌 Add new setting for how unattended updates will be run Fixed .

Originally most important reason to put the status checks on the status report page was because if the the site is depending on unattended updates then they should be warned ahead of time if they are likely not to work because of problem we can figure out ahead of time.

But #3359727 is changing how these status checks are run. If you are going to run unattended updates via a drush command we run the status checks then because running them via the status report by the web server are not going to tell you what the problem might be when the drush command attempts the update

So for status report message Package Manager itself puts on the status report I guess this be only for instance of using PM from the web server.

@ted.bow could you update this and update the issue summary if there's a change to the approach ?