I have heard a lot of people in the Magento community mention the benefits of using a local.xml for Magento theme development
I can understand the benefits and I actually can't think of any cases where its use could be detrimental.
Are there specific situations where local.xml is a bad choice? If there are, then what would those be?
MagePsycho's points are all correct, so I'll offer the following adding onto them.
local.xml layout file is only appropriate for the end-implementer, of course - makers of distributed modules should ensure that their modules configure & use a new layout update file. This may or may not be assumed in the original question, but it bears mentioning.
Also, in the case of a multisite installation, if several site themes share a common set of layout updates, but one or more site requires further updates, then it is ideal to create a custom module which configures a layout file to collect the common local layout changes. This allows for theme-specific local.xml files which do not contain duplicated layout updates.
The local.xml file of your theme's layout is always loaded last. Therefore, you can override the existing layout node and customize your layout according to your project's requirements.
Also, using local.xml is upgrade-proof in the sense that a single layout xml contains only necessary xml layout updates.
It may take you some time to adjust the design via local.xml because you can't comment an unnecessary block's nodes; you must remove the block via xml remove nodes. Also, you have to take care while sorting the block positions.
However, once you are done with one theme using local.xml then you can easily reuse the same concept (with some modification) for other themes.
Overall, using local.xml:
Makes your system more upgrade-proof
Saves time for future projects
Fewer number of files = less overhead :)
Hope this makes some sense :)
Cheers!
Related
After searching for articles regarding template rewrites, I've done a successful one written on the article here.
However, as stated in the article, one would have to copy the contents from the original .phtml file to your custom .phtml file. This is where the problem lies -- since we're a team handling different modules at a time, it may come to a point where they would need to overwrite the .phtml file I've written and do the same process -- copying the contents from the original (Which in this case, should be my custom .phtml) to their custom .phtml, which isn't upgrade safe at all because any future changes that I make on my module will not reflect on the template as my colleague has already rewritten it.
Would there be another approach for this? Or would the only way around this is to merge our code into a single custom .phtml file?
One possible solution is to modify HTML via Magneto event core_block_abstract_to_html_before.
So that multiple modules can add modifications upgrade safe.
Downside is using regular expressions or xml changes in the code, not in the templates.
When developing a module that will be reused outwith the scope of any one particular project i.e. using the community code pool, should I use the base theme to store my template, layout and skin files?
I am almost 100% certain that i should, but i see so many community modules using the default skin and theme directories that it has planted a tiny seed of doubt.
Yes, you should absolutely be using base/default for your community modules theme - in doing so you are utilising the fallback hierarchy Magento provides, allowing your theme to be portable and easy to extend by clients wishing to do so.
I'm not expecting upvotes for this answer, but would like to clarify on Tim and Drew's answers:
Unfortunately at the moment Magento only provides us with 3 levels of fall-back:
base/default
current_package/default
current_package/current_theme
Because 'current_package' is 'default' on standard Magento installations, you will often see extension developers place their files in 'default/default'. That is poor decision-making as it will mean the files will no longer be found when a non-default package is specified.
Obviously placing files in 'base/default' is also not the most optimal place, because in a sense you are removing the distinction between core and 3rd-party files. As others have mentioned, right now it is the only way of reliably adding your files while still allowing fallback to take place.
Fortunately, this will not be an issue in Magento 2, as these files will be part of modules instead, allowing pretty much infinite fallback.
Yes. Best practice is to create
app/design/frontend/base/default/template/your_extension_dir/
and
app/design/frontend/base/default/layout/your_extension_dir/
and put your files there.
I am minimizing my javascript files in my magento build to optimize page load time. I already minimized the skin/frontend/THEME/default/js files that were large, and next on my list are the varien javascript files.
My question is: Is it harmful to minimize the varien javascript files since they are technically part of Magento's core? I will obviously save backups of uncompressed files.
Thanks!
Minimizing the CSS and JS should have no side effects, that being said I have seen it screw up some of my style sheets before. Best approach is to enable each one by one in an testing environment and make sure everything looks and functions properly and look for any JS errors. Fooman speedster does the same thing that is built-in now with Magento.
If you encounter any issues disable the merging, your original files (JS/CSS) will be retained and are not modified, they are simply processed and combined into a new single file, so to answer your question it will not harm any core files by enabling such feature.
CKeditor's installation instructions tell me to just unzip the whole distribution file on my webserver's production directory. But it is full of files I definitely don't want there, like source code, examples, and even server-side code in PHP. I got rid of most of these files but there is one I'm not sure about: contents.css.
I can see this file uses a lot of styles I definitely don't want to see in my site. My question is:
Is contents.css required by CKeditor, or used by default? Do I even need this file on my production site?
I suppose it depends on what you're using in CKeditor, or what you plan to use later. Personally, I'd suggest renaming the file (something like) contents.css.old and creating a new contents.css file, copy across all the styles that you think you'll need and then destruct-test your implementation of CKeditor, to assess whether you've got all the styles that you need.
Add to, or remove from, that file to get your finished version and then use that one. I'd strongly advise keeping the original version around though, for future development purposes.
To your specific questions, though:
Is contents.css required by CKeditor, or used by default?
I believe so.
Do I even need this file on my production site?
Not so far as I know, its absence will likely cause things to look a little less-pretty, though, until you apply your own styles.
As suggested, above, though, I'd rename the original and then create your own stylesheet with the same name, it's rather easier than going through all the various js files looking for, and changing as appropriate, references to contents.css.
I am looking to clean up the file that we store in source control (SVN) for the Magento projects we are working on.
Which files/folder are have no purpose being in SVN, ie the ones are not necessary for the site to function, or are only transient?
So far I have identified
var\cache
var\session
media\temp
var\locks
downloader\pearlib\download
downloader\pearlib\cache
There are some I am unsure about:
var\report
downloader\pearlib\docs
media\catalog\product\cache\
Can anyone provide a definitive list?
http://activecodeline.com/git-ignore-gitignore-file-for-magento-project answers a larger question, but could be helpful none-the-less.
There's a whole bunch of stuff in Magento that doesn't need to be in source control, as it will remain constant (as long as you follow some sane development practices.) The above link goes through all the directories that need not be tracked by source control.
I typically ignore these folders for development, but you may choose to store images if you think it's appropriate:
/var: This is always temp data or data that can be regenerated
/media: These are images and uploads, not really source code, but keep if you want
/downloader: I don't like to use Magento Connect and prefer to install things manually. You can always get Magento Connect elsewhere, so no need to keep it in the repo.
/includes/src: This is compiled source code, you can regenerate if needed. Not really that usefull since we have SSD disks and APC.
We usually have something like:
/app/etc/local.xml
/downloader
/var
/media
Media usually contains images that are configured in admin, like product/category images, logos, CMS images, merged JS/CSS and import/export data I believe.
Some extensions also have files in media that should be versioned (ex. product feed templates)
There is also an htaccess file in var and media so you have to include those.