Skip to content

fedms install profile

The fedms install profile is what a tenant site installs to become a FedMS instance. It pulls in the seven component modules, the required contrib modules, the themes, and the baseline config.

Composer package

1
fedms/profile (GitLab: fedms/components/profile)

Where it lives in a tenant site

1
2
3
4
5
6
7
8
web/profiles/contrib/fedms/
├── composer.json
├── config/                    ← profile-owned config
├── fedms.info.yml
├── fedms.install              ← install/update hooks
├── fedms.permissions.yml
├── fedms.services.yml
└── src/

What it installs

The install: section of fedms.info.yml lists every module that gets enabled on profile install. The list is long; the most important non-FedMS modules are:

  • Drupal core modules — node, taxonomy, media, paragraphs, workflows, dashboard, navigation, book, …
  • fedms_eca and fedms_federation — the two FedMS modules enabled directly by the profile. The others come in transitively through dependencies.
  • gin_login — styled login page.
  • helpdesk_gitlab / helpdesk_integration — Helpdesk ticket system integration.
  • login_emailusername — email-or-username login.
  • masquerade — admin impersonation.
  • role_delegation / roles_permission_builder — permission management.
  • webform / webform_content_creator — webform engine and the sync-to-entity bridge.
  • config_devel / config_split / config_ignore / config_rewrite — the config-management toolchain.
  • drd_agent — Drupal Remote Dashboard agent (for monitoring).

And themes:

  • Gin — admin theme.
  • Olivero — front theme.

What it ships in config

The profile owns the baseline config — config that any FedMS instance needs regardless of which features are enabled. This includes:

  • The four config_split profiles (develop, live, test, this_site).
  • Custom date formats (fedms_date_long).
  • Default form and view displays for nodes, users, block content.
  • User profile fields (field_address, field_email, field_image, field_jobtitle, field_language, field_name, field_phone).
  • The two default node types (book, page).
  • The default text formats (basic_html, full_html).
  • The default editor (CKEditor 5).
  • The dashboard.fedms dashboard.
  • The base media types and their displays.

Rewrites

The profile uses config_rewrite to apply opinionated tweaks to upstream config on install:

  • book.settings, collapsiblock.settings, date formats, file settings, gin theme settings, pathauto settings, project_browser settings, symfony_mailer_lite settings, system cron, system date, views settings.

The rewrites are non-destructive — they merge into the existing config without replacing the upstream defaults wholesale.

Permissions

The profile defines exactly one permission:

1
2
3
'administer fedms':
  title: 'Administer FedMS'
  description: 'Administer customer related settings'

Used for tenant-instance-level configuration access.

Custom install / update logic

Any one-shot install logic that doesn't fit the config-management model lives in fedms.install (the _install and _update_N hooks). Keep this minimal — prefer config over code wherever possible.

The install pipeline (high-level)

When l3d ahoy fedms install runs (see vendor/fedms/scripts/install.sh), the order is:

  1. Book module workaround (a known core/book bug).
  2. .base.sh — base setup.
  3. Import config from fedms profile optional/.
  4. Import config from fedms_content optional/.
  5. Import config from fedms_eca optional/.
  6. Import config from fedms_federation optional/.
  7. Disable the ECA modeler (drush modeler_api:disable eca) to avoid model auto-generation during the next imports.
  8. .user.sh — user setup.
  9. config.sh — final config tweaks.
  10. Optional config/install.sh — site-specific extras.
  11. Re-enable the ECA modeler (drush modeler_api:enable eca).
  12. drush cron — flush any post-install jobs.

Updating the profile

Adding a new baseline feature to the profile typically means:

  1. Add the module to the install: section of fedms.info.yml.
  2. Add the relevant config files to config/install/ or config/optional/.
  3. Add the file names to the config_devel: lists in the info file.
  4. Update the composer.json requires.
  5. Open an MR with an updated CHANGELOG.md.

Next steps