The icon paths in moodle are all hardcoded with .gif extensions. I want to use PNG's in my theme. Now I can can make a PNG image and just give it a .gif extention and the web browsers will happily play along (even though the web server is sending the wrong mime type), but is there any better way of doing this?
Hi Alan,
You could just ignore the hardcoded img tags and apply your own icons using the "background" CSS property (http://www.w3schools.com/css/css_background.asp, http://reference.sitepoint.com/css/background).
Applying images without any content (icons for example) is also a good practices with regard to accessibility.
hth
Frank
PS
Some older browsers don't support PNG.
You could just ignore the hardcoded img tags and apply your own icons using the "background" CSS property (http://www.w3schools.com/css/css_background.asp, http://reference.sitepoint.com/css/background).
Applying images without any content (icons for example) is also a good practices with regard to accessibility.
hth
Frank
PS
Some older browsers don't support PNG.
And if you want to use the icons as list markers there's an even better approach, see Site Admin Block: Better image placement.
Cheers,
Frank
Cheers,
Frank
This would be true in some cases. For example, the icons in the admin block. But other icons, like the course edit icons, are really part of the page content.
One way of doing this is to configure your Web server to send the correct MIME type. If you send the correct MIME type then there is absolutely nothing wrong with calling your PNG images .gif, .frog, or .zombiesatemybrain.
Depending on the server you're using, you can probably do this with an .htaccess file in the folder where the icons are located. I haven't looked up how to do this...
This will not work if you use the smartpix system which sends its own MIME type based on file extension.
Another webserver-based solution is to make it send redirects for each image. Using Apache mod-redirect or similar tools you can redirect specific .gif request to .pngs - this can be done either with a 'hard' redirect that the browser has to follow, or internally to the web server without causing a second request. Because it overrides the normal request, you can do this even if using smartpix.
It would be nice if Moodle had better support for this. For example, the smartpix system could be extended so that image requests did not include extensions and it automatically just tries .png and then .gif. It would be possible to do this without changing the rest of the system (just enable smartpix and change the smartpix.php script so that it ignores the extension and searches as above, sending the relevant MIME type for the version it finds).
By the way I don't entirely agree with Frank about the accessibility implications. Sometimes images are purely decorative and in that case it is appropriate to include them via CSS. But often they are content (they hold some meaning) and in this case it's not appropriate to add them via CSS; unlike CSS decorative images, HTML images can contain alternative text and even long descriptions, both of which may be important for content images.
Given the context that content images (<img>) are important, unfortunately it's a major limitation of CSS that there's no direct way to use it to change image files, i.e. you can't do something like img[src='whatever.gif'] { image-source: url(whatever.png); } Oh well.
--sam
Depending on the server you're using, you can probably do this with an .htaccess file in the folder where the icons are located. I haven't looked up how to do this...
This will not work if you use the smartpix system which sends its own MIME type based on file extension.
Another webserver-based solution is to make it send redirects for each image. Using Apache mod-redirect or similar tools you can redirect specific .gif request to .pngs - this can be done either with a 'hard' redirect that the browser has to follow, or internally to the web server without causing a second request. Because it overrides the normal request, you can do this even if using smartpix.
It would be nice if Moodle had better support for this. For example, the smartpix system could be extended so that image requests did not include extensions and it automatically just tries .png and then .gif. It would be possible to do this without changing the rest of the system (just enable smartpix and change the smartpix.php script so that it ignores the extension and searches as above, sending the relevant MIME type for the version it finds).
By the way I don't entirely agree with Frank about the accessibility implications. Sometimes images are purely decorative and in that case it is appropriate to include them via CSS. But often they are content (they hold some meaning) and in this case it's not appropriate to add them via CSS; unlike CSS decorative images, HTML images can contain alternative text and even long descriptions, both of which may be important for content images.
Given the context that content images (<img>) are important, unfortunately it's a major limitation of CSS that there's no direct way to use it to change image files, i.e. you can't do something like img[src='whatever.gif'] { image-source: url(whatever.png); } Oh well.
--sam
You're absolutely right, Sam. I wanted to say something in that vein but it must have got lost between my brain and the keyboard...
I can't find any documentation on the smartpix system in Moodle Docs, can you point me to some?
A solution might be on the horizon with the future CSS 3: http://www.w3.org/TR/css3-content/#inserting3
Cheers,
Frank
I can't find any documentation on the smartpix system in Moodle Docs, can you point me to some?
A solution might be on the horizon with the future CSS 3: http://www.w3.org/TR/css3-content/#inserting3
Cheers,
Frank
Please feel free to add documentation for smartpix. 
Basically you turn it on in admin (search for smartpix, obviously) and then all image requests are routed through a PHP script. This means you don't have to have a copy of every icon in every theme - it automatically searches the current theme, then parent theme etc, then eventually the /pix folder.
Because this is a single point of control it would also be a place that potentially could handle tasks such as automatically selecting PNG instead of .gif if one is available.
pix/smartpix.php.
--sam
PS I'm not a fan of CSS generated content, to be honest
CSS 3 is kind of a long horizon though... ;)
Basically you turn it on in admin (search for smartpix, obviously) and then all image requests are routed through a PHP script. This means you don't have to have a copy of every icon in every theme - it automatically searches the current theme, then parent theme etc, then eventually the /pix folder.
Because this is a single point of control it would also be a place that potentially could handle tasks such as automatically selecting PNG instead of .gif if one is available.
pix/smartpix.php.
--sam
PS I'm not a fan of CSS generated content, to be honest
... one that started more than six years ago 
Will have a look at that smartpix thing, for starters see http://xref.moodle.org/pix/smartpix.php.html
Will have a look at that smartpix thing, for starters see http://xref.moodle.org/pix/smartpix.php.html
Just in case it wasn't clear, I'm the one who actually wrote smartpix - and failed to do any documentation for it Well, I thought the description on the admin page would do...
--sam
--sam
If you turn smartpix off, it's possible to get apache to do it right using mod_mime_magic.
Can I make a request for Moodle 2.0? This should be relatively straightforward. Instead of doing something like {$CFG->pixpath}i/help.gif do something like icon_path('i/help'). The icon_path function would search through the directories for an appropriate image and return its path. To solve the problem of performance, make up a mapping of icon names and their paths and cache it somewhere. Then update the cache whenever the theme is changed. This removes the need for smartpix and also solves the problem of performance. And bonus points for taking advantage of the Accept header. 
I could write this myself if you think it's a good idea. It would be backwards compatible.
N.b. This is how GTK handles it's icons, that's where I'm getting the idea from.
I doubt there should be a performance problem to solve, so I wouldn't bother caching if I were you. The performance problem (if any) caused by using smartpix will probably be more a result of the overhead of starting up the PHP interpreter etc, than of checking like 4 different locations to see if a file exists, that doesn't take much time...
In fact using smartpix itself doesn't appear to cause critical performance problems (that we noticed). Smartpix requests are handled an awful lot quicker than ordinary Moodle requests, they aren't heavyweight requests. And it sends appropriate browser headers including an expires a few hours ahead, so you shouldn't get too many unnecessary HTTP requests for the icons (which, unless you put some effort into Apache configuration, may not be the case for the 'standard' webserver-served icons).
However, smartpix is only implemented the way it is because it was a 'low-impact' way of changing the system - in other words, rather than changing thousands of lines all across every area of Moodle, it just requires changing the way the pixpath variable is set up. I'm not suggesting it is the best approach.
I agree something like your system would be better, but probably not that one exactly - since this would clearly be a 2.0 change it should probably be integrated into Tim's theme/weblib-replacement system rather than just a global function. That should automatically provide a way for themes to slot in replacements, including changing the filename if they like.
--sam
In fact using smartpix itself doesn't appear to cause critical performance problems (that we noticed). Smartpix requests are handled an awful lot quicker than ordinary Moodle requests, they aren't heavyweight requests. And it sends appropriate browser headers including an expires a few hours ahead, so you shouldn't get too many unnecessary HTTP requests for the icons (which, unless you put some effort into Apache configuration, may not be the case for the 'standard' webserver-served icons).
However, smartpix is only implemented the way it is because it was a 'low-impact' way of changing the system - in other words, rather than changing thousands of lines all across every area of Moodle, it just requires changing the way the pixpath variable is set up. I'm not suggesting it is the best approach.
I agree something like your system would be better, but probably not that one exactly - since this would clearly be a 2.0 change it should probably be integrated into Tim's theme/weblib-replacement system rather than just a global function. That should automatically provide a way for themes to slot in replacements, including changing the filename if they like.
--sam
Good point, I should change my suggestion. Smartpix had a relatively low profile because the resolutions could be cached. If we resolve the icon path on the main page, we'll lose that. I think an update to the smartpix logic (or a similar replacement) would be best.