Drafts Laravel Package

Technical Evaluation

What this actually is. Despite being filed under "Laravel/PHP package," fof/drafts is a Flarum extension, not a standalone Composer library. It runs inside a Flarum host application and depends on Flarum's extension bootstrapping, its Eloquent-backed models, migrations, policy/permission system, and frontend asset compilation (Mithril/JS). It inherits Laravel idioms (service providers, Eloquent, migrations, middleware) but is not installable or useful outside a Flarum forum. Evaluate it as a forum feature module, not as a reusable PHP dependency.

Architecture fit. Good, if and only if Flarum is already your forum platform. The extension adds a Draft model scoped to user + discussion, a serializer, API endpoints, and a frontend autosave layer that persists content server-side and mirrors state in the browser. It is additive: one migration, no core schema mutation, no monkey-patching of core classes. That is the cleanest possible footprint for a Flarum feature extension, which keeps blast radius small and rollback cheap (disable extension, drop table).

Integration feasibility. Low effort. composer require fof/drafts, enable via admin or php flarum extension:enable fof/drafts, run migrations, configure the draft-autosave interval and group permissions in the admin panel. There is no external service, no credential, no queue worker, and no cron dependency. A competent Flarum operator completes this in under an hour including staging verification.

Technical risk. The functional risk is low; the supply-chain risk is the real item.

• 18 stars and 0 dependents is a thin adoption signal. Stars are a weak proxy, but combined with zero dependents it means almost no downstream production validation you can point to during a review.
• Single-vendor concentration: this is a FriendsOfFlarum extension. FoF is the de facto standard vendor in the Flarum ecosystem, which materially offsets the low star count — but it also means a large share of your forum's feature surface rests on one volunteer organization.
• The stated last release date (2026-10-23) is in the future relative to any normal review window. Treat the metadata as unreliable until you confirm the actual tag and changelog against the repository. This is a data-quality flag, not a code-quality one.
• MIT license removes legal friction. No commercial support tier exists, so support is GitHub issues plus your own engineers.

Key questions to resolve before approval.

1. Which Flarum major/minor versions and PHP versions are explicitly supported, and does the extension's composer.json constraint match our pinned Flarum version?
2. Is there an automatic pruning/retention policy for draft rows, or do drafts accumulate indefinitely per user?
3. Does the autosave interval create write amplification on our database tier at our expected concurrent-editor count?
4. Are drafts included in user data export and account deletion flows, and does that satisfy our privacy commitments?
5. Who owns patching if FoF archives the extension or a Flarum core release breaks compatibility?

Integration Approach

Stack fit. Requires an existing Flarum 1.x host on PHP 8.1+ with MySQL/MariaDB, PostgreSQL, or SQLite. Install is Composer-native and fits the same dependency workflow as the rest of the Flarum extension set — no separate build pipeline, no container, no sidecar. If we are not already on Flarum, this package is irrelevant and the conversation should be about forum platform selection instead.

Migration path. Straightforward, with one caveat: the migration adds a drafts table and the extension registers new API routes. On a forum with existing content, expect a fast, additive migration with no backfill. The real migration work is policy, not schema — deciding which groups get draft permissions and what the autosave cadence should be so we do not surprise users with unexpected write behavior.

Compatibility. Two axes to pin. First, Flarum version: verify the extension's declared constraint against our exact core version, and check the changelog for the last two Flarum minors. Second, extension-set interaction: draft persistence touches the discussion composer, so any other extension that modifies the composer (mentions, uploads, markdown editors, rich-text plugins) is a candidate for conflict and must be smoke-tested together, not in isolation.

Sequencing.

1. Confirm actual release tag and Flarum/PHP support matrix from the repo, not from aggregated metadata.
2. Stand up a staging clone of the production forum; install, migrate, enable.
3. Test the composer with the full production extension set enabled — draft save, restore, discard, multi-tab, and permission-denied paths.
4. Decide retention policy and document it before launch, not after.
5. Ship to production behind group permissions limited initially to staff or a pilot group; widen after one week of error-rate and DB-write observation.
6. Record the rollback step (disable extension; retain table for 30 days before dropping) in the runbook.

Operational Impact

Maintenance. Low recurring cost. The extension has no external dependencies to rotate and no scheduled jobs to monitor. The maintenance burden is version-tracking: every Flarum core upgrade becomes a compatibility checkpoint, and because the package is community-maintained, there is no vendor SLA telling us when a compatible release lands. Budget a recurring line item for "verify drafts extension against each Flarum upgrade" rather than assuming it rides along.

Support. No commercial support. Our engineers own first-line triage. Given the small codebase, a mid-level PHP engineer can read the whole extension in an afternoon, which substantially de-risks the absence of a support contract. Mitigation: pin the version in composer.json, and vendor a fork under our org if upstream goes quiet — the MIT license permits this and the surface area is small enough to make it credible.

Scaling. The load is per-editor write traffic on the drafts table, not read fan-out. Autosave cadence multiplied by concurrent composers gives the write rate; at typical forum concurrency this is trivial, but a short autosave interval on a large forum with many simultaneous composers is the one place this could show up as database pressure. The table grows with drafts per user and is not self-limiting — plan an index on user/discussion and a periodic cleanup of stale drafts. No horizontal scaling concerns; it scales with the database like everything else in Flarum.

Failure modes.

• Stale/orphaned drafts: drafts for deleted discussions or disabled users linger without a cleanup job; manifests as table bloat, not user-visible breakage.
• Composer conflict: another composer-modifying extension clobbers the autosave hook, producing silent data loss — the worst failure mode here, because users believe their text is saved when it is not.
• Browser storage exhaustion: the client-side mirror can hit quota on content-heavy drafts, causing autosave to fail quietly.
• Multi-tab/multi-device divergence: last-write-wins on the same draft can overwrite content; low frequency, high annoyance.
• Upstream abandonment: a future Flarum release changes composer internals and drafts break on upgrade; recovery is a community patch or our own fork, with a lead time measured in days, not hours.
• Privacy gap: drafts excluded from export/deletion flows creates a compliance exposure that surfaces during an audit rather than at launch.

Ramp-up. Minimal for operators — admin panel configuration, no new tooling. For engineers, roughly half a day to read the extension and understand its model and routes, plus the same again for the composer hook if we ever need to patch it. Documentation for end users is a short help-desk note on where drafts live and how long they persist. Overall: a low-cost, low-risk, low-differentiation feature whose main operational demand is that someone explicitly owns upgrade compatibility — name that owner before enabling it.