Every part of UA Quickstart is available for internal and external vendors to use as they see fit to help University of Arizona clients meet their goals.
Because the main purpose of Quickstart is to reduce one-off development and ensure that time and resources spent by one department can benefit the University as a whole, anything built using Quickstart can potentially be contributed back to be a part of Quickstart.
When starting any new project, it is important to consider both the initial delivery of the website as well as the long term support and maintenance of that site.
Whenever Drupal core or any contrib modules that are UAQS dependencies receive security updates, the codebase for UAQS is updated to include these updates and is thoroughly tested by the UA Digital team to ensure that it doesn’t conflict with any other UAQS functionality and, if it does, then that is updated as well and further tested. In addition, UAQS features are constantly improving in usability, accessibility, security and design.
With that in mind we have provided the following guidelines that allow custom development without sacrificing long-term maintainability.
You can access the Repo on Bitbucket at bitbucket.org/ua_drupal/ua_quickstart
Do: Use the pre-built University of Arizona modules.
At the time of this writing, there are 62 modules that have been made to provide functionality or styling that is consistent with the UA Brand or ecosystem. Before writing your own custom module, see if what you need has already been created by the UA Digital Team.
Don't: Modify any of the pre-built University of Arizona modules.
If any of the pre-built modules get you close to what you want, but not all the way there, it is still better to create a completely separate module than to modify an existing one. This will ensure that any module updates won’t overwrite your code. It’s usually a good idea at this step to make sure that you really need those changes.
Do: Use pre-built Quickstart Views.
Several Views have already been created to present People, News, Events, Majors, Etc. in consistent ways across the University. Check to see if one of the existing Views will meet your needs.
Don't: Modify the settings for any Views provided by Quickstart Features
If you need to make a slight modification to an existing view, you must clone to make your own version for modification. Include the client's name in the view so we know it's a one off immediately. But even better than cloning and modifying is contributing the requested view into the Quickstart platform so it can be better managed.
Don't add filters or fields. Even changing something as simple as the pagination will cause the View to be overridden and it will risk being overwritten when updates are applied. Make a separate View that is not configured in Quickstart code!
Do: Use Quickstart Entity Bundles.
The configuration settings for the various Drupal entity bundles provided with UA Quickstart are exported and managed as part of Drupal Features.
Entity bundles provided by UA Quickstart Features include:
- Content types (Node module)
- Block types (Bean module)
- Paragraph types (Paragraphs module)
- Taxonomy vocabularies (Taxonomy module)
- Field collections (Field collection module)
Don't: Modify any configuration that is managed in code.
Any site-building tasks that directly change these configuration settings should be avoided including:
- Modifying entity bundle field settings (i.e. Manage fields) via the Field UI
- Adding fields to UA Sites entity bundles
- Deleting fields from UA Sites entity bundles
- Editing existing fields on UA Sites entity bundles
- Modifying the text format settings for any UA Sites entity bundle fields
- Modifying the form labels of fields on UA Sites entity bundles
- Changing the form order of fields on UA Sites entity bundles
- Modifying entity bundle display mode settings (i.e. Manage display) via the Field UI
- Enabling or disabling view modes (Teaser, Full content, etc) for UA Sites entity bundles
- Changing field display settings for any UA Sites entity bundle view modes
- Hiding/showing fields
- Hiding/showing field display labels
- Changing field formatter settings
- Changing field display order
- Adding/removing/changing Fieldgroups
Do: Set up General Configuration on your site
All of the following is fine to update without any conflicts with Quickstart.
Site Information Configuration
- Configuring Site name, Slogan, E-mail address
- Configuring Default front page, Custom error pages
- Changing the site logo and footer logo images
- Configuring the footer Copyright notice
Contrib Module Configuration
- Google Analytics module configuration
For any UAQS Feature, you can easily see which things you can or cannot change on the Features Page.
- Got to /admin/structure/features
- Select The University of Arizona from the left side menu.
- Click on the name of the Feature you want to change Configuration for.
- Anything in Default config can be changed. Nothing else can be changed or it will override the feature and no longer be updated.
There's a contributed module for almost everything in Drupal, but just because they exist doesn't always mean that you should use them.
The more Modules that you have enabled, the slower your site will be and the potential for bugs and conflicts grows with the complexity of the site.
The first thing is to consider if you really need the functionality that the module provides!
If you do need to install a module that adds functionality make sure you choose one that:
- Is actively being maintained
- Has a stable release available
- Is being used by at least 100's (prefer 1,000's) of sites
- Has a Drupal 8 version, or at least a planned release for Drupal 8
- Does not have a large number of outstanding issues
- Is not on the list of Unsupported modules for your hosting environment. Example: Pantheon https://pantheon.io/docs/modules-plugins-known-issues/
Consider prefixing module/theme names to avoid namespace collisions
Keep custom modules or themes in a `custom` subfolder of `sites/all/modules` or `sites/all/themes`
Use Feature Exports for Content Types
Exporting your Content Types as Features will make them highly reusable.
Stanford does this well: https://swsblog.stanford.edu/blog/3-tips-making-your-drupal-features-highly-reusable
Consider using drupal.org branch/release naming conventions
Follow Drupal coding standards
Use security best practices
XSS and SQL injection prevention