Wedge
Public area => The Pub => Plugins => Topic started by: Dragooon on March 11th, 2013, 05:02 PM
-
I really think a separate topic for this is a better idea rather than Arantor barging in all the threads and beating the drum :P. Basically:
1) I really want to maintain my GitHub repository
2) I'd love (some) my plugins to be core (partially because I think they're quite good candidates, but mostly because that'd be quite neat)
3) I really want to develop the features further as they're something I enjoy making and improving (especially the notifications thing, I think it's awesome). But I want my main GitHub repository (really!)
So, any ideas on how to solve this problem? I got a couple,
1) Make them plugins included by default and enabled, similar to how Joomla does a lot of it's things (or even vBulletin I think?)
2) Make them pseudo plugins, something that internally work like plugins but cannot be disabled or ironed out (and hence has no UI in Plugins area), hence make them automatically build from the latest GitHub revision (or tag, we can decide that later).
Making them plugins vs no plugin is more or less an argument of semantics, I'd say they're better as plugins because:
1) It's not really any slower or faster either way
2) They are good examples of how plugins can be made
3) Plugins are easier to maintain as they're consolidated in a single place
Any ideas anyone?
-
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
-
I really think a separate topic for this is a better idea rather than Arantor barging in all the threads and beating the drum :P.
1) Make them plugins included by default and enabled, similar to how Joomla does a lot of it's things (or even vBulletin I think?)
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'.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.
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.
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.
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.
-
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?
-
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?
-
Would you be inclined them to break more 'core' features into modules like that?
-
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, add_plugin_css_file and add_plugin_js_file 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.
-
Here's a third option (for real). The entire thing goes into Sources, Themes, languages folder with each file going in there respective places. But it still uses hooks. I can see this working, this way it cannot be disabled easily, still uses hooks, require no crappy rewrites (barring a couple of changes in the core plugin itself). I do loose my GitHub repository :P...
-
I don't want to make you lose your repository if it's at all possible :(
-
I don't want to make you lose your repository if it's at all possible :(
1) Let it be a pure plugin (and we're back to square one), now that I think about it, a special "core plugin" isn't a great idea. It's either fully plugin or fully core
2) This is something I'm taking from how Android gets built, that thing is distributed to atleast 50 repositories. Make a separate script that'll automatically fetch external dependencies and compile them into the core build. Notifications and other plugins being some of them. It shouldn't be too hard, I can perhaps do it if everyone's on board the idea. It probably does complicate things a bit (perhaps unnecessarily).
I can't honestly think of a way that'll work for all of us. Perhaps leave it as a plugin for now and re-visit this when Wedge's beta or something? Then we'd have more input, especially from active users
-
It could be done like, when we are installing wedge, it could ask if we want to install those plugins, something like they do with toolbars when we install some programs :niark:
-
It could be done like, when we are installing wedge, it could ask if we want to install those plugins, something like they do with toolbars when we install some programs :niark:
-
Nah, the smiley is related to the whole 'here's a free program, would you like to install some crappy toolbar while you're installing this free program?' Like various of the torrent software trying to foist Ask toolbars on you.
If I were seriously going down that road, I'd actually write a system to prepare builds on the server and let people build packages together if it's optional.
But something like notifications is not something I'd want as an 'optional' feature if that makes sense.
-
What if the notification core goes into Wedge's core completely and most of the notifiers remain as plugins?
-
That seems logical, though it might confuse people as to why they aren't getting notifications. At the very least I think replies to posts would need to be a core feature if the notification innards becomes core.
-
No, some essential ones will also be in the core along with notifications and the subscriptions core. But the less important ones remains as plugins.
-
Oh, that definitely works for me!
-
Okay, so how do they go in? I guess the two core plugins will be directly into the sources. Will the essential notifiers also be embedded into sources?
-
Ideally, they'd go in directly to the sources, including loadSource calls etc. as necessary with direct function calls as and when appropriate.
-
Ideally, they'd go in directly to the sources, including loadSource calls etc. as necessary with direct function calls as and when appropriate.
EDIT: I merely ask because I cannot commit to Wedge's repository, so will you or Nao do it or should I make a diff patch?
-
And yeah, I'd like to get this in the repository ASAP. After that we can start stripping out the existing subscription stuff and re-implement any missing features.
-
Well, the problem with stripping the existing subscription stuff is that you're still going to get people who want email notifications of crap >_<
XenForo does the same thing, though in XF's case they call it 'Watched Threads' so while you'd get an 'alert' (or notification) of a reply, if you've watched the thread, you'll also get an email about it.
I left a message with Nao about what to do regarding repo access, but I get the feeling a diff might be easier.
-
My plugin can send e-mails :P. The whole thing is designed to make every notifier configurable to send instant email, periodical summary of notifications or no email. So one can set to receive emails for topic subscription instantly and weekly emails of likes and mentions or any which way they want. I'll admit the email themselves are not nice (in terms of content) but its still a WIP. The idea has always been to give more options to the user, and receiving emails however they want is one thing which are all configurable at one place.
-
And since it's the most convenient way, I'll work on a patch in a while (one more week till my exams are over, but I'll probably work on it before that). I'll just implement the notification core in the first patch.