WFO Info routing and initial template structure

[eric-gade]

What does this PR do? 🛠️

This PR implements #1470. Specifically, it:

• Creates a new route in which WFO information nodes can be accessed via their WFO code
• Creates an initial override template structure for this node type, along with hooks that massage the data into a usable form.

What does the reviewer need to know? 🤔

New Routing

We have added a new route and handler class in the weather_routes module that lets us access a WFO Information node by its WFO code, ie /offices/OKX will route to the single WFO Information node that is linked to the OKX office (note that the code can be upper or lowercase).

Any incorrect WFO codes -- or references to WFOs for which a node has not yet been created -- will redirect to the 404 page.

Drupal hook for modifying template data

Because we want complete control over how WFO Information nodes, their fields, and the constituent data fields on all these entities are rendered in the template, we have to do some modifications to the node's render array. That happens in this hook inside the theme file.

The only thing to know about this is that if we add/remove/modify any of the fields, we will likely need to update the hook.

Template structure

The templates for the wfo-information node are overrides, and located at new_weather_theme/templates/wfo-info/. Right now there are only two: the override for the node itself, and an override for the image formatter. We went with a field template override for the image because munging its data in the hook is way more complex than other field types.

Aside from the image field, the example template will create a <dl> list for the variables and their current values for each of the field types available for WFO Information nodes. In other words, for now, the page will simply display what pieces of information are available.

Screenshots (if appropriate): 📸

[greg-does-weather]

Nice! I like that this builds the node and returns that as the render content. That's way slicker than what I imagined. Also, how long did it take to find the way of customizing the image template? Whew.

I'm skipping the accessibility test on this one since the template is only a placeholder. We can do more thorough review once we build out the real template later.

Code Review Checklist

A checked item is either an assertion that I have tested this item or an indication that I have verified it does not apply to this pull request.

The Basics

• Checks are passing
• I read the code
• I ran the code
• (if applicable) Post deploy steps are run
• (if applicable) I validated the change on the deployed version in

Documentation

• changes to “how we do things” are documented in READMEs
• all new functions and methods are commented using plain language
• any new modules added documented in modules.md

Security

• security false positives are documented
• data from external sources is cleaned and clearly marked

Reliability

• error handling exists for unusual or missing values
• interactions with external systems are wrapped in try/except
• functionality is tested with unit or integration tests
• dependency updates in composer.json also got changed in composer-lock.json

Infrastructure

• all changes are auditable and documented via a script
• it is clear who can and should run the script
• (if applicable) diagrams have been updated or added in PlantUML

Accessibility

• New pages have been added to cypress-axe file so that they will be tested with our automated accessibility testing
• Meets WCAG 2.0 AA or 2.1 AA for Section 508 compliance
  • Site is keyboard accessible. All interactions can be accessed with a keyboard
  • Site is free of keyboard traps. The keyboard focus is never trapped in a loop
  • All form inputs have explicit labels
  • Form instructions are associated with inputs
  • All relevant images use an img tag
  • All images have appropriate alt attributes
  • Multimedia is tagged. All multimedia has appropriate captioning and audio description
  • Text has sufficient color contrast. All text has a contrast ratio of 4.5:1 with the background
  • Site never loses focus. Focus is always visible when moving through the page with the keyboard
  • Tab order is logical
  • Tables are coded properly. Tables have proper headers and column attributes
  • Headings are nested properly. Heading elements are nested in a logical way
  • Language is set. The language for the page is set
  • CSS is not required to use the page. The page makes sense with or without CSS
  • Links are unique and contextual. All links can be understood taken alone, e.g., ‘Read more - about 508’
  • Page titles are descriptive

Device Matrix

• firefox/gecko (renders correctly and user interactions work)
• chrome/chromium/edge (renders correctly and user interactions work)
• safari/webkit (renders correctly and user interactions work)
• web page is readable and usable
  • at 480px (mobile)
  • at 640px (tablet)
  • at 1024px (desktop)

[greg-does-weather]

Ooooh, neat!