zsoltjanes/statamic-bard-openai
A Statamic addon that connects the Bard fieldtype to OpenAI, letting editors generate, rewrite, or expand rich-text content directly in the control panel. Configure prompts and API settings to speed up drafting while keeping Bard formatting.
Architecture fit. This is a Statamic addon, not a general-purpose Laravel package, so its architectural fit is narrow but clean. Statamic addons follow the standard Laravel package contract: a service provider registered via Composer auto-discovery, published config, and a front-end component that hooks into the Bard fieldtype (Statamic's block-based rich text editor) inside the Control Panel. Under the hood a TPM should expect the usual Laravel primitives — the Http client or Guzzle against the OpenAI Chat Completions endpoint, config published to config/, and an API key sourced from .env. That is orthodox and low-friction for a Laravel team. The architectural constraint is that it only delivers value where the site is on Statamic Pro (Bard is a Pro fieldtype) and where content authoring — not rendering — is the bottleneck. It is an editorial productivity tool, not a runtime dependency; it should never sit on the hot path of a page request.
Integration feasibility. Mechanically simple: composer require, publish config, set OPENAI_API_KEY (or a Statamic-managed secret), add the field configuration in a Bard fieldset, and the "write with AI" affordance appears in the editor. There is no database migration and no data model change, which collapses the usual integration risk. The real feasibility question is not technical but governance: 3 GitHub stars, 0 dependents, and a single-maintainer repository mean the package has essentially no production evidence base. The repository name (statamic-ai-writer-for-bard) does not match the Composer package name (statamic-bard-openai), which is a small but real signal of immaturity and complicates provenance checks in a supply-chain review.
Technical risk. Ranked by severity:
NOASSERTION) is blocking. An unrecognized or custom license cannot be cleared by procurement or legal for commercial use without direct author inquiry. Until resolved, assume you cannot ship it.2026-07-07 release (metadata noise or an automated tag) give no confidence in a patch cadence.Key questions. Who owns this repository, and what is the actual license text? Which Statamic majors and PHP/Laravel versions are declared compatible, and is that verified in CI? Does it support configurable models, token limits, and per-role rate limits, or is the model hard-coded? Where is the API key stored and is it exposed to the browser bundle? Is generated content returned as structured Bard blocks (ProseMirror/TipTap-compatible) or as flat HTML that will corrupt block structure on save? Does streaming/timeout handling degrade gracefully, and is there an audit trail of AI-generated edits?
Stack fit. Good fit for a Statamic Pro + Laravel shop; poor fit for anyone else. It presupposes Composer-based deployment, a CP exposed to authenticated editors, and organisational willingness to call OpenAI. If the team is on WordPress, Craft, or headless Laravel-only, stop here.
Migration path. There is no migration — this is additive. The correct path is: (1) resolve licensing, (2) fork or vendor the addon into a private Composer repository so upstream abandonment cannot break builds, (3) pilot on one fieldset in one non-critical site, (4) review generated output quality and block-structure fidelity for two to four weeks, (5) only then roll out per-fieldset with an editorial policy attached.
Compatibility. Verify explicitly against the target Statamic major and PHP version; do not trust the absence of an upper bound in composer.json. Because the CP component is coupled to Statamic's front-end stack, treat any Statamic major upgrade as a breaking-change event for this addon and schedule a regression test of the Bard editing experience as part of that upgrade.
Sequencing. Licensing and privacy sign-off → private fork and pinned version → secrets management and spend caps in place → single-fieldset pilot → editorial guidelines and fallback to manual authoring → broader enablement. Nothing about the value proposition justifies running steps 2–5 in parallel.
Maintenance. Effectively zero cost while it works, high cost the moment it doesn't. Assume you, not the author, will fix incompatibilities with future Statamic releases. Budget a small standing allocation (a few days per Statamic upgrade cycle) or accept that the feature may be unavailable for weeks after an upgrade.
Support. None meaningful. No community, no dependents, no evidence of issue triage. Internal ownership must be named — an individual on the web team who can read the source and patch it — before this goes anywhere near a production site.
Scaling. Scales with editorial headcount and token volume rather than traffic, which is the good news: page requests are unaffected. The limits are OpenAI rate limits, per-minute token quotas, and cost. Enforce per-user quotas and log token usage per generation so finance can attribute spend; without that, an enthusiastic editorial team can produce a surprising monthly bill.
Failure modes. OpenAI outage or 429 throttling (degrades to a dead button — acceptable, must not block saving); malformed or non-block-safe output (degrades to corrupted rich text — the worst case, and the one to test hardest); key rotation mishandled (silent 401s); model deprecation by OpenAI (hard failure with no upstream fix); addon abandonment (frozen against a Statamic major). Each should have a documented fallback: manual authoring always works, and the AI affordance should be disableable per environment via config.
Ramp-up. Hours for a developer to install and configure; under an hour of editor training. The friction is not technical adoption but behavioural governance — teams need agreed rules on disclosure, fact-checking, and which content types may be drafted with AI. Write those down before the pilot, not after.
How can I help you explore Laravel packages today?