The purpose of this document is to discuss the implementation and configuration of the Drupal specific aspects of the CancerGov Digital Platform solution. Each section should discuss the approach that will be taken, as well as alternate approaches that were evaluated and passed on.

Whenever possible we should strive to use Drupal Core approaches in lieu of 3rd party modules. For example, Panels was an important and popular module for handling Landing Page type pages in the past. However, the Drupal community has put a focus on supporting this type of functionality within the Core (Layout Builder) AND integrating it with other Core features such as Content Moderation(workflow) and Content Translations.

When we must augment what is available in the core, we can use third-party modules. We should be very discerning in when we use third-part modules over custom builds, and when choosing which third-party modules. A rough criteria is as follows:

• Criteria #1 -Third-party vs Build: Is this something that we cannot easily build on our own? Is using a third-party module worth a potential security issue or Drupal upgrade blocker while waiting for the maintainers to update their module? Examples:
  • Paragraphs supports repeating blocks of content and would be a key requirement of our implementation. It is a complex module and would require a significant amount of time to implement; therefore it is a strong candidate for use as opposed to building.
  • Bibliography & Citation allows for management and use of bibliographic information and adding citations to content. Citations within content is an important feature in the site, but when investigated, the module include WAY more functionality than we would need. Our implementation would only need a 10th of the functionality. This would not be a good candidate as the number of dependencies and complexity of the module(s) combined with other criteria increase the risk for upgrade blockers and security issues.
  • Allow Formats patches an issue where you cannot set which Text Format a field should use. It was created due to a longstanding issue in core. This is an example of when we should use the submitted patch to Core (or roll our own version); track the progress of the fix; and then implement it correctly when Core has been updated.
• Criteria #2 - Usage: Is the rest of the Drupal community actively using the module (and therefore testing it)?
• Criteria #3 - Issue Tracker: Is the rest of the community is using the module, are the maintainers:
  • Actively maintaining it? i.e. are they putting effort into their module? Are they releasing updates frequently
  • Accepting patches from others? i.e. if others are putting in effort, are people submitting tickets only for those patches to be flatly rejected for invalid or petty reasons? Are they not even doing releases with other's work.