Akeneo Quickexport Configurator Laravel Package

Getting Started

Read this first: this is not a Laravel package. It's an Akeneo PIM module — a Symfony bundle you install into an Akeneo application. If you're a Laravel developer, you either (a) also maintain the Akeneo instance, or (b) consume Akeneo's exports/API from Laravel. The module itself does nothing inside a Laravel app; there is no service provider, no facade, no Laravel-style config.

Version scope (updated for v1.1.7): the current release declares support for Akeneo 7.x and 2026.x. Akeneo's year-based releases (2024.x, 2025.x, 2026.x) are the continuation of the 7.x line on a modern Symfony stack — the legacy majors (3/4/5/6) are no longer the target and the README/assessment guidance for them (e.g. AppKernel.php bundle registration) is stale. Confirm against composer.json constraints before installing.

Minimal path:

1. Install in the Akeneo app, not your Laravel app. Note the repo is published under the webkul vendor — verify you're requiring the real package:

   composer show webkul/akeneo-quickexport-configurator
   composer require webkul/akeneo-quickexport-configurator:^1.1.7
   

2. Register the bundle in config/bundles.php (the only registration path on Akeneo 7.x / year-based versions — no AppKernel):

   Webkul\QuickExportConfigurator\QuickExportConfiguratorBundle::class => ['all' => true],
   

3. Clear the container and cache:

   bin/console cache:clear --env=prod
   bin/console debug:container --tag=<module-tag>
   

4. Where to look first:
   • src/DependencyInjection/Configuration.php and .../…Extension.php — these tell you the real YAML keys and service IDs. Don't trust README snippets over this file.
   • src/Resources/config/ — service wiring, tag names, compiler pass registration.
   • The bundle class — confirms expected Akeneo version constraints.
5. Test on the version you actually run. "Supports 2026.x" in a single-line release note usually means a constraint bump; don't assume behavioral parity with 7.x until a smoke test passes on your instance.

First use case: you want the product grid's Quick Export modal to expose a custom configuration — an extra option, a preset filter, or a new export profile — without hacking a core Akeneo bundle. Register it through this module, verify it appears in the modal, run one export, and confirm the generated file lands where you expect.

Implementation Patterns

A. Tagged-service registration (most common). The module almost certainly exposes a tag or collection so you can register your own configurator/option provider without editing vendor code.

# config/services.yaml in your Akeneo app
services:
    App\QuickExport\CustomOptionConfigurator:
        tags:
            - { name: '<module-tag-from-Resources-config>' }

Confirm the tag exists before wiring:

bin/console debug:container --tag=<tag>

B. YAML option declaration. If the module's Configuration.php defines an options tree, the day-to-day win is declaring options in your app config rather than in PHP. Treat Configuration.php as the source of truth for key names and defaults.

C. Derive from an existing quick-export profile. Akeneo ships csv_product_quick_export / xlsx_product_quick_export (naming varies by version). Copy the vendor job YAML, adjust options, and register the derived profile through this module rather than editing the core file. This is the pattern that survives Akeneo upgrades — and it's what makes the 7.x → 2026.x jump survivable.

D. Laravel ↔ Akeneo handoff. After Quick Export produces a file, pick it up in Laravel from the filesystem, S3, or SFTP — or poll the job execution endpoint (GET /api/rest/v1/jobs/{jobCode}/executions). To trigger an export from Laravel, use the REST API (OAuth client + API enabled), never try to invoke Symfony services from a Laravel process. They are separate runtimes.

E. Prefer event subscribers / decoration over overriding the module's services — if it dispatches events or exposes interfaces, subscribe there so upgrades don't break you. This is extra important now that the module tracks two major lines: anything you decouple from its internals keeps working when the supported-version list moves again.

F. Multi-instance shops. If you maintain one Akeneo 7.x instance and one 2026.x instance, keep your custom configurators in your own namespace with the same tag wiring on both, and run the export smoke test (bin/console pim:job:execute <jobCode>) against each after every module bump.

Gotchas and Tips

• Container cache is aggressive. After any YAML or service change, run cache:clear and then debug:container. In prod a stale container is the #1 cause of "my option doesn't appear."
• Compiler pass ordering matters. Collection passes must run before the pass that consumes them. Check TYPE_BEFORE_OPTIMIZATION vs TYPE_AFTER_OPTIMIZATION if your tag isn't collected.
• Job profile vs job instance. Quick export generates a transient instance per execution; options are per-run. A misconfigured profile often shows no error until you actually trigger an export — test with bin/console pim:job:execute <jobCode> before debugging the UI.
• The v1.1.7 change is a compatibility claim, not a feature. It adds 2026.x alongside 7.x. There are no new options, no deprecations, and no migration steps — so nothing in your config needs to change, but nothing is proven either. Read the actual diff; if it's only composer.json constraints, treat 2026.x as "probably works" and prove it yourself.
• Verify the vendor/package name. The changelog points at webkul/akeneo-quickexport-configurator; older notes and forks used a personal namespace. composer show before and after requiring to avoid installing a stale fork.
• Akeneo version drift is brutal. Namespaces and bundle registration changed across majors. Pin the module version in composer.json and check its constraints against your PIM's Symfony/PHP versions before upgrading either side.
• Maturity risk is real. Small maintainer surface, thin release notes, and a restrictive/unclear license (NOASSERTION in metadata earlier — re-check the current LICENSE). Pin the exact tag, read the source, vendor a fork if you depend on it in production, and get license clarification before shipping.
• Debugging commands worth memorizing:

  bin/console debug:config <alias>
  bin/console debug:container --tag=<tag>
  bin/console pim:job:execute <jobCode>
  tail -f var/log/prod.log
  

• Extension points, in order of preference: compiler pass → service decoration → event subscriber → overriding vendor config. Avoid patching vendor/ — the next composer update erases it.
• Keep Laravel concerns separate. Don't try to share models, config, or auth between the Laravel app and Akeneo. Share files and API contracts, nothing else.