Thoughts on the Extension Ecosystem

askvortsov

I'm fairly new to Flarum, and wanted to share some thoughts and insights about the extension ecosystem and core-extension relationship as a newcomer who hasn't yet had time to grow accustomed:

One of Flarum's most interesting design choices is to keep the core as minimal as possible, and move most functionality into extensions. I think this is overall great, but there's a few issues that I have bumped into:

Crowded Extension Management: In the same way that packaging every feature imaginable into core would be chaotic and bloated, needing to install 20-30 extensions can also be crowded, confusing, and result in extension clashes. I think that some extensions, especially smaller, universal ones, could be packaged with the core. https://discuss.flarum.org/d/22727-show-password/5 comes to mind as an example.
I think that we should be a bit more liberal in choosing which extensions to bundle by default. There are features that are generally considered to be essential forum features (Private Messaging, User Management, User Profiles, Censored/Blocked Profanities, a conventional categories view, an accessible error log). For some of these, extensions already exist (Byobu + GiffGaff PR, FaF User Directory, FaF Masquerade). I think these should be bundled for 2 reasons:
- Just like tags, most forums are likely to want them, so bundling makes life easier for less technical forum managers
- Other extensions might rely on them. For instance, I'm currently working on a SAML2 Extension, which would integrate with Masquerade (if installed).
The lack of documentation of extenders, actions/listeners, REST API, Authentication, etc is a barrier to entry for extension developers. I believe this is being worked on, but wanted to mention it regardless
On a brief tangent, I actually think that Masquerade could be included with Core: I know that there's been a lot of discussion around UTF-8 compatible display names, and this could be an opportunity to generalize this feature to profile fields in general. Additionally, a lot of potential use cases of Masquerade are as a dependency for other extensions, so including it in the core base would make sense
Some extensions depend on / are incompatible with other extensions. Maybe we could add a check to the extension activation system that wouldn't let you activate an extension if it's incompatible with a currently installed extension, or depends on an extension that isn't installed. Would also require de-activating a dependency before deactivating the dependent extension. Incompatibilities and dependencies could be specified by extension authors

[deleted]

askvortsov Hey, just a note, you double posted 3 points 😃

Kind regards.

Littlegolden

askvortsov *Crowded Extension Management

So agree with this.

jordanjay29

askvortsov needing to install 20-30 extensions can also be crowded, confusing, and result in extension clashes

I've long (though not loudly) advocated for savvy community members to create "extension bundles" or extensions that are nothing more than a composer.json file that calls the installation of other extensions through the Composer require command. You can see this in action in the BBBBCodes Extension. Essentially, just a curated pack of extensions that someone has selected and tested to ensure they work together well. It's a middle-man step that some might see as extraneous, it might slow down upgrades for some extensions as bundle maintainers would have to test before updating, but it would give some users a peace of mind and convenience that seems to be a growing need in the Flarum ecosystem.

This would alleviate points 1, 2 and 4. I understand the joy of having a one step installation, but this approach ignores the fundamental structure of Flarum. It's built to be a framework that can be extended. Default bundling of extensions means, for the Flarum team, that they take on the development and maintenance of those extensions in an official capacity. That's obviously not ideal when our core software is still in beta, and we're pushing hard to reach a stable version for the API (which will, in turn, give greater stability to extension developers). This is why development teams like Flagrow, Reflar and now Friends of Flarum have risen up and tackle extensions that are useful and considered necessary, but are too much for our core development team to take on officially.

askvortsov The lack of documentation of extenders, actions/listeners, REST API, Authentication, etc is a barrier to entry for extension developers. I believe this is being worked on, but wanted to mention it regardless

This is an excellent point, and one that we struggle with as a team. We had some documentation writers, once upon a time, but they didn't survive in that same capacity. Flarum could definitely use new ones, folks who are interested in writing technical documents for others to follow, and who have the capacity to learn to understand code. If that's you, feel free to reach out to me on Discord.

askvortsov Some extensions depend on / are incompatible with other extensions. Maybe we could add a check to the extension activation system that wouldn't let you activate an extension if it's incompatible with a currently installed extension, or depends on an extension that isn't installed. Would also require de-activating a dependency before deactivating the dependent extension. Incompatibilities and dependencies could be specified by extension authors

This is actually possible to do with composer.json, it simply requires extension developers to be aware of incompatibilities and assert the protections their extension needs. If any developers are reading this and need to know how to do this, check out the Composer conflict docs.

askvortsov

[deleted] Hey, just a note, you double posted 3 points

Fixed, thanks for letting me know!

askvortsov

jordanjay29 I've long (though not loudly) advocated for savvy community members to create "extension bundles"

That's a really good idea! Might be good to add a section to the official docs. The only issue is that it doesn't decrease the number of extension settings that need to be managed in the admin dashboard

jordanjay29 That's obviously not ideal when our core software is still in beta, and we're pushing hard to reach a stable version for the API (which will, in turn, give greater stability to extension developers).

This all definitely makes sense. Maybe some of this could be revisited later on, but I definitely understand that the core team's priority is building a solid base before getting distracted with other stuff.

jordanjay29 We had some documentation writers, once upon a time, but they didn't survive in that same capacity.

From my understanding of the B12 milestone, there's gonna be a lot of improvement to extenders and middleware, right? This could be a good opportunity to recruit some writers. Maybe an official post about this to get attention? And yeah I'll reach out.

jordanjay29 This is actually possible to do with composer.json, it simply requires extension developers to be aware of incompatibilities and assert the protections their extension needs.

That would definitely cover the conflicts part of it, but it wouldn't help in terms of requiring a dependency to be enabled before a dependent extension is enabled, right?

jordanjay29

askvortsov That would definitely cover the conflicts part of it, but it wouldn't help in terms of requiring a dependency to be enabled before a dependent extension is enabled, right?

I think this can be done programmatically when the extension is enabled. IIRC, one of the Flagrow (now FoF) extensions does it.

EDIT: I may be misremembering, don't take my word for it.