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.
Related
I'm beginner in Joomla So please any one help me. I'm editing on less files in both locations (media/guild/less/ and templates//less/) but changes are not reflected in front-end. Why has not reflected changes in the front-end.
It seems that your less files are not compiled to css, so no changes appear. Less can be compiled in the browser using Javascript, or via the commandline. I my opinion, there are only very few cases, in which it makes sense to compile in the browser.
To compile those files from the commandline you can have a look here
If you are new to Less/npm and all other needed stuff, you should have a look at the official docs.
As #philipp points out, Less files need to be compiled before they can be used.
Templates that use Less handle this in different ways. For example, Less files might be recompiled and saved each time you save the template settings. Deleting the Joomla cache and refreshing the front-end of the website might also trigger a recompile of the Less files.
For simple and future proof changes, it is often easier to override the CSS via a custom CSS file compared to editing the Less files directly.
working on a Joomla site I came across the following problem: I need to give frontend-access to a specified directory on the server. The user (an elderly man who is not into IT, should be as simple as possible!) has to upload photos into a directory and should also be able to delete them if he wishes. I have found several extensions that allow easy uploading from the frontend. Still, I did not find any which would also allow to delete content, in fact I haven't even found one that even displays the content of the folder.
The features I ideally would like to have are:
- uploading
- displaying in a list
- deleting out of that list
the content of a specified folder via front-end.
Does anyone know an extension providing the needed features? Or would there possibly be a solution combining multiple extensions, each of them fulfilling one of the needs?
Thanks in advance!
the Image Galery of the DOCman extension (https://www.joomlatools.com) should do the job but it is not free...
Regards
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.
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.