Update ProjectInfo class to reflect changes to extension system

I have been working on the issue 2470145. As I searched for other places where this might impact, I came across some code&comments in this class, which don't reflect the changes. Can I invest more time into this?

Removing a tag that isn't used in core.

I spoked with alexpott, and for now, until the release I just posted a patch for documenting and setting a default value for the deprecated "status" variable.

This patch cannot work, until the issue 2470145 is fixed. I tested with the patch from the issue above and it works.
Anyhow it should be retested after the usability issue above is considered fixed.

This patch does make a slight but significant change - if a project is hidden but is not in the test package and is enabled it's security updates will show. This was the old behaviour for base themes but I think it should be extended for all. If a project is installed and has security updates you need to know this regardless of the hiddenness.

Makes sense.

The patch itself looks great. So I had to review this by applying and looking at the touched files, to see if everything that should be updated is indeed updated. That's how I found the following:

1. In ProjectInfo:

      * @todo https://www.drupal.org/node/2338167 update class since extensions can
      *   no longer be hidden, enabled or disabled. Additionally, base themes have
      *   to be installed for sub themes to work.
   

   This TODO should be removed :)

2. Also in ProjectInfo:

      * This iterates over a list of the installed modules or themes and groups
      * them by project and status. A few parts of this function assume that
      * enabled modules and themes are always processed first, and if disabled
      * modules or themes are being processed (there is a setting to control if
      * disabled code should be included in the Available updates report or not),
      * those are only processed after $projects has been populated with
      * information about the enabled code. 'Hidden' modules are always ignored.
      * 'Hidden' themes are ignored only if they have no enabled sub-themes.
      * This function also records the latest change time on the .info.yml
      * files for each module or theme, which is important data which is used when
      * deciding if the available update data should be invalidated.
   

   This needs to be updated. It will be much simpler now :)

3. In update.report.inc:

     // Create an array of status values keyed by module or theme name, since
     // we'll need this while generating the report if we have to cross reference
     // anything (e.g. subthemes which have base themes missing an update).
     foreach ($data as $project) {
       foreach ($project['includes'] as $key => $name) {
         $status[$key] = $project['status'];
       }
     }
   

   I think all of this can be deleted too?

Great!

Just nits that can be fixed on commit:

1. +++ b/core/modules/update/src/Tests/UpdateContribTest.php
   @@ -87,7 +88,30 @@ function testUpdateContribBasic() {
   +    // Testing means it should not appear.
   

   Nit: s/in the Testing/in the Testing package/

2. +++ b/core/modules/update/src/Tests/UpdateContribTest.php
   @@ -87,7 +88,30 @@ function testUpdateContribBasic() {
   +    // A hidden and installed project not in the testing package should appear.
   

   Nit: s/testing/Testing/

Committed/pushed to 8.0.x, thanks! (fixed those two nits on commit).

Albeit not easy or obvious to get to:

+++ b/core/modules/update/templates/update-project-status.html.twig
@@ -105,18 +103,4 @@
-  {% if base_themes %}
-    {% set basethemes = base_themes|join(', ') %}
-    {% trans %}
-      Depends on: {{ basethemes }}
-    {% endtrans %}
-  {% endif %}
-
-  {% if sub_themes %}
-    {% set subthemes = sub_themes|join(', ') %}
-    {% trans %}
-      Required by: {{ subthemes|placeholder }}
-    {% endtrans %}
-  {% endif %}

Does this mean we no longer show the base theme to child theme relationship anywhere in core?

Just to give a use-case: if I were to use bootstrap theme and it has updates, it would be nice to know that upgrading that may affect my child theme.

Maybe this issue will half help: #2372183: Display same info for themes as for modules, @davidhernandez mentioned it to me.

I guess that is why that other issue exists #2372183: Display same info for themes as for modules because it should apply to both. I think the use-case I mentioned is valid in both theme and module dependency cases.