Split Laravel Package

Technical Evaluation

Framing correction (important for scoping): fof/split is not a Laravel package. It is a Flarum extension — a Composer package that plugs into Flarum's extension API, which itself is built on Laravel/Illuminate components (illuminate/support, illuminate/database, illuminate/validation). It is not installable into a Laravel application, and it exposes no service provider, facade, or config file for a Laravel host. Everything below treats it as a PHP/Composer dependency inside a Flarum forum, which is the only architecture it fits.

Architecture fit. The extension adds a single moderation capability: take one or more posts out of an existing discussion and move them into a brand-new discussion, with the split posts re-parented and the original discussion left intact. Architecturally this is the right shape for the problem — it is a thin orchestration layer over core Discussion/Post models plus a frontend control in the post stream (Flarum's Mithril-based UI). It does not introduce its own tables, entities, or persistence layer, which keeps the integration surface small and the coupling to core high-but-shallow. That is the correct trade-off for a workflow utility: it will break on major core upgrades rather than silently drift.

Integration feasibility. High, with the usual caveats. Install is composer require fof/split, enable via php flarum extend, run migrations (none expected of consequence), clear cache. Authorization is expected to follow Flarum's policy/gate model, so the main configuration work is a permission matrix (who may split posts) rather than code. The realistic integration effort is measured in hours, not weeks, for a team already running Flarum.

Technical risk. Low blast radius, moderate longevity risk:

• Blast radius: a failed split breaks a moderator action, not the forum. No write path touches unauthenticated users. No new attack surface beyond the permission gate.
• Longevity: 12 stars, 0 dependents, single-maintainer FriendsOfFlarum pattern. This is the dominant risk, not correctness. Mitigation is strong: MIT license and a codebase small enough to audit and vendor in under a day.
• Data integrity: the real risk is not code failure but incomplete domain side effects — search index entries, tag assignments, subscription/notification state, and read-state for the moved posts. These are the things a split must handle and the things most likely to be silently wrong.
• Release metadata anomaly: the listed last release (2026-10-23) is in the future relative to normal reporting; treat the version/date pair as unverified until confirmed against Packagist and the repo tag list.

Key questions to resolve before committing:

1. What flarum/core constraint does the current release declare, and does it cover our pinned core version (1.x vs 2.x)?
2. Does the split reindex moved posts for search, and does it preserve or intentionally drop tags, recipients, and followed-state?
3. Is the permission granular enough to delegate "split" without granting broader moderation rights?
4. How does it behave on very large discussions (thousands of posts) — is the move transactional?
5. Is there an audit trail (who split what, when) and does it survive the operation?
6. Are translations and RTL covered, and is the frontend asset pipeline compatible with our build?

Integration Approach

Stack fit. Fits a standard Flarum deployment: PHP 8.x, MySQL/PostgreSQL/SQLite via Illuminate, Composer-managed extensions, asset compilation through Flarum's frontend. No additional infrastructure, no background workers, no external services. For a Laravel shop, the code will read as familiar — Eloquent models, event subscribers, policy classes — which lowers the review cost materially.

Migration path.

1. Pin the exact version in composer.json; do not float. Record the resolved tag and its flarum/core constraint.
2. Stand up staging from a production database dump (anonymized) — split behavior is data-dependent and cannot be validated on an empty forum.
3. Install, enable, run migrations, rebuild assets, clear cache.
4. Configure the permission matrix and confirm it maps to existing moderator roles rather than creating new ones.
5. Seed staging with representative edge cases: a 2-post discussion, a 500+ post discussion, a tagged discussion, a discussion with a poll/attachment, a discussion with restricted recipients.
6. Execute split scenarios and verify post-split invariants: original discussion intact, new discussion correct author/timestamp, search finds moved posts, tags behave as specified, no duplicate notifications.

Compatibility. Low conflict risk given the absence of schema changes, but the real compatibility question is coexistence with other FoF extensions commonly deployed alongside it (tags, approval, sticky, discussions). Test the combined set, not the extension in isolation. The frontend control is injected into the post stream, which is the most likely place for UI collisions with other post-stream modifications.

Sequencing. Treat this as a two-track rollout: technical (pin → staging → edge-case validation → production enable behind permission) and organizational (write the moderator runbook → train → announce). Do not enable the permission for all moderators on day one; pilot with two or three, watch for the failure modes below, then widen. If the package fails validation, the fallback is a 1–2 day internal build or a vendored fork — the codebase is small enough that "replace" is a genuine option, which caps the downside of the whole decision.

Operational Impact

Maintenance. The maintenance burden is dominated by core upgrade compatibility, not by bug fixing. Budget an explicit re-validation task each time flarum/core moves a major version. Because the codebase is small and MIT-licensed, the standing posture should be: consume upstream while it is maintained, fork on first sign of abandonment. Vendoring cost is low enough that this is a controlled risk rather than a dependency gamble.

Support. The feature is moderator-facing, so support load is user-facing, not infrastructure-facing. Expect questions about "where did my post go" — the split creates a new discussion and moderators need a consistent way to leave a redirect/notice. Publish a short runbook: when to split, how to name the new discussion, whether to leave a pointer in the original thread, and how to reverse a mistake. Reversal is the weak spot — confirm whether an undo path exists or must be done manually.

Scaling. Negligible steady-state cost: splits are rare, human-initiated, and bounded. The only scaling concern is a single large operation on a very long discussion — a multi-thousand-post move can be a long transaction with lock contention on a busy forum. Mitigate by confirming the operation is transactional and, if not, by restricting splits on very large discussions or scheduling them off-peak.

Failure modes to instrument:

• Partial split: posts moved but the original discussion left in an inconsistent state (orphaned or duplicated).
• Search drift: moved posts unfindable, or old URLs/links 404 without a redirect.
• Metadata loss: tags, recipients/access restrictions, or poll/attachment associations dropped on move — this is a confidentiality risk if a restricted discussion's content lands somewhere less restricted.
• Permission leakage: split capability bundled with broader moderation rights.
• Stale frontend assets: control missing or duplicated after deploy because assets weren't rebuilt.
• Silent abandonment: no upstream activity, next core upgrade breaks the extension with no patch forthcoming.

Ramp-up. For an engineer: half a day to read the extension end-to-end and confirm the side-effect checklist above; roughly a day to validate in staging. For moderators: a one-page runbook and a 15-minute walkthrough. Total organizational lift is small — which is the honest read on this package. It is a narrow, well-shaped utility with real but bounded value; the decision it deserves is not "is this strategic" but "is a 1–2 day adopt-and-fork-check cheaper than building it ourselves," and at this scope the answer is almost always yes, provided the data-integrity questions in the Technical Evaluation are answered before production enablement.