Should we unbundle the feature plugins?
By Steve Clay
We really need core devs to aggressively focus on UX, but there are a few roadblocks:
- No one in core has ownership of the bundled feature plugins; we know they're not showing their age well.
- We know most users can extend them with something like {plugin}_tools so the thought of breaking that compatibility is tough.
- Having to wait until the next major version to rework UI means few others can provide input on work for potentially a long time.
- Having to document BC breaks in core adds overhead.
I suggest we remove all most feature plugins from core. Not just make them separate repos, but also not bundled. Installing Elgg would give you something more like Drupal out-of-the-box. Official Elgg plugins like blog would have their own versions not necessarily tracking Elgg core. If you want to make a plugin that extends blog, you would need to register a dependency on the blog release, not the Elgg release.
We already have separate repos for lots of plugins so we could start improving them right away and telling users feel free to replace your bundled 2.0 plugins with those in the repos.
Feedback and Planning
Discussions about the past, present, and future of Elgg and this community site.
@Matt Yes. Basically making them not core plugins, just branded under Elgg.
@iionly Yes, plugins would likely have to depend on both core version and versions of plugins they extend. That added dependency management makes long term site maintenance harder.
A less extreme version of this idea would be the Area 51 plugin. The downside being it would take additional work to migrate Area 51 features into the core for 3.0.
I feel there is currently a disconnection between the core and the plugin ecosystem. Detaching these plugins from core will not only improve their quality, but will also expose many problems that plugins devs face on daily basis. In the long run this will be a useful exercise, that will help shift the core team mentality towards understanding how core fits into the bigger picture and how it caters to the world of needs, and not the other way around, where the plugins are written to fit the limitations of the core.
I am pro separate repos per plugin. A big part of {plugin}_tools plugins that are available date back when elgg releases we very slow and changing plugins in the Elgg repo would take a long time before it was released. Even the current major release for the Elgg core is way to slow for plugin features. Therefore separating them from the core and putting them on an own release schedule is a good approach. This could mean we do not put effort in creating extra plugins, but improve core plugins altogether, or make them better extendable (less chance for BC-issues). And if those plugin get bundled in the Elgg download everyone would benefit.
- Previous
- 1
- 2
- Next
You must log in to post replies.