Forums

It's impossible to satisfy everyone - if you try too hard you end up with something full of compromises that satisfies no-one fully.

To be fair I'd have thought it should be obvious there would be changes between 1.2 and 1.4 just because of the version number?

Cheers. I've updated the copyright year and bumped the version number to 1.4.8. I want to solve this ticket before we do a release though, so will try look into it soon...

That error looks more like there is a problem with your MySQL install.

See: http://stackoverflow.com/questions/1676 … -directory

Mixing would be horrible. Personally I prefer on same line, but I can cope with either. I would suggest probably keeping them on a new line, simply to avoid changing unless we have a good reason.

Ideally the modules should be independent - they were designed so that other projects can just drop in the database or cache layers without reliance on FluxBB. Using some kind of FluxBB loader would break that - and I don't see what it gives us, other than being more complicated?

I actually wrote a mod for 1.3 ages ago that did pretty much just that - if a post had been reported (by anyone) but not yet had the report zapped/deleted, it should show "already reported" instead of the report button to prevent duplicate reports. It sounds like a sensible feature for 2.0 to me at least.

I think method names and variable names should be changed to camelCase - or at least be consistent with each other. You suggested this for methods, but not variables. I don't like the idea of doing methods one way and variables another.

Braces around one-line conditionals I don't like, and never do them myself. Though I'm not going to argue strongly against them - I can see their advantage, I just personally don't like them.

Spaces vs tabs - tabs. Fuck spaces.

Class names - depends if we are using namespaces or not, as Frank said.

Sure - I've changed it to the default on GitHub.

For FluxBB 2.0 we have already replaced DBLayer with a new database module, which does use PDO internally for driver abstraction. Simply using PDO directly would have worked for 1.4, but for 2.0 we need queries to be extensible and with a mild form of SQL dialect abstraction too, hence the database module rather than direct use of PDO.

It should be easy enough to simply check the last modified time of the pack and update the cache based on that. It means we need a disk read on every load - but reading the file attributes should be better than actually opening and reading a version number from the file.