Posted on 16th May 2013 16th September 2015 By Benjamin L.
So this will cause ultimate uproar and go against the grain of every Magento developer - but we've got a solid process for theming - that does not use local.xml (more on that later).
We always work off the base/default template - but zero out the CSS. Even though all designs don't particularly lend themselves to the structural layout of a vanilla Magento store - we find it good practice to use the default theme as a starting point; we can remove un-used methods/loops/divs etc. as necessary during the templating.
We install this extension first, so that we get a level of theme fallback - when we later remove the theme files we copied.
The ultimate goal is that we don't have to keep copy and pasting each file that we modify whenever we need to, we just edit the file in the theme.
This header serves a purpose later when we do the final template clean-up. As we will do a recursive diff on the base/default/template directory and the sonassi/default/template directory - then delete anything that hasn't been changed.
This way, only the modified files remain and the overall package has been reduced to the minimum changed files.
The two above classes add the functionality into Magento so that you can extend - but not overwrite a layout XML file. Extensibility of the layout XML is important for us, as it allows us to still maintain the same file separation catalog.xml, cms.xml etc. - but only need to add short portions of layout XML to manipulate blocks (insert/clone/remove).
The local.xml methodology is that you just enter your overriding changes into one cumbersome unmanageable file.
The nolocal methodology means that rather than putting all changes in a single file, you put them in a file with the appropriate filename that it is modifying (eg. catalog.xml) - by simply creating a new file sonassi/default/layout/custom/catalog.xml - with *only the modifications.
Again, once we're done making the template, we can just remove the contents of sonassi/default/layout with the exception of the custom directory. This way again, like with the template, we have a lightweight extended template - based off the base templates.
We delete them, all of them. We don't bother copying them into our package's CSS directory. We'll copy in the JS and that is it - the images and CSS directory will be empty from the start.
As we're using SASS nowadays, we'll have another directory (scss) for the pre-processed CSS - and output to the main styles/print CSS file(s).
So as we mentioned, once the template theme is completed, you can now clean it up - to remove the un-modified files and reduce it down to the bare minimum.
[ -d "$PREFIX$DIR" ] || mkdir -p "$PREFIX$DIR"
[ -f "$PREFIX$FILE" ] || cp -pa "$FILE" "$PREFIX$FILE"