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 😍

                                9 days later
                                5 days later

                                I've only just joined but like the look of Flarum a lot and I'm keen to see where the project goes.

                                askvortsov More tools to simplify managing extension infrastructure, updating extensions for new Flarum releases

                                Sorry if someone already asked about this. On the roadmap it mentions tools to manage extensions. I was just thinking about the fact that you can easily have 20 to 50+ extensions. Maybe more. The main think I don't like about Flarum (and I LOVE Flarum) is having to, one by one, deactivate extensions.

                                Will core one day have a bulk deactivate, bulk reactivate, and bulk purge database for extensions? And of course an uninstall option that can be used without composer. But, more importantly in my opinion is, more bulk actions.

                                  17 days later

                                  One tip for next update.

                                  Walys
                                  I think, "preview mode" should be available for all messages directly via core function.
                                  I think is more vital in OP message than for replies. In markdown not view the real desing when you type in and for large first post "preview mode" is essential.

                                  This is the correct site to this message or have other thread?
                                  Maybe in github or in this thread it´s ok?

                                      Walys Thank you for the suggestion, but this is somewhat unlikely to happen. New discussion preview is an opinionated feature. Should the preview be on top? Side-by-side? Only in full-screen writing mode? As a toggle back/forth? In an empty discussion layout? Should the sizes be adjustable? The list of questions goes on. Additionally, as evidenced by there being community-made solutions, it's possible to make outside of core, and isn't constrained too much by not being in core. Since core is meant to be a framework, I'm not convinced that this feature needs to be included in core.

                                          askvortsov 😅
                                          Yes, have many question above as you said but all is about UX design. This is not my question.
                                          And yes, it´s possible to make outside of core and have in the forum one good extension to implement preview mode in the OP message. But it´s necessary go to install a one more extension to implement this "simply" feature when stay now in the core for all replies?

                                          But not problem, only have my two cents to go up the Flarum Proyect.
                                          IF all Core Developer think the same and not view this option, the users cant do any more. 😄