• Proposals
  • Show extensions that are really compatible

Hello,
I am not entirely sure but I have a feeling that when I am looking for a specific extension, the list of those extensions are not filtered with the compatibility of the Flarum version filter (by default, the last one, today 1.8.9.).

I would like to the filtered be applied and maybe, each developer (or maybe some trustable members), test their extensions and approve them to be "sure" that is compatible with the filtered Flarum version.

    SkakashiS each developer (or maybe some trustable members), test their extensions and approve them to be "sure" that is compatible with the filtered Flarum version.

    I completely understand this request. But you have to take into consideration that properly reviewing every extension is a massive undertaking. As a rule of thumb, we usually recommend people to use extensions only from authors/teams that have shown continuous commitment to maintain extensions. One of these parties is @FriendsOfFlarum (or FoF)

    SkakashiS I am not entirely sure but I have a feeling that when I am looking for a specific extension, the list of those extensions are not filtered with the compatibility of the Flarum version filter (by default, the last one, today 1.8.9.).

    Where exactly are you looking? The list on https://flarum.org/extensions is filtered by latest Flarum version by default. However compatibility on Flarum.org is currently derived only based on the composer information sent by the extension, so no tests or installs done.

      luceos As a rule of thumb, we usually recommend people to use extensions only from authors/teams that have shown continuous commitment to maintain extensions.

      This is why, at least, I suggest some confirmation "button" where the developers should press to been show in the "updated" list because now, I think that the filter is not working... or at least, how I understand that should work.

      luceos Where exactly are you looking? The list on https://flarum.org/extensions is filtered by latest Flarum version by default.

      Yes, I'm looking there. This is the reason I opened this discussion. 😛 The filter, as you say, may see the composer file but I think that is not enough to check if it works or not.
      In my opinion, it should show extensions that should work; especially for new administrators / users that trust that this is true.

      Maybe I'm wrong and I'm the only one that think in this way. This could also happen hehe, but I would like that the extension page to be more user-friendly and, maybe a bit more restrictive (we know that there are a lot of abandoned projects or some others with very poor information).

      Thanks for reading me. I don't want to make things much more complicated but just to get a clean evironment and useful.

        I have had some ideas about this in the past. Here are a few options:

        • Allow any registered user of Flarum.org to report how well a certain major version of an extension works. The form will have the option to just click "works", but also to optionally add how well it performs and what this version adds in regards to features.
        • Create a group of users that take upon them the responsibility to review extensions, create a backlog for them for any major extension version of any extension that hits a certain download threshold.
        • Allow the maintainer of the extension to click a button for any major release of their extension, send them an email to a page to confirm it is tested on certain flarum versions.

        I'd love to get more input about this.

          luceos I like the idea of users reporting, though some consideration will need to be given to what ratio of "works"/"doesn't worK" is the threshold as some users will have server/config issues falsely marking it broke, and conversely some users will not fully test it's functionality and mark it incorrectly as "works."

          I have in the past encountered systems that used automation to run a basic library compatibility check. Atlassian's marketplace use to offer a tester (cant find it anymore) and Prestashop's validator come to mind. Atlassian also previously required the plugin descriptor XML to denote specific product compatibility ranges. Feels like the latter would be possible in composer.json fields.

            eddiewebb Last night I was looking at a rather helpful website @clarkwinkelmann developed for assessing Flarum based forums overall states.

            I can't seem to recall the URL right now, hopefully clark could share a link for you here whenever he's able to.

            There's a particularly interesting feature at clark's site which may be relevant.

            Once clark's site finishes the assessment, it produces a variety of useful results about our forums, including a list of enabled extensions—which also features tags on any outdated extension that have updated versions available.

            I wouldn't have a clue how clark created this uniquely advantageous tagging feature, but my first thought was that it could be incredibly useful as a feature in the administration interface extensions dashboard. Basically we'd see little [Updated version available] tags appearing on extensions as they're updated.

              Yep. That's the one.
              Just realized it also shows a notice on the abandoned extensions too, which is pretty cool.

              The lab uses the same logic as Extiverse/Flarum.org, the compatibility/updates are indicated based on the Composer requirements published by the extension author.

              Well, tbh most of this flew right over my head. But the underlying concept reminds me of mazzly's 'Add-on Update Notifier' addon for XF.

              eddiewebb as some users will have server/config issues falsely marking it broke, and conversely some users will not fully test it's functionality and mark it incorrectly as "works."

              Yeah I'm afraid that a pure user provided review process will cause a lot of false feedback. In fact Extiverse - at some point - had a review feature, but it was used only to complain about things not working. So providing such a feature, will possibly cause a negative spiral and thus affect developer/maintainer spirit.

              eddiewebb Atlassian also previously required the plugin descriptor XML to denote specific product compatibility ranges. Feels like the latter would be possible in composer.json fields.

              This is already the case. But compatibility with Flarum 1.* is something entirely than >= 1.8.9. The code actually already did check these constraints provided and marked constraints that were either too wide, or too old (1.1.8 etc) as incompatible due to non-backward changes since release.

              eddiewebb I have in the past encountered systems that used automation to run a basic library compatibility check.

              This has crossed my mind too. It would be possible to spin up a clean Flarum install in an isolated docker environment, where the extension is tested. But .. what do you test? Some extensions require configuration before they work (eg API tokens), others only affect very specific frontend page or even worse, add their own. The effort to create a test tool that would be able to identify the areas impacted by an extension is .. massive.

              So yeah 😬 😅

              SkakashiS This is why, at least, I suggest some confirmation "button" where the developers should press to been show in the "updated" list because now, I think that the filter is not working... or at least, how I understand that should work.

              I feel a button isn't entirely what we need to look at. Even if it's a button, what would it mark compatibility with? Just the last version? The composer file of the extension already allows marking compatibility, and developers can do a few things:

              • make it very wide, eg 1.*, as a consequence it is more than likely the extension isn't compatible with latest Flarum versions because a lot has changed between 1.0 and 1.8
              • make it very narrow, eg 1.8.9+, as a consequence this version of the extension cannot be installed on older Flarum versions

              What I could potentially look at is when there's a wide constraint, whether the extension has received a recent update. If that's the case than these newer versions are compatible. However this still does not resolves the initial issue, a version of an extension is published and it still breaks Flarum.

              What would potentially be a solution is to have a button available to users that just says "This works on Flarum <version>" with a dropdown. This would act as a confirmation. I could potentially gamify this and attach milestone rewards for continuous assistance in this matter, but then again in that case I almost return to my initial idea:

              luceos Create a group of users that take upon them the responsibility to review extensions, create a backlog for them for any major extension version of any extension that hits a certain download threshold.

              😊

                13 days later

                luceos What would potentially be a solution is to have a button available to users that just says "This works on Flarum <version>" with a dropdown. This would act as a confirmation

                I like this idea. That the developer or "trusted users" could update that status (or maybe a lot of confirmed people -no BOTs- with a "vote" style).
                I mean, I imagine something like:

                • Extension XXXXXX - Tested and working at Flarum 1.1.8. ...
                  Meanwhile, we are in version 1.8.9. but at least you know that it's last stable version was tested in the 1.1.8. because some extensions can not being updated since a lot of time ago but still working. So comparing last time it has been updated with current version is not a valid option (I think).