Various feedback on 8.x-3.x

Thanks!

#1: We are doing a best effort to identify projects and versions with the tools at hand. Without the *_deploy modules, projects checked out of git will not have the project information and version information, so they may be misidentified as custom projects and their version will be unknown (we cannot suggest updates for them). We do have some heuristics to detect custom vs contrib modules, eg. detecting if they are in modules/custom or modules/contrib directory, but that is a suggested way of organization and not necessarily used on a Drupal site (see https://git.drupalcode.org/project/drupal/-/tree/9.0.x/modules). Additionally because there are multiple alternate *_deploy modules to possibly use so we cannot add a hard requirement on one. Also you may in fact have each contributed project added from specific versions with project info and version info, so you may not need either module at all. We cannot really tell from the data available if we miscategorize something and thus you must have one of these modules, otherwise we would know not to miscategorize them. Maybe the only sure-fire detection method is you needing them is if we have identified contributed projects where we don't know the version. In that case, you almost surely need one of those modules. How would you explain this succinctly on the UI? :)

#2 is also on 2.x and was raised in #3154325: If site is one the latest 8.x version don't show warning that a 9.x version is available, @tedbow proposed a fix. I should commit that :) Credited you there too.

#3: was found and fixed in #3163522: Incorrect label for id attribute on 3.x branch. Added a credit for you there too :)

#4: I agree it would be the same in one table and the same across all other tables, however if you have a lot of projects in a table, you don't necessarily see what data you are looking at. Also I am not sure it is quite evident that only projects in the last table would be compatible, so that is either worth repeating or otherwise highlighting.

#5 and #6 were resolved by #3168546: Fix automated tests on 3.x branch, will credit you there too now.

(To be continued, need to run now).

Continued.

#7: It is currently singular at all times. I did not both with doing plural magic. If there are multiple rows in that table, it would be plural as all of the items in that table were identified as belonging to that next step. However this is a good bug find because the ones you did not get version numbers were already up to date. Opened #3168907: Projects already up to date are categorised as to be updated to properly categorise those.

#8: is this new in 3.x? I think this would be a pre-existing thing? Not that it should not be fixed, but I don't think there was any change about the dialog.

#9: I believe this was also resolved in #3168546: Fix automated tests on 3.x branch in particularly with:

+++ b/src/Form/UpgradeStatusForm.php
@@ -334,7 +336,7 @@ class UpgradeStatusForm extends FormBase {
-      $result_summary = $this->t('N/A');
+      $result_summary = !empty($report) ? $this->t('No problems found') : $this->t('N/A');

#10: We cannot really tell apart valid vs. invalid autoload issues. If you try to autoload a class name and have a typo, that is totally valid and needs fixing. We caught a lot of such problems even in high profile contrib modules in the early days (in less used parts of the modules). There may be any number of problems identified in projects that declare they are Drupal 9 compatible given that they may have conditional codepaths for Drupal 8 compatibility that need to use the old class names, etc. That does not by itself mean they are not Drupal 9 compatible. This is an area where we need to trust the maintainers that if they declared the project Drupal 9 compatible than it is even if there are those problems found. I would not silence the problems though given that then if you are fixing a project locally and start with updating the info file, then the module would suddenly remove all reporting of the remaining problems, which is not intended. I think this is an area where some user understanding is required. Do you have suggestions to improve the UI to achieve this?

#11: Yeah this is a real problem. I think the issue queue link is useful even for cases where the project declares Drupal 9 compatibility but especially for those projects where they did not declare compatibility. It would be great to find a way to grab this info without scanning projects first. This needs more thought for sure. We could also append the Drupal.org issues link to the plan even in that case.

Opened #3168912: Drupal.org issue link replaced with Drupal 9 plan on scan, otherwise not pulled for 11.

Committed #3154325: If site is one the latest 8.x version don't show warning that a 9.x version is available.

To reiterate it looks like these are outstanding potential improvements:

• #1 could use more discussion around wording
• #4 could use more discussion maybe?
• #7 bug is fixed but the wording may need to be improved
• #11 needs discussion in #3168912: Drupal.org issue link replaced with Drupal 9 plan on scan, otherwise not pulled

IMHO #11 would be the biggest improvement if we can figure it out.

Look at #10 again that is not new with 3.x either, 2.x already shows those as compatible. Not sure if we can do anything about that.

The rest I already indicated as fixed above.

I think this was resolved as much as it could based on the above. Thanks again for your extensive testing.