README

Selective loader for the Shopware 6.7 Core framework. muckiware/core turns shopware/core into an application framework without commerce: it boots the DAL, DI container, events, message queue, Admin API, app system, flows, media and mail — but no Checkout, Storefront, SEO, currency or sales channel context.

It is the base layer of Muckidrive; muckiware/master (the customized administration) and all plugins in custom/plugins/ run on top of it.

shopware/core ~v6.7      ← original service definitions, entities, migrations (vendor)
muckiware/core           ← this package: decides which parts of shopware/core are loaded
muckiware/master         ← administration without shop modules
custom/plugins/*         ← project specific plugins

• Package: muckiware/core (type library, MIT)
• Namespace: Muckiware\Core\ (PSR-4, package root)
• PHP: 8.2 – 8.5
• Installed as composer path repository (custom/muckiware/*)

Contents

The bundles are registered in config/bundles.php instead of the Shopware Core bundles. Shopware\Core\Checkout\Checkout and the Storefront are intentionally not registered.

How it works

1. Hybrid service loading

Shopware ships its service definitions as PHP files (vendor/shopware/core/*/DependencyInjection/*.php). Instead of copying them, every Muckiware bundle loads a selected subset of the original vendor files and only describes its differences. This keeps constructor arguments in sync with the installed Shopware version when composer updates shopware/core.

Each bundle's build() follows the same sequence:

loadSWServices()      → PhpFileLoader on the vendor DependencyInjection folder (whitelist)
loadMuWaServices()    → XmlFileLoader on the bundle's own DependencyInjection/overrides.xml
ServiceOverrides::*   → remove unsupported services, swap classes, make services public
addCompilerPass(...)  → the Shopware compiler passes of that bundle + Muckiware specific passes

The vendor path is resolved by Helper::getFolderByClassName(), which reflects on a Shopware class (e.g. Shopware\Core\Framework\Framework) and walks up to the requested folder. Without a class name it resolves the project root (or PROJECT_ROOT from the environment, used by the admin build scripts).

Loaded Shopware service files

Framework::buildSWDefaultConfig() additionally loads the vendor package configuration (Resources/config/packages/*.yaml and packages/<env>/*.yaml — feature flags, shopware.yaml, …), the same way Bundle::buildDefaultConfig() does for a bundle's own config. Only YAML is loaded; packages/mcp.php is skipped because the Admin/Store API MCP tool sets are not registered.

2. Service overrides (ServiceOverrides)

Each bundle declares its differences as class constants and applies them via Framework\DependencyInjection\ServiceOverrides:

Current class replacements:

overrides.xml

Standalone Muckiware services and aliases that redirect a Shopware service id to them:

3. Running without the Checkout bundle

Many loaded Shopware services still reference Checkout services or entities. Two mechanisms make the container compile and the DAL work anyway.

RemoveCheckoutDependentServicesPass

Compiler pass (TYPE_BEFORE_REMOVING) that cleans up dangling references iteratively:

• A service whose required constructor argument references a missing service is removed — which may in turn make other services unresolvable, so the pass loops until nothing changes.
• Optional references (tagged iterators, service locators, service closures in locator maps, method calls) are filtered instead of removing the parent service. Iterator keys are preserved (e.g. asset package names).
• Services that Symfony already inlined are not treated as missing; services removed on purpose via ServiceOverrides::remove() are (ServiceOverrides::pullRemovedIds()).
• Env var placeholders that are no longer used by any service or parameter are dropped, otherwise the PhpDumper fails with "Environment variable X is never used".

The pass is registered twice (priority 100 and -250), because later BEFORE_REMOVING passes re-register service locators with their original map and bring back closures to removed services.

LenientDefinitionInstanceRegistry

LenientDefinitionRegistryPass swaps the class of Shopware's DefinitionInstanceRegistry. Entity definitions of loaded bundles still have associations to Checkout entities (customer, order, payment method, …). Instead of throwing DefinitionNotFoundException, the lenient registry:

1. instantiates and compiles the definition directly if the class exists in vendor but is not registered (keeps real fields, e.g. for many-to-many mapping lookups), or
2. returns a GhostEntityDefinition with an empty field collection if the class does not exist.

Instances are cached before compile() to break circular association chains. Entity-name lookups (getByClassOrEntityName(), used by FkFields since Shopware 6.7.15) are resolved the same way.

RemoveCurrencyServicesCompilerPass (System)

Removes every remaining service or alias whose id contains Currency (e.g. the sales channel currency association registered by sales_channel.php). The database tables stay untouched.

4. Routes

Shopware loads routes from each bundle's Resources/config/routes.php. The Muckiware bundles import only the controllers that make sense without a shop:

• Framework: Admin API controllers, plugin, store, message queue, increment, migration, app system (controllers and routes), script API, rule API, SSO
• System: system config, user API, custom fields, state machine API, number range, sales channel (admin only)

5. Boot

• Framework::boot() registers the feature flags, binds the telemetry meter, configures cache compression and stampede protection (same as the Shopware Framework bundle).
• System::boot() registers custom entities (CustomEntityRegistrar).

6. Web installer (Installer/)

public/index.php boots Muckiware\Core\Installer\InstallerKernel as long as there is no install.lock (and SHOPWARE_SKIP_WEBINSTALLER is not set). The kernel extends the Shopware installer kernel; bundle, views, translations and assets still come from vendor. Replaced parts:

The installer runs before the system is installed, so its styles and logos are shipped by the asset-only bundle MuckidriveInstaller (registered in config/bundles.php): bin/console assets:install copies Installer/Resources/public to public/bundles/muckidriveinstaller. The version shown in the installer is read from this package's composer.json.

Extending

A standalone copy of a Shopware class causes TypeErrors wherever Shopware type-hints the original class — prefer extends + class swap.

Shopware updates

After composer update shopware/core:

bin/console lint:container       # constructor argument / type errors
bin/console database:migrate --all
bin/console plugin:refresh
bin/console dal:validate

Check in particular:

• new or renamed vendor DependencyInjection/*.php files and services that reference Checkout
• classes in SW_CLASS_REPLACEMENTS and overrides.xml against their vendor originals
• installer: vendor RequirementsController, ShopConfigurationController, MigrationCollectionFactory and base.html.twig against the Muckiware versions; MAJOR_VERSIONS when Shopware adds a new migration major (e.g. V6_8)
• the frontend entity is a MySQL view over sales_channel (SELECT * is frozen at creation) — new sales_channel columns require a migration in muckiware/master that recreates the view

Legacy files

Some files are left over from the former XML-copy approach (before the Shopware 6.7.15 port) and are not loaded by the current bundles:

• Content/DependencyInjection/*.xml except overrides.xml and product-search.xml
• System/DependencyInjection/*.xml except overrides.xml
• Framework/DependencyInjection/in-app-purchase.xml, System/Resources/config/basicInformation.xml
• copies of Shopware compiler passes in Framework/DependencyInjection/CompilerPass/ and System/DependencyInjection/CompilerPass/ — the bundles register the vendor passes; only LenientDefinitionRegistryPass, RemoveCheckoutDependentServicesPass and RemoveCurrencyServicesCompilerPass are Muckiware specific
• classes not wired in any service definition: Framework/Api/Controller/InfoController, Framework/Sso/Controller/SsoController, Framework/Webhook/Service/WebhookManager, System/CustomEntity/CustomEntityLifecycleService, System/DependencyInjection/DependencyInjectionException