Download the PHP package oh-deer-bundles/smart-export-bundle without Composer

Smart Export Bundle

Configurable, on-the-fly data export for Symfony applications. An admin UI lets you define export engines (one per entity you want exportable, e.g. Customer) and their columns (including columns reached through relations, e.g. addresses.city), with per-column filtering, default values, and visibility rules. The result is embeddable in any host page via a single Twig function, smart_export_popup(), which lazily loads its own assets and content only when a user actually opens it.

This README covers installation, configuration, integrating the popup into your own Twig templates, and a walkthrough for building your first export. Keep it open during setup — it's written to not skip steps.

Requirements

• PHP >= 8.2, Symfony 7.4 (config, dependency-injection, form, http-foundation, orm-pack, security-bundle, string, validator)
• Doctrine ORM
• phpoffice/phpspreadsheet (for the Excel export format and the data-structure reference file)

Installation

1. Require the bundle

If you're consuming it as a local path repository (as this monorepo does), add it to your app's composer.json first:

2. Register the bundle

config/bundles.php:

3. Map the bundle's entities

config/packages/smart_export.yaml:

4. Import the routes

config/routes/smart_export.yaml:

All routes are prefixed accordingly — with the example above, the admin index is /smart-export/admin/.

Secure the admin routes yourself — this bundle has no opinion on authentication/authorization. Restrict at least everything under your prefix in your firewall's access_control, e.g.:

5. Run the migration

The bundle ships entities, not migrations — generate one in your app the normal way:

Configuration reference

All keys are optional; shown values are the defaults.

Creating your first export

1. Look up your data structure

From the admin index (/smart-export/admin/), click Download data structure. This generates an Excel sheet listing every Doctrine entity in your app, its properties and their types, and its associations (target entity, relation type, inverse property). Use it to pick your pyramid-tip entity — the one export rows are built from — and the path to any related data you want to include.

For example, exporting customers with their address's city: the tip is Customer, and the sheet tells you Customer has an association to Address (property addresses), which itself has a city property.

2. Create the engine

Click New Export and fill in:

• Name / Code / Description — free text, for your own reference.
• Related entity — pick your pyramid-tip entity from the dropdown (populated from every Doctrine entity in your app, by short class name — Customer, not the FQCN App\Entity\Customer\Customer).

Saving redirects you to the edit page.

3. Add columns

Each column maps to one exportable field. Click Add column and set:

Reorder columns with the ↑/↓ arrows — this is also the export's column order. Save when done.

4. Try it

Click Demo export (the eye icon) on the index. The popup opens with your Filtres → Colonnes → Format wizard exactly as an end user would see it, including the row-count check before generation. Once you're happy with it, the edit page's Voir le code button gives you a ready-to-paste Twig snippet, real uuid included, for embedding it in your own app (see below).

Integrating into your app (Twig)

Render a trigger anywhere in your own templates:

This prints a plain, unstyled link plus a lazy popup shell — no CSS/JS is loaded until the first call on the page, and the popup's own content (columns, filters, distinct values) is fetched only when a user clicks the trigger.

Options

smart_export_popup(uuid, label = null, options = [])

Example: a Bootstrap-styled download button

Backing up and promoting exports between environments

On an engine's edit page, Exporter downloads a minimal JSON snapshot (header + columns). Importer (on the index page) reads one back in: it's always parse → preview → explicit confirm, never a one-click write. Re-importing a file whose uuid already exists on the target updates that engine in place (its columns are fully replaced, not merged); otherwise a new engine is created, keeping the file's own uuid when possible — so promoting an export from one environment to another, then re-importing it later after changes, keeps working with the same uuid your Twig code already references.

Restricting rows per user

If some entity in your export graph needs per-user row-level access control (e.g. only the customers a given user is allowed to see), list it under security.restricted_entities and implement AllowedIdsVoterInterface:

AllowedIdsResolver calls your voter on demand — never via a login event — and caches its result per user for security.allowed_ids_ttl seconds. The restriction applies wherever the entity appears in an export's join graph, not just when it's the tip entity, and composes with (never bypasses) the id Twig option above. Without a configured ids_voter, a restricted entity grants no access to anyone (fail closed) — this is deliberate, not a bug: set ids_voter as soon as you add anything to restricted_entities.