The Future of Flarum: A Roadmap

linc

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!

linc

[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.

askvortsov

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!

Suiramus

askvortsov

Well, I have flarum installed the.. let's say the "normal way" through softaculous and this version will come out sooner or later, how I will be able to update it? Will I loose any data? Thanks

Zeokat

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

Zeokat You have a "noopener + ugc" and not a "nofollow" for internal links.

clarkwinkelmann

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.

Zeokat

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.

Akefu-Brewer

askvortsov Are you talking about Toby Zerner?

askvortsov

Akefu-Brewer Yep, he founded Flarum back in 2014.

Akefu-Brewer

askvortsov He also founded the software EsoTalk, which is what Flarum is forked off of, there was also an esotalk fork called Geteso.

Esotalk:https://github.com/esotalk/esoTalk
Geteso:https://github.com/geteso/eso

eSozluk

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.

Eldenroot

eSozluk Yes! Would be nice!

halimjr

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 😍

milk

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

010101

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.

Walys

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?

askvortsov

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.

Walys

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. 😄

010101

askvortsov As you know, there is already a preview feature when replying in core. That’s opinionated. Everything’s opinionated. I too have wondered for a long time why previewing on post creation isn’t in core. I try not to ask these things though because I know the answer is that core is bare bones. But, again, a preview feature is in core already… So one could argue this is enhancing/expanding that a little. And, since a preview-like feature is already in core I think it makes it harder to say that previewing something shouldn’t be in core. Unless you remove the reply previewing too.

Also, when I say preview should be in core, a core maintained extension would be fine too. Such as likes & mentions.

I think the way the preview extension I maintain does it is the right way for Flarum. You don’t want side by side because: mobile. But, I’m sure the preview extension I maintain needs a total re-code.

When 2.0 comes out one day, I may or may not have time to fix the preview extension I’m maintaining if it breaks. It feels like an extension that deserves a professional coder’s attention. This stuff is just an extra hobby for me. Not my main hobby, nor related to my job or schooling.

So I guess at a minimum I’m pleading that eventually, a core developer should at least adopt the preview extension I’m currently maintaining. 🥺🙂 Re-code it. Enhance it. Love it.

☮️

askvortsov

Walys The reason I listed all these questions is that there really isn't a right answer: depending on the community and target market, completely different combination of features could be needed. That flexibility is possible through extensions, but not really through core.

In the long-run, our goal is to make "installing one more extension" as frictionless and smooth as possible. Previewing replies was included in core in part because there was a clear best way to do it. That's not the case here.

« Previous Page Next Page »