Development Discussion Board

I'm +1 on David his implementation.
Although I do think that all phpBB core template calls should include that event parameter, but yes filtering the calls that way seems the sensible approach.

Well I'm speaking without knowledge of the inner workings of the dispatcher, but you probably have a core.assign_block_vars , core.assign_vars and a core.assign_var event. Then a MOD author must know through which method his data comes in, pretty much like he currently must know which event to use. ...

I don't see why those changes won't be released, its a minor update so there will be an update path and otherwise you can quite easily create diffs through GitHub to find the changeset manually.

Not yet starting an RFC for this because I first want to see some thoughts on this. It is pretty safe to assume that a lot of the new events will alter variables send to the templates. One approach to handle this is by adding an event just before the data is given to the template object (see core.vi...

Also, perhaps turn this into a revamp of bbcodes for multi-language support and also translate things like colour/quote (actually I've just realised typing this. It should say colour as phpBB is English(GB) by default.) Translating them only confuses people even more. If I land on an English board ...

Corrected the RFC to list the correct variable names.

t_backoff : i dont think i had. There are 3 persons that said that they wont do it. We should only care for who wants to do it. If 3 said they wont do it, there may be others that will.. And the rest didn't even bother to respond with saying "I don't do it" ;). In general I'm pretty sure ...

RMcGirr83 wrote:My point is, I believe it much ado about nothing. Just don't allow the foe'ing, as is currently the case

^ that

As far as I can see a use case for such a feature it has a very small target area and therefore would fit far better as an extension rather then a core feature.

This would be up to the administrator, who would need to decide which fields to display there. Obviously, but it is IMO a bad thing to add a feature that hardly can be used due to the current styling. I do agree that changing the styling of the memberlist would be a good idea, but I think that shou...

How would this look? The memberlist is already crowded so adding even more fields will only cramp the output even more or you'll have to accept that it won't fit on the screen anymore. I do agree that the fields should be viewable on the memberlist but I'm -1 on overcrowding the page by forcing them...