Lack of WYSIWYG Editor is the #1 stopper for using of flarum

askvortsov

boc Which issues are you facing with https://discuss.flarum.org/d/26455-wysiwyg-rich-text-editor?

TB54

Valeyard With a site supporting dark/light theme, giving users too much ease of control over colour in a rich-text editor leads to frequent problems (such as they paste in pre-coloured text into a rich-text editors and then hit "post" or "reply" and it looks wrong). For that reason I'm glad there's no colour option in the editor itself, and if there was I would remove it.

Well, as much as I find Rich Text satisfying enough, for that specific thing I would be glad to see it proposed as an option - the consequence is not that I don't use color, just that I have to do it manually each time with bbcodes.

Valeyard

boc I'm sorry, but you completely misread my post. I didn't say anything about "rich text". WYSIWYG doesn't mean "rich text" or "color" or anything else. WYSIWYG is What You See Is What You Get and nothing else.

Rich Text Editors and WYSIWYG Editors are almost synonyms with what you're talking about. The only appreciable difference is that WYSIWYG should look 100% like the post output, whereas a Rich Text Editor may have some subtle difference, or it may still allow you to see the mark-up code that you write yourself (different ones handle that differently). @askvortsov's extension does exactly what you're asking with the only appreciable difference being in the exact appearance of emojis, and of course it cannot show you both light and dark theme. So it's not quite full WYSIWYG, but it's extremely close and further along that end compared with most Rich-Text Editors.

What I mentioned is most certainly relevant because it relates to how pasted-in text is handled. MyBB's for examples keeps formatting colour of the source, and that's bad if you have both a light and dark theme because it leads to frequent problems - and most members using Rich Text Editors do not instinctively understand how to remove the formatting when they paste text. Fonts are another annoyance as well - you don't necessarily want pasted-in text to follow the source font, and thankfully with Flarum you can't native select other fonts at all which I think is good.

I suggest you test out the extension yourself if you haven't already.

Anyway your point was that the decision to leave it out of the Flarum Core will hurt adaptation of the forum software. Respectfully I disagree with you on that. Flarum is incredibly popular already, and from what I can tell most people don't bother with the Rich-Text editor. Some people don't want to let their users have too much ease of access to control the text formatting, and prefer discussions to flow organically with standard text. Flarum is a different type of forum software to others, what some see as its drawbacks others see as an opportunity.

TB54

Valeyard and that's bad if you have both a light and dark theme because it leads to frequent problems

I don't really understand this, if it's the only reason to not put colors in the composer: it seems to me that it would just needs a CSS line in dark mode, asking to invert the luminosity of the span text with color in messages, and to keep the hue as it is (and maybe tame it a little for it to not appear too flashy).

Something like that (not sure of the values, this should be checked with several colors):

.Post-body span[style*="color"] {
          filter: invert(100%) hue-rotate(180deg) brightness(80%);
}

Besides, the color tool could be proposed only as an option if it's still a problem for some.

Valeyard

And what are you going to do about:

[color][url=...][img]someimage.jpeg[/img]...?

TB54

Valeyard Oh ok, i just understood! Well, easy, you invert again for img:

.Post-body span[style*="color"] {
          filter: invert(100%) hue-rotate(180deg) brightness(80%);
}
.Post-body span[style*="color"] img {
          filter: invert(100%) hue-rotate(180deg) brightness(120%);
}

Here is the BBcode example to do a test (with a dark red as color):


[color=#800000][url=https://www.google.com]
[img]https://discuss.flarum.org/assets/logo-9yg6hfqg.png[/img]
Link-text[/url]
, No-link-text[/color]

Here is the light mode result:

Here is the dark mode result with above CSS:

The values should be tested more precisely that said, as the result color for red is a little dull.

TB54

I don't understand: in your example, what would be different in the final code? There would still be a span around all with a color assigned, no?

010101

tankerkiller125

Ditto. And although I love and appreciate all attempts so far, all WYSIWYG type extension attempts so far have had quirks. There's some really cool extensions out there for Flarum that you get used to and if a WYSIWYG extension breaks or conflicts with just one of them, it's a real bummer. 😮‍💨

I've gone back and forth, but I am back to using the plain markdown editor.

I understand the periodic desire for WYSIWYG especially for forums where you have members who have never used Markdown and don't understand why when they accidentally typed # hello it became huge text. 😆 Then I have to explain to them... so, the editor supports markdown, this is why that happened, blah blah blah. And/or, I'll have a user from time to time who just cannot understand the markdown link format.

Although I get the desire and empathize, the plain editor is much more lightweight and typically compatible with all/most other extensions out there for Flarum. I think Flarum would have had to START with a WYSIWYG editor... from the very beginning. That way as extensions were built they would be compatible and there'd be less quirks. But, that wasn't what the creators wanted at the time.

In short, be careful what you wish for (compatibility issues / slowness / quirks). And, there's the already mentioned rich text extension which is very close to WYSIWYG.

GoodTimes

Hello everyone, I believe the discussion may have veered off in the wrong direction.

It's important to note that WYSIWYG editors don't necessarily need to support all the complex features of HTML5. Rather, their purpose is to provide a live preview of the content as it's being edited. In fact, a simplistic editor like the one currently available in Flarum (but with WYSIWYG) could be more than enough for 99.9% of forums, featuring only basic functionalities such as bold/italic/strikethrough text, lists, links, etc.

However, if someone requires more advanced features that are difficult to support for both dark and light themes, such as text colors, they can always develop a plugin for the editor.

I don't see any valid reason why a simple WYSIWYG editor lacking advanced features like text recoloring cannot exist in Flarum's core. With the ability to add complex features through extensions.

SychO

GoodTimes Core is meant to be simple and lean, a foundation that allows customization ad enhancement through extensions. Have you tried https://discuss.flarum.org/d/26455-wysiwyg-rich-text-editor ?

GoodTimes

SychO Core is meant to be simple and lean

Core's implementation of WYSIWYG could also (and should) be simple and lean. There is nothing wrong with that.

SychO Have you tried https://discuss.flarum.org/d/26455-wysiwyg-rich-text-editor

Yes, I've tried that, but:

It's buggy.
It's overcomplicated, and thus, it's too big.
It's an extension, so its future is uncertain since it is maintained by just one person. It receives a lot less attention, testing, and bug reports from the community than core features. Having fewer users leads to less quality and long term stability.
People (community) are more willing to invest their time, feedback, testing, and support into core features than extensions, as it provides greater assurance of the future stability of that functionality.

SychO

GoodTimes Unfortunately, core is also only maintained by very few individuals, so more features come at a cost. Rather then have a lean WYSIWYG into core, it would be better to have a lean WYSIWYG extension.

luceos Flarum is about keeping the number of bundled extensions and core as lean as possible. We don't have many developers, we don't have much capacity, so the capacity we do have has to be used efficiently and effectively.

ByeByeFlarum

boc

I created an account to make my first, and I suppose last, comment on this forum.

Although it's less performant and requires more resources, I have decided to go with Discourse for my forum because after I created a topic and I pasted information I had copied from a Wikipedia article, the text along with all of the links, formatting, and images... magically appeared!

Why would I rely on some 3rd party, unofficial plugin for, what is for my users, a crucial feature?

My dudes, it is 2024! I remember using WordStar and later WordPerfect before Apple introduced the Lisa, and ultimately the Macintosh. I remember using the Macintosh in late 1984 when I was a freshman in college using a #2 pencil to fill out the correct bubbles on something akin to punch cards in order to register for classes. The Macintosh's GUI and WYSIWYG blew me away! I was thrilled to not have to deal with arcane "control codes" and "reveal codes."

That was nearly... F-O-R-T-Y Y-E-A-R-S ago. If you think it's unimportant for myriad users to be able to natively copy and paste HTML formatting into forum posts, well, then I don't have any desire to engage you in discourse.

Being more performant and requiring fewer resources is irrelevant to me if Flaurm is ineffective at making it easy for my customers to easily paste in a WYSIWYG manner. Engineers tend to myopically focus on efficiency and features. But non-technical users, unsurprisingly, tend to focus on neither. Instead, non-technical users tend to focus on... B-E-N-E-F-I-T-S!

But the lack of native WYSIWYG ain't the #1 showstopper keeping me from using Flarum. What's the the #1 showstopper? The haughty manner in which the developers responded in this thread.

Pro Tip: being haughty will drive potential users away from Flarum.

Goodbye and Good Riddance,

Signed "Not a fan of Flarum"

ernestdefoe

ByeByeFlarum Well you know Flarum isn't for everyone. I understand and appreciate the fact that the Flarum team do their best to make the software as small and as light as possible so that you don't have to have a ton of server resources to be able to run the software. Pretty much all options are via a third party extension. Yes maybe they could create more first party extensions that will be regularly updated. I would love a WYSIWYG that is more updated maybe using a more modern editor but it is what it is currently. Maybe someone will come along and do something like that in time. The developers don't respond in a haughty manner. Flarum wasn't built for novice people to use hence the need for Composer. All it takes is a little bit of time and patience to learn and using Flarum isn't that hard. I will admit that sometimes they may come across as haughty because they think everyone has the technical knowledge to do things but I have asked before for them to dumb it down for me and guess what they DID. They replied in a manner anyone could figure it out. So maybe they just came across that way to you but I have talked with several of the devs on Discord and they are far from haughty. In fact they have been some of the nicer people I have talked to.

I have setup a Discourse site and while it has a ton of features it to me was overly complicated and because of that I quit using it. To me Flarum is more intuitive but you also have to realize is that Flarum hasn't even been out of BETA for that long not really considering how long it was in BETA. I think when version 2 comes out there will be a ton of changes that will make things easier on everyone. So me personally I am looking forward to 2.0 and what all it brings. Yes I know it will take time to get most of the extensions I use updated to work on 2.0 but the more major ones will be updated pretty quickly I would suspect (basically anything made by Friends of Flarum, Blomstra, and Clark Wilkleman) so I'm not that concerned. Good luck to you with your adventure with Discourse. Maybe you won't find it as complicated as I did.

toks

I am joining this discussion late and share the same frustration with not having an easy-to-use WYSIWYG editor for Flarum, especially for image attachments. Is there a way to replace the default editor with something like Trix or Quill?

GoodTimes

Why can't I like posts in this critically important topic?

luceos

I think this feature warrants it's ownProposals where it clearly states the intended difference with the existing wysiwyg editor differences.

RelicSystem

I think part of the issue lies in the fact that everyone approaches Flarum with their own agenda. Personally, I find Markdown preferable—not because I’m an expert or have every detail memorized, but because it’s lighter and less buggy than most WYSIWYG editors... in my opinion.

However, I understand why some users might desire a WYSIWYG editor. According to reports, the one developed by askvortsov isn’t suitable for everyone and has its share of bugs. I’m curious how many of these issues were reported to the developer (a quick glance at the GitHub repository suggests not many: askvortsov1/flarum-rich-textissues).

It’s puzzling why someone would create an account on the project’s forum just to criticize a missing feature they personally need. As mentioned earlier by others, the best approach is to propose the feature. If the community supports it (financially or vocally), the core team would likely consider it. Ignoring their own community would be stupid.

In the meantime, nothing prevents another developer from forking the existing WYSIWYG editor, providing patches, or even creating an alternative based on the same editor (ProseMirror). If, like me, you lack the coding skills, consider reaching out to those who do and collaborating with them.

GoodTimes

RelicSystem Personally, I find Markdown preferable

That's fine. You can choose to use a Markdown-only editor if you prefer, even if WYSIWYG is provided with Flarum by default. However, the majority will stick with WYSIWYG, and that's exactly why it's good practice to tailor defaults for majorities, while less common preferences (such as Markdown preference) can be offered as options or plugins.

RelicSystem It’s puzzling why someone would create an account on the project’s forum just to criticize a missing feature they personally need. As mentioned earlier by others, the best approach is to propose the feature. If the community supports it (financially or vocally), the core team would likely consider it.

There's nothing puzzling about that; people explain why they can't use Flarum—it lacks critical features for them—and that they will switch to Flarum when it's addressed. This is quite useful information for Flarum developers. So it's exactly what you said: they are proposing features vocally. Thus, your paragraph is really weird and contradicts itself.

RelicSystem In the meantime, nothing prevents another developer from forking the existing WYSIWYG editor, providing patches, or even creating an alternative based on the same editor (ProseMirror). If, like me, you lack the coding skills, consider reaching out to those who do and collaborating with them.

You're missing the main point: it's too risky to rely on third-party plugins for critical features like WYSIWYG or file uploading. It's completely normal to expect these to be available out-of-the-box, especially since every competitive software provides these features in their base distributions.

It has already been stated that if WYSIWYG were built into Flarum, it would receive much more attention from the community—more pull requests, bug reports, and other forms of help and feedback—compared to being just a plugin supported by a single person, with uncertainty about its future.

I love Flarum, but I definitely won't migrate my most important communities to Flarum from other forum software until WYSIWYG and file uploading are available out-of-the-box.

hackshuu

I'm using Flarum and while it would be good to have it in the core I don't mind using an extension, but I understand those who prefer to don't rely on an extension

ernestdefoe

hackshuu I understand the concern about it being a third part extension as well but tons of people are using it without issues but that doesn’t mean someone couldn’t have issues later on if there is a major change in Flarum. Something like this would be nice if it was done by either 1st party or by Blomstra or Friends of Flarum as I doubt they would be going anywhere any time soon. In fact me and @luceos was having a conversation yesterday because I was trying to post a link and didn’t do the Markdown tags right and the link didn’t show.

« Previous Page Next Page »