Les Mills Class Types Laravel Package

Product Decisions This Supports

• Content authoring workflow for fitness-class content. The package adds a Bard toolbar button that wraps selected text in a <span class="..."> for Les Mills class types. Product value is entirely in editorial velocity: writers tag class names inline without hand-editing HTML or filing engineering tickets.
• Build vs. buy: this is a "buy" only by default. The scope is a single custom Bard button, which is a small, well-understood extension point in Statamic. Building an in-house equivalent is likely a few hours of a Statamic developer's time; adopting this package trades that effort for a dependency with 10 stars and zero dependents.
• Taxonomy consistency decisions. If class types (e.g., BODYPUMP, BODYCOMBAT, RPM) are a controlled vocabulary, the button enforces the class names at the point of authoring. That is a content-governance decision as much as a technical one — decide whether class types live in this addon's config, in a Statamic fieldset/global set, or in a shared design-system token list.
• Roadmap fit for a Les Mills licensee/franchise site. This is highly specific to the Les Mills brand and to Statamic + Bard. It makes sense if you are building a franchisee or marketing site on Statamic and already have the CSS/design system that consumes these span classes. It is not a fit for multi-brand or non-Les-Mills properties.
• Not a decision driver for structured content or SEO. A span with a class is presentation-layer markup, not structured data. If the roadmap requires class types to be queryable, filterable, syndicated, or emitted as schema.org markup, this package does not address that — that is a field/collection modeling decision.

When to Consider This Package

Consider it when all of the following hold:

• The site runs Statamic with the Bard fieldtype, and content editors are the primary users of the class-type markup.
• You are producing Les Mills-branded content and already have front-end CSS/JS keyed to these span classes.
• You want the smallest possible authoring affordance and are comfortable with a single-maintainer, low-adoption addon (10 stars, 0 dependents) that is nonetheless actively released (latest 2025-08-30).
• You have a fork-and-own posture: the code is small enough to vendor, audit, and patch internally if the maintainer walks away.

Look elsewhere — or build in-house — when:

• You are not on Statamic, or you use Replicator/Markdown rather than Bard. There is no Laravel-generic value here.
• You need class types to be structured, queryable data (entries, taxonomies, global sets) rather than inline spans.
• You need portability across brands or a configurable vocabulary the editorial team can manage without a deploy.
• The class list is expected to change frequently; hardcoded button options mean a code change and release for every new class type unless the addon exposes config.
• Your dependency policy requires multiple maintainers, meaningful adoption, or a security review — 0 dependents means no ecosystem signal on upgrade safety.
• You need accessibility or semantic guarantees: a bare span carries no meaning to assistive tech; a <abbr> or a linked glossary entry may be the better product answer.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost Statamic addon that lets our editors tag Les Mills class names in body copy without engineering help. The financial exposure is minimal — it is not infrastructure, it is a toolbar button, and it can be replaced in-house in roughly a day if the open-source project stalls. The real decision is not "should we take this dependency" but "should our class-type markup live in a button at all," because inline spans are not reportable, searchable, or portable data. If class types matter to the business beyond styling, we should invest in modeling them properly instead.

To engineering: Treat this as reference implementation, not a dependency. Review the addon, then decide between (a) installing it and pinning the version with a note that we own the fork, or (b) reimplementing the Bard button in our own addon so the class vocabulary lives in config or a global set and survives theme changes. The package is single-maintainer with zero dependents, so upgrade risk is ours either way; the only question is whether we accept that risk passively or on our own code. Either path is small. The 2025-08-30 release is a good sign of life but is not a substitute for a maintenance plan.