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:

FieldNotes
Name and handleThe handle is what --profile takes on the command line.
DescriptionFree text, for the next person.
DefaultWhether this profile applies where nothing more specific is assigned. Exactly one profile is the default.
RulesPer rule: on or off, its severity, and its own options.
SectionsSection handles this profile applies to. Empty means “not scoped by section”.
SitesSite ids this profile applies to. Empty means all sites.
Excluded fieldsField handles to skip entirely, whatever the rules say. Useful for code samples and imported data.
DictionaryWords 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:

  1. A profile scoped to both the element’s section and its site.
  2. A profile scoped to its section.
  3. A profile scoped to its site.
  4. 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, plus readability.grade-level at a target of 9 and style.weasel-words promoted to a warning. Marketing copy should be readable and unhedged.
  • Docs (scoped to documentation) — the same as house style, with style.passive-voice explicitly off and style.sentence-length raised 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.