Theme fallback across Magento’s design packages makes this possible:
- Minimize volume of code being maintained.
- Minimize fallback layers.
- Separate customizations from core files.
- Leave core code intact for upgrades.
Packages contain themes. A “package/theme” lives in two directories:
- Never modify Magento core design packages. Projects always have a designated “package/theme” for segregating project code from platform code.
- Never duplicate entire themes or modules in a project theme. Project themes should only include new/different code.
Minimum design fallback
Minimizing layers in the fallback hierarchy makes inheritance easier to trace.
Maximum design fallback
Through configuration it’s possible to expand the fallback hierarchy. This is not recommended because the inheritance chain lengthens with every level, and that makes upgrades more time consuming.
Further fallback levels requires modifying the Magento core. This is rarely necessary.
The configured theme should contain all
/img assets. CSS usually references images with relative URLs, and these will break if assets are split across themes.
The following packages are never part of the fallback hierarchy in projects. They are used by Magento for product demos, and contain modifications specifically for demo purposes. This code is clutter and dead weight on custom implementations.
Frontend modifications should stay entirely in the project’s package. Enrolling the “default/x” packages needlessly lengthens the fallback chain and binds you to the Magento demo implementation (which may change).