I was thinking about how many things in Elkarte really ought to be addons and how many addons might do better in the core. We seem to have many things like the News Fader which really ought to be addons rather than core functionality.
Perhaps it would be better to create some official Elkarte addons that could be included with the installation? For example, the News Fader, the Like system, OpenID logins, calendar, etc. from the core. And things like SimplePortal and my external authentication addon from the addons. These things should be a selectable option when downloading Elkarte for installation rather than baked-in functionality or 3rd party addons, since they're not technically "core" functionality to a forum engine, but are important to a lot of people using Elkarte.
Of course, this would mean handing over the code for any volunteering addons to the Elkarte team, which would then fall under the Elkarte license.
Opinions?
Yeah pretty much. Just choose the components you want to install with the core.
I'm not so sure about removing them and let the user pick what they want at install (just because I think the "normal" admin just picks the first package he finds and use it, and if it doesn't contain what he wants he goes somewhere else).
Though, I certainly like the modularity approach.
I think I wrote something in that direction as well, suggesting to make any the "non-strictly-forum" feature (calendar, likes, mentions, portals, etc.) isolated entities, attached to Elk using the same hooks/events any addon would use.
That alone would allow updates of the modules without having to update the "core".
Okay, "crazy" idea.
Each module could have the "toggle on/off" inside the core, but then the code is downloaded and installed only when the module is activated, and the download could happen from a github repository (for example).
And new modules could be introduced fetching a feed from github (with a cronjob).
And, yes, the news fader should definitely be something "external" (and it should be pretty easy to separate), and maybe more powerful.
And now I stop, because I'm already flying way too high. LOL
This, this, this. Pretty much exactly. These features should be using the same hooks as addons rather than being heavily integrated. This would allow us to provide a "lite" core package which could be configured with extra features. Almost everything listed on the "Core Features" page of the admin panel should be an external module.
It would be fantastic to be able to install these from a Github repo. Much easier for the admin to toggle on and off too, and check if anything needs updating.
Cross-posting because this topic makes much more sense than the other. ;D
Still working on that, today I extracted the polls from the Post controller:
https://github.com/emanuele45/Dialogo/commit/000609c3a96734c99647f76219e04611568144f6
doing so I had to add few more triggers and optimize some stuff.
Next should be the drafts, but here I have a doubt: is it better to put the drafts as a "module" of the posting action, or maybe give them a completely different controller, that calls up some "validation" code from the posting?
Certain things like OpenID login which are related to very core functionality should stay in the core. Of course the team should try to avoid WordPressisms (my own word for huge features which are part of the core but are only relevant for 1/20 of the users at all).
OpenID logins are certainly
not core functionality. A site would function just fine without.
In that case, I'd say the log in is the "core" functionality.
Then the functionality can have different implementations that can be the "internal" (with user/pwd typical of ElkArte), or the "external" (OpenID, OAtuth, a bridge or whatever).
And OpenID is one of the core implementations of the log in function.
And with this:
https://github.com/emanuele45/Dialogo/commit/08741584927c86b4f8b98ee3e23cdbc7c7fd02f4
Post_Controller is down to 1644 from the 1.0 2346 lines!
And there are still other stuff to take care of. :D
ETA: yes, I know I'm only hiding the complexity somewhere else, but re-organization is the first step to understand what exactly is going on and where. ;)
Awesome work ema! Couldn't agree more on splitting up complexity. At work I spent the better part of 1.5 years working on what we called the "blob". A huge project with over a 1000 files in it. I literally pulled over 70 stand alone projects out of this one project. Now I've been working on removing inter-dependencies between them. Not fun... but soooo worth it now that I've had to alter/change/add code to the smaller projects. lol
You guys are doing so many great things with SMFElkArte that is has needed for so long. Still a long road ahead, just wish I could be more involved in it...
That was a hell of a spagetti-code!! LOL
I'm going to get carried away pretty badly on this... almost like (or even more) than Norv in certain circumstances LOL.
Just today, I did some more stuff, approaching the admin panel as well, in particular:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9
and:
https://github.com/emanuele45/Dialogo/commit/ab21cb6f91aa1b6f8eb9fbf8b93af31e33aa071e
What do they do?
Instead of adding entries directly to the core features array, for example, the code "autoloads" core features:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9#diff-164bf3b768f714cbe8623c6dc556692eR291
it uses file name pattern and a static method:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9#diff-1f8b3d2604cab5d04aa205c77628f680R35 (this is for the drafts for example)
the same applies for the menu entry:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9#diff-79a5e5f23e833f0d50fc481fd8e59cbbR581
and:
https://github.com/emanuele45/Dialogo/commit/9c46316c990e1b6cd8cf0952480573e0c80f1bd9#diff-1f8b3d2604cab5d04aa205c77628f680R55
What do you think?
And in particular, what would you think to extend this to any other "core feature"? (Renaming the "Core Features" page to "Modules" or something like that.)
Holy crap ...
/me marks this as unread as I've had to much wine to comment ! :P
LOL
More thoughts for when Spuds has stopped drinking beer! :P
At the moment I'm thinking at how to automatically load addons without too much hassles.
The first approach I had in mind was to scan the directories, load all the files with a certain naming pattern (i.e. ".addons.php" or ".integrate.php", or similar), scan for classes with a certain naming pattern, loads everything and then define what was active and what not and run only what was supposed to be run.
The advantage of this approach would be no need to store almost anything into the database, the addons by themselves would be able to determine if they are active or not and act accordingly. In addition an addond would be installed/uninstalled just by placing a file/directory at a certain place (e.g. in the sources directory or in a special directory like "integrate" somewhere).
This, tough, has a couple of drawbacks:
1) it requires a scan of the file system at each and every page load,
2) it has to load a bunch (maybe large, dunno, I know people that have some hundred of mods installed or idling into the packages directory) of files just to find out if we are using them or not.
Additionally, the "drop the file to enable the addon" may or may not be nice, so I decided to use a slightly different approach.
Like for modules (that at the moment are "things" bound to one or more specific action, like the drafts for example), there are two phases:
1) the admin area, here all the addons and modules are "loaded" to show an entry "somewhere" (most likely the packages page itself, even though at the moment I'm using core features for modules, but because they are already there...) with a toggle, that "enables" (the equivalent of the current install) the module/addon, when enabled, Elk saves the "data" (the file name and the subdirectory it is stored to) of this module/addon somewhere into the database (being lazy I'm currently using the settings table, in a second moment a standalone table can be used),
2) all the other pages, in any other page, just the enabled addons are loaded, and hooks are "registered" on-the-fly, when the file of the addon is loaded.
This way, only what is really necessary is included and is run.
I'm not sure it makes any difference in terms of speed or memory or whatever, though it looks less "bloated" to me that way.
You shouldn't touch the filesystem if you don't habe to. Remember, it is the slowest part of the computer.
Make it so that it scans for people with permission to enable plugins and alerts them that there are new plugins available. Cache that and make those load from settings. Only enable plugins when an administrator says so. Require each plug in to have its own directory and make the bootstrap file either be the name of the directory which implements an interface containing a method to get the name (getPluginName) or something like "PluginBootstrap" so you're not searching for the file.
Yep, that's sort of what I'm doing, not (yet) exactly though similar.
Addons loading:
https://github.com/emanuele45/Dialogo/blob/b1a569006e307d7a1bb8de2a5ff2e7a0a7482eb3/sources/Hooks.class.php#L220
So it gets addons from "somewhere" (the database usually) and registers the hooks.
Addons "discovery":
https://github.com/emanuele45/Dialogo/blob/b1a569006e307d7a1bb8de2a5ff2e7a0a7482eb3/sources/Hooks.class.php#L260
Basically grabs anything that is named "{Something}.integrate.php" in a directory or any subdirectory and use a composer.json file (yeah, it is a bit bold on my side call it "composer", but for the moment it's just to give guidances on "good practices") to give some general informations.
And the discovery is used in the core features page to populate the page:
https://github.com/emanuele45/Dialogo/blob/b1a569006e307d7a1bb8de2a5ff2e7a0a7482eb3/sources/admin/CoreFeatures.controller.php#L284
https://github.com/elkarte/Elkarte/pull/1950
/me is out for a beer now... or two. xD
Question: at the moment I put all these "modules" into the subs directory. Is it the correct place to have them?
I'm asking because some of these modules use superglobals ($_GET, $_POST, $_REQUEST) and/or have fatal_errors, and stuff like that. I think I tried to minimize it, but some are likely still there.
...hmm... something to think about.
The subs directory seems correct, maybe it's just a matter of clean up a bit the things. :D