Policies
Colby College will support the latest two (2) versions of Chrome, Firefox, Safari, Edge, and browsers with greater than 1% of global market share (iOS, Android, Opera, etc).
Colby College will support any device that can run a supported browser. Although Colby’s web features are built to support the latest in responsive design, devices with small screens may have limited functionality.
We will only do whole-sale find and replaces on locations and links, but never people. This policy will help memorialize the person’s name inside the post content.
The communications office will have the ability to modify businesses claimed as Colby business inside of Google Maps. ITS will claim each business because they administer G Suite and all sub products. The coordination with ITS is as follows:
- 1.Colby IT administrators (using a 'Colby Administrator' account) will claim ownership of College businesses as part of the Gsuite colby.edu domain.
- 2.Colby IT administrators will sub-assign ownership to Communications staff via Group - any further delegation to other Colby staff will be managed by Communications
- 3.Any requests for new businesses or business ownership can be made through the office of communications, if IT administrators receive any requests directly they will notify communications prior to taking ownership.
To keep code modular, we should try to break functionality out into reusable dependencies wherever possible. The type of dependency may vary depending on context. For example, we may choose to use JS in some contexts and PHP in others.
Secrets like API keys and other tokens should not be stored in the code. Instead, they should be injected from an external source into a project to then be used by the code.
Platform.sh (if using) has a way to add variables through the project UI. For instructions on how variables work, visit https://docs.platform.sh/development/variables.html.
Quality assurance testing, manual and/or automated, is to be done on each new feature, bug fixes, and updates of any kind (dependency/plugin/theme).
Upon updates to a 3rd party plugin, we should scrutinize the changelog, if provided.
Scenario: A plugin or several plugins need updating. This is either for regular maintenance or because something is broken and an update will fix it.
- 1.Update plugin(s) on a staging environment.
- 2.Smoke test key elements of colby.edu on the frontend
Top sites (by pageview):
/academics/majors-minors/
/libraries
/admissions
/residentiallife/campus-housing/
/museum
/miller
/parents
/davisconnects
/alumni
/goldfarb
- 1.Run automated tests on frontend (if applicable)
- 2.Smoke test key features in wp-admin
- Loading dashboards
- Editing a page
- Editing a post
- Previewing a page/post
- Interacting with media library
- 3.If no issues are found, tell ITS what plugins and what versions should be updated in the round of updates on Tuesday/Thursday morning.
- 4.Obviously if issues are found, we need to discuss the impact and either decide to proceed or to find a fix/workaround
Although 3rd party themes should be used sparingly, if used, and upon updating, we should do extensive testing on key features of the theme. For example, if the theme uses a page builder, we should test page building and the affected blocks. We should scrutinize the changelog, if provided as a roadmap of what to test.
- Developer
- Developer documentation includes all the knowledge that a developer needs in order to use a feature. Examples of this can be installation instructions, examples of function calls and arguments, component props, change logs, general usage examples. Comprehensive developer documentation must be completed before a feature is released. Developer documentation should be stored in a readme alongside the code in GitHub.
- User
- User documentation includes all usage instructions for editors and other non-technical administrators in order for them to use a particular feature inside page content. User documentation is to be stored on another site, and then linked to extensively.
Only users with the roles of Administrator or Editors will be permitted to use a page builder. Even after a user is permitted to edit or create a page with a page builder, Colby branded templates should be used unless the situation is deemed a special case, and therefore needs special treatment.
For larger projects, or for web projects that are off-shoots to the Colby brand, the Office of Communications will facilitate in choosing themes and templates.
When choosing 3rd party themes or building themes in-house, we should seek themes that are compatible with Elementor. For developer documentation on how to build themes compatible with Elementor, check their docs:
We will use semantic versioning via git tags to provide version information for software. Semantic versioning follows the structure
1.0.0 or major.minor.patch to bring more meaning to the differences between each version. Semantic versioning works extremely well with Composer and NPM.Last modified 2yr ago