I'm using Magento 1.6. I've created my own theme (mytheme) under base.
So my file structure is app/design/frontend/base/mytheme
I could also develop my theme under app/design/frontend/default/mytheme
Which is best practice? And what are the implications of using base/mytheme rather than default/mytheme?
Cheers,
Eddie
I do disagree with the solution of Mr Storm.
ref: http://www.magentocommerce.com/knowledge-base/entry/magentos-theme-hierarchy
Those documents recommend You avoid to use the package default (as the base package too)
You have to creating Your own package 'mytheme' and to define a theme 'default'
ref: http://info.magento.com/rs/magentocommerce/images/MagentoDesignGuide.pdf
"Please ignore legacy Magento instructions and tutorials that instruct
you to create your custom theme inside of the default design package,
or to edit files in the default/default directory directly.
Rather,
the method that affords the best upgrade path for your theme and the
most protection from accidental changes is to create a new designpackage
and to create your custom theme inside of there."
So the correct answer is
app/design/frontend/your-package/default
Do NOT use:
app/design/frondend/default/your-theme
You don't want to put your theme in the base folder. The base folder is meant to contain the "core" theme that ships with Magento. It's the ultimate fall back, and the last place a file is looked for. It was specifically introduced to provide a place where core Magento developers could blow the entire directory away and replace everything (if need be)
To create a theme for Magento, you'll want to create a theme folder in your design package
app/design/frontend/default/mytheme
Then, in the admin go to
System -> Configuration -> Design
and enter mytheme in the Default field. Your theme will now the the "default" place Magento looks for files. If it doesn't find one, it will fall back on what it finds in the base folder.
Related
I have a Joomla Website developed by giving work to freelancers.
It has many modules, plugins and components which were developed.
Now I want to develop another website on Joomla. I want to use those extensions but don't have the installation zip files.
Is there a way to export them or to create them by exporting some files. Id yes - then specifically how?
The question is different from Is it possible to export already installed component in joomla 2.5? as there they are just asking about exporting a component whereas here the exporting has to extend to plugins and modules as well.
There's a tool for that: GreenCape/extension-export, called Extension Exporter. It was written for and tested on Joomla 3.8. Unlike other tools, it takes the extensions manifest file into account (especially for folder names).
(Disclaimer: I wrote it)
To nibra's answer:
This is very nice, thank you for sharing.
Remarks:
after installation, I couldn't enable your plugin, needed to set the $filterForm variable public in InstallerViewManage.php line 64
I could export my component, then removed, but when tried to install it back, it missed the router.php file, which I did not have on administrator side, so I needed to remove it from the exported installation XML file.
After that I could install my component successfully, but language file was missing, because my component is in Hungarian and no English language file was set for it.
Also it would be nice to dump the database tables with the component so I didnt need to export/import separately.
So this will be a great tool after a little manual finetune.
Thank you!
I created a custom module that represents a custom payment method, the steps I follow are;
1) Create a module architecture in /app/local/NameSpace/MyModule
2) Create an xml file in /etc/modules to configure my module
3) Create templates /design/frontend/base/default/template/mymodule
The module works well, but i want to reuse the module in other projects with all in one installation. now, i want to know if i must develop a script to copy the xml file in /etc/modules and templates manually? or there is an existing solution in magento 1.9 to do this operation?
Thanks in advance,
You want to create a Magento Connect package. There's a UI for doing this under the System Magento menu (although the UI is sort of terrible) and some googling around should set you right. Once you have a connect package, you can install it into any system via the /downloader UI (also available via the System menu) or the ./mage CLI command.
Also -- if you choose "Magento Other" as the role for all your files, your resulting tgz archive can simply get uncompressed/unarchived into any Magento system's root folder. Also of interest -- my script for creating Connect Packages from raw tar archives.
I am working on an web built in PrestaShop that needs some re-design. I have made a copy of their theme and I am working there. Now I need to add some javascript files and they need to be included in all my theme pages.
I have read similar questions here and looked for info and basically I have found two solutions proposed:
1) Add the file directly into your HEAD.tpl using something like {$base_dir}
(explained here: Prestashop root directory)
2) Add the files in the FrontController.php (overrides/classes) with a new setMedia() function
(explained here: http://tinyurl.com/cxucwq7)
The second solution seems the most recommended one but when I open the FrontController.php I see the following warning:
* Do not edit or add to this file if you wish to upgrade PrestaShop to newer versions in the future.
So I'm a bit confused now. Is it safe to edit this file? How about future upgrades, will they overwrite any changes made there? Isn't it safer to add them to your themes header.tpl and not affect the core of the cms?
(This is my first question here, I tried to follow the guides but I would appreciate any comments on how can I improve it, thank-you!)
It is totally safe to use the override file, and that's why they exist. I have used them in every Prestashop I made and they've never had been replaced in an update. The text they put is for the license, they probably just copy/paste it everywhere.
I wouldn't recommend manually adding the files to the header.tpl. It will work, but the advantage of adding it with the Tools::addJs() method is that the script will be concatenated with all the other scripts.
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 have a zope instance with many plone sites each for different customers. I want override particular translations such as the date format just for a single plone site without affecting the others. How do I do this?
Tutorials such as http://maurits.vanrees.org/weblog/archive/2010/10/i18n-plone-4#overriding-translations seem to indicate custom translations override all sites on a zope instance.
This is how I solved it. It's a bit of a hack solution but it worked for my particular scenario.
As per http://maurits.vanrees.org/weblog/archive/2010/10/i18n-plone-4#overriding-translations I
created my own locales package.
overrode the the plonelocales domain just for one particular language variant, in this case en_AU.
loaded the package in zope via buildout with particular attention to make sure it's the first ZCML slug (not instructions in the blog post incorrectly state it must be the first package in the egg section. This wasn't enough to make it work for me).
for each site I wanted to switch date formats I went to site setup > Languages and switch the language to "English (Australian)".
The other gotcha is that when releasing and deploying your locales package make sure that you've
generated the the .mo file first (done for you if you run zope locally)
and you've used an MANIFEST.in file to tell setuptools to include all .mo files as you shouldn't put .mo files under source control and by default setuptools only includes files under source control.
This does not get me a custom date format for every single site but good enough if the custom date format you want is actually that of the language variant you choose to use.
You can implement your own zope.i18n.interfaces.ITranslationDomain utility which looks up translations in a different place. The normal translation domain utilities stores a list of gettext message catalogs. Those are loaded from mo files on the file system and registered with ZCML.
But you can implement a different translation domain, store it as a persistent utility per site and give it some additional storage to look up messages in.