This document describes the ideal maintenance plan for the giving.cu.edu website currently hosted on the Pantheon platform. Work on this site dates back to 2015, and over the years several groups and their needs were folded into the growing list of features.
Vendors performed all development work up until the Donor Portal stage where DE (Digital Engagement) staff took over direction. Since February 2020, two developers within DE have worked on the Giving website with no meaningful contributions from vendors or campus partners.
You can review the history of the website on the team wiki: https://advwiki.cu.edu/display/digital/Giving+Website+History
You can also view some documents in Teams for more context mostly in the "Original Documentation" directory: https://cu0.sharepoint.com/:f:/t/AdvDigitalTeam/EkiaNZL3n1xHqZPHaeEWXhwB3FaPBF2ZtjErBmSjvY5L3A?e=STNnPA
The website can function perfectly fine for several years to come by utilizing Drupal 7's extended support; however, the CU security team might not allow that option and deem the Giving website in violation of security protocols after November 28, 2023.
The Drupal 7 Extended Support program was scheduled to start on November 28. 2022, but the Drupal Association pushed back that date another year. The future maintenance of this project is tied to when D7 is finally end-of-life, and the more that decision is pushed out, the less focus is put towards migrating the current codebase and website.
However, the best path forward is migrating the current codebase to a Drupal 9 instance also hosted on Pantheon, but separating out order data from the content management system instead of keeping them together. We started a decoupled frontend to pull data from the Drupal backend, but it is best to keep the frontend tied to Drupal for many reasons, mainly to keep maintenance costs lower than with a decoupled approach.
- Drupal 9 CMS instance - https://github.com/CUCentralAdvancement/the-cms
- Decoupled front end (to be deprecated) - https://github.com/CUCentralAdvancement/giving-frontend
- Giving Gateway app - https://github.com/CUCentralAdvancement/giving-gateway-js
- Newest attempt only on Pantheon - https://github.com/CUCentralAdvancement/cua-giving
You can also view a list of issues related to maintenance in the project issue queue: https://github.com/CUCentralAdvancement/cu-giving/issues?q=is%3Aissue+label%3Amaintenance+
And here are past "incident" reports relating to the Giving website: https://github.com/CUCentralAdvancement/cu-giving/issues?q=label%3Aincident+
Maintaining the site involves a few parts:
- Drupal 7 codebase - The main codebase of the site containing custom and open source code.
- Pantheon Environment - The code is run on a Drupal-specific hosting platform called Pantheon.
- Drupal CMS Users - CU staff access the Giving website for various tasks with varying levels of permissions.
There are also some connected services and websites:
- Authorize.net - Embedded iframe payment form for echeck and credit card orders. At one point, code created recurring orders, but that functionality does not currently work.
- CommunityFunded - A crowdfunding platform that posts order information to the Giving website.
- Gift Planning Website - This is a Drupal 7 site built by a vendor but still listed as being maintained by Digital Engagement/Marketing. More info to read: https://advwiki.cu.edu/display/digital/Gift+Planning+Website
- Foundation Website - Only a redirect to a subsection of the website, but the CU Foundation uses it as "their website".
| Name | Type | Services Offered | Service Types | Used Since 2020 |
|---|---|---|---|---|
| Elevated Third | vendor | Developed giving.cu.edu and light maintenance | dev, support | Yes |
| Archetype5 | vendor | Pantheon organization owner | N/A | No |
| UIS | campus_partner | Develop Drupal 9 profile | dev, support | No |
| Stetler | vendor | Develop Gift Planning website | dev, support | Not sure |
There are a few concerns we consider "site maintenance" tasks:
- Monitoring Alerts - Any application performance monitoring alerts or error notifications need to be dealt with according to SLA agreements.
- User Access - CU staff members log into the website to edit content. Users need to be managed with onboarding, training, activity checks, and best practices for authentication and security.
- Data Governance - All site data needs to have a lifespan attached and sensitive data should not be stored for longer than it takes to process.
- Dependency Updates - The open source Drupal code needs to be updated as security and bug fixes are released.
Each application and service needs to have alerts for activity out of the ordinary patterns. Code deployed needs information about its dependencies, vendors and services have outages planned/unplanned, and web applications are often attacked.
Alert types:
- Security releases - like for Drupal
- Planned outage/maintenance - Salesforce does this a lot, but Authorize.net has notices on the UI sometimes
- Abnormal traffic patterns - New Relic provides this by viewing the requests per minute and other charts
- Application reliabitliy - Pings that provide health checks for 200 responses and uptime monitoring
Resolution: The application or service has been checked for the types of alerts listed above and the primary RACI contact has access to alerts and knows what to do when they receive them. Vendors need to receive alerts as well.
Tasks:
- Look at performance monitoring tools, like New Relic, for internal user traffic abnormalities and review logs if triggers reached.
- Look at performance monitoring tools, like New Relic, for external service traffic abnormalities and review logs if triggers reached.
Any application or service with user accounts needs to have a policy for granting and revoking access to the user accounts. User accounts also include "machine users" and accounts solely used to grant API keys.
The amount of user accounts granted for an application should be the bare minimum and no more. For example, in the Pantheon account only one or two accounts need to have access to fulfill a RACI matrix, but currently accounts like "[email protected], [email protected], [email protected], [email protected]" are all generic accounts with access to backups containing PII data.
Covers:
- User provisioning
- User de-provisioning
- Account suspension during incidents
- Periodic recycling of credentials
- Adoption of multi-factor authentication, if possible
Resolution: The application or service covers all the policy areas mentioned above and someone from CU is mainly responsible for providing the checks. Vendors can perform work, but access control is best left to staff members.
Tasks:
- Look at access logs and follow user access policy for cleanup
- Help users gain access to the website
Any application or service that stores data in a database needs to have a robust data governance policy in order to maintain data integrity and proactively mitigate fallout from any data breaches.
Covers:
- Data backups and schedule
- Disaster recovery procedures
- Data hygiene and cleanup - For example, delete orders on the Giving website after processing.
- User uploaded files reviewed and deleted after period of inactivity
- Could also include...
- Checking for broken links?
- Keeping sitemaps up-to-date?
- Keeping robots.txt files up-to-date?
Resolution: The application or service covers all policy areas mentioned above and each item is tied to a RACI list performed eiter by CU staff or a vendor. If a policy area can't be covered, some kind of secondary measure is noted.
Tasks:
- Delete sensitive content regularly
- Make sure backups are up-to-date and working on a schedule
- Audit content and data periodically to determine what can be removed and what needs to be updated
Any application or service that included user configurable dependencies needs to have a policy for updating those dependencies.
Covers:
- Security updates with response times to update
- Other non-security updates with response times to update
Resolution: The application or service covers all policy areas mentioned above and each item is tied to a RACI list performed eiter by CU staff or a vendor. If a policy area can't be covered, some kind of secondary measure is noted.
Tasks:
- Use an automated tool to provide PRs when dependencies are updated: Dependabot on Github or similar
- Use automated tests to verify the updates don't break any current functionality
- Deploy the updated code in a timely manner to prevent bad actors exploiting vulnerabilities before the production environment can be updated.
The following sections describe how to maintain each of the two systems in more detail.
Drupal is a CMS (Content Management System) used across the CU (University of Colorado) to build and maintain many web properties. The Giving website, specifically, was developed by Elevated Third, a Drupal-based agency located in Denver.
Maintenance tasks:
- Review access and accounts
- Recycle API keys
- Dependency Updates - See the Drupal Dependencies section.
- Sensitive Data Cleanup - Order data and webform submissions have sensitive information in them that is not needed after processing
| Name | Frequency | Provided By | Contact | Notes |
|---|---|---|---|---|
| Review access and accounts | - | Central Advancement | AF | CuF controls the accounts and access |
| Recycle keys | - | Central Advancement | AF | Can only recycle key for online donations account |
| Check error logs | - | Central Advancement | AF | Create GH issues out of any noticable errors |
| Check for broken links | - | Linkchecker module | AF | Contact stakeholders related to links for resolution |
| Expire content and venity URLS | - | Central Advancement | AF | Contact appropriate stakeholders for resolution |
| Update core and contrib modules | Weekly | Central Advancement | AF | Test suite must pass before deployments |
| Delete old order data | TBD | Gift Processing | Kenny | Order Deletion Process |
| Review Webform data deleted | Quarterly | Central Advancement | AF | Webform submission Deletion Process |
| Handle PCI scans | Monthly | Central Advancement | AF | Notes on PCI scans |
The main concern with the codebase is Drupal 7's EoL scheduled for November 2023. Several vendors will provide support and security releases after that date; however, many Drupal 6 sites still exist five years past Drupal 6's EoL so Drupal 7 will likely get support for many years past 2025. You can read more about Drupal 7 extended support plans and any updates: https://www.drupal.org/project/d7es
Apart Drupal core, most of the remaining code comes from the Drupal community's "contrib modules". Some of these modules are used on almost every Drupal 7 site, but other modules probably should have never been added in the first place.
For example, "Drupal Commerce" and its many contrib modules provide many features needed for an ecommerce store but none of the features are used on the Giving website. Therefore, all the code related to Drupal Commerce can be removed without removing any existing features.
In addition to providing more functionality than needed, some modules become abandoned by the original maintainer potentially leading to security issues or bugs that never get fixed.
For these reasons, it is recommended to only use Drupal 9+ core for any future projects involving Drupal, but we realize a few of the most popular contributed modules will be needed to complete any migration work.
Pantheon is a hosting platform specialized for the Drupal and WordPress PHP-based CMSes. It is used across CU to host website built using the Drupal CMS.
Maintenance tasks:
- Review access and accounts
- Recycle API keys
- Dependency Updates - See the Pantheon Dependencies section.
| Name | Frequency | Provided By | Contact | Notes |
|---|---|---|---|---|
| Review access and accounts | - | CU Foundation | AF | CuF controls the accounts and access |
| Recycle keys | - | Central Advancement | AF | Can only recycle key for online donations account |
| Update platform dependencies | - | Central Advancement | AF | Must test all PHP and MariaDB updates with test suite |
| Service | Current Version | Recommended Version | Notes |
|---|---|---|---|
| PHP | 7.1 | 7.4 | 7.4 is EOL 11/2022 but last 7.x release. |
| MySQL/MariaDB | 5.5.30 | 5.7? | No Pantheon notes on what the version should be |
| Solr | 2.x.something | 3.x.something | Should this be moved to a basic search? Why use SOLR? |
Discuss the service, its uses, and how to perform any maintenance tasks.
Authorize.net is the payment provider used to capture payment information. An iframe loads the payment form in order to meet PCI compliance level A (need to confirm?) and webhooks report payment information back to the Giving website.
Issues:
- Webhook responses can pause if any error occurs while processing. Someone has to manually enable the webhooks after this happens.
- There used to be functionality to create recurring orders automatically but this broke and now people handle recurring orders manually. The webhook responses break occasionally when manual entry errors occur.
- Occasionally someone will try to run credit card numbers using the checkout form, and when many checks are run by bots it disables the ability to donate online for a brief period.
- Authorize.net can have blips in service uptime and no one can donate online during those blips.
- The DM team does not control access to this service entirely. There are "Manual Entry" and "Phone Center" accounts in addition to the one giving.cu.edu connects to.
Maintenance tasks:
- Review access and accounts - The CU Foundation controls the accounts and user access.
- Recycle API keys - We use one API login ID/transaction/signature key combination for integration with the Giving website.
| Name | Frequency | Provided By | Contact | Notes |
|---|---|---|---|---|
| Review access and accounts | Monthly | CU Foundation | ? | .. |
| Recycle keys | Monthly | Central Advancement - Digital Marketing | [email protected] | .. |
Community Funded is a crowdfunding platform used by all four campuses to host crowdfunding campaigns. After adding items to their cart, the user is transferred from CF to the Giving website's checkout screen in order to capture payments.
CF does have an authorize.net integration that could be leveraged to completely remove the need to connect to the Giving website.
Issues:
- Campus partners occasionally report issues with order confirmation pingback.
- No current API keys used
- Unclear who controls the relationship, ex. who contacts them about security issues? How to handle service outages?
- Cannot accept recurring gifts within the platform
- Cannot Accept gifts via Venmo, Paypal, etc. via the platform
- No great way to have short links/vanity URLs
- No great way to provide a DNS entry, like
crowdfunding.cu.edu, and use that for CF content
Maintenance tasks:
- Review access and accounts - The Annual Giving team controls the accounts and user access.
| Name | Frequency | Provided By | Contact | Notes |
|---|---|---|---|---|
| Review access and accounts | Monthly | Central Advancement - Annual Giving | ? | .. |
We are developing a public user guide that will tell you all about what the users do, but for user access maintenance the main tasks revolve around granting and taking away access based on Giving site platform usage rules.
User guide: https://github.com/CUCentralAdvancement/giving-site-user-guide
Maintenance tasks:
- Review access and accounts - Use org charts and activity tracking data to provision and de-provision users as needed.
| Name | Frequency | Provided By | Contact | Notes |
|---|---|---|---|---|
| Review access and accounts | Monthly | Central Advancement | ? | .. |