Style profiles
A profile is a named house style: which rules run, at what severity, with what options. It is the object you actually configure, and it is where your style guide lives.
Where they are stored
Profiles live in project config, under redpen.profiles.<uid>. That is a deliberate choice with real consequences:
- A style guide moves between environments with the rest of the site’s configuration, instead of being re-typed into production by hand.
- Changes land in version control, so “who banned that word and when” is answerable from the git history.
- Editing profiles requires
allowAdminChanges, the same as any other project-config change — which is usually what you want in production.
Creating one
Go to RedPen → Style profiles → New profile. A profile has:
| Field | Notes |
|---|---|
| Name and handle | The handle is what --profile takes on the command line. |
| Description | Free text, for the next person. |
| Default | Whether this profile applies where nothing more specific is assigned. Exactly one profile is the default. |
| Rules | Per rule: on or off, its severity, and its own options. |
| Sections | Section handles this profile applies to. Empty means “not scoped by section”. |
| Sites | Site ids this profile applies to. Empty means all sites. |
| Excluded fields | Field handles to skip entirely, whatever the rules say. Useful for code samples and imported data. |
| Dictionary | Words to treat as correctly spelled, one per line. Passed to the network backends. |
Lite: one profile, the default one, applied everywhere. Multiple profiles and per-section or per-site scoping are Pro features.
How a profile is chosen
For a given element, RedPen picks the most specific profile that matches, in this order:
- A profile scoped to both the element’s section and its site.
- A profile scoped to its section.
- A profile scoped to its site.
- The default profile.
The console command’s --profile option overrides all of this and applies one profile to everything, which is what you want when checking a whole site against a single standard.
A worked example
A typical setup for a site with a marketing section and a technical documentation section:
- House style (default) — banned terms, brand capitalisation, accessibility and structure rules on as warnings. The style rules left off.
- Marketing (scoped to
news,landingPages) — the same, plusreadability.grade-levelat a target of 9 andstyle.weasel-wordspromoted to a warning. Marketing copy should be readable and unhedged. - Docs (scoped to
documentation) — the same as house style, withstyle.passive-voiceexplicitly off andstyle.sentence-lengthraised to 40. Technical writing runs longer and uses passive constructions correctly.
Rules absent from a profile
A profile only has to record what it changes. Any rule not mentioned falls back to its own defaults for enablement, severity and options — so adding a new rule in a plugin update does not require every profile to be re-saved, and hand-editing project config to remove a stanza is safe.