Gdpr Laravel Package

Product Decisions This Supports

• Compliance scope for community products. The extension covers the three GDPR obligations that most often block a community launch: data portability (user-initiated data export), erasure (account deletion with anonymization of prior posts), and consent capture at signup. As a PM, this lets you scope "GDPR-ready" as a checkbox rather than an epic.
• Build vs. buy vs. already-have. This is the rare third case: it ships bundled with Flarum core, so the decision is not "adopt" but "configure and verify." That reframes the roadmap question from "do we build compliance tooling?" to "what does this not cover, and who owns the gap?"
• Enterprise/B2B sales unblocking. Security and privacy questionnaires from EU/UK prospects will ask for DSAR handling, deletion rights, and data export. Having a defensible, documented "yes, self-serve" answer shortens procurement cycles more than the feature's engineering cost suggests.
• Support-cost modeling. Self-serve export and deletion remove a recurring manual ops burden (email requests routed to an admin). Quantify this against your current ticket volume before deciding whether to invest further.
• Risk register entry. The package is a read-only subtree split — a distribution mirror, not an independent project. PM-level consequence: you cannot file issues, accept community PRs, or fork it meaningfully here. Roadmap dependency on this code means tracking the upstream Flarum repository and its release cadence, not this artifact's.
• Category hygiene / dependency inventory. Note that this is a Flarum extension, not a Laravel package. It is coupled to Flarum's extension lifecycle and event system and is not portable to a Laravel application. If it appeared in a Laravel dependency review, that is a taxonomy error worth correcting before it distorts a build-vs-buy analysis.

When to Consider This Package

Consider it when:

• You are running (or evaluating) Flarum as your community platform, and you have EU/UK users or B2B customers who ask about privacy rights.
• You want baseline, self-serve DSAR handling without standing up a consent-management vendor or writing custom export/deletion flows.
• You have limited privacy-engineering capacity and prefer a maintained, in-ecosystem baseline over bespoke code you must own indefinitely.
• You need deletion that anonymizes rather than hard-deletes, preserving thread integrity — a real product differentiator for forums where deleting a user shouldn't shred discussion history.

Look elsewhere when:

• You are not on Flarum. This is not usable in Laravel, Symfony, or any other PHP stack; there is no adapter path worth the effort.
• You need capabilities beyond baseline rights fulfillment: granular cookie/tracker consent management, consent versioning and re-prompting, retention-schedule automation, audit trails suitable for evidentiary purposes, DPIA workflow tooling, or data-residency controls. Those require a dedicated CMP or privacy platform.
• You require a vendor with an SLA, indemnification, or a support contract. This is MIT-licensed community code with a subtree-split distribution model.
• You treat community health (stars, issue activity, contributor count) as an adoption gate. Do not use this repository's 13 stars or its low composite score as a signal — it is an automated mirror; all real activity lives upstream. Evaluating it on mirror metrics will produce a false negative.

How to Pitch It (Stakeholders)

For executives (30 seconds): "The GDPR capability we'd otherwise have to build or buy is already included in our forum platform at no additional cost. It gives users self-serve control over exporting and deleting their data — the two requests that most often stall EU/UK deals and generate manual support load. There is no new vendor, no new contract, and no new infrastructure. The trade-off is that it's community-maintained baseline coverage, not a full privacy platform: if we later need enterprise-grade consent management or audit evidence, that becomes a separate, funded decision rather than a surprise."

For engineering: "This is a Flarum extension distributed as a read-only subtree split of the upstream monorepo — treat it as a mirror, not a fork target. Do not send PRs or open issues here; track Flarum core releases and pin versions accordingly. It hooks Flarum's existing extension lifecycle (event subscribers, migrations, permission model) and adds no new runtime dependencies or services. Integration surface is small: permissions for who can export/delete, plus anonymization behavior on user deletion — that anonymization path is the one piece worth a test, since it touches content ownership and moderation history. Two things to flag explicitly to product: it does not provide cookie/tracker consent, and it does not produce audit-grade logs. If compliance asks for either, that's net-new scope, not a configuration change."