Wedge

I'm cool with the template changes :)I'd avoid making too many functions, especially if they're fairly similar or related. Trust your instincts on this one.No, if you have an object whose job it is to handle the template skeleton, not only is it the holder of the data, but it's also responsible for changing that data. In any case, if it's to be tamper-proof except for through the defined methods, the methods have to be part of the object because you'd make the list itself a private variable - which by definition can only be manipulated inside the object's own methods, and is never made directly available outside of it.At least then there would be a useful start to debugging...You know, we could just ship with both English and French installed by default so it's always > 1 :whistle:I had noticed, but I'm not in the slightest surprised. It's a massive undertaking at the best of times, and it has so many knock-on effects that it will inspire fear and dread in anyone.There aren't that many situations, and frankly I think they're avoidable too.

The main ones that I envisage are where you end up with what amounts to a single album that contains all the attachments, but that access rights to that album are inconsistent with how an album usually functions. That, and separating viewing a thumbnail from viewing the main file (it's a fairly common request because SMF says either you can see it or you can't, no in-between ground)As you reminded me yesterday, http://yarr.me/cache/8a07b66f80a1982895b8acf157fe1002.jpg

I have no problem with changing how users see things, provided that where we go to is a logical, meaningful place. To me, sifting out the code so that we have one path for accessing attachments/avatars/gallery items seems like a logical place to go - and we get the benefits of integrating Zoomedia cleanly :)Nothing wrong with having ambition. Maybe that is a little unbalanced in terms of work vs reward (though far less so than building a wall just to put a hook on it for a coat), but I think it's a meaningful one because right now we have two distinct paths to serving files and so on, even though the operations are virtually identical, and we should fix that.

Really: what's the difference between what MGalleryItem does and what Dlattach does? They still look up where a file is, whether the user can see it or not, and ultimately serve the file.Again, I don't really see it as a failure, no more so than my not having reimplemented permissions yet. It's just another thing to do that has massive system-wide consequences and can easily turn into a tour-de-force of bug hunting.OK, best thing to do is take a look at the code in the modified Download() function in Display.php on this site (or, failing that, a fresh 2.0 final install with SD 2.0 installed).

Firstly, it checks for 'avatar' in the URL, and if so, it queries for the avatar's details (filename etc.). If not, SD's injected code looks for 'ticket' in the URL, and if so, it tries to query for the details *there*. Failing that, it just looks for the normal route (attach id + topic id)

Note that it doesn't *fetch* the information at this point, merely queries for it, and then passes the query result to the fetch code, so regardless of the query actually run, it knows that no rows means the attachment can't be found or seen (either way, it neither knows nor cares which), otherwise it serves the file it has.

SD added its own handler in there, and I can envisage something similar in the attachment code, whatever form it's in, to have a hook, and see if anything attached to the hook will validate the requested file, and if so, prepare to serve it.Yup. So many inter-related parts, it's so hard to judge where to start.

AeMe 2.10 was specifically the reason why I added ENUM support :P But it wasn't tested thoroughly, it just means that the code which deals with defaults is a shade buggy, not that it's a hellhole of support nightmare :P