This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I want to edit the HTML output that a particular module is rendering in the module's tmpl/default.php file. I located the file on the FTP, made the changes, and nothing is being conveyed when I clear the cache and browse to the page where I should see the difference.
Not sure what I'm missing here. Joomla 2.5.7.
You should never edit the modules built n tmpl/default.php file. Doing so will likely result in the edits being overwritten when you update the module.
#Jobin Jose is on the right track with #4 for both the answer to your query as well as the correct way to change the HTML output of a module.
First, make a copy of your_module/tmpl/default.php
Next, save that copy in templates/your_template/html/your_module/default.php
Make all the edits you want to that copy of the file, it will not be touched when you update the module later.
Make Sure the following things
you have permission to edit the file in FTP.
No cache plugin is enabled.
the right module tmpl/default.php is editing.
Make sure its not overrided(If it is overrided then you can found the html of module inside your template folder.)
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.
This might be more of a user question rather than a developer question. but developers should be able to offer insights.
For the person creating and editing content, what's the best practice for where to store images associates with pages? (I'm referring to the Plone folder, not the file system directory).
Should it be stored inside the same folder as the content item itself? Or a subfolder within the working directory? Or a special directory writeable by all for storing images?
If you do some sort of shared image upload Plone folder, what would the permissions on that Plone folder be? Once again, I'm referring of course to the Plone folder, not the file system directory.
I see that in the site admin TinyMCE options you can configure some default paths for image uploads. How would you do it so that the user won't be overwhelmed by all the images in a common images folder? (in other words, he can see and edit only his own image uploads).
This is truly a serious weakness in Plone, in the sense there is no "Best or More Oftenly Recommended Way". As #keul highlighted, Plone is flexible enough to support almost every imaginable usecase, nevertheless I can't see much of a consensus - neither a set of common steps - to fulfill the common usecase you described, in a hierarchical-and-permissioned paradigm.
That said I recommend you to check and share opinions, feature requests and code on the second of these:
https://pypi.python.org/pypi/Products.ImageRepository
https://github.com/plone/plone.app.mediarepository
Both focus on easing the use of tags to manage the overwhelming of items you described. I believe this kind of problem would mostly arise when adding images inside TinyMCE sessions, say, adding a News item. However if you just need to update images for sections or the homepage I recommend you to take a look at collective.cover:
http://www.youtube.com/watch?v=h_rsSL1e4i4
btw I also recommend you to check these solutions for richer image handling:
https://pypi.python.org/pypi/plone.app.imagecropping
https://pypi.python.org/pypi/Products.ImageEditor
https://pypi.python.org/pypi/unweb.iptc/
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.
Is it possible to automatically remove code comments in Visual Studio files before committing to source control, or is it possible to virtually have comments in files but physically store those in separate files?
The end goal is not to have comments in source control, but be able to have those locally.
This is wrong-headed.
What you should remove is commented out code. Let the version control system do its job. Comments that illustrate what's in the code and why should remain.
How do you expect to retain them if you remove them in source control? The next time you check out the code, the comments won't be there.
For development, It is good to keep comments in your code. Don't remove them. You cannot let your comments locally and commit non-commented files, because when checking out your repository, it'll have no comments at all.
Through comments, other developers are able to figure out what's going on much faster and be more precise as well. They can find bugs and improve your code. So, comments are cool. I mean, good comments. I know code must speaks by itself, but comments are important as well.
If you intend to save storage, please, don't do that for development process. What you can do is deploy your code withou any comment, and, if possible, compressed.
We are being programming language agnosic, but I am pretty sure every language has some way to strip out comments and optimize it for deploy.
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.