Wedge

Only last night I encountered a change in behaviour between my local PC and the server that my code was deployed onto; it was a schoolboy error on my part for forgetting it (call_user_func_array expects the callee to be specifying its parameters explicitly as references, rather than values, especially given that the caller was using references) - on my 5.2 setup it worked as expected, on a 5.3 box it broke quite interestingly.

The reason it doesn't matter in the SMF world is because so much of what goes on is DIY coding rather than letting PHP's own functions do the job. Number formatting, timezone offsets, time generally, etc.

So, I needed something that would operate during the SD ticket load phase and then proceed to add a template in. Since I'm slightly lazy and had no desire to force yet another file to be loaded when the template was a very simple one, I just put the source and template in the same file.

So, getting back to the point: I'd suggest we don't have it load files in template hooks. Any new template will require code to back it up anyway, which means you're going to be loading a file to engage the logic-powering hook anyway, and that new file can load a template if it wants, or it can embed the template if it wants. Then if the mod wants/needs theme specific changes for some random reason, it can be left to the mod author to make it happen if they so desire.

It may be version specific but int(4) should do something different to tinyint(4) - in theory, an int(4) should consume at least twice the space of a tinyint(4) and potentially quadruple it; (snip).

I don't believe MySQL uses that value for type hinting though, because of the above fact that it could be unreliable, meaning that I think it's always going to allocate 4 byte integers for everything even if it's only a one byte column, so it might be worth glancing through the code sometime to see if we do actually need 4 byte ints everywhere, since I'm not sure.

In other news, at some point we need to make sure that the list of tables that we end up with is in the listed of reserved tables in the DB class(es).

Nope, because I updated before committing and got your changes first, but mine happened to be nowhere near yours.

Incidentally, at some point recently we broke the installer somehow, it never gets onto step 2 :/

More specifically, if there's any kind of error that would force it to fall out of DatabaseSettings(), it's just going back to the start rather than actually showing an error :/