I think that the editor code (in the HTML) should be tighter. Not that it's going to change anything on compressed files, but if for any reason your server is not sending gzipped data, I've found that my optimizations, while not changing anything to the feature set, actually saves over 3KB... That's not a bandwidth saving I'm going to laugh at, really.
I'm having a couple of issues with one thing though... SMF/Wedge always define images_url in the HTML JS. In Wedge, it is we_images_url. It is only used 3 or 4 times in the entire code, and never for interesting things.
I've been looking at the code for $settings['images_url'], and I can't find any place where it is set to anything else than $settings['theme_url'] . '/images'.
So, my question would be... Can't we just print the we_theme_url variable, and add /images/ to it when needed?
I'm just worried it could be set at some point to $settings['default_theme_url'] . '/images', but I couldn't find it. (I have to say, I'm drowing in micro-optimizations right now... Big commit coming up, eh.)
If we can guarantee we never need an unsigned value, we can use that. However int is problematic because unsigned int is an unsigned 32 bit value which runs over the limit of PHP at times (and can be silently switched for a float)
Never heard about that... But yeah, I figured the signed stuff must be an oversight on the SMF devs' part.
However, I don't feel like checking all INT entries and adding unsigned to them, so if you're not interested with the idea, I guess we can simply forget about it, at least for now...
Tinyint, smallint and mediumint can all be safely made unsigned if the values never go negative.
It can be useful but if you're not offering patches it's almost not worth the effort. More thought needed.
OTOH, maybe files shouldn't get a @version at all, in these conditions
Not worth adding @version to all files, or not worth removing it...?
I don't think the actual @version string is of any interest, whether in the program or legally.