Create initial feature to display relevant PSA data in Drupal

Here's the start of a patch, with tests and no real code. Yet.

So, I had to commit #2 so we could have code and a branch. This next patch builds upon that. All of the code from that patch and here are up for review.

Still remaining:

• Filter by project name
• Filter by enabled modules

Plus we will want to decide if we want to use the messenger service or build our own similar thing. Building something similar but not the same thing seems like a lot of unnecessary overhead. Messenger will always get displayed. With any theme. And will work with any caching. Rolling our own means we have to build all that all over again. I'm not sure what the gain is. Perhaps we could add that as a feature/nice to have later.

One final note, I changed the project name to be more Drupal like and less composer-like. This will make it easier to see if the project is enabled as Drupal doesn't (yet) know any of these things by their composer name. Using the composer name feels more clean but doesn't work in the real world of Drupal.

So we'll see things like:

"project": "core"
instead of
"project": "drupal/core"

And for contrib:

'project' => 'rabbit_hole'
instead of
'project' => 'drupal/rabbit_hole'

phpcs.

Re #3 I'd have to agree that making a custom implementation of the Messenger service doesn't seem to provide any real world advantages and could just result in more maintenance overhead.

+++ b/src/Services/AutomaticUpdatesPsa.php
+++ b/src/Services/AutomaticUpdatesPsa.php
@@ -0,0 +1,79 @@

@@ -0,0 +1,79 @@
+<?php
+

This seems like something we'd want to add generically to core whether or not automatic updates are enabled. I can see doing it here first while d.o is sorting out the PSA JSON feed itself, but probably needs a core issue too and might be worth putting up a patch even to get UX team review? I think this is something that could go into core directly once the feed is available.

+++ b/src/Services/AutomaticUpdatesPsaInterface.php
@@ -0,0 +1,18 @@
+   * Get public safety messages.

Isn't PSA short for 'Public Service Announcement'?

Also agreed on just using the messenger service here especially if this ends up a standalone core patch.

Isn't PSA short for 'Public Service Announcement'?

+1

Opened #3041885: Display relevant Security Advisories data for Drupal

While adding tests, I realized we need to add the extension type to the json format. Otherwise for contrib we don't know what to check. Which should we look in? extension.list.module, extension.list.profile, extension.list.theme

Cleaned up tests. This is mostly ready for review now.

1. +++ b/src/Services/AutomaticUpdatesPsa.php
   @@ -0,0 +1,235 @@
   +   * Parse core project json version strings.
   

   Nit: JSON (and elsewhere)

2. +++ b/src/Services/AutomaticUpdatesPsa.php
   @@ -0,0 +1,235 @@
   +          $extension = $this->modules->getAllAvailableInfo()[$extension_name];
   

   Minor but given there are oinly two different lines in the three foreach loops wondering if it could move into a helper with extension type as an argument? Or... not even a helper just inline that logic in a single foreach?

Added some error logging, more tests and fixed the feedback from #19.

This seems related

This is looking good 💪

+++ b/automatic_updates.module
@@ -0,0 +1,37 @@
+    switch ($route_name) {
+      // These pages don't need additional nagging.
+      case 'update.theme_update':
+      case 'system.theme_install':
+      case 'update.module_update':
+      case 'update.module_install':
+      case 'update.status':
+      case 'update.report_update':
+      case 'update.report_install':
+      case 'update.settings':
+      case 'system.status':
+      case 'update.confirmation_page':
+        return;
+    }

could use in_array here?

Re #22, that is a direct copy/paste from core. I can remove it here since this is contrib, but it might be something to keep in mind when port this to core.

Fixed #22 on commit. And added #3045273: Add real endpoint after drupal.org provides a live feed to come back and update things when the real endpoint is live.