Porting Site Audit 2.x to Drush 9.x

Which location has more active development, this project on drupal.org, or the GitHub repo?

An update on where I am at.

I am still planning on using the 2.x branch as the basis for driving my work, as in the short term, strong compatibility with 2.x is critical. However, the 3.x branch has done a lot of cleanup that I do not want to have to re-do in my interim port. So, what I am going to do is identify a 2.x command to port, copy the source code for the appropriate Check from the 3.x branch, make it not a plugin, and wire it up to the Drush command. In my first stage I only care about json output; dealing with reports will happen later.

I have also been thinking about how to reconcile the Plugin architecture from the 3.x branch with a non-module / global Drush command implementation. I think that trying to inject a plugin into Drupal per #7 is not necessary. I'm going to have the Drush command register the built-in commands with simple code that just instantiates the objects and puts them into a simple manager. Later, the plugin code can be wired up to this as a separate way to inject checks into the manager.

At the moment, I think this is better, but I'm only just getting started here. It will be a while before I get to plugins. Are there any contrib modules that are currently using the plugin mechanism to add Site Audit checks?

Another way to state #8 is that I want a Site Audit Plugin to have a 'hasa' relationship with a Site Audit Check, not 'isa'.

The first thing I see that would have to change to make this refactor work would be to make the registry an object, and move `checkInvokeCalculateScore` to the registry.

I started an experimental project to work in:

https://github.com/greg-1-anderson/site-audit-tool

Note that this tool works with both Drush 8 and with Drush 9.

Many details are missing / unspecified at this stage; this project shows only how a check may be separated from the Plugin, and how Drush output formatters can render table or json output. TBD items include html output, cross-check-references (currently done via the plugin mechanism) and reports.

Update on where this is at.

- I moved the Site Audit Tool repository to https://github.com/pantheon-systems/site-audit-tool.
- I ported all of the checks that are being used by the Pantheon dashboard.
- The tool runs some basic tests on all of the checks it supports, using both Drush 9 and Drush 8.
- The code for the checks came from the 8.x-3.x branch, but I made some changes.
- The plugin manager is no longer used to manage checks. Ideally the tool would provide a basic manager, but for now the checks that are available are merely instantiated directly from the commandfile.
- Checks that were returning render arrays were reverted back to the older code from the 7.x-1.x branch to simply insert html.
- Places in the code that needed to do `drush_get_option` now check for attributes of the registry object. I copied options such as 'html' and 'details' into the registry for this purpose.
- I did not use or port any of the report code; instead, I use Drush output formatters to render all output. This means that html mode is not supported in the tool. The html flag will still cause the checks to emit html-embedded-in-json, as `--html --json` previously did.
- I removed the various instances of string padding that were being inserted in non-json mode.

Unfortunately, Pantheon is not interested in sponsoring work on the Drupal module portion of Site Audit. We simply have too many other things competing for our attention right now. If there was interest in sharing checks between the Site Audit Tool and the 8.x-3.x branch, I could probably do some more work to facilitate that. If anyone wants to do that, let me know and I'll outline some steps (integrate with the plugin manager, etc.). It is also possible for 8.x-3.x to continue on in its current form, and leave the Site Audit Tool as a fork.

Anyway, I am sorry that Pantheon didn't pick up this work a year or more ago. It would have been easier to figure out a route forward together earlier.

Pantheon is willing and able to collaborate on maintaining the Drush extension portion of this utility. A drush extension meets the important original use case that Site Audit need not be installed in the Drupal site in order to operate.

For Drupal sites that are not on Pantheon, it makes a lot of sense to have a module that one could install to get a UI to replace the Pantheon Dashboard UI. We can collaborate on making these work together, but we do not have the bandwidth to finish and maintain the incomplete 8.x-3.x branch.

I outlined above how these components could work together. If anyone wants to put time into doing that, I am willing to help.

OK, from your reply above it sounds like your current plan is to try to make the module run as not-a-module if installed as a global or site-wide command, and try to initialize and use the plugin manager in this mode as if the code were a module. I think this is a bad idea, and you'll likely discover more reasons why if you try to do this. I think it could ultimately work, but I think it's also at risk of being fragile.

I think that my proposal, to require pantheon-systems/site-audit-tool as a Composer dependency of the Site Audit module would yield better results in the long run. I'm willing to do some work to make a PoC patch, but if I did this it would perhaps cause some extra work for you, as I backed out some of the 8.x-3.x code (using Drupal themes embedded in json output) as mentioned above.