[TYPO3-core] RFC: Make image hash names longer to avoid collisions

Ernesto Baschny [cron IT] ernst at cron-it.de
Fri May 18 11:54:59 CEST 2007

Karsten Dambekalns wrote: on 18.05.2007 10:39:
> Hi.
> On 18.05.2007, at 10:18, Andreas Otto wrote:
>> Martin Kutschker wrote:
>>> I never understood the logic of using truncated md5 hashes and argued
>>> before to use only the real hashes.
> I'm all for it.
>> * Check DB layout: Where are short md5 hashes used?
> Easy, I can do this. Extensions would probably break, though.
>> * Check TYPO3core: Where are short md5 hashes used?
> Doesn't matter that much, see below.
>> * How to change existing code to make use of full-length md5 hashes? What
>> about backwards-compatibility?
> Easy: Just change the default in shortMD5 from 10 to 32, all places
> should work. The remaining ones should be easy to find. Again, extension
> could break or at least still use short hashes.
> Second possibility: Make shortMD5 always return full md5 hash, ignoring
> the requested length. *Will* break some things. :)

I won't make "32" the default behaviour of shortMD5, as this would
probably make more trouble than benefits. I would replace the call to


with something like:

t3lib_div::shortMD5($string, $TYPO3CONF[...]['shortMD5size'])

throughout core, and adapt core-tables acordingly, if needed. We could
then mark shortMD5 as deprecated and make extension developers simply
use "md5()" in future. As soon as everyone is happy with 32 byte hashes,
we can drop shortMD5.

I currently cannot see any reason for 10-char hashes except the "optic"
in filenames. And if it is just the optic, we can argue with the
collision problem with that. I don't really care if my temp-file is called:

stylesheet_124ee84b16.css  or

Maybe if we have hundrets of temp-images (e.g. GMENU) this will increase
page-sizes a bit? or make debugging a bit harder?


More information about the TYPO3-team-core mailing list