Plugins Bundle Laravel Package

Getting Started

Do not treat this as an installable dependency in a Laravel app. The realistic first step depends on which of two situations you are in.

If you have a legacy Symfony2/Sylius codebase that already references it:

1. Read the bundle in this order — SyliusPluginsBundle.php, then DependencyInjection/SyliusPluginsExtension.php, then Resources/config/services.xml. The extension file is the actual public surface: it lists the plugin manager/registry service and any console commands. The README is thin; the code is the documentation.
2. Register it in app/AppKernel.php:

   new Sylius\Bundle\PluginsBundle\SyliusPluginsBundle(),
   

3. Clear the cache immediately (app/console cache:clear). Symfony2's container is compiled, and stale cache is the number-one cause of "the bundle does nothing."
4. First use case — inspect, don't install: run app/console list and look for sylius:plugins:*. If no command exists, resolve the manager directly and dump the list:

   $plugins = $container->get('sylius.plugins.manager')->getPlugins();
   

If you are on Laravel (the likely case):

1. Clone the repo read-only. Do not add a repositories entry or a require line — the composer.json targets PHP 5.x/7.0 and Symfony 2.x, and resolution against Laravel 9+ on PHP 8.1+ will hard-fail before you reach any runtime error.
2. Timebox a 1–2 day prior-art read and produce a one-page spec: manifest fields, discovery rules, lifecycle states (installed / enabled / disabled / update-available), resource conventions.
3. First use case is the manifest schema — that is the only artifact worth lifting. Everything else (kernel registration, container extension, Resources/ layout) is Symfony2-specific and does not translate.

Implementation Patterns

Composer-as-registry. The core idea: a "plugin" is a Composer package that also declares one or more Symfony bundles. The manager enumerates installed packages and filters by that declaration. If you use it at all, use it as a read-only registry — iterate plugins to build admin menus, dashboards, or feature flags. Never treat it as an installer; there is no maintainer to fix a broken install path.

Kernel registration loop. Symfony2 has no runtime bundle registration, so plugins still need a line in AppKernel.php. The day-to-day pattern is a guarded loop that asks the manager for bundle classes:

foreach ($this->getPluginBundles() as $class) {
    if (class_exists($class)) {
        $bundles[] = new $class();
    }
}

Order matters — respect any declared dependency order, not alphabetical. A plugin that boots before its dependency will fail on container compile, which surfaces as a cryptic service-not-found, not a plugin error.

CLI-driven observability. The highest-value use of a 14-star archived bundle is auditing, not automation. Wire plugin inspection into your deploy script: on each deploy, dump the active plugin list + versions to a log or dashboard. That gives you a diffable record of what changed between releases — genuinely useful during a migration.

Per-plugin configuration. Plugin config typically flows through the bundle's DI extension (load, then prepend/merge). Copy the shape of this into Laravel as a PHP config file per plugin, merged in a PluginServiceProvider or a dedicated PluginManager singleton.

Laravel translation (the build path). Reimplement natively rather than porting:

• Discovery: read vendor/composer/installed.json or use Composer\InstalledVersions and filter on an extra.laravel-plugin manifest key. This mirrors the bundle's Composer-as-registry model without any Symfony coupling.
• State: a plugins table (name, version, enabled, installed_at) so enable/disable is a DB flag, not a kernel edit. This is strictly better than the Symfony2 model, where "disable" means editing AppKernel.php.
• Registration: a single PluginServiceProvider that iterates enabled plugins and calls register() / boot() on each plugin's provider, respecting declared dependencies.
• Resources: use Laravel's loadViewsFrom / loadTranslationsFrom / loadRoutesFrom with publishable assets (--tag) instead of Symfony's Resources/config|views|translations convention.
• Manifest: keep it declarative (name, version, provider, requires, priority) so third parties can ship a plugin without touching your code — the one design idea worth carrying over verbatim.

Gotchas and Tips

• Composer will fail before anything else. Expect a hard conflict on php and symfony/* constraints. Do not reach for --ignore-platform-reqs — running unpatched Symfony2 code on PHP 8 is undefined behavior, not "mostly working."
• "Disable" is a code change, not a flag. In Symfony2 the bundle list is compiled into the container; toggling a plugin at runtime is impossible. Any admin UI showing a toggle is cosmetic unless it rewrites the kernel or the container. This is the single biggest thing to fix if you rebuild.
• One broken plugin kills the boot. A missing bundle class or a compile-time container error takes down the whole kernel — including your admin, which is where you would have gone to fix it. Guard registration with class_exists() and keep a hardcoded allowlist you can fall back to.
• Stale container cache masks changes. After any kernel or config edit, clear cache and warm it. Also note bundle order affects which service definition wins when two plugins define the same id.
• Check for outbound network calls before running it. Bundles of this class often phone home to a plugin registry to list or fetch artifacts. If that endpoint is dead the feature is broken; if it unpacks remote code you have an unsandboxed RCE surface with no maintainer to triage a CVE. Grep for Guzzle/file_get_contents over HTTP in the source first.
• Service IDs are not a stable API. Pulling sylius.plugins.manager from the container works in Symfony2; if you ever try to port that call into a modern Symfony or Laravel container, the service may be private or the ID gone entirely. Depend on an interface, not a string ID.
• Translation/route namespace collisions. Two plugins shipping the same domain or route prefix will silently overwrite each other. Namespace per plugin (plugin.{name}.*) from day one.
• Do not copy Sylius assumptions into Laravel. Doctrine resource config, Sylius container parameters, and Sylius core classes have no Laravel equivalent. Partial extraction is how you inherit confusing runtime errors months later.
• Forking is a permanent commitment. "Vendor it and patch" quietly converts a zero-cost read into permanent ownership of an EOL Symfony2 component. Pin it in the lockfile, flag it for migration, and if you must patch, keep a shim so the real fix is replacement.
• Extension point worth keeping: the manifest → registry → lifecycle-state triad. Everything else is scaffolding you should reimplement in a few days natively rather than maintain for years.