Confused yet?. Let’s just say that rather than modify Magento’s base, default or in other words “stock” files, you create your own custom directory (and sub directories) and create files with the same names as the ones that you want to override in the default. Magento will check your files first and use them. If you don’t have a file in your directory that it needs to render the page, it will check the directory called “default” and it’s subfolders. If the file it needs isn’t in there, it will check the “base” directory and it’s subfolders. This doesn’t mean that you can’t create your own unique custom files and call them, but that’s another post by itself.
Magento also requires that each one of these main folders (base, default and x number of customs) contain a subfolder called “default”. Without doing archeological research into the evolution of Magento, I can only come to the conclusion that they did this simply so they could have default folder nested inside the default. Frankly I don’t know why the outer default wasn’t merged into the base folder to begin with as they both exist in every installation. If I had been a part of the Magento Project from the beginning, I would probably understand how things got so tangled up. But I wasn’t. And I don’t. Like so many things in Magento, I just suppress my irritation and get used to it.
As you start working with Magento, it’s best to just mimic the hierarchy of the app/design/frontend/default/default directory and it’s subdirectories. Now a word about the “skin” directory…
The “skin” directory follows a similar directory hierarchy and contains mostly css files and media, images, etc. You should call your custom directory by the same name as the custom directory in “app”. So if you have an app/design/frontend/myCustomFolder, you will want to create a skin/frontend/myCustomFolder to match. Again you will want to duplicate the directory structure in skin/frontend/default/default. Skins can be pretty damn effective without having to modify anything in the apps folders which are for layout (xml) and code (phtml) files. I have been fairly amazed at how drastically one can change Magento simply with css.
The Design Package selection in the admin or "backend" UI
In Magento’s admin interface, you can select the design package and skin separately. Which means you can use the default design package and select and use your own skin package. In which case you wouldn’t need to create a directory in app.
I won’t go into the details at this point about the layout and template files. Suffice it to say that it is much easier to understand the concept than dealing with the actual practice. The concept being that the “layout” of the blocks of code are controlled by xml files in the app/../../../layout directory and the code itself is contained in “phtml” files located in the app/../../../templates directory. PHTML files are essentially html files that contain PHP code in php tags interspersed with the html. Not difficult to deal with if you are familiar with both html and php. In practice, I haven’t had to play around much with the layout xml files. Which is good, because they are difficult for me to understand. The Designers Guide, gives examples of changes that you can make in the xml and the associated results in the rendered pages… but many of them don’t work as advertised for some reason. Your mileage may vary.
There is anther method used by Magento for creating pages (and blocks that can be inserted into pages) and that is done through the admin interface. This is very convenient for placing dynamic content like specials and sales by users who do not want to learn Magento. Magento has a built in WYSIWYG editor for just such purposes and allows content management in a form similar to other CMS software like WordPress, etc. It also allows scheduling the time that the content will appear for which makes it nice for ad campaigns and limited time offers.
All in all, Magento is extremely capable and offers a variety of ways to get things done. I have only scratched the surface and explained things in a way that is more conceptual than technically accurate for the sake of getting the reader’s feet wet and prepared. Check back for some specific posts on how to do what I think are common things in Magento Development, without pouring over hours of forum posts and Google searches.