Sylius Bulk Edit Plugin Laravel Package

Getting Started

Install and register the bundle.

composer require setono/sylius-bulk-edit-plugin

Then register it in config/bundles.php:

Setono\SyliusBulkEditPlugin\SetonoSyliusBulkEditPlugin::class => ['all' => true],

The bundle ships with no database migrations of its own (it operates on existing Sylius resources), so bin/console doctrine:migrations:migrate is usually a no-op — but run it anyway if you're on an existing install to confirm nothing was added.

Where to look first. Given the project's size (3 stars, negligible adoption), don't treat the README as authoritative — read the source:

• src/ — the bulk-edit action(s), form types, and the service that actually mutates variant prices.
• src/Resources/config/ — service wiring, grid overrides, and where the admin action gets attached to the product grid.
• src/Resources/translations/ — the labels you'll want to override if you localize your admin.

First use case. Log into the Sylius admin, go to Products, select several products via the grid checkboxes, and look for the bulk action dropdown that the bundle adds (typically a "Bulk edit prices" entry). Choose your operation (percentage change / fixed amount), pick a channel if prompted, apply, and verify a couple of variants on the product edit page. This is the intended happy path — confirm it works end-to-end before building anything on top of it.

Implementation Patterns

Treat it as an admin-UI convenience, not an API. The plugin is built around the Sylius grid bulk-action system. The pattern it establishes is:

1. Grid bulk action collects selected product IDs.
2. A form collects the edit parameters (operation type, amount, channel).
3. A service iterates the products → their variants → their ChannelPricing rows and applies the change in a single flush.

If you need to change prices programmatically (imports, scheduled jobs, ERP sync), don't try to reuse the UI action — replicate the loop against ChannelPricing directly, or better, extract the plugin's price-service into your own service and call it. That's the most valuable thing this package gives you: a working reference for "apply a delta to every variant's channel pricing across N products."

Common day-to-day workflow — seasonal repricing. Merchandisers select a product page (or filter the grid first, then select all), apply a +10% bulk edit for a season, and verify. Because the bulk action operates on whatever the grid selection is, combining it with Sylius grid filters (taxon, enabled, brand) is the real power: filter to a taxon, select all, apply the delta. Encourage your team to use filters before selecting rather than hand-picking rows.

Extending with your own bulk action. The Sylius pattern is to register an action service tagged for the grid and point the grid definition at it. If Setono's plugin doesn't expose a clean extension hook for additional operation types (percentage, fixed, set-to-value), the pragmatic approach is to add your own bulk action service alongside it, reusing the plugin's price-application service. Copy the plugin's action class as a template.

Integration tip — audit logging. Bulk price edits are a classic "who changed this?" problem. Wrap or decorate the plugin's price service with a decorator that logs product ID, variant ID, old price, new price, and the acting admin user. Sylius doesn't do this for you, and once prices are overwritten the old value is gone.

Permissions. Gate the bulk action behind the standard Sylius product-update permission (sylius.product.update) if the plugin doesn't already — bulk editing is a high-blast-radius operation and shouldn't be available to every admin user who can view products.

Gotchas and Tips

Very low maintenance signal. Three stars and effectively zero dependents means: expect no upstream fixes, assume compatibility only with the Sylius version it was tested against (check composer.json constraints before upgrading Sylius), and plan to fork if you rely on it. Pin the version.

Prices live on variants, not products. Sylius stores pricing on ProductVariant → ChannelPricing, per channel. Any confusion about "editing the product price" usually means a multi-channel setup where only one channel's pricing got updated, or a product with multiple variants where you expected all of them to move — verify the plugin iterates variants correctly on multi-variant products before trusting it in production.

Multi-channel is the #1 pitfall. If your store has more than one channel, a bulk edit that doesn't explicitly scope to a channel will either miss channels or (worse) apply the same delta to every channel, destroying channel-specific pricing. Test with a two-channel fixture.

Rounding and negative prices. Percentage deltas produce fractional cents; Sylius stores prices as integers. Watch for rounding drift after repeated edits (a +10% then -10% does not return to the original). Also guard against a fixed-amount reduction driving a price below zero — the plugin may not validate this.

No dry-run / no undo. Assume there is none. Before a large bulk edit, take a database snapshot or export ChannelPricing for the affected products. This is the single most important operational habit with this plugin.

Debugging. Sylius bulk actions are notoriously opaque when they silently do nothing — the usual causes are (a) the grid definition isn't overridden with the action, (b) the bulk action service isn't tagged/registered, or (c) the form fails validation and the flash message is suppressed. Use bin/console debug:container to confirm the action service exists, and check the Symfony profiler's form panel on the grid page.

Translations and UI labels. Override the bundle's translation keys from your app's translations/ directory rather than editing vendor files, so a composer update doesn't wipe your changes.

Best suited as a fork. For a long-lived project, the highest-leverage move is to vendor a copy of the price-application service into your own codebase and wire your own admin action to it. That gives you test coverage, audit logging, channel scoping, and dry-run capability — none of which you should count on this package for.