I am using prestashop 1.7.X and I have overridden the file ps_shoppingcart.less to give the shoppingcart a modified style. However these rules interfere with the file cart.styl.
Since I want to achieve compatibility with upcoming versions, I want to make the less file having a higher priority then the styl file so the rules don't interfere anymore.
How can I do this and what would be the best practice to do this?
(I know that I could just delete the content of the styl file).
Rsgards
A simple way is to use prestashop priority (on PS 1.7)
$this->context->controller->addCSS(css_path, 'all', priority);
Related
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 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!
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.
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.