martyfriedel/les-mills-class-types
A Laravel package that provides a ready-made list of Les Mills class types—such as BODYPUMP, BODYCOMBAT, RPM, and more—as an enum or config for easy use in gym timetables, booking systems, and class management features. Avoid hardcoding class names and keep your code consistent.
This is a Statamic addon that registers a Bard toolbar button. When an editor selects text inside a Bard field and clicks the button, the selection is wrapped in a <span class="..."> whose class corresponds to a Les Mills class type (BodyPump, BodyCombat, RPM, etc.). It is not a general-purpose fieldtype and does nothing outside the Bard editor.
First steps:
Confirm prerequisites. You need a Statamic site (v3/v4/v5 depending on the tagged release) with at least one Bard field. Check composer.json for the statamic/cms constraint of the release you are pulling before installing.
Install:
composer require martyfriedel/les-mills-class-types
Statamic addons use package auto-discovery via the extra.statamic key, so no manual provider registration should be required. Verify it loaded:
php artisan about # or
php please addons:list # depending on Statamic version
Read the source first. Before touching config, open vendor/martyfriedel/les-mills-class-types/ and look at:
src/ServiceProvider.php — how the Bard button is registered (Bard::button(...) for older Statamic, or a Vue component registration for newer).resources/js/ — the actual button component and the hard-coded class list. This is where the Les Mills class names live, and it is the file you are most likely to need to edit or fork.config/ and resources/views/ if present — whether anything is publishable.Register the button in your fieldset. In resources/fieldsets/*.yaml (or the Bard field config), add the button handle to the buttons array:
bard:
type: bard
buttons:
- bold
- italic
- les_mills_class_types # exact handle from the addon's registration
First use case: give editors a safe way to tag a class name inline — e.g. "Join our BodyPump class on Monday" — without letting them hand-edit HTML or pick arbitrary CSS classes. The addon constrains the vocabulary to the Les Mills set, which is the entire value proposition.
Style the output yourself. The addon produces the markup; it does not ship frontend CSS. Add rules for each class in your site's stylesheet (or generate them from a config/array) so .bodypump etc. render as intended.
Fieldset-first configuration. Add the button to the specific Bard fieldset that needs it rather than every Bard instance. If multiple fieldsets should share it, use Statamic's fieldset inclusion (import / fields reuse) so the toolbar config lives in one place.
Keep the class vocabulary centralized. If the addon hard-codes the class list in JS, don't scatter matching CSS across your theme. Mirror it in one place:
// config/les-mills.php
return [
'bodypump' => ['label' => 'BodyPump', 'color' => '#e4002b'],
'bodycombat' => ['label' => 'BodyCombat', 'color' => '#003da5'],
// ...
];
Then loop it in Antlers/Blade to emit the CSS, and treat the addon's JS list as the source of truth you sync manually — or fork the addon and read from a shared JSON file.
Render-side handling. Bard stores content either as ProseMirror JSON or rendered HTML depending on the field's save behavior. Because this addon produces a span with a class (not a semantic mark), verify what actually lands in your content files:
{{ bard_field }}
If you need to post-process (e.g. add aria-label or convert <span> to a more semantic element), do it in a small Antlers modifier or a Blade component rather than relying on the button to emit perfect markup.
Content migration/backfill. For existing articles that mention class names as plain text, write a one-off Artisan command that regex-replaces the first occurrence of each known class name with the span. Run it on a copy of the content directory and diff before committing — Bard JSON is easy to corrupt.
Local development loop. Statamic addons frequently ship unbuilt or CP-bundled assets. If the button doesn't appear:
php artisan vendor:publish --tag=statamic-assets (tag name varies)php artisan cache:clear and php artisan view:clearComposition with existing buttons. It coexists fine alongside bold, italic, link, and html. Place it next to link or a formatting group so editors find it; it is a formatting action, not an insertion action.
This is a very small, single-purpose package — 10 stars, 0 dependents, and a low health score. Treat it as reference source code more than a dependency you'll get support for. Pin the exact version in composer.json and be prepared to fork if the next Statamic major breaks the Bard button API (which it has done between v3→v4→v5).
Bard button APIs changed across Statamic majors. A release tagged 2025-08-30 is likely built against Statamic 4/5. Verify against your installed version before assuming compatibility; the symptom of a mismatch is usually a button that renders but does nothing, or doesn't render at all with a console warning.
Selection is required. Like all Bard mark-style buttons, clicking with no selection will no-op silently. Make sure editors know to select the class name first. If the addon instead inserts text at the cursor, be aware that wrapping an existing selection vs. inserting new text are two different behaviors — test both against the actual source.
Stored markup is a span, not a semantic element. That's fine visually, but screen readers and search engines get nothing from class="bodypump" alone. If the class name is meaning-bearing (it usually is here), ensure surrounding prose carries the meaning, or post-process to add data-class="bodypump" / aria-label on render.
Bard save mode matters. If the field is configured to save ProseMirror JSON, your span markup lives inside the marks/content structure and is easy to corrupt with regex migrations. Do backfills against rendered HTML output, or use a proper ProseMirror-aware transform.
Changing the class list means changing JS. There is almost certainly no admin UI for managing Les Mills class types. Adding a new class = editing the addon's JS source and rebuilding assets, or forking. If Les Mills updates its program lineup (they do), budget for this. A fork with the list moved to a config file or JSON asset is the pragmatic long-term move.
No frontend styles ship with it. Editors will tag text and see no visual change on the site until you write CSS. Confirm in staging that .bodypump, .bodycombat, etc. are actually defined in your compiled stylesheet — Tailwind users especially will need safelist entries, since classes appearing only in CMS content are purged.
Debugging checklist for "button doesn't work":
buttons array, spelled exactly as registered?php artisan cache:clear && php artisan view:clear && php artisan config:clear.composer.json.Extension point of last resort: copy vendor/martyfriedel/les-mills-class-types into packages/ or addons/ local path, point Composer at it with a path repository, and own the code. For a 10-star package with a hard-coded vocabulary you'll need to change, this is often the right call rather than fighting the vendor directory.
How can I help you explore Laravel packages today?