Wedge

yep, exactly. I believe with the new plugin system we should move in a more "modular" direction.. other candidates: the memberlist ( only the public part -> action=mlist), the forum statistics (action=stats).

I know, I know both are widely used but we could release these bundled with the wedge core and disable (or even enable) by default..

The idea is certainly that the modularisation of the plugin system should make it possible to do that; there is absolutely no reason why it shouldn't be achievable.

However, I do see a practical constraint: usability. Bundling plugins is doable, auto-activating them slightly less so, but it is possible - right up until the user wants to configure them or whatever - it means that they have to go to places they wouldn't normally associate with these things in order to alter them.

Also note that the statistics page could be unbundled, but I'm not sure the statistics gathering could be, unless it became a stock bundled plugin, enabled by default.

Ironically, though, our biggest plugin candidate is probably the one plugin I can't see us removing: AeMe, as the intention is to have it handle attachments and avatars to replace the existing core for that.

I'm sort of on the fence as far as moving things like mlist and PMs into plugins. I'd appreciate more feedback on it from what people want.

For example, how often is the member list disabled for non-admins? (who can use the admin panel version anyway)

Mind you, taking a look at PunBB's extension list, they have so much not in the core it's unreal. Having a CAPTCHA on registration, attachments and more are not core features :/

I'd tend to keep all of it in the core, myself. Just my opinion.

That's my gut instinct, as much as I can see the benefits to pushing some of those into plugins, the calendar especially.

Calendar is okay because there aren't much feelings (hard or good) for it I guess :P
Overall, yes we could bundle a few plugins in the main file, but mainly as examples of how they're used, more than ways to separate core from plugin.

*nods* I still look back at my own experience with PunBB on this one; polls to me are a pretty core feature.

What it comes down to really is inertia, how much people would be willing to put up with before considering different software.

One solution to problems would be to present plugins in a way that makes them as much a part of the admin area as the rest, i.e. allow to enable/disable them directly within the *homepage* of the area...

I thought about that, and that was in part why I moved the plugins entry to the end of the list so that any plugins could create their own items in there for that reason (and not end up pushing stuff way way down the list)

The mechanics of the plugin manager certainly don't prevent it, but I think having many items in the menu might be a bit fragile. Even with the rewrite of the menu code, I'm still wary of putting more than 10 items in any given menu area.[1]

In fact, that's why I haven't put in a specific interface for plugins to hook into to declare new items automatically, because I'm not convinced plugins should have to restrict themselves to a single top level item somewhere. Some plugins need an entire menu (like WedgeDesk), some will want configuration items embedded into the existing architecture (like reCAPTCHA), and I don't want to break that.

Plus, one of the perks of the list of plugins as it stands is that it tries to determine is a plugin is enable-able or not. I wouldn't want to apply that logic to be run on the front page every time.

1.	There's no reason for it on a technical level. In SMF, there was a good reason not to: the menu bg didn't go beyond 10 items. But in Wedge, the only reason I'm wary of it is usability. More than 10 items in a list is mentally harder to process unless they're grouped in some fashion.

I feel that if a plugin is going to be bundled it may as well be a core feature since it's shipped with the software anyway (this was my stance against SD's Frontpage being bundled). I think PM's are too widely used to be offered as a plugin, just seems to me that most would expect that to be a core feature. Memlist I can be convinced either way, I doubt too many bother to disable it or remove permission to view it. JMO

On the one hand, making it a plugin forces all its code and functionality to be in a small box, so to speak, and it does mean we can update a given feature independently of the core (assuming the core is flexible enough to support it, in SD's case that wasn't always true, especially of the front page plugin)

On the other, it does add the usability issue - and therein lies what you're getting at. If it is bundled, it's effectively saying 'I should be core'. But it does also allow for disabling and removing something you're not going to use and to re-add it back later.

Yes, I doubt most sites change the default settings, but I can fully imagine sites that would want those things gone, and I know I've been asked about both in the past (and incidentally, both PM and memberlist are the two areas removed by SimpleDesk's standalone mode, funny)

But it's that distinction that prompts me to keep them in, even if they could be split off without too much headache. Just because I can doesn't necessarily mean that I should.

Interesting to note how my own interpretation of things changes over time.

Specifically: http://wedge.org/pub/feats/6469/how-about-pms-being-listed-in-core-features/

That's probably the clearest case of an 'I want to be a plugin' example in this case. But certainly being disable-able centrally.

Funny you should link to that as I was just rereading that topic before making my next point which happens to be: If these are going to be kept as core feature a better method of disabling them should be available opposed to just permissions since these will still be visible to admin.

*nods* However it ends up being done, it should be done thoroughly for things like that.

I have no issue with them beeing a "plugin" in general as long as they are bundled with core..  Similar to the old SMF "Core Features", one mouse tick and the related feature is active/inactive.

IMO the biggest benefit of a plugin based architecture: you can simply enable / disable a feature, or update the plugin to a newer version or even better completely remove it and  replace it with something different, and all that without breaking the "core" itself.

Another big benefit: you could split the developement into various groups, someone can work on the PM plugin, another one can work in a completely different area.

Therein lies the issue. If you bundle a plugin in the core, why is it not actually core? Most users won't care that the two things are separate.

On the other hand, if you have these things as plugins, it's not so obvious about enabling/disabling them, which is the one reason I'm so set on removing Core Features. Go through the SMF 2 support board and see how many people ask about post moderation. I appreciate there's a reason it's disabled by default[1] but the simple fact that it's completely non-obvious that you have to go there erodes most of the value of splitting things off.

In our case, yes, we could put the calendar and memberlist and so on into the Plugins/ folder in the trunk and have them developed there (and thus auto bundled) but you'd have to go to the Plugins page to enable them, which is as counter-intuitive as going to the Core Features page, in fact possibly more so.

Which means I'd have to extend the plugin system to provide some way of directly adding items to the admin menu so they can be activated (much as the calendar currently can be)... doesn't seem that encouraging to me.

I'm not against the idea in principle, because I'm all too aware of the benefits of segregating the code up into bundles that are self contained, but I'm concerned at the usability for end users.

1.	Though I still think that's possible to overcome.