Bug #14927
closed
Fileicon-Path is hardcoded and not changeable for the Frontend
Added by Arne Bippes almost 19 years ago.
Updated over 5 years ago.
Category:
Content Rendering
Description
The icon-directory for the filelink-property is hardcoded in the source (t3lib/gfx/fileicons/). The Backend is configurable using TBE_STYLES. Something similar is needed for the frontend.
The appended patch for class.tslib_content.php uses the TBE_STYLES code from class.t3lib_iconworks.php. It reads new TypoScript propertys:
filelink.icon.iconAutoCfg {
forceFileExtension = png // alternative file-extension to look for (default is gif)
absDir = /srv/www/typo3/fileadmin/icons/ // Absolute path to the directory with the icons
relDir = fileadmin/icons/ // Relative path to the directory with the icons
}
(issue imported from #M1378)
Files
will this bug ever be fixed? It's only a few lines of code but really anoying :(
Could easily be included for 4.1 ;)
maybe like a global constant that is automatically pased to ->filelink.iconPath and can be overridden within each instance of ->filelink
i vote for this bug entry
this would allow us to secure /typo3 via http authentication, thus blocking script kiddies trying to exploit bugs in /typo3 scripts
(ok, there a no such bugs known YET)
There is a property called iconCObject that will enable you to create your own icons however you like.
Example
iconCObject = CASE
iconCObject {
# look at TSref to see how you can do it
}
Many thanks Joey for this worthful contribution! :-)
(for those wondering what this means: We used this bug report at T3DD07 to demonstrate how fixing bugs works...)
is this fixed now for 4.2? filelinks will be taken care of in 4.2 if i am correct
I think this is fixed.
Best reference is svn revision change from 1420 to 1421 which changed the important lines mentioned in class.tslib_content.php.diff nearly exactly as proposed.
Seems fixed. If not, please reopen.
- Status changed from Resolved to Closed
Also available in: Atom
PDF