Search found 201 matches

by Erik Frèrejean
Wed Jun 06, 2012 8:00 pm
Forum: [3.x] Discussion
Topic: Events on $template->assign*()
Replies: 10
Views: 7019

Re: Events on $template->assign*()

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.
by Erik Frèrejean
Wed Jun 06, 2012 7:51 pm
Forum: [3.x] Discussion
Topic: Events on $template->assign*()
Replies: 10
Views: 7019

Re: Events on $template->assign*()

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. ...
by Erik Frèrejean
Wed Jun 06, 2012 7:07 pm
Forum: General Development Discussion
Topic: [RFC] Changes to how 3.1 will be released
Replies: 8
Views: 6823

Re: [RFC] Changes to how 3.1 will be released

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.
by Erik Frèrejean
Wed Jun 06, 2012 7:05 pm
Forum: [3.x] Discussion
Topic: Events on $template->assign*()
Replies: 10
Views: 7019

Events on $template->assign*()

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...
by Erik Frèrejean
Wed Jun 06, 2012 6:49 pm
Forum: [3.x] Discussion
Topic: rtl base communities BBCode
Replies: 21
Views: 14508

Re: rtl base communities BBCode

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 ...
by Erik Frèrejean
Wed Jun 06, 2012 11:42 am
Forum: [3.1/Ascraeus] Merged Event Requests
Topic: [RFC|Implemented] core.append_sid
Replies: 5
Views: 10031

Re: [RFC] core.append_sid

Corrected the RFC to list the correct variable names.
by Erik Frèrejean
Tue Jun 05, 2012 9:06 am
Forum: [3.0/Olympus] Discussion
Topic: phpBB 3.0.11 Release Candidate 1 published
Replies: 41
Views: 55044

Re: phpBB 3.0.11 Release Candidate 1 published

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 that it is...
by Erik Frèrejean
Tue Jun 05, 2012 9:00 am
Forum: [3.x] Discussion
Topic: Ignore posts of all users on foe list
Replies: 25
Views: 18012

Re: Ignore posts of all users on foe list

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.
by Erik Frèrejean
Mon Jun 04, 2012 11:32 am
Forum: [3.x][Archive] RFCs
Topic: [RFC] Custom Profile Fields on Memberlist
Replies: 10
Views: 9941

Re: [RFC] Custom Profile Fields on Memberlist

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...
by Erik Frèrejean
Mon Jun 04, 2012 9:16 am
Forum: [3.x][Archive] RFCs
Topic: [RFC] Custom Profile Fields on Memberlist
Replies: 10
Views: 9941

Re: [RFC] Custom Profile Fields on Memberlist

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...