When Savas Labs receives a work-in-progress project, we will review critical functionality, architecture, security, and code pre-development to ensure any risks are identified up front. Some of these items may be optional on certain projects but all are recommended when relevant.
- Identify risks so we can mitigate their impact
- Prepare ourselves for more accurate estimation
- Vet assumptions made by us and our clients
- Accurately quantify the amount of work remaining on the project
- Inform client of how much work previous developers have completed and any issues that have arisen
- Engender trust by showing clients we’re competent, open, and transparent and guide them to a better, less risky, more informed place
- Run the Hacked module on the codebase to identify any patched code
- Run Security Review and Site Audit on site
- For Drupal 7 sites, run Drupalgeddon
- Check server file permissions
- Find out who can access the server
- Find out how is code deployed
- Check file and directory permissions
- Check for server software patches/updates
- Core and contrib modules are up to date with latest stable release
- Patches, if any, are documented and in a
/patchesdirectory - Contrib/custom code is split into (sites/all)/modules/contrib and (sites/all)/modules/custom
- Credentials are not stored in version control
- Modules and themes live in proper place in Drupal
- Format code for Drupal coding standards
- Run code through phpcs
- Ensure each custom module has a README explaining what it does
- Theme: review templates to ensure output is sanitized
- Review existing tests, if any
- If there are not any tests, ask the client to explain what the most important tasks are on the site
- PHP error settings - Errors go to logs only, not to screen
- Permissions/roles (Security Review module will also help identify issues here)
- Use Schema module to identify any mismatched schemas, as well as custom tables that are not part of any module schema
Examples:
- eCommerce
- Mail setup