fof/discussion-views
Adds view counters to Flarum discussions, tracking how many times each thread is viewed and displaying the count in discussion lists and on the discussion page. Helps community admins gauge interest and surface popular topics. Simple to install and configure.
Architecture fit. This is not a general-purpose Laravel package — it is a Flarum extension (fof/discussion-views) that adds per-discussion view tracking to a Flarum forum. Architecturally it is still PHP/Composer-native and Flarum is built on Illuminate components, so the toolchain, service-provider patterns, and migration style are familiar to a Laravel team. But the fit is binary: if the target system is a Flarum forum, it slots in cleanly as a first-party-style extension; if the target is any other Laravel application, fit is zero and the only reusable asset is the design pattern (counter column + increment-on-read + optional dedupe), which is a few hundred lines to replicate.
Integration feasibility. Mechanical and low-effort: require via Composer, enable through the Flarum admin panel or extend.php, run migrations. The integration surface is deliberately small — an event subscriber or middleware on discussion views, a persistence target, and likely a serializer attribute to expose the count to the frontend. There is no queue, no external service, no credential provisioning. The realistic effort is not in wiring it up but in deciding whether the counting semantics match what the product needs.
Technical risk. High relative to the value delivered. One star and zero dependents means no observable production validation and no downstream ecosystem pressure to keep it correct. Friends of Flarum is a recognizable name within the Flarum ecosystem, which is a mild positive signal on intent, but it does not substitute for adoption evidence. The stated last release of 2026-10-23 is a future date, which in a scoring dataset usually indicates a metadata or clock artifact — treat the release provenance as unverified until you inspect the actual tags and commit history. The code is MIT, so the escape hatch is real: worst case you fork it. The genuine risk is silent semantic failure (counts that are wrong but plausible) and abandonment against a future Flarum core upgrade.
Key questions.
discussions table row (lock contention on hot threads) or a separate counters table?flarum/core constraints and PHP versions are supported, and is Flarum 2.x on the roadmap?Stack fit. Adopt only inside a Flarum deployment. There it is a natural fit — Composer-managed, migration-driven, no runtime dependency beyond the forum's own database. If view analytics are needed in a separate Laravel product surface, do not couple the two applications through this extension; read the counter out via the forum's API or a replicated read, and keep the analytics logic in your own codebase where you control the semantics.
Migration path. Treat the upstream repository as a source, not a dependency. Vendor it into a private VCS or a Composer path repository and pin to a specific commit SHA rather than a floating version constraint — with one star, you want immutability and a clear diff surface when you patch. If you already track views through another mechanism, plan a one-way backfill decision up front: either accept a discontinuity in the metric or write a reconciliation script, but do not let two counters coexist ambiguously.
Compatibility. Verify three things before writing any code: the flarum/core version constraint against your pinned core, PHP version against your runtime image, and database support (MySQL vs. Postgres) for whatever the migration does. Confirm the migration is reversible in staging — a non-reversible schema change on a live forum is the most likely way this gets painful.
Sequencing. Run a two-to-three day spike in a staging forum with realistic traffic shape, then make an explicit build-versus-adopt call. Given the near-zero adoption signal, a small in-house counter is a legitimate outcome and often the lower-total-risk choice; adopt only if the spike shows the semantics (dedupe, async writes, serializer exposure) are already what you need and would take longer to reimplement than to own.
Maintenance. Assume you own it from the day you install it. Budget for an annual review against Flarum core upgrades and a fork-and-patch path for security fixes. This is not a large ongoing cost — the code is small — but it is a permanent line item, not a one-time install.
Support. No commercial support, no SLA, no guaranteed issue response. Escalation is the public Flarum community forum plus your own engineers. Factor that into any incident runbook that references view counts.
Scaling. View counting is a write-path concern, and this is where a small extension can hurt a large forum. The failure shape to watch for is synchronous writes on every discussion read, which converts a read-heavy workload into a write-heavy one and can produce row-level lock contention on your hottest threads. If the spike shows synchronous increments, plan for a Redis or buffered-counter layer with periodic flush, or restrict the feature to discussions above a traffic threshold.
Failure modes. Ranked by likelihood: counter drift from bot and crawler traffic; silent breakage after a Flarum core upgrade with no maintainer to patch it; lock contention on popular discussions; a schema change that is awkward to roll back; and — lowest probability but highest cost — an unpatched vulnerability in an abandoned dependency that forces an emergency fork.
Ramp-up. Low for anyone who has touched Flarum or Laravel: half a day to read the extension end to end, one to two days to stand it up in staging with meaningful traffic and validate the counting semantics. The engineering ramp is trivial; the organizational ramp is the real cost — someone must be named as the owner of this fork and its upgrade cadence before adoption, or it becomes orphaned infrastructure six months out.
How can I help you explore Laravel packages today?