Theme Fallback

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:

/app/design/frontend/{package}/{theme}/
/skin/frontend/{package}/{theme}/

Best practices

  • 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.

Magento Community

  1. configured-package/default
  2. base/default

Magento Enterprise

  1. enterprise/configured-theme
  2. enterprise/default
  3. base/default

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.

Magento Community

  1. configured-package/configured-theme
  2. configured-package/configured-default
  3. configured-package/default
  4. base/default

Magento Enterprise

  1. enterprise/configured-theme
  2. enterprise/configured-default
  3. enterprise/default
  4. base/default

Further fallback levels requires modifying the Magento core. This is rarely necessary.

Skin fallback

The configured theme should contain all /css and /img assets. CSS usually references images with relative URLs, and these will break if assets are split across themes.

Banned packages

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.

  • default/default
  • default/modern

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).