Check out the SMF Function DB!
Started by Arantor, February 13, 2013, 06:22:30 PM
Quote from: Arantor on February 13, 2013, 06:22:30 PMI'd love to see future versions of SMF have a stronger plugin system. Putting aside all the discussions related to hooks, there are two things I'd love to see.1. A more standardised method of plugins being able to have all their files in one place, rather plugin authors needing to do things over and over in terms of file management.2. Plugins being able to deploy to the server without having to mess about with CHOWN or CHMOD at all, so that you can just deploy a new installation and drop plugins in without having to mess around changing file permissions. This generally relies on point 1, though.Thoughts?
QuoteThe 1 HUGE HOOK would have to be flexible enough to do just about anything!
Quotehow it deals with security
QuoteThought you were asking for suggestions on what SMF might do to start a Plugin System for Modifications, that instead of Modifying SMF files, has their own files that modify SMF instead, by either, adding, editing, and/or removing features from it, however, in it's own files, not SMF Files. In this case, the next logical thing for SMF to do is to make a Hooks change. Or maybe continue to expand on hooks as they are doing currently.
QuoteNot sure what else they could be doing that wouldn't be a completely dramatic change, that would change just about everything and probably wouldn't be backwards-compatible anyways.
QuoteThat is, that they have reached a Dead-End, where as, something needs to change completely and not partially.
QuoteJust need more Arantors out there to make this happen I suppose...
QuoteMore contributors who are aware of all that has transpired, all that is transpiring and where it is likely to go from there. These are in all too short supply.
Quote1- I like SMF's consolidation of the source files into one direcotry and template files into another directory (with images as a subdir). I find this logical and straight forward...
Quote2- sometimes, it mitgh be easier, especially for newbies is a mod installed all of its files, plug-in style into a single mod-sub-directory like WordPress and Joomla do... each mod has its own subdirectory and structure independent of SMF core and/or any other mod
QuoteDoes this require that code be added to check for hooked routine/plug-in wherever you want to make a change? What if I want to add something at a point where there is no hook/plug?
QuoteWhat is the performance impact of this? Will SMF have to check for the existence of a module at every hook/plug point? Is this a runtime late binding (elegant, but slow, compared to compile-time binding)?
QuoteWow, GREAT STUFF Arantor!! Definitely need more minds like you!
QuoteIt's definitely a step forward, and the fact that there is also a $params array where we can set $params['local'] to empty, we can load up a CSS file from anywhere on the server, thus having css files into our own folders and images linked via css to our own sub-folders within our own folders.
QuoteI just wanted to say that this is a very HUGE step in the right direction of exactly with what Arantor is talking about!
QuoteWell, if it's all been done, than why are we talking about it? lol...
Quote from: Arantor on February 14, 2013, 07:02:32 PMQuoteWell, if it's all been done, than why are we talking about it? lol......others and I went off adventuring, trying all these things out and reporting back on what we found works well and what doesn't work so well, sharing the experiences of the journey.
Quote from: Arantor on February 14, 2013, 07:02:32 PMFor example, more of the steps required in making it more modular require breaking templates up so they aren't massive leviathans of code but each module of content is a single unit and that $context['sub_template'] as a minimum needs to be an array rather than a single function surrounded by one or more layers. Though you can get infinitely more interesting than that too.