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.
