Wedge

I'm honestly thinking we don't need to change the topic id column at this time, just because I don't know any forum that is going to get anywhere near it - and again, if they are even remotely close to it, they're going to run into other problems long before that which require us taking a look and helping optimise it anyway, and we can deal with scaling it closer to time.

I have no issues with them being open source, provided that you're happy to keep on top of what comes in and make sure that any changes don't conflict with what Wedge is doing, really.

I still think it's likely to eat time trying to keep everything in step if we're not careful, but other than my usual cynicism about workloads, no objections :)

I find WeCSS better than LESS to deal with.

I've seen it elsewhere and while I find it interesting, I can't shake the feeling it should be a plugin rather than core.

Heh, I know that feeling.A fine goal :) Though I wouldn't worry about trying to reuse styles - I think it might be better to keep them separate but well documented, so that a theme which wanted to change everything could do so and require a shade more work than a theme that doesn't. As long as they're consistent, they don't have to reuse code - I can see it would likely make things worse to forcibly try to reuse code like that.I'd probably be inclined not to, not because of my usual fears etc. related to such but simply the maintenance aspect about how much work it would take to de-integrate then re-integrate it later with updates etc.Works for me :) It is much more clearly contrasted now :)

I agree certainly with the last two points, because that means you can handle saving, as well as throwing back errors etc.

Renaming? Yes, it would be nicer that way.

As far as making it a hook goes, yes, that's the sort of thing that should be a hook but the way it appears to be implemented could get interesting since it requires the ability to be able to selectively remove an item from the chain.

Off the top of my head I forget exactly how the hooks array ends up being, whether it is feasible to have hooked functions that function like that. Also, there is one stated use of that hook, which is what all the effort goes to - the question I have is what priority the existing hooked function should then have?

Basically, Profile-Modify.php lines 755 adds a function to that stack to reload the user if we're making a change and the current user is the user being changed (so we forcibly update the user information), but I would imagine that needs to be pretty much the last thing we do, no?

First of all, do not be too concerned about the number in brackets. It is primarily a display setting from the console tool, for setting how many columns should be used for displaying the field. If the field requires 5 columns but can handle 8, it'll store all 8 but it will attempt to use only 5 for displaying.

The deal, really, is the column type itself, and I'll actually grab the code from a helper function I put in the packages DB stuff:


So, there's your ranges for each of the columns, including the typical number involved for column sizes (just because the create/alter table statements *need* a size)


There are problems with using even more than a couple of thousand boards, let alone tens of thousands, and they all revolve around how board access is handled - throwing even a few hundred values into a WHERE ... IN (...) clause is not pretty, doing it for thousands of boards even less so. I've been thinking about this a bit, and have come to the conclusion that maybe we need to rethink how board access is physically implemented - perhaps we need to rethink {query_see_board} as a subselect.

Thing is, this limit is still present whether albums are boards or not, assuming query_see_board is still used to figure out access to them. It's just less noticeable.

Realistically, any forum that's big enough to be hitting 64K boards is also likely to have other problems and need support from us before it gets there anyway, in which case we deal with it before they get there.

Expanding id_group is no issue in itself but we need to rethink additional_groups in that situation. Unless I've been asleep for a long time and it's changed and I wasn't looking, it's done as a textual column in the members table, and there were issues in the past with it being truncated. I can't remember if we expanded that or not, but if not, we need to at least do that.

Lastly, performance. It's always a tough call but generally speaking, using the smallest size possible for your columns is considered to be the best approach. It keeps the table smaller, more importantly it keeps indexes smaller. And when you get up to huge sizes, the bottleneck becomes I/O not CPU anyway, so physically less data being thrown around = faster movement.

Yeah, I know you weren't one of those people. But there were an awful lot of applications that we simply refused, far more than most people ever knew about.