by Stanford Web Services
Version: 1.0.0
Date: October 30, 2015
This document is meant to be a comprehensive guide to web development standards for Stanford Web Services around Drupal web development. This document is our canonical source and guide.
- Abide by Drupal coding standards.
- Never hack core.
- Use linters (phpcs, phpcb, phpmd, eslint, csslint).
- Check with coder module.
- Follow function commenting Doxygen standards.
- Always translate your strings.
- Must include a helpful README.md. You can find a stub at this gist.
- Must include a LICENSE.txt containing GPL V2.
- Include a CHANGELOG.txt with helpful human readable notes.
- Drupal module documentation guidelines.
- (Optional) Provide Behat tests.
- Always provide an upgrade path between major versions.
- Follow module file structure example.
- Try to be as close to KIT complaint as possible.
- Do not re-use fields from other features. Be self contained and namespaced.
- Do not re-use the body field.
- Be granular with Feature components.
- Drupal 8 Twig coding standards.
- Use our base core themes - Open Framework.
- Use our core theme's framework Twitter Bootstrap.
- Follow our Branding guidelines.
- All themes must be responsive and work without JavaScript enabled.
- Use semantic markup and css naming.
- CSS files should live in a /css directory.
- Javascript files should live in a /js directory.
- Images should live in a /img directory.
- Template files should live in a /templates directory.
- Create drush.make files for D7, or composer.json files for D8.
- Never put content in to modules. Use our content server for sample content.
- Write Behat tests.
- Always provide an upgrade path between major versions.
- Follow our best practices on how not to bork your website
- Always host under HTTPS.
- Always use our Features, modules, themes, and approved contributed modules before creating your own.
- Always contribute back to the community in the form of patches and pull requests.
- Look for ways to create re-usable modules and features.
- Always document your code, modules, themes, and installation profiles.
- Provide README.md files in all projects.
- Explain how to install, configure, and use your contribution.
- Provide troubleshooting steps or contact information for help.
- Meet or exceed WCAG Level 2.0.
- Attempt to meet or exceed Level 2.0AA
- Follow Stanford's guidelines and standards SOAP.
- Follow Drupal best practices.
- Always test for low bandwidth and non JavaScript enabled browsers.
- Please follow Drupal's version conventions
- ALWAYS use version control.
- When working on existing projects create feature branches. General practice suggests you name the feature branch after the ticket id.
- When creating commit messages prefix the commit message with the ticket id you are working on. eg: "BASIC-123: My commit message".
- When to branch, fork, or create a new GitHub organization.
- Create a repository for each module, feature, or theme. Do not include whole sites in one repository.
- Do not use git submodules.
- Use Drupal version conventions to name your main branches.
- When creating a git tag use GitHub's release system and follow Drupal version conventions.
- Use PSR-4 namespacing.
- Prefix with the Stanford namespace. Eg:
field_stanford_or\Stanford\Department\MyFeature\MyFeature.php.
- Please follow the fork, branch, and pull request model on GitHub.
- We accept issues on GitHub.
- We accept requests and issues in to our suggestion box.
- We use open source daily and should contribute back when possible.
- Leave GitHub repositories public unless otherwise directed.
- Use open source software when possible.
- Follow conventions for writing secure code or we will get little Bobby Tables.
- Always keep up to date with Security releases on Drupal core and Contrib.