Wedge

Hmmmmmm

I'd argue that if its included it may as well be a feature (especially if enabled by default). Including a plugin by default for the 2nd reason you mention (example of how plugins can be made) was done in SimpleDesk and I can't say it went down as expected, it turns out that it may as well had been a feature in the end.

If it is a core feature that I dont want to use then I can disable it, fine no issues there; However it is a plugin that I dont want to use I just dont want it installed at all even if disabled.

I leave the more technical side of this discussion to those with the know how :P

:lol:It isn't how vB 3 works. Maybe 4 or 5 do, but 3 doesn't.


OK, let's nail down first of all what is or is definitely not a matter of semantics, i.e. technical matters.

It means we have a little more work to do on boot than we would on an otherwise fresh out of the box system, because fresh out of the box, it realises no plugins are enabled, and has to do precisely nothing about that fact.

The other thing is, there are ways to disable it and cause the house of cards to crash down if it remains as part of the plugin system. The system is designed around trying to be resilient, e.g. disabling in the event of inability to access the folder/plugin-info.xml file, and it will forcibly disable from that point onwards. But if you have plugins linked to it, they're going to fail (though the plugin manager will attempt to deal with that too, but only in the admin panel, not more generally)

The other problem is that whatever gets made as a plugin will get less attention than the core itself when it comes to bug fixing. Just because it's consolidated in a single place, unless that place is in the core properly, it's likely to get overlooked. I found this more than once. Sad, but true, and a lesson well learned from SimpleDesk - the amount of bugs I discovered through that bastard front page plugin was incredible.

Even if it a plugin that is shipped, forcibly enabled and impossible to disable without manually fudging the DB and so on, it could still cause problems if it does ever get disabled.

But I agree on the 'being a good example'.Oh yes, that bastard front page. I spent far too long making that >_< It would have been better as a core feature, off by default in hindsight. But essentially that's a minor feature.This, ultimately. The technical issues are all surmountable, but the semantics and perception are much, much harder to move.

Particularly in the case of the notifications system, which to me is not just a core feature but it's a core feature you'd never want to disable, in which case there's no need to provide the infrastructure that gives the chance of it being disabled. That's the real advantage of it being a core feature, and I don't like having to run around pretending to the outside world that something is other than what it is.

I'm fairly sure vBulletin had some default plugins, but it's been a long while since I used vB4 so I'm not too confident about that. But Joomla/Drupal and majority of CMS definitely do.This is perhaps a problem that's most prevailing to me. If a person wants to screw up his forum he can do n number of ways, deleting a couple of essential files being one of them.Currently the notifications system is based on hooks, if you want to integrate into core how would you deal with that?

Oh, sure. But that takes a certain amount of something really bad going on, or wilful intent to damage.Wouldn't be hooks. It would just be straight loadSource and direct invocation of things, plus the hooks provided by the notification system etc. would be part of the big list in ManagePlugins.

Okay

I would sort of like more voices on this though (especially Nao's)

I'm going on my experiences with SimpleDesk and the consequences of poorly thought out decisions that sounded good at the time and I'm sure you can see why I'm eager not to repeat that. However... I'm not totally opposed to the idea, it's just not my first choice, if that makes sense.

That's fair enough, it's just that I'm more of a plugin guy than a core feature type guy and modifying files things. Hence most of the things I implement are consolidated and run via hooks (even most of the projects I've created work like that). So I'm not a fan of including it into the core, IMO things should go the other way with more things being plugin (in the sense of how they are coded, not how they're presented if that makes sense. As in code should run via hooks and module).

Would you be inclined them to break more 'core' features into modules like that?

You mean "then" right? "Inclined", yes. Willing to do? Probably not :P. I liked the direction you took with calendar.

See, if I'm honest I'm seeing things standing at a crossroads, as I mentioned recently, where I'm looking at adding CMS stuff and essentially building towards making the forum a key thing - but not necessarily the core of the site, meaning that you could build a site that was a blog and a gallery without being a forum.

I won't deny that I can envisage a place and a time where we head towards what smCore were building.

You're assuming that by making things plugin-esque I'm implying that they're removable. That's two different things. I'm merely saying that just because a thing is core doesn't mean that it has to be directly embedded into files, but it can (and probably should) use hooks.

Oh, yes, they're quite different, it's just that with plugin vs core, there is a semantic implication that is quite important.

If something is perceived to be a plugin, even if it isn't, it will have behaviours ascribed to it. Plugins can generally be removed with impunity and generally have no significant side effects (unless you remove, forcibly, something that is a major dependency, but even then going to the plugin manager page will do some clean up on that). Bundled-and-not-disableable plugins are still 'plugins' and could be abused in the same fashion.

Unless we do something that pulls them out of the plugin area and pushes them into another folder, e.g. in Sources, but that raises a ton of other issues (since the language loader etc. won't like it)

And people, seeing something in the 'plugin' folder might assume, however incorrectly, that it can be removed.

Which means we have one of two problems: trusting users not to do something stupid, or redesigning 'plugins' to be 'core plugins' (which means they can't be removed, but also are able to properly use some form of source, template and language loader, since none of the current options will work) which still means separate maintenance that is neither a conventional plugin or a core feature.

Which would you prefer?

Perhaps a third option, a new folder in Sources that means something like modules (?) with the whole feature sitting there like a plugin folder (minus maybe the plugin-info.xml (automatically deleted on install?)) and included in a separate place then later merged with plugin behaviour on run time. Although to be honest this is more or less a special case of plugins as core plugins. You gotta trust the user a bit.

I don't really want to have to rewrite all of loadPluginSource, loadPluginTemplate, loadPluginLanguage[1], add_plugin_css_file[2] and add_plugin_js_file[3] but I don't see any alternative, because the core equivalents of these also aren't suitable, without rewriting the plugin anyway, to the point it might as well be a straight include...

ALL of those require the files to be in the plugins folder. Which I really don't want for the aforementioned reason.

1.	Though that needs an overhaul to handle the caching stuff
2.	Which is buggy because it hasn't kept up with the changes related to CSS files
3.	Which may also be buggy, not sure