Likes Laravel Package

Product Decisions This Supports

• Engagement feature scope: build vs. reuse. flarum/likes gives you post-level "like" reactions out of the box — like/unlike state on each post, a per-post like count, a liked flag for the current user in the post API payload, permission gating, and notifications to the post author. If your product is a community, support forum, or feedback board, this is a scope item you can check off for $0 instead of speccing a reaction system.
• Roadmap sequencing for community loops. Likes are the cheapest first-order engagement mechanic and the substrate for several later features: "top/best answer" ordering, reputation or trust scores, digest emails ("your post got 12 likes"), and moderator triage. Adopting it early creates the event stream and data model that those roadmap items depend on.
• Moderation and content-quality signals. Aggregated like counts are a low-cost proxy for content quality and can feed sort orders, "helpful" badges, or escalation rules — a decision point when evaluating whether to invest in a ranking/recommendation effort.
• Platform selection input. Because this ships bundled with Flarum core, the existence and quality of bundled engagement primitives should be scored in any "Flarum vs. Discourse vs. build-on-Laravel" evaluation. It shifts the calculus toward adoption by removing 1–3 sprints of engagement work.
• Deprioritizing custom reaction systems. If the product ask is "reactions," this covers the MVP. A decision to build multi-emoji reactions, per-reaction analytics, or reaction-driven reputation should be made explicitly after validating that single-signal likes are insufficient.

When to Consider This Package

Consider it when:

• You are already running Flarum, or are selecting Flarum as your community platform. In that case the extension is bundled — you enable it in the admin panel rather than installing it, and the decision is a configuration toggle, not a procurement.
• You need standardized, permission-aware engagement with minimal design cost: guest/member permissions, notification wiring, and API endpoints are already coherent with the rest of the platform.
• You want to stay on the platform's maintained upgrade path. This repo is a read-only subtree split of the extension inside Flarum's core monorepo; versions track core releases, and MIT licensing removes legal friction.
• You need a baseline engagement signal before investing in analytics or ranking infrastructure.

Look elsewhere when:

• You are not on Flarum. Despite the PHP/Laravel lineage in Flarum's foundations, this is not a drop-in Laravel package. It is coupled to Flarum's extension contract, models, authorization system, and Mithril/JS frontend. Porting it is a rewrite, not an integration. For a general Laravel app, evaluate cybercog/laravel-love or overtrue/laravel-like instead.
• You need multiple reaction types, emoji sets, or per-reaction reporting. Look at dedicated third-party Flarum reaction extensions rather than extending this one.
• You need analytics-grade, immutable engagement events (for experimentation, cohorting, or ML features). Likes here are state, not an event pipeline; you would need to add instrumentation.
• You need engagement that is portable across platforms — a SaaS community tool, a headless setup, or a migration path off Flarum.
• Health signals are your gate. The 18-star count is not a signal of package quality: this repository is a distribution mirror, and the canonical code and community live in Flarum's core repo. Evaluate the platform's release cadence and issue activity, not this repo's metrics. Also independently verify the listed release date before committing to a version pin.

Operational caveat for engineering: do not fork or open PRs against this repo. Contributions go upstream to the Flarum core monorepo; this split is generated. Pin the extension version in lockstep with core and plan a regression pass for major-version upgrades.

How to Pitch It (Stakeholders)

For executives: This is not a purchase decision — it is a free, MIT-licensed engagement feature that already ships with the Flarum community platform. Enabling it adds likes, author notifications, and permission controls to our forum without new spend, new vendors, or new headcount. It removes a roadmap item (post reactions) from the backlog and creates the engagement data we would otherwise have to build and maintain. Risk is low and reversible: it is a toggle, and it is maintained as part of Flarum core rather than by a third party. The low star count on this repository is a mirror artifact, not an indicator of abandonment — diligence should be done on Flarum core's release cadence, which we should confirm before we commit.

For engineering: Treat this as a bundled core extension, not an external dependency. The repo is a read-only subtree split published for Composer resolution; the source of truth is Flarum's core monorepo, so all patches go upstream. It provides the likes data model, per-post counts and current-user liked state in the API, authorization integration, and author notifications on the existing extension surface. The real work is not integration — it is deciding whether we need anything beyond a single boolean signal, and instrumenting like events if product wants them for analytics. Budget effort for version pinning against core and a regression pass on major upgrades, and skip it entirely if we are not on Flarum.