Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Gdpr Exporter Laravel Package

milenmk/laravel-gdpr-exporter

A Laravel package for GDPR compliance that helps you export a user’s personal data from your application. Configure data sources, generate downloadable exports, and fulfill data-access requests with minimal setup.

View on GitHub
Deep Wiki
Context7

Getting Started

Since this assessment has no prior baseline, treat 1.4.0 as the first version you evaluate. The 1.3.2 → 1.4.0 bump is a minor release under semver, so no breaking changes are signalled — but the changelog link is the only artifact published for this release, so skim the diff before upgrading a pinned install.

  1. Install into the app that holds the personal data (not a shared/Lander package):
    composer require milenmk/laravel-gdpr-exporter
    
  2. Discover the surface area before writing any code:
    • php artisan list | grep -i gdpr — confirms the command name(s) the package registers.
    • vendor/milenmk/laravel-gdpr-exporter/config/ — read the shipped config verbatim. In packages like this, the config is the API: it defines which models are exported, which columns/relations are pulled, and what is deliberately excluded.
    • vendor/milenmk/laravel-gdpr-exporter/src/ — check for a contract/interface or trait that models must implement, and whether exports are dispatched as queued jobs.
  3. Publish and version the config:
    php artisan vendor:publish --provider="Milenmk\GdprExporter\...ServiceProvider"
    
    Commit the published config so the exact scope of a data export is auditable — this is the document you show a DPO or regulator.
  4. First real use case: a subject access request (GDPR Art. 15). Point the config at your User model and its relations (orders, addresses, consents, logs), then trigger an export for a test account and open the generated file end to end.
  5. Immediately test the erasure side against the same account before going near production. Export is read-only and safe to trial; deletion/redaction is not.

Implementation Patterns

Model registration over ad-hoc queries. Drive the export from the config's model map rather than adding one-off ->toJson() calls. This keeps every export path funneled through the same declaration, so a request handled by a support agent produces an identical artifact to one handled by a console command.

Queue the job, don't inline it. A user with thousands of orders/audit records will blow past PHP's max_execution_time and memory limit inside an HTTP request. Wrap the export in a queued job and email a signed, expiring download link when it completes. If the package ships its own job class, extend it rather than reimplementing; if not, keep the package's exporter callable inside your own job so the file-generation logic stays in one place.

Two distinct workflows, one config. Treat export (Art. 15/20) and erasure (Art. 17) as separate operations even if they read the same model list. For erasure, most apps need redaction (null out PII, keep the row for referential integrity) rather than row deletion — decide per model and encode that decision in config, not in controller code.

Integration with audit logging. Log every export request (who, when, subject, which artifact hash). This is both a GDPR accountability requirement and your only way to debug "the export was missing X" after the fact, because the file itself has been handed to the data subject.

Consent and retention hooks. If you already have a consent table, make sure the export includes consent history (granted/withdrawn timestamps, source) — it is one of the most commonly omitted categories in a first implementation and one of the first things a DPO asks for.

Testing pattern. Use a factory-created user with a known, minimal data graph and assert the exported structure against a fixture. Assert on presence of keys rather than full-file equality, or the test suite will break on every unrelated migration.

Gotchas and Tips

  • Empty/summary changelogs. 1.4.0 ships no release body, only a compare link. Read the diff (git log --oneline 1.3.2..1.4.0) before upgrading, particularly the config file — if a new config key was added, your published (older) config will silently lack it and default behaviour may differ.
  • Published config drift. Once you publish the config it stops receiving package updates. Diff it against vendor/.../config/ on every minor bump; a new model or column added upstream will otherwise never appear in your exports.
  • Silent omissions. The most common production failure is under-exporting: a relation not listed in config, a hidden attribute on the model, or a select that never loads the column. Validate against a real account with realistic data, not a seeder.
  • $hidden and $casts interaction. Eloquent's $hidden protects API responses, but array/JSON exports respect it too — so a field hidden for security may vanish from the GDPR export as well. Check whether the package bypasses this via direct query or explicit column selection.
  • File storage and expiry. Export files contain the entire PII footprint of a user. Store them on a private disk (not public), encrypt at rest, and delete on a TTL (24–72h is typical). Confirm the package's default disk, since local in newer Laravel means storage/app/private while older installs pointed at storage/app.
  • Memory on relation-heavy exports. with() on a user with deeply nested history loads everything at once. Prefer chunked per-relation queries, and measure peak memory with memory_get_peak_usage() on a large test account.
  • Soft deletes and anonymised rows. Decide explicitly whether soft-deleted records are included in an export. Excluding them is often a compliance gap; including them can leak data you thought was erased.
  • Third-party processors. Data held in Stripe, Mailchimp, Sentry, etc. is not in your database and this package cannot see it. Your subject-access process needs a documented manual step for processor-held data — the package solves only the first-party half.
  • Extension point. If the package exposes an interface for custom exporters, implement it for models with non-standard storage (JSON columns, encrypted casts, polymorphic relations) rather than forking the package. Forking makes future minor upgrades — like this one — painful.
  • Not a compliance guarantee. The package produces a file; the lawful basis, identity verification of the requester, and the 30-day response clock are your application's responsibility.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox