[Plan] Site Audit 3.x [#2968983]

Problem/Motivation

The 2.x version of Site Audit has a number of problems. It works only as a Drush plugin, it has no exposure in the Drupal UI, composer doesn't install it properly, incompatibility with Drush 9...

Proposed resolution

Site Audit 3.x should be a regular Drupal module with a UI exposed to run reports. If some checks cannot be run without privileged access, a Drush and Drupal Console command will be provided to run reports as expected.

Remaining tasks

Redefine Site Audit as a normal Drupal module.
Convert the existing DIY plugin system for checks into the standard plugin system with extensible @site_audit_check plugins. #2969605: Create plugin manager for Site Audit Checks
~~Create a UI to externalize reports in Drupal.~~
Create Admin UI to allow checks/report to be enabled/disabled. #2971352: create settings UI to disable/enable reports and checks
Port all 2.x checks to 3.x. - one issue per report
Deprecate 2.x as hard as possible, as it doesn't quite work right anyways.

User interface changes

We'd actually have one. It should appear under admin/reports similar to the Hacked! module.

API changes

Checks would be extensible through the standard Drupal plugin system.
Reports too, probably.
Drush 9 commands to run an HTML, Text, or JSON report. #3001200: create Drush 9 integration
Drupal console support would be nice too. #3001204: Add Drupal Console commands

Data model changes

Not applicable, unless if we want to store reports locally. If we do, steal the data model from https://www.drupal.org/project/site_audit_collector and create a submodule ("site_audit_store"?) for the feature.

Comments

Comment #1

2 May 2018 at 16:37

socketwench created an issue. See original summary.

Comment #2

socketwench commented 2 May 2018 at 16:43

Issue summary:

View changes

Comment #3

jrglasgow commented 2 May 2018 at 20:56

@socketwench
How do we want to go about working on this?
Do you want those of us who are interested to work on creating issues on d.o and submitting patches?
Do you want to create the issues yourself and then we can begin submitting patches.
Or we could fork on Github and start creating issues and pull requests?

Which do you prefer?

Comment #4

fluxsauce commented 2 May 2018 at 21:07

The 2.x version of Site Audit has a number of problems. It works only as a Drush plugin, it has no exposure in the Drupal UI

Some history; it was explicitly designed as a Drush command, which is how it checks hundreds of thousands of sites on Pantheon. It makes sense to provide multiple interfaces, which is what I had started doing in the 3.x version on GitHub before I stopped working in Drupal.

Exposing it as a module makes perfect sense, but I would recommend continuing to allow a similar functionality, IE not require that site_audit be required to be installed in a target site if it's available in Drush / Console / whatever the current equivalent is.

Comment #5

socketwench commented 2 May 2018 at 21:24

@jrglasgow My preference would be to do the work on D.O, since there is more visibility for Drupal devs.

Comment #6

socketwench commented 2 May 2018 at 21:26

Exposing it as a module makes perfect sense, but I would recommend continuing to allow a similar functionality, IE not require that site_audit be required to be installed in a target site if it's available in Drush / Console / whatever the current equivalent is.

That is a good point, although I'm unsure how to actually make that work given the composer issues. Does Pantheon still use Audit in this way?

Comment #7

fluxsauce commented 2 May 2018 at 21:30

Last I knew, Pantheon used git, not Composer to install it.

There was an email thread with packagist regarding what to do, which last I checked was still pending research / response from Drupal Infrastructure. Would it make sense to follow-up on that as part of this effort?

Comment #8

andyrigby commented 3 May 2018 at 08:14

not require that site_audit be required to be installed in a target site if it's available in Drush / Console / whatever the current equivalent is.

I agree with this. If I were to put a hosting hat on, site_audit is useful for hosting environments, but I would not want to be adding packages/modules to a client site.

For one, I would not want to deal with dependency issues, but probably the greater issue would be the end client or developers would be unlikely to want me to make changes to their site/code.

Comment #9

jrglasgow commented 4 May 2018 at 15:01

Issue summary:

View changes

Comment #10

jrglasgow commented 4 May 2018 at 15:02

Issue summary:

View changes

Comment #11

ikit-claw commented 4 May 2018 at 23:47

@andyrigby

"but I would not want to be adding packages/modules to a client site."

Well you don't have to just do "composer require --dev drupal/site_audit"

And then to install the module you have to do "composer install --dev"

That is how you should handle all development modules for drupal 8, this is not the first dev module to exist.

Comment #12

jrglasgow commented 8 May 2018 at 13:37

Issue summary:

View changes

Comment #13

jrglasgow commented 8 May 2018 at 13:43

Issue summary:

View changes

Comment #14

socketwench commented 9 May 2018 at 01:49

Hmmmm. This is a real bind. I've more often installed Site Audit on client sites via composer because they are on an VPS, shared hosting, or something that does not have privileged access. Last I heard, composer doesn't support drush-command-only modules and drush dl is deprecated.

So where does that leave us?

Comment #15

socketwench commented 9 May 2018 at 04:46

I want to make everyone happy here, I really, really do, but I'm looking at the pros and cons of a few different approaches and they all have compromises:

1. We extend and continue the present 8.x-2.x architecture.

Pros:

It works, runs reports, we don't need to rewrite or port anything.

Cons:

Composer installation doesn't work. It installs in modules/, not drush/. Deleting and recreating the Packagist entry and recreating it as project type "drupal-drush" might fix the issues, although this would be risky and disruptive. The last email conversation I had suggested that this might not help anyways due to something innate in how composer works.
If I'm understanding the Drush 9 docs, we wouldn't be able to leverage the Drupal 8 plugin system due to lack of DI. I find this unfortunate because plugins have become a natural extension point, and not leveraging it seems like it would dampen potential community involvement.

I have begged for help elsewhere with the Composer issue, but the situation here is distressingly unique. It's been very frustrating.

2. We move forward with the Drupal module approach.

Pros:

We can use all of 8.x's APIs, use Plugins, the works.
It makes it much easier for site builders and small agencies to use Site Audit because it's Just Another Module.
As Just a Module, we would be able to get more developers to help with the project as the structure would be familiar.
In theory, composer installation would Just Work.

Cons:

We break any integration with 3rd Party Modules (Security Audit, I think Hacked! had an integration once?) and they'll have to write a plugin instead. Granted, it may be as simple as a different base class, some namespacing, and an annotation.
You would need to use composer tricks or other invasive approaches to run Site Audit in a broader scale -- such as if you're an infrastructure provider.

3. Composer based command/library?

This isn't my area of knowledge either, but we could move the core audit checks into a composer command or library. A module, drush and Drupal Console commands would just be front ends.

Pros:

It would work like 2.x does, as an installed site-local module and as a globally installed command.
Any front end is opt-in, likely with different Packagist entries for the core library, global command, and module.

Cons:

This is uncharted territory for me, so I'm not sure if this is a good idea or would even work.
Getting community involvement might be more difficult as this approach heightens uniqueness.
Possible complication in how the module interacts with Drupal?

4. Something else?

These are just the ideas I had over the last couple of weeks. My preference is #2 because it's known territory, and that makes it easier to boost and get more community momentum on it. Still, the concerns about making it available as a global command are a valid point.

Comment #16

ikit-claw commented 19 May 2018 at 22:11

I still think 2 is the best approach.

Comment #17

shawn_smiley commented 2 July 2018 at 17:03

I like the module approach as well and that fits in well with our desire to use the site_audit module as the basis for a platform self-check system in a Drupal application we're building for a client. Hopefully, we'll be able to contribute back some of the external integration checks that we'll be building such as Salesforce Integration checks.

The only other option, which has been lightly touched on by others in this thread, would be to pull the core of site_audit and the individual checks out into separate libraries that would be installed in the vendor directory. Then provide module, drush, and drupal console wrappers that leverage those libraries. To do this, someone would need to setup some git repositories for each of the common library components and register them with https://packagist.org/ (see https://jameshfisher.com/2017/11/06/how-to-release-a-composer-package.html)

We can start pushing up some patches/pull requests in the next week or so if there is an agreed to architectural approach.

Comment #18

jrglasgow commented 20 September 2018 at 13:18

Issue summary:

View changes

Comment #19

jrglasgow commented 20 September 2018 at 13:26

Issue summary:

View changes

Comment #20

truls1502

he/him

Norwegian Bokmål

commented 2 November 2018 at 20:27

I have not used this module in Drupal 8 site yet.

But I have earlier created a feature request #2911891: Overrides the site's language regarding D7, so I was wondering if you plan to release 3.x in D8, do you mind to let us to specific or able to override the site's language? What do you think about it?

Comment #21

colan

he/him

English

Toronto 🇨🇦

commented 14 December 2018 at 18:13

We've been using Site Audit successfully as part of the Aegir Reporting framework (wrapping it in Aegir Site Audit) for both D7 and D8 sites.

Whether it's installed as module or not, we Aegir maintainers will be happy as long as we can access the results outside of the Web UI (via Drush, Console, Ansible, etc.).

Personally, however, I like the idea of not having to install it as a module to keep target sites untouched, as much as possible, but I'll be fine with either scenario. I'm actually a Hacked! maintainer and have done a lot of work on #2066371: Integrate hacked with site_audit & allow hacked to be installed globally.

Comment #22

norman.lol

he/him

German

Berlin

commented 16 June 2020 at 20:19

As already mentioned in #3052993-17: Porting Site Audit 2.x to Drush 9.x I think I'm going to follow @greg.1.anderson's proposal (and approach 3. from #15 by @socketwench) to Composerize the module and pulling in the actively developed and well-maintained https://github.com/pantheon-systems/site-audit-tool fork as a dependency on top of the work towards an UI that @jrglasgow has done so far into a stable 3.0 release.

By that we can have the best of both worlds. The standalone Drush commands and the checks will be provided by the site audit tool fork and the UI will be provided by the Site Audit module. To onboard users the installation guide must be rewritten in a way that this module and the Drush commands also work for unmanaged projects requiring users to run composer install after unzipping the tarball and upload all module files including vendor/.

I see that this means that a lot of code which has been written in the 8.x-3.x branch would be removed by following this approach. On the other hand it would make the module much more lightweight and we can benefit from the work that @greg.1.anderson for Pantheon is doing in the fork. My biggest hope is that the Site Audit module can gain some development-momentum by that after it more or less halted about a year ago.