Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Hi there,
My company (EchoDitto) and I have developed what we're calling an "inspector" module. It provides a report that you can run just before you launch a site to make sure that you've got all your Drupal ducks in a row. Among other things, it checks that:
- Caching and JS / CSS aggregation are turned on
- You have pathauto installed with best practice settings
- You have path_redirect installed with best practice settings
- Cron has been run recently
- You've got spam protection on your webforms
- Submission addresses of your webforms don't contain any internal or testing domains
- You don't have any published nodes that contain "dummy" text (like lorem ipsum)
- You've installed a WYSIWYG and assigned it to at least one other input format
- You have at least one user with an administrator role
... and other stuff you want to check before making a site go live.
Some of the reports are configurable, and new reports can be added using hooks.
We'd love to contribute this to the community. And I, as the person maintaining the module, need CVS access in order to do that!
Thank you for your consideration and please contact me if you have any questions. Can't wait to get this into contrib!
Regards,
Paul Venuti
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | inspector.tar_.gz | 16.74 KB | venutip |
| #2 | inspector.zip | 19.87 KB | venutip |
Comments
Comment #1
venutip commentedGetting a validation error when I try to attach a zip of the module ...
Comment #2
venutip commentedAttached!
Comment #3
avpadernoComment #4
jerdavisA couple of points to check after a quick review.
1) You'll want to make sure extra directories (__MACOSX for example) are removed.
2) You should download and run Coder (http://drupal.org/project/coder) against the code as there are some documentation, grammar and white space issues that need addressing.
3) When installing the module and running the reports out of the box, I'm getting the following errors on the report page:
* warning: Invalid argument supplied for foreach() in inspector.module on line 544. * user warning: Column 'status' in where clause is ambiguous query: SELECT n.nid,n.title,nr.body,e.email,w.confirmation,w.submit_text FROM node as n, node_revisions as nr, webform_emails as e, webform as w WHERE type='webform' AND status=1 in inspector.module on line 697.Also as a personal note, I wonder if it makes sense to change the default states of the checkboxes or perhaps remove some of the default checks prior to putting this module in contrib. Some of the checks may benefit your internal practices but are not standard best practices, and therefore it's a bit presumptuous to say that all sites should include some of these checks.
I didn't vet the architecture of the module itself and feel that deserves a bit of review. I'm curious about the need to include all of the report functions in the inspector.module file and why those wouldn't be registered through your exposed hook rather than as private functions.
This was just a quick review, but those are some of the notes and thoughts I had.
Comment #5
venutip commentedThanks for the review! Ran the module through Coder and cleaned up all the whitespace and other issues that it reported; got rid of those OSX dirs; and took care of those two errors you noted. New module is attached.
As for your other comments, they are well-taken. Our more-specific checks have been broken out into a separate Inspector-aware module that we use internally, but we still wanted to provide as many useful reports as appropriate in the base module. I'll revisit the issue with my colleagues.
Thanks again!
Comment #6
avpadernoPlease read all the following and the links provided as this is very important information about your CVS Application.
Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:Migrating from CVS Applications to (Git) Full Project Applications.
Comment #7
avpadernoAs per previous comment, I am setting this issue to won't fix.
Since new users can now create full projects, applications have a different purpose and they are handled on a different issue queue. See Apply for permission to opt into security advisory coverage for more information.