Wedge

smCore is dead unless someone picks it up. Except anyone who does is likely going to start over anyway. So yes, it is dead.

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

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.

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.

: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.

Hmm, it should still have warned. Something is very much amiss.There's a bug report somewhere around here of someone using the select+drag of text to move it around, except the event was captured by the drag 'n' drop.The problem that I mention isn't that at all, I wouldn't mind but I have mentioned it multiple times now.

If you have an attachments system like that, you need to be able to reference the topic it came from, not so much for 'which topics use this' but 'can the person see this attachment'. Would really suck if attachments could be leeched without having proper board access.

Right now, access to a given file is based on its album. But that doesn't work for attachments whose access rights are implicitly different. Thus you need to be able to indicate where a given media item is supposed to get its authentication from, be that an album or thread access. Or, indeed, anything else you care to think of, e.g. helpdesk attachments.

I did suggest one method of doing this but you weren't very keen on it.

That's the great thing about having this caching mechanism, it allows me to explore all kinds of craziness like this ^_^