Change Composer to Redactor
-
looking great hopefully it will be on the core, this is so much better specially for the average users
-
We have tons of work to go including finding a way to get all of the existing composer plugins to be compatible (ex. Embed plugins) and making sure this works on mobile. It's a start, but we're confident
Thanks to @Drew-Llewellyn, this will be available for anybody using nodebb without having to purchase a licence
-
Make it bundled but disabled in the next release? Tell everyone here about it. Some will chose to use it. With a good field test and bugs ironed out during 0.7.1 it'll be ready for default by next release, protecting novice users during this first one.
-
I think the only question is compatibility between composer plugins. If it's an easy switch without losing functionality then why not?
I've also been looking at https://iframely.com/ (resurrected on a different thread earlier), if done right this could basically deprecate all other embed style plugins
-
Yeah, I definitely think an all-in-one embed plugin would be ideal. Many of our embed plugins add content in different ways: inline, box at the bottom, etc.
It would be good to get one standard format that all embed plugins adhere to, or supercede completely
-
Does it need to be in the composer?
Could you create a framework / API of sorts where any embed plugin gets called after the post is saved? I am not sure how the plugin API works right now, but if something was called with an array of links - it could then parse them and embed them in a flexible manner.
I am personally keen on the embed.ly API (not the JS solution) as it gives some amount of flexibility on what can be embeded - I like that they return entities and taxonomy which can lead to richer tagging.
-
@psychobunny it looks like if you use the github version of iframely it's free forever, at the expense of not using iFrames (oh no, the tragedy!). Is that right? Certainly seems like an easy win.
-
@shri Post content is parsed on its way out of the database, not on its way in. We try to preserve the raw content as much as possible.
So for example, the youtube embed plugin detects the presence of youtube-style URLs, and replaces them with the HTML embed code, every time the post is queried from the database.
-
@shri said:
I am personally keen on the embed.ly API (not the JS solution) as it gives some amount of flexibility on what can be embeded - I like that they return entities and taxonomy which can lead to richer tagging.
It seems that iframely also does this, and as @Drew-Llewellyn says, there's an open source version that can be installed as an npm package
-
@julian fair enough. And thinking about it, it is absolutely the correct way to go. And looking at code strategies from Wordpress / vBulletin looks like the post after it has been extracted and filtered on the way out of the database is then cached temporarily for x hours to ensure fast renders.
I don't think the embed preview in the composer is a big deal anyways. It is the final render that is more important.
-
New to NodeBB, but am loving what I am finding! I have had a lot of (painful) experience with WYSIWYG over the last few years. I've even gone so far as to build an Angular version of SirTrevor.js. Markdown seems to scare non-techy types, so I applaud efforts here to get Redactor on board.
@julian said:
@shri Post content is parsed on its way out of the database, not on its way in. We try to preserve the raw content as much as possible.
So for example, the youtube embed plugin detects the presence of youtube-style URLs, and replaces them with the HTML embed code, every time the post is queried from the database.
I must admit I am partial the block-style editors like SirTrevor or Makona as blocks can remove much of the inherent problems with WYSIWYGs. Storing data in blocks enables the preservation of the raw data as well as the necessary metadata. It is a change for folks used to MS Word, but I find block-style content creation is intuitive and a better fit for mobile devices. That said, it seems the team is up to the challenge of getting Redactor onboard I am very much looking forward to it!
@psychobunny said:
I've also been looking at https://iframely.com/ (resurrected on a different thread earlier), if done right this could basically deprecate all other embed style plugins
I've been using iframely for well over 6 months now, and am an absolute fan. I have been using it in a block-style editor as I mentioned above -- and it's near perfect. Figuring out embeds in a WYSIWYG is a hairy problem, and I applaud the NodeBB team if they get that solved.
All this talk of block-style editors almost motivates me to create a plugin. I'm still new to NodeBB, but if I find it's a suitable project I just might do that.
-
The more thought I give to this (and the more time I spend with NodeBB) I'm seriously considering a block-style plugin for some of the use cases I'm thinking of using NodeBB for.
-
From the browsing I've done it seems that posts are stored all as blobs of HTML, or is that wrong?
-
What would it take to store posts in blocks? I'm specifically thinking MongoDB where we could store a nested array of blocks that comprise the post. Each block can have associated metadata like whether or not it is an embed, tags, mentions, etc. (This can be done in Redis as well). Mongo has performance issues when arrays grow constantly, but I'm assuming here that posts aren't typically edited to go from 2 paragraphs to 100.
Would someone with some understanding of the underlying data model and code mind shedding some light on this?
-
-
@agd1 Post content is stored as raw markdown with the regular composer.
WIth redactor, the post content is stored in HTML because that is the only lossless way of storing the input data. I'd much rather save tokenised JSON over HTML, but I haven't really looked into other ways Redactor can output entered content.
-
@julian I hear you. There's are some pretty amazingly smart people out there who may know something I don't, but the only way I have discovered of storing tokenized JSON from traditional WYSIWYG like Redactor is to do a HTML to JSON conversion (and there are plenty of Node libraries out there that do this). While this may be a feasible solution for basic use cases, in my experience it is an absolute nightmare when we start talking about embeds -- and the modern web is clearly all about embeds.
I've been giving some thought to writing a plugin for a block-style editor, as I'll need that for my own needs anyway, but it would be great to have some help. The benefits to me are many, and there are really one two downsides: it's new for some people and you lost the ability to next images to the right of left of text (but is that actually a benefit??).
Anyone have any opinions/thoughts/interest in a block-style editor?
-
I wanted to build one for actually modifying templates. Kinda widgets system 2.0
-
@psychobunny do you think it would be large effort to start storing posts in blocks vs entire blobs? Haven't quite dug in to learn NodeBB's code just yet.
the metadata associated with each block could be something like
{ blockIndex: Number, //the block number starting at 0 blockType: String, //text. header, image, video, iframely embed, etc. content: String, properties:{} } -
@Drew-Llewellyn YES. When is it going to be integrated in nodeBB?
The standard composer is so bad......normal people cannot work with it in a normal way and get really frustrated when doing 10 minutes over 1 line of text...cannot even have a url within a visual
-
@Danny-McWilliams @Ali @jarey @leksar @zerefel @Djeber-Boudiba
It's in its early stages, but it's an official NodeBB component:
https://community.nodebb.org/topic/6093/official-plugin-redactor-composer-now-available-in-0-7-1If any devs are able to contribute to adding all of the available functionality that'd be great.
