I've been looking into how Theme Fall-back / Hierarchy works since CE 1.4 and I think I've fairly well understood it.

Then I move a legacy theme (the names purple-mix and purple_theme following are exemplary) which had been put inside the legacy locations:

app/design/frontend/default/purple-mix
skin/frontend/default/purple-mix

Those files have now been moved into the more appropriate, namespaced and currenlty as best-practice suggested ones:

 app/design/frontend/purple_theme/purple-mix
 skin/frontend/purple_theme/purple-mix

This so far looks fine to me and is more or less just context of my question. It gets more interesting when I add magento extensions / modifications into the mix.

Some third-party plugins now have placed files into the old (and according to What About default/default? (Magento's Theme Hierarchy Changes in CEv1.4 and EEv1.8) deprecated) location (even that plugin for example is a Feb 2014 release).

If I read the documentation it's now the case, since the moment I activate the new theme purple_theme, the fall-back to default/default will not be triggered any longer. Is this correct?

And so I now wonder what is best to do. Should I duplicate (copy) all those files into my own theme's default directory (purple_theme/default)? Or should I move those files?

Or should I copy/move them into base instead (the extension files in question are within their own sub-directory, e.g. for the Payone plugin, it's skin/frontend/default/default/payone/core/mandate.css)? What would be recommended practice here?

From my own (so far limited view, I don't have that much Magento experience), I tend to moving those files into base/default so that every theme will benefit from the extensions changes (I also have the full tree under Git version control, so I'm sort-of relaxed that file-changes are easily tracked).

Also is it good practice to discuss this with extension developers? What are common guidelines to give to them?

I've seen Custom Package/Theme for Admin module that falls back to default package? which is about admin configuration (and version 1.8) so I'm not sure if it would apply for frontend as well (and if already since version 1.4).

I even think about having something like Magento Enterprise Theme Fallback (Sonassi) with the difference, that I don't want to have fall-back to frontend/enterprise/default but frontend/default/default. Via Theming - starting from scratch.

(Exemplary extensions that are in use: One-Step-Checkout, Payone and Customer-Credit; Currently on an outdated 1.4 version, as you can imagine this is also in the light of upcomming Magento upgrades)

  • this may help you to understand why files where they are :) blog.belvg.com/… – Stefan Gregori May 7 '14 at 13:18
  • @StefanGregori Thanks for the link, I understand the hierarchy, but I wonder how to deal with files from extensions that do not play with exactly that hierarchy (or which assume there are only themes within the "default" namespace) – hakre May 7 '14 at 13:36
  • well, as i unterstand it, theire files should always be in base/default just because they can not know the name of your custom theme folder! but then, if you make changes to them, make a copy to your custom theme because with that, the extension stays upgradeable and your changes wont get overwritten. – Stefan Gregori May 7 '14 at 13:56
  • @StefanGregori: That is also what I tend to: Extension should place their "core" stuff into base/default despite Magento docs warn about this. I probably will revive default/default with some plugin so that there is another middle-layer for fall-backs. – hakre May 7 '14 at 14:20

As you mentioned you have the full project under git so I would suggest moving these files to base/default, comment/document etc what has happened so that you know when/if you update these extensions what you need to do.

Finally feel free to contact the extension developer, they will normally be happy to help and welcome new ideas.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.