Wedge

Exactly, I'm expecting that to be the case most of the time, but for the occasions it isn't, having a getter to see what's been added would be useful. Not sure a setter is needed though.

I think you're in the minority on that one, unfortunately. I suspect most people don't really care :(

As for $can_use, you're probably right.

And really, if you do want to rename it, just do it! :P As per WP:BOLD, and not even with a [citation needed] in sight :P

The idea was to parse the post then cache it, which seemed more logical to me than force whatever changes there were every time. In the case which prompted that, the hook makes DB queries.

Yes, it should be $s not $d, oops.

Fairly sure I just reused the same language string there, out of laziness. The whole disable/remove part is distinctly less polished.

I changed the mention because it referenced Modifications.english.php which doesn't exist now.

They're addon-item which derives from admin-item which is used in the main menu, and should be defined as inline block. The idea is that they're inline, but the entire container is right aligned, so the container is floated right, but I found the only way to make then work properly was to do it how I did it; if one item has 3 buttons and another only has 2, that item will have a space to the right so enable/disable buttons always line up.[nb]Though in hindsight, it's only ever going to be 1 icon or 2, not 2 or 3, because the combinations are (do-enable + remove, or do-disable + optional settings)

I'm no template designer :P

Re PHP 5.4 stuff, I read it as break x being broken, not break $var but it's easily possible that I misread it.

I must have missed the use of plugin at the time but it was quite late at night :P And $can_use... pass, can't remember, sorry.

I honestly wouldn't sweat too much. Make the information available to add-on devs, from the query object instance, in some fashion. If they want to check, that's up to them, if they don't, again that's up to them.

What I'd imagine is that very often the joins that are already in place will suffice, and that add-on authors will avoid extra joins if necessary. I'm not bothered with trying to hold the authors' hands too much, but provide them the tools to avoid problems, I can't make them use those tools.

Looks good to me :) I can conceive of some nasty situations with this, though, most notably about multi binding the same table unnecessarily.

For any given query, if a table is joined, two things could occur. Firstly, it's possible that users join the same table (with the same criteria) multiple times, especially if the list of tables isn't available to the binding method (can't see right now), since I'm not 100% clear how MySQL will optimise that case.

Worse, someone rebinds a table with an existing alias but with different criteria, e.g. INNER JOIN table2 AS t2 ON (t1.id = t2.id) INNER JOIN table2 AS t2 ON (t2.id = t3.id)


Just as a note to readers: this process will not be necessary on every query and unless you want to make queries hook able (or are using hook able queries), you won't need to worry about this and can just use the standard method.

I don't make videos much, though maybe I might have to make some for Wedge.

The post page is not the most extreme example I had in mind and it should be possible to do fairly easily - I'm just thinking of other examples that are less obvious, like the quick moderation ones that are designed to be subtle and out of the way that I see as being a problem.

But yes, per class would be nicer and more extensible in the long run. It is something I gave thought to but have had greater priorities of recent times :(