Drupal Config vs Content Breakdown

Drupal essentially stores information in two ways.

The first is via database. A database is not shared across environments, and is unique to each environment (dev, test, prod). Databases cannot move up the chain, as in from dev to test. Or from test to live. Databases CAN be copied down the chain, as in from live to dev. This is useful if you need to test something on the dev environment and want it to utilize all of the latest changes on prod with the latest data that matches prod. In that case, you can clone DOWN the database from prod and replace the dev database with that clone.

The second is via configuration files. These are all managed via git and are in yml format. This includes things like site and module settings, fields in content types, and views. Configuration files MUST be checked in at a lower level like a multi-dev site or from the dev environment. If the change is made only on prod, it will work for the time being, but will be overwritten on the next code push.

This doc will breakdown what is content (managed by database) and what is config (managed by files/git) so you know when things need to be changed on dev first or if it can be done directly on prod.

Content/Database

Changes to these items can be done on prod directly. If they need tested on a dev environment, that is fine, but any work here will need to be manually re-created on test or live to see it.

• Anything in the main content list - https://libraries.ou.edu/admin/content

  • This is virtually every page’s main content other than pages that are managed via views

• User profile info via editing any user here: /admin/dashboard/users

• Custom blocks content - https://libraries.ou.edu/admin/content/block

  • Custom block can be used virtually anywhere in Drupal. One example is that the footer content is managed by a custom block. This is considered content and is environment specific.

• Media - https://libraries.ou.edu/admin/content/media-grid

  • List of docs and images used on the site. This has been copied down to other environments, but is unique to each indiv env.

• Unique taxonomy terms - Example: https://libraries.ou.edu/admin/structure/taxonomy/manage/resources_by_subject/overview

  • This is a tricky one. Taxonomy type creation and field and display management is done via configuration files. BUT, the individual items listed inside a taxonomy term are in fact content and are environment specific.

Configuration Files/Config

If it is not on the list above, it is config! Any config change needs done on a multi-dev site and merged to dev or directly on the dev environment (https://dev-ou-libraries.pantheonsite.io)

• Anything under the configuration tab for sure. Shown below

Open

• MOST under the structure tab.

  • The key items here are:

    • Any content type changes. That includes fields, form display, and display of content types.

    • Webforms. That includes editing ANYTHING within a webform, like the content, fields, or “to” emails.

    • Views. Includes ANYTHING inside a view

    • Block layout

    • Block type. Changes to block types.

    • Taxonomy. Note the text about taxonomy in the content section above. Individual taxonomy list items are content and not config. Anything else in the taxonomy tab IS config. That includes the taxonomy types, fields, and display.

    • Flag module updates - Also called my favorites on our site.

    • Role changes for users

    • User profile fields creation or modifications