Whats about Freeflarum? They still restrict extensions managements after the roadmap completed?

    wolfshards Probably @SKevo can tell us what he thinks about this, but I'm pretty sure that FreeFlarum won't add the package manager to their platform.

      This development sheet is very complete and consistent. I can't wait to test this new version and give you a feedback of my experience. Thank you for this huge development work.

      wolfshards to answer your question, then it's a no.

      As for me, I love where Flarum is heading with this. It will really help the less experienced people to install additional extensions for their forum - and that sounds really great for folks that self-host. But with FreeFlarum, there would need to be some system in place that reviews the extensions to only allow safe and trusted ones to be installed. And actually, there already is our GitHub repository that you can use to request new extensions, so I personally think that this feature would be redundant in our case anyways.

        ☁️ A major rewrite of our JSON:API layer that will drastically reduce the code extensions need to write.

        Has anyone written about the current challenges being faced? I assume this will involve a considerable backwards-compatibility break so I'm interested in what goals are in mind for this.

        Better support for alternative search drivers

        Are you looking to support a specific list of alternative drivers, or attempting something more generic?

        The 2.0 section in particular looks like it's been mostly distilled to items that break backwards compatibility, which shows considerable restraint. 😄 Folks tend to get carried away with those '.0' releases in my experience. Will be interested to hear more about those plans as details get figured out.

        I also appreciate the commitment to press forward with PHP deprecation. I know it's troublesome for many folks but it really does require apps pushing their requirements forward to get folks off of insecure versions in a timely way IMO, and no 7.x versions will be getting patches by then I'm sure.

          linc Has anyone written about the current challenges being faced?

          From my limited understanding (I haven't worked on the JSON:API side of things all that much) the current library we use is outdated and poorly documented which can/will lead to issues with PHP version compatibility in the future along with potential performance issues. Because it's outdated it also most likely does not support the most recent changes/upgrades to the JSON:API spec.

          Our goal is to completely replace our current library with an updated one that is properly maintained and documented for better performance and a better guarantee that it won't break when new versions of PHP are released. Not only that but upgrading will hopefully mean better support from JSON:API spec items that are newer.

              tankerkiller125 Oh I see, so it's more a "refactor-in-place" type of change, and less a "change the API structure to provide new/different data" item. Good clarification, I was off in left field with my reading of it, thanks!

                [2.x] Importers for other software, or integration with an importer framework.

                I still hope to beat 2.0 by a wide margin with a fully rebuilt Porter tool that also supports Flarum. Lacking something existing on your side, my current plan is to dump to SQL directly, but this is likely to leave some gaps (like secondary generated data or other things I don't want to duplicate the logic for on the importer side — I haven't dug enough yet to name what that could be). If there's some other format or considerations you'd like me to make, hit me up sometime in the next month or two. I continue to noodle on this most weekends after setting it aside for a bit over the holidays.

                  linc Has anyone written about the current challenges being faced? I assume this will involve a considerable backwards-compatibility break so I'm interested in what goals are in mind for this.

                  Not publicly yet, but this has been discussed internally somewhat. The main goal is to change the API for extending the JSON:API from "implement every endpoint for every model" to "describe the attributes, relations, restrictions, update rules, etc of a model, and the actual endpoints will be procedurally generated. This means that:

                  • Developers will need to write much less code to add or modify models. It hopefully won't be necessary to implement endpoints or serializers directly.
                  • Every model will (almost) automatically get some features w.r.t. filtering, sorting, searching, etc.
                  • Coordinating includes + relationships + etc will become a lot simpler.
                  • If the model implementation is generic, we can often do some graph traversals and figure out which relations need to be eager-loaded without that being specified explicitly

                  So this will definitely break extensions (although we will likely retain some BC layers where possible), but the client-facing JSON:API should only get more correct, if it changes at all.

                  linc If there's some other format or considerations you'd like me to make, hit me up sometime in the next month or two

                  I haven't spent a lot of time digging into importer architecture, but I imagine that with a modular core and a well-designed "intermediate" representation of data when converting from one forum architecture to another, it shouldn't be too difficult to connect Flarum to your project. Likewise, if you have any architecture questions or concerns regarding Flarum, please don't hesitate to reach out!

                        Honestly, when you take seriusly SEO improvements will be a +100.

                        I can't understand how an internal link (that comes from the same forum domain) is still marked as nofollow in year 2022. And other critical SEO bugs that remains from the first Flarum era...

                          Amarok yes that's on all forums (and I assume Zeokat is aware and referring to it), because right now the entirety of the post content is considered "untrusted" since the TextFormatter library we use doesn't have a concept of internal or external links. Links outside of post content shouldn't be impacted.

                          This is not a reason against fixing this, but just to point it out, not adding nofollow could also have negative SEO effect if users share many dead links.

                          For the time being I think an extension letting the owner configure "trusted" external domains that shouldn't be nofollowed is the best way forward to give flexibility to forum owners. Even if we make internal links automatically followed, I think whitelisting other websites could be a common enough use case for people who host their forums on a subdomain of their main website, so the extension makes sense.

                              Amarok Yes, and that is exactly what should be avoided.

                              clarkwinkelmann Everything you've said makes sense and is exactly what Flarum needs.

                              Regarding broken internal links, there is third party software that allows webmasters to audit these situations and correct them.

                                  askvortsov 💾 A new bundled extension that will allow you to install, update, and delete extensions, and update Flarum, without using a terminal. If we get this right, a one-click-install experience becomes easy.

                                  this option will be very nice and very useful, I hope it comes soon.

                                      askvortsov 🔍 Better support for alternative search drivers, along with a refactor of our frontend search UI.

                                      I will eagerly wait for it. Currently, the search bar is not working on those sites that use non-English Unicode languages like Bangla/বাংলা.

                                      Good luck 😍