Wedge

Where is it used without a hyphen in the language files then? Last I saw, any use without a hyphen was internal...

The name isn't critically important, the idea behind it is. wetem is fine with me, weske reminds me of Hesk which I'd rather not be reminded of, thanks. Ugly ugly ugly.

Heh, I know what you mean!

Objectifying the template skeleton... hmm.

Well, let's say it's wetpl. What does wetpl need to know or keep control of that nothing else should be controlling or dealing with? Seems to me that it needs to be aware of the context vars attached to the skeleton.

So that means we have a class and it has its own variables that are internal. Since we don't want to allow access to any old routine, it'd be a private variable of the class.

We'd then create a function for querying the skeleton, whose purpose, essentially, is to just return that variable. (This is known as a getter, or accessor, method)

Then you'd create functions under the class that essentially do what loadBlock does now, but there's the difference that instead of having to modify $context, when you're inside the function, you also get $this, allowing you to refer to the internal variable(s).

Really, it'd still be basically the same as loadBlock now, except that it would belong solely to wetpl and it would be able to modify the private variables to prevent anything else touching or breaking them, because you're forcing any changes to go through the methods you've given everything else to use.

Would adding the streams provide something that currently can't be done without a lot of work?[1] If not, don't change it.

1.	To me, the answer seems to be no.

Very occasionally, I peruse the stats, and happened to notice that as of today, wedge.org has accumulated 1,002,000 or so page views for 2011. (Compared to 267,000 or so for 2010)

I'm not sure whether there are unseen factors at work (e.g. draft saving comes to mind) but whatever, I think we can safely argue that it's been a busy old year thus far!

Go on, then, yo've convinced me to rebadge things as plugins as far as new functions go :P

As long as we get away from 'mods', though.You are kidding, right? A tour of duty in the SMF support boards teaches you that most people running forums are not web masters how you and I would know the definition and most of them, honestly, don't even seem to know how to read instructions first - or, more infamously, will go round, tick boxes in admin, then wonder why it doesn't work how they expected. The number of people who write in with "it was working fine, then I did something and it changed it to <something> and now I don't know how ti fix it", especially with query less URLs (index.php/topic,1.0.html format), or ordering posts to have newest first.

This is why I assume user stupidity first and wait to be convinced otherwise.

Bump for the above.


Also, is the feed block totally driven by the skeleton now rather than late-injected into the sidebar as it used to be? It just occurs to me that some of the things I want to do may well rely on the feed block of the sidebar for positioning/ordering.

I tend to agree about distribution, that the number of people using Wedge, with English being, or not being, first language. I also agree with the logic about users who don't have English as their first language being able to acclimatise to Wedge having 'plugins', especially as other software has it and that it is, therefore, a consistent term - far more than add-on is ever likely to be.

That covers non-English users, but for English-first-language people, add-on might be more logical but plugin is certainly more consistent with other software and as such more likely to be understood by users of other software.

For first time users, though, I'd argue add-on is probably more approachable than plugin, which is why I went with that originally, but all things considered, I think you're probably right to be championing plugin.