Sylius Bundle Laravel Package

Getting Started

Check compatibility before anything else. This bundle's last tag is from November 2015, which places it in the Sylius 0.15–0.17 / eZ Publish 5.x era. Open composer.json in the repo and read the require block: the Sylius, Symfony, and ezsystems/* constraints it pins are the single most important piece of information about whether it can be installed at all. If you are on Sylius 1.x/2.x or Ibexa, the answer is almost certainly no without a rewrite.

Assuming you are standing up a matching legacy stack (or forking):

1. composer require xrow/sylius-bundle against the legacy dependency set. If resolution fails, clone the repo and add it as a path/VCS repository with --no-update to see the real conflict.
2. Register the bundle the 2015 way — AppKernel::registerBundles(), not config/bundles.php. Typical entry is new xrow\SyliusBundle\xrowSyliusBundle() or the namespaced equivalent declared in the class file; confirm the exact FQCN from the src/ tree before editing.
3. Import the bundle's routing if it ships Resources/config/routing.yml.

Where to look first, in order:

• composer.json — version constraints (see above).
• DependencyInjection/*Extension.php — the config tree tells you every knob the bundle exposes.
• Resources/config/services.yml — the service IDs are your integration surface; everything you'd override or decorate is listed here.
• Resources/views/ / Resources/translations/ — any Twig or eZ template helpers it provides.
• README.md if present; given the star count, assume it is thin or absent.

First use case: rendering a Sylius product list or product detail inside an eZ content view. The bundle exists to be the glue between Sylius's product/catalog model and eZ's content model, so a product page rendered through an eZ template is the canonical "hello world." Build that one page end-to-end before trusting anything else in the bundle.

Implementation Patterns

• Reference implementation, not a dependency. With one star and zero dependents, nobody is exercising this code. Vendor it (fork into src/ or a private package) and treat upstream as frozen. Do not expect security or version PRs.
• Service decoration over forking. Where the bundle defines services in Resources/config/services.yml, decorate or alias those IDs in your own services.yml rather than editing vendor code. Keep the vendor tree replaceable.
• Config-tree extension. Most of the bundle's behavior will be driven through its Configuration class. Read the tree, then set values in config.yml under the bundle's root key. Anything not exposed there will require a compiler pass or service override.
• eZ template integration. Expect to call into the bundle from eZ view layers rather than the other way round. Register the bundle's Twig namespaces / helpers where your eZ templates can see them, and keep the boundary thin: fetch Sylius data in a controller or Twig extension, pass plain arrays into the eZ template.
• Sylius resource configuration. If the bundle adds Sylius resources, register them in your config.yml under sylius_* keys before enabling the bundle's services, or you will get "resource not found" at container compile time.
• Isolated test harness. Stand up a fixture app with a single product and a single eZ content object. Because the bundle has essentially no test coverage, your harness is the regression suite; add a smoke test per integration point as you wire it.
• Migration escape hatch. If you are on a modern stack, the realistic pattern is: read this bundle for the shape of the Sylius↔eZ (or Sylius↔Ibexa) bridge, then reimplement the glue directly against the current Sylius resource/event system. Budget for that rather than fighting composer resolution.

Gotchas and Tips

• Abandonment is the headline gotcha. No release since 2015, one star, zero dependents. Assume zero upstream support; pin the exact commit in your lockfile and document the fork in your README.
• PHP and Symfony drift. 2015-era bundles routinely declare php: >=5.5 and Symfony 2.x services that are private-by-default or removed in 3.x/4.x/5.x. Watch for scope: keys in service definitions (removed in Symfony 2.8+) and container-aware base classes.
• Bundle registration API changed. AppKernel vs bundles.php; also the automatic bundle inheritance rules differ. If the bundle relies on getParent(), check it still resolves.
• DI visibility. Services defined in the bundle are private under modern Symfony. Inject them or alias them — don't $container->get('xrow...') from a controller; it will throw.
• Debugging toolkit: bin/console debug:container --tag=…, debug:config <bundle_alias>, lint:yaml, and debug:router are your fastest path to what the bundle actually registered. If the container fails to compile, the offending service ID is usually named in the exception.
• Config quirks. Many 2015 bundles use semanticConfig with ->cannotBeEmpty() on required nodes; a "missing child node" error means you skipped a required block in config.yml. Check the Configuration::getConfigTreeBuilder() method for the exact shape.
• Extension points that are safe: the bundle's config tree, service decoration by ID, and event listeners on whichever Sylius/eZ dispatchers it hooks. Not safe: sub-classing the bundle's own classes — they were not written with inheritance in mind and likely have no final/protected discipline either way.
• Logging. If the bridge silently fails to render, add a kernel.exception listener at debug level and check the eZ content-view cache — stale eZ caches after a bundle change are a common cause of "nothing happened." Clear ezpublish/var/cache manually, not just Symfony's.

Bottom line for day-to-day use: unless you are maintaining a specific legacy Sylius 0.x + eZ Publish 5 installation, this is a reading reference, not a package you will composer require. Plan for a fork-and-own maintenance model, or a reimplementation on current Sylius/Ibexa.