Use AlertComponent consistently

_articles/appdev-testing-credentials.md

@@ -38,11 +38,9 @@ See also: [TTS Handbook page on Sensitive Information][tts-handbook-sensitive-in
 
 **Goal:** test against a brand new partner API using live credentials for their test/sandbox/staging environment
 
-{%- capture alert_content -%}
+{% component alert type=:warning %}
 **Note**: Production credentials and sending production data should only happen in the production environment (`prod`, `staging`, `dm`)
-{%- endcapture -%}
-
-{% include alert.html content=alert_content alert_class="usa-alert--warning" %}
+{% endcomponent %}
 
 1. Write code locally, read secrets from [`IdentityConfig.store.xyz`]({% link _articles/appdev-secrets-configuration.md %}#configuration-in-rails-apps)
 1. Upload actual credentials to S3 YML in a sandbox env (for test credentials) or prod env (for live credentials), use [app-s3-secret]({% link _articles/devops-scripts.md %}#app-s3-secret)

_articles/cloudwatch-101.md

@@ -58,10 +58,9 @@ If you are comfortable with the command line, you can also use our [query-cloudw
 
 ### Filtering by event
 
-{%- capture info -%}
-See [Analytics Events][analytics-events] for the most up-to-date documentation of individual events and their fields.
-{%- endcapture %}
-{% include alert.html content=info alert_class="usa-alert--info" %}
+{% component alert type=:info %}
+See [Analytics Events]({% link _articles/analytics-events.md %}) for the most up-to-date documentation of individual events and their fields.
+{% endcomponent %}
 
 This query filters down to one event, ["SP redirect initiated"][sp-redirect-initiated]:
 

_articles/devops-scripts.md

@@ -55,13 +55,11 @@ app-s3-secret: Upload changes to S3? (y/n)
 y
 ```
 
-{%- capture production_warning -%}
+{% component alert type=:warning %}
 **Note**: When editing secrets, especially in **production**,
 it's a best practice to share the diff in the `#login-appdev` channel for visibility.
 Make sure to redact sensitive values!
-{%- endcapture %}
-
-{% include alert.html content=production_warning alert_class="usa-alert--warning" %}
+{% endcomponent %}
 
 After updating, [recycle the configuration][config-recycle] so that
 this updated config is picked up.
@@ -334,7 +332,9 @@ repository.
 
 ## `oncall/download-piv-certs`
 
-{% include alert.html content=idp_script_alert alert_class="usa-alert--info" %}
+{% component alert type=:info %}
+{{ idp_script_alert }}
+{% endcomponent %}
 
 This script takes a user UUID and downloads the public PIV certs they have tried to use
 over the last 2 weeks:
@@ -346,7 +346,9 @@ Downloading cert to: /tmp/certs/uuid1/cert1.pem
 
 ## `oncall/email-deliveries`
 
-{% include alert.html content=idp_script_alert alert_class="usa-alert--info" %}
+{% component alert type=:info %}
+{{ idp_script_alert }}
+{% endcomponent %}
 
 This script checks for email deliveries (and bounces) for emails by user UUID.
 It queries within the last week.
@@ -368,7 +370,9 @@ It queries within the last week.
 
 ## `oncall/otp-deliveries`
 
-{% include alert.html content=idp_script_alert alert_class="usa-alert--info" %}
+{% component alert type=:info %}
+{{ idp_script_alert }}
+{% endcomponent %}
 
 This script looks up SMS and voice OTP delivieries within the last 72 hours, specifically to streamline
 escalating delivery issues to AWS Pinpoint support (they require traces within 72 hours).
@@ -389,11 +393,10 @@ escalating delivery issues to AWS Pinpoint support (they require traces within 7
 
 ## `query-cloudwatch`
 
-{%- capture alert_content -%}
+{% component alert type=:warning %}
 **Note**: This script has moved to the [identity-idp](https://github.com/18f/identity-idp)
 repository.
-{%- endcapture %}
-{% include alert.html content=alert_content alert_class="usa-alert--warning" %}
+{% endcomponent %}
 
 In the web UI, cloudwatch results are limited to:
 - 15 minutes of time

_articles/help-center-contact-form.md

@@ -11,12 +11,11 @@ subcategory: "Tasks"
 The backend to the Login.gov marketing site [Contact Form](https://login.gov/contact/) is
 a Salesforce instance.
 
-{%- capture alert_content -%}
+{% component alert type=:error %}
 The backend will reject form posts that contain dropdown values it does not know about,
 so new field options need to be added explicitly with the help of the Salesforce team
 before we can deploy changes on our side.
-{%- endcapture -%}
-{% include alert.html content=alert_content alert_class="usa-alert--error" %}
+{% endcomponent %}
 
 ## Configuration
 

_articles/incident-response-guide.md

@@ -7,10 +7,9 @@ cSpell: ignore sitrep sitreps ISCP
 redirect_from: /articles/secops-incident-response-guide.html
 ---
 
-{%- capture alert_content -%}
+{% component alert type=:info %}
 In a situation? Check the [Incident Response Checklist]({% link _articles/incident-response-checklist.md %}) for a quick reference.
-{%- endcapture -%}
-{% include alert.html content=alert_content %}
+{% endcomponent %}
 
 ## Introduction
 
@@ -34,7 +33,7 @@ The complete [Login.gov Incident Response Plan](https://docs.google.com/document
 
 ## Response Process Quick Reference
 
-Specific activities associated with each phase of response, with the exception of Preparation, are generally documented by type of event in the Login.gov Incident Response runbooks. 
+Specific activities associated with each phase of response, with the exception of Preparation, are generally documented by type of event in the Login.gov Incident Response runbooks.
 
 Activities for _Initiate, Assess, Contain and Remediate_ are done in a circular flow until the suspicious or system impacting activity is no longer found in the environment.
 
@@ -46,7 +45,7 @@ An incident is any event that presents an immediate risk to **Confidentiality, I
 
 ### Assess
 
-**GOAL:** Determine the status of the event as either a true positive or false alarm, then assign an impact and severity. 
+**GOAL:** Determine the status of the event as either a true positive or false alarm, then assign an impact and severity.
 
 The Response team should determine the impact classification, make a best guess at severity to move forward quickly.
 
@@ -67,15 +66,15 @@ The Response team should determine the impact classification, make a best guess
 </details>
 
 ### Contain
-**GOAL:** Document the scope of the incident.  Limit the spread and impact of the incident and begin to formulate what remediation actions are required. 
+**GOAL:** Document the scope of the incident.  Limit the spread and impact of the incident and begin to formulate what remediation actions are required.
 
 ### Remediate
 
 **GOAL:** Implement steps needed to recover and return the environment to normal operations. Continue to examine the environment for additional signs of compromise. Spin down the Situation Room.
 
 ### Retrospect
 
-**GOAL:** Review details of the incident to improve the incident handling processes. Create follow up actions for system improvements. Close the incident report. 
+**GOAL:** Review details of the incident to improve the incident handling processes. Create follow up actions for system improvements. Close the incident report.
 
 
 ## Response Process Flow Diagram
@@ -94,11 +93,11 @@ Note the severities may (and often will) change during the lifecycle of the inci
 
 We assess an incident on three areas, **Functional Impact**, **Informational Impact** and **Recoverability**.
 
-A **functional impact** is assessed if any part of Login.gov’s usability, functionality or service becomes unavailable to end users, relaying partners or internal staff. 
+A **functional impact** is assessed if any part of Login.gov’s usability, functionality or service becomes unavailable to end users, relaying partners or internal staff.
 
 An **informational impact** is tracked when any data elements categorized as PII is exposed to an unauthorized party. Internal and confidential information such as API keys, private configuration or business data are also included in this impact category.
 
-The Login.gov team tasked with responding to the event must determine the **recoverability** which is defined as the level of effort they believe the incident will take to recover from. This will help shape the type of response that is required and determine the amount of time and resources needed to return to a nominal state. 
+The Login.gov team tasked with responding to the event must determine the **recoverability** which is defined as the level of effort they believe the incident will take to recover from. This will help shape the type of response that is required and determine the amount of time and resources needed to return to a nominal state.
 
 
 ## Incident Severities
@@ -164,7 +163,7 @@ Both Functionality and Information Impact examples:
 
 Recoverability Level is used to gauge how much time and resources will be needed to return the system to normal operational state.
 
-| Level           |  Definition  | 
+| Level           |  Definition  |
 | --------------- | ------------ |
 | Regular         | Time to recovery is predictable with existing resources |
 | Normal          | Time to recover is unpredictable; no additional resources are needed |
@@ -178,7 +177,7 @@ Recoverability Level is used to gauge how much time and resources will be needed
 Roles are assigned when possible as responders join the incident.
 
 ### Situation Lead (SL)
-* Responsible for leading all members of the initial incident response. 
+* Responsible for leading all members of the initial incident response.
 * Requests additional responders as needed, including a new SL if they need to cycle off.
 * Ensures roles and team are coordinated and have what they need
 * Shares context on what is happening and asks clarifying questions

_articles/windows-virtual-machine.md

@@ -35,11 +35,9 @@ subcategory: "Setup"
 
 8. Log in to the virtual machine
 
-   {%- capture alert_content -%}
+   {% component alert type=:info %}
    The password is `Passw0rd!`
-   {%- endcapture -%}
-
-   {% include alert.html content=alert_content %}
+   {% endcomponent %}
 
 ## Configuring applications for local development
 

_plugins/view_component.rb

@@ -75,16 +75,29 @@ def parse_params(context)
 
   def render(context)
     content = super
-    if !content.include?('<')
-      content = context.registers[:site].
-        find_converter_instance(Jekyll::Converters::Markdown).
-        convert(super).sub(/^<p>(.+)<\/p>$/, '\1')
+    if !/^\s+</m.match?(content)
+      # If the rendered content doesn't appear to be HTML, treat it as markdown. This implementation
+      # is similar to that of Jekyll's built-in `markdownify` filter. Default markdownification will
+      # add a wrapping `<p>`, which isn't always compatible as component content, so it's removed.
+      content = context.registers[:site]
+        .find_converter_instance(Jekyll::Converters::Markdown)
+        .convert(super)
+        .sub(/^\s*<p>(.+)<\/p>\s*$/m, '\1')
     end
     content = content.html_safe
 
     component_class = "#{@component_name.camelize}Component".constantize
     component = component_class.new(**parse_params(context).symbolize_keys).with_content(content)
-    ActionController::Base.new.render_to_string(component)
+    rendered = ActionController::Base.new.render_to_string(component)
+
+    # Rendered component output may span multiple lines of HTML, which isn't always compatible when
+    # rendered in indented content (e.g. lists), where the sudden unindentation may be incorrectly
+    # interpreted as a termination of the list. Replacing newlines with spaces should be relatively
+    # safe for how HTML whitespace is interpreted, since newlines are converted to spaces anyways as
+    # part of the process.
+    #
+    # See: https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Whitespace#explanation
+    rendered.gsub("\n", ' ')
   end
 end