| title | Components |
|---|---|
| description | How sitectl uses components to model optional stack capabilities and help operators turn features on and off safely. |
import { Compose } from "/snippets/compose-tooltip.mdx";
Components are how sitectl models optional capabilities within a stack. Instead of treating a project as one large, all-or-nothing setup, components let each optional feature carry its own defaults, configuration rules, and operator guidance.
When a plugin defines a component, sitectl can:
- Ask about it during site creation — prompting you to enable or disable it before the first launch
- Report its current state —
sitectl component describelists all components registered by the active context's plugin, showing whether each one is on, off, or out of alignment with the project files - Apply state changes safely —
sitectl set <name> <on|off>records the desired state, andsitectl convergeapplies the resulting file changes with a confirmation step before anything destructive happens
A component can be in one of two states:
| State | Meaning |
|---|---|
on |
The component is active and its services, configuration, and Drupal modules are in place |
off |
The component is inactive; its services and configuration are removed or suppressed |
Within a state, a component also carries a disposition that records more detail about how it ended up there:
| Disposition | Meaning |
|---|---|
enabled |
Explicitly turned on by an operator |
disabled |
Explicitly turned off by an operator |
superseded |
Replaced by a different component or approach |
distributed |
Shipped as part of the upstream template; not yet explicitly set by an operator |
# Show all components for the active context's plugin
sitectl component describe
# Target a specific project directory
sitectl component describe --path /path/to/projectThis reports every registered component: its name, current state, and whether the live project files match what sitectl expects. A drifted status means the project files no longer match the last applied component state — usually something was changed outside of sitectl.
# Using the top-level set command
sitectl set fcrepo off
sitectl set blazegraph on
# Using a plugin namespace when multiple plugins are involved
sitectl set isle/fcrepo offAfter running sitectl set, the desired state is recorded but project files are not yet changed. Follow up with sitectl converge to apply the change.
# Preview what would change
sitectl converge --report
# Apply changes interactively
sitectl converge
# Apply changes for a single component
sitectl converge --component fcrepoconverge compares each component's expected configuration against the project files on disk and repairs any differences. Use --report to review changes before applying them.
When you run sitectl create isle, sitectl asks you about each component that has a meaningful architectural choice — like whether to include Fedora or Blazegraph. You can answer interactively or pass flags to skip the prompts. Your choices are applied to the project before the first launch.
The component model is designed to grow. Planned additions include:
- PostgreSQL — switch the Drupal database backend from MariaDB to PostgreSQL
- Memcached / Redis — add caching layers to the Drupal stack
- Load balancer support — configure ISLE to run behind an upstream reverse proxy
- mergepdf — enable PDF aggregation for paged content in Islandora
See the developer component guide for how components are defined and what each field in the definition struct means.