Magento Enterprise Theme Fallback

If you are adopting a minimal-is-best approach to templating your Magento Enterprise store (ie. local.xml method), you’ll soon run into some odd behaviour with the theme fallback. Typically, a Magento store will try to load a file in the following order

./app/design/frontend/custom_package/custom_theme
./app/design/frontend/custom_package/default
./app/design/frontend/base/default

However, if you are using Magento Enterprise and which to use the default Enterprise theme as a basis to serve your new theme, you need to alter the fallback method to support checking the Enterprise theme too. It should really be like this by default, as otherwise it would involve copying and pasting of many files simply to achieve the same output. So rather on Enterprise, it would be preferred to do the following,

./app/design/frontend/custom_package/custom_theme
./app/design/frontend/custom_package/default
./app/design/frontend/enterprise/default
./app/design/frontend/base/default

We’ve submitted an official bug report to the Magento EE team, but in the mean time, feel free to use this little extension to provide the additional level of fallback.

Download

  • http://twitter.com/jakeasmith Jake A. Smith

    Oooo… Very cool.

  • Peter

    This is a lifesaver, does the bug still exist in EE 1.12??

  • Andrew

    Hi Benjamin.

    Thanks for the module and the effort made in trying to resolve this issue.

    Are you aware that this module breaks the installer and is thus not that appealing to include in a project as deployment becomes tricky?

    it breaks the enterprise 1.12.0.2 edition as well as the new 1.13 edition. I have spent a lot of time trying to disable the module before install (with config xml : and of-course that doesn’t work) and re-anable after the installation has completed.

    if you are interested in the error :

    Fatal error: Call to a member function append() on a non-object in ……appcodecoreMageInstallcontrollersWizardController.php on line 77

    on this line of the WizardController it is trying to :

    $leftBlock = $this->getLayout()->createBlock(‘install/state’, ‘install.state’);
    $this->getLayout()->getBlock(‘left’)->append($leftBlock);
    return $this;

    And whats happening is that $this->getLayout()->getBlock(‘left’) returns Null and thus the installer kicks out that error.

    Any suggestions? I want to use this fix but i cant justify it if it breaks the installer.

    Andrew

  • sonassi

    Hi Andrew,

    This module has absolutely nothing to do with the error you are seeing. It quite literally adds 1 line of code to the core, to tell it to search through 4 directories for fallback rather than 3.

    Your issue is very much something else.

  • Andrew

    Hi there.

    I wish you were correct on this. I have reviewed exactly what this module does, and ofcourse I can see it adds TWO lines to the core, overriding the getFilename and getSkinUrl methods in Model/Design/Package.php

    While you dont believe this to be true, i have tested this on two clean versions of enterprise and get the same error everytime. If I disable your module, the installer works.

    Try it.

  • Andrew

    Again. I tested Both 1.12.0.2 and 1.13.0.0 with nothing else except this module.

    It breaks the installer. I can even show you how and why if you are interested to know? The issue above is 100% related to this module. if i disable it, the installer works. there is zero doubt in my mind. you don’t have to believe me, just try it yourself. Im trying to use this fix as well as help you.

    Andrew

  • sonassi

    Hi Andrew,

    When you refer to the installer – do you mean the Magento base installer (ie. when you remove local.xml?). If so why are you running the installer after having installed modules? If you are trying to just clone/migrate a store to a new URL – there are MUCH better methods than re-running the installer. See http://www.sonassi.com/knowledge-base/our-magento-git-guide-and-work-flow/#git-create-staging-environment

    In-fact, we don’t advocate running the installer under any circumstance other than the very first installation. Even then – we use a scripted CLI installer. See http://www.sonassi.com/knowledge-base/fully-automated-magento-install-script/

  • Andrew

    Hi.

    Yes I mean the Magento base installer. While I am sure there are reasons for not rerunning the base installer, that is unfortunately a matter of choice/preference. I personally don’t often use local.xml for customization in general and thus am quite happy to re-install on an imported DB. Whether or not that is the BEST possible way to do things is another discussion and I’m looking forward to reading that link you just posted and finding an explanation for why you are suggesting its a bad idea.

    For the record, this module does break the base installer. No matter how you see it, that is something that it should not do. Thanks for the response anyway, I will look for other ways of solving this

  • Andrew

    Hi.

    I have read through both articles and reviewed the mage-install.sh script which all looks great and im sure to look into doing something similiar, but there is no explanation, or justification on why one should not run the base installer again. Ofcourse this wont work when automating deployment, but still there is no reason why this module should break the base installer as that is essentially breaking the core of magento.

    Anyway thanks for the responses.

    Andrew

  • sonassi

    Hi Andrew,

    There is absolutely no reason to run the installer again. It is an installer – not a re-installer.

    Re-running the installer does a lot more than just creating a new local.xml file and with it not only being an extremely slow process; it is also prone to potential error/db corruption if a HTTP timeout occurs. Re-running the installer effectively requires the store to rebuild and re-index the entire database to correct/update any URLs

    If you need to change the DB credentials, edit the local.xml.
    If you need to change the URL – use sed and mass replace the URLs in the DB dump
    If you need to change the locale – do it via the admin
    If you want to add a new admin user/role – use a standalone script (eg. http://inchoo.net/ecommerce/magento/locked-out-from-magento-admin/)

    You should *never* use the installer as a re-installer. You are getting errors – because you are using the wrong process, not because of an extension you are using.