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.

So excited 😄

      datlechin Getting things done with the terminal made me feel more special. I hope this feature comes in the distant future 😄

        Very surprised with a lot of things, I can feel that you are going to do what the current core team really wants nowadays, which makes perfect sense and is good for Flarum, it is certainly a fresh and motivating approach. Very excited to see this roadmap become a reality. All my support!

        Good stuff. Thanks as always for all of the work and thought you and the core developers put into this project. It’s one of the best open source, self hosted projects out there. It has been for a long time and will continue to be for a long time! 🙏

        Just don’t do too many things just to do them. Or because they are the cool thing to do right now. Which I know is an impossible ask.

        I wish extensions never had to break. Beta to 1.0 was understandable. Or, having to adjust something due to a new PHP version for example is understandable. Losing an extension completely and not being able to fix it is harder to take.

        But I know that’ll be pretty far down the road yet. Maybe by then extensions will create themselves and I’ll be nothing but a body and A.I.

        askvortsov 💥 Features!

        🥰 That's so amazing if you add those features for shared hosting 😉
        Flarum is in softaculus and maybe will be the perfect time to add those features.

        Will flarum grove up and continue like now with his great community

          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.

          🔥🔥🔥🔥🔥 managing a server is really a big headache that's why we look for shared hosting options, make flarum fully compatible with shared hostings including extension store like wordpress plugin store.

          askvortsov 🧩 Widget support built into core, making it simpler and easier to customize frontend layouts.

          🔥🔥

          askvortsov 📥️ Importers for other software, or integration with an importer framework.

          🔥

                Excellent roadmap, guys!

                askvortsov A new bundled extension that adds automated tools to help assist with GDPR compliance.

                IMHO, although it might be not a so "optically" observable feature for a regular user, I find it to be of extreme importance for Flarum's sustainable development nowadays. Very nice!

                  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!