content-model-centralized-content.md

Content Model: Centralized Content

Guiding Principles

• Editors should be able to see nationally controlled content alongside their content so they do not repeat or contradict the national content.
• On page view they should be able to see nationally controlled content to simulate how it appears on the frontend.
• National content editors should have a good editorial experience, complete with moderation, revisions and other governance features built into sections and menu access.
• The frontend should get all the content they need to render a page in one query.

Centralized content uses the contrib module Entity Field Fetch to have a field on one content type, grab content dynamically from a paragraph on a Centralized Content node. As a human enforced standard, Entity Field Fetch fields will be prefixed with field_cc_ so that they can be recognized as a centralized content field.

When loading a node that use centralized content, it will provide a reference to the paragraph that looks like this

[field_cc_bottom_of_page_content] => Array
   (
      [x-default] => Array
         (
               [0] => Array
                  (
                     [target_type] => paragraph
                     [target_uuid] => bdf77955-a825-4931-b9ee-cb0a067cf70d
                     [target_field] =>
                  )

         )

   )

The target_type and the target_uuid provide the details about where the content should come from. The values will be the same for ALL nodes that use the field_cc_bottom_of_page_content which in this case appears on all VAMC System Policies Pages.

Current Implementations

• VAMC System Policies Page pulls centralized content from VAMC System Policies Page Content
  • field_cc_bottom_of_page_content
  • field_cc_gen_visitation_policy
  • field_cc_intro_text
  • field_cc_top_of_page_content

List of all field implementations of this across the cms Related Content Model Document

How to establish a new Centralized Content field?

1. Create a new appropriately named centralized content node on Prod (Unless it makes sense to use an existing one).
2. Add a "Centralized Content Descriptor" paragraph that provides the Title and Description for the paragraph that you will be creating next. This will only appear as guidance for the editors on the node you are creating.
3. Add a paragraph of any type that you need to appear where this centralized content is used. Make sure this paragraph is sorted to appear immediately below the Centralized Content Descriptor you created in the previous step.
4. Wait for this content to appear in the sanitized database you pull into your sandbox.
5. On your sandbox, in the entity bundle that will be the destination for the centralized content, add a field of type "Entity Field Fetch field". Prefix the field's machine name with "cc_". In the settings for the set the target entity type as "Node" since the content is coming from a Centralized content node. Set the node id and the machine name of the field and the uuid of the paragraph to be fetched. The PID can be found here.
6. Add a "Tooltip" field group widget on both the "Manage form display" and "Manage display" tab for the entity. Then move your field_cc_ field(s) into the field group.
7. Save and export your entity configuration as you would for adding any field.

Why didn't we use ___ ?

1. Content Blocks placed with layout builder: Bad workflow, bad governance, bad editorial experience, GraphQL knows nothing of layout builder.
2. Paragraphs library: Not supported cleanly by workbench moderation and workbench menu access (bad workflow and governance).
3. Markdown field: Not supported cleanly by workbench moderation and workbench menu access (bad workflow and governance). Not revisionable.
4. Text field with default content: Hard to update values everywhere in one shot. (bad workflow and governance bad editoral experience) Not revisionable.

Table of Contents