UPDATE RECOMMENDED 230530
Baseline Tech Specs
The basic audit template covers some basic technical stats so we can get a bird eye view of how well the site is put together and what type of stack it's running on.
The main goal of this audit is to assess the feasibility of a migration to Pantheon. If the site is already on Pantheon, the site audit tool mostly takes care of these concerns. If the client is receptive and on a decent hosting platform, you might consider installing the site_audit module.
When we rank something red or yellow we need explanations of what these ratings mean in the Notes section. We will also need to change our default recommendations if, for instance, a multisite is a good solution for a client's needs.
Site Audit Template is HERE
Section 1: Server
Section 2: Drupal
Item | How to find |
Tools | |
Version Control | Go to the webroot and run "git version" |
Drush | Try running drush in the webroot; if it exists, "drush version" |
Directory Structure | |
Files Directory Size | Run You can run It may be worth it to see what size is with imagestyle/imagecache directories excluded: |
Database Size | Run then or Run the following query that lists the sizes of all the available databases. SELECT table_schema AS "Database", ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "Size (MB)" FROM information_schema.TABLES GROUP BY table_schema; |
Other “Files Directories” | See if any other large files exist in the codebase; particularly in the root of the codebase. find . -type f -size +1G To see if the site has any files too large for Pantheon: find web/sites/default/files -type f -size +256M |
Codebase Structure | Are there non-standard directories? Is all custom code in |
Multisite | See if directories exist for multisite in sites/ |
Non-Drupal Code | Custom scripts are often found in the root of the codebase, check there and feel around a bit |
Codebase | |
Contrib Codebase Quality | Run hacked module if possible. How are patches documented? |
Custom Codebase Quality | Is the Drupal API used well? |
Theme Layer Code | Is the Drupal API used well? Are templates misused (tons of PHP in templates instead of preprocess functions)? |
Contributed Modules | With drush installed run this command: drush pml --no-core --type=module --status=enabled |
Content Types | Run either: echo "SELECT COUNT(*) FROM node_type" | drush sqlc OR $ mysql -uusername -ppassword databasename > SELECT COUNT(*) FROM node_type; In Drupal 9: drush ev "print_r(array_keys(\Drupal\node\Entity\NodeType::loadMultiple()));" |
Views | Run either: echo "SELECT COUNT(*) FROM views_view" | drush sqlc OR $ mysql -uusername -ppassword databasename > SELECT COUNT(*) FROM views_view; On D6 you can get the list of all views code and db from the views_cache table with the following query: SELECT COUNT(*) FROM `cache_views` WHERE cid LIKE 'views_default:%'; The query only shows views that are not in code. The best solution on D7 and up is to use drush: drush views-list --status=enabled This will give you a summary at the end of both code and db views. |
Taxonomy | In D6 you can get a table list of Vocabularies, # of terms, and content types used on with the following query: SELECT v.name, COUNT(DISTINCT td.tid) as '# of terms', CONCAT_WS(', ', vnt.type) as 'used on' FROM vocabulary v LEFT JOIN term_data td ON v.vid = td.vid LEFT JOIN vocabulary_node_types vnt ON v.vid = vnt.vid GROUP BY v.name ORDER BY v.vid ASC; |
User roles | In D6 display list of roles and users per role SELECT r.name, COUNT(ur.uid) as 'users' FROM role r LEFT JOIN users_roles ur ON r.rid = ur.rid GROUP BY r.name |
Section 3: Kalacare Content Audit
If this client will be moving into Kalacare, we need to do a deeper audit of their content types and custom functionality.
During the audit phase, we should evaluate whether we will be able to support this client effectively. Briefly look at the categories defined in the Kalacare Brief Template and evaluate the difficulty of supporting the client.
Once the client has signed a Kalacare deal, we should perform an in-depth audit with the goal of helping onboard Kalacare agents into the project.
See:
Front-End performance
A lot of drain can happen on the front end, and this can vary per browser. Lots of calls to external JS or iFrames can really slow things down.
A speed test is the best place to start:
Deeper Technical Audit
DRAFT - MATERIAL NEEDS WORK
Some clients who have specific concerns or have a technical background may require further research. Here are some resources that may assist in preparing audits for them:
Section 1: Performance Audit
Item | How to find |
Response Times | |
Server Response | This will vary between requests; for a quick idea, load the page in question with the Network tab open and the browser cache disabled and see how long it takes for the initial request of the HTML document to be returned. |
Render time | How long does it take for the webpage to actually render? This is best represented by the red line in the Google Network tab, which represents the "load" js event (when all images, stylesheets, js files, and other assets are loaded). The blue line represents the DOMContentLoaded event and is less important for our purposes. |
Google Page Speed | What's the PageSpeed Insights score for the URL you're investigating? Use the mobile speed and the desktop speed (mobile/desktop) in the audit. |
Performance Config | |
Image Optimization | Is the site effectively using image styles to make sure that images are an appropriate size? Bonus points if they have a system in place to handle responsive images. |
Resources
Section 2: Custom Code Review
Example Audits
Review History
Who | When | Status |
---|---|---|
Bob | 20230530 | Current, but this could benefit from going into depth on some more automated auditing tools, as well as updates to Kalamuna’s process. |