forced_root_block deprecation

[vjsingh]

Apologies if this is not the right place to ask this.

I found this in the docs: Important: Setting forced_root_block to false or an empty string has been deprecated in TinyMCE 5.10. For TinyMCE 6.0, this option will only accept valid block elements.

I want to prevent <p> tags from being generated on enter, and instead create <br>s. This used to be possible by setting forced_root_block to false.

Will there be any way to do this in TinyMCE 6?

See:
#6304
#2634

[Daijobou]

I'd like to know that, too. Otherwise, I guess we can't use version 6.

[EkimChau]

Hi everyone,

This is a good place to bring up your concerns around deprecated items that you rely on. TinyMCE is moving into the collaboration space, and we need to review and streamline what we support. 



The current forced_root_block: false setting is difficult to have working with block based content (eg: lists and tables). It can also block various editor functions from working correctly and cause non-semantic HTML to be generated. We can simplify our code by removing this support and prefer to find alternative approaches that is easier to maintain without the negative side effects this setting can create.

I'd like to explore and discuss your use case for using BR tags instead of paragraphs. Hopefully we can find a solution that allows you to continue serving the current use case and or improve it.

Please share your use case and why you can't wrap text in blocks and if you know of any alternative approaches to achieve your requirement that we can better support for you in the next major revision.

I'm seeking understanding of the problem to be solved and ideas or alternatives that could work.

TinyMCE Product Team

[Georgevanvelzen]

We used forced_root_block to have <br> instead of <p> because when you redirect the tiny text to email, the <p> get stripped by outlook and the text in the email results in being one large chunk of text. when using forced_root_block, the emails would format correctly.

[EkimChau]

Hi Georgevanvelzen,

I see your use case is around emails, and that outlook strips out html and just leaves plain text. I am familiar with this issue dealing with old email clients a long time ago, but not so much recently so i'll need to get more context on whats happening. Just some follow up questions to help me understand.

• Are you able to provide a code snippet of what the html formatting looks like before and after outlook strips?
• What percentage of your users experience this problem? Does it happen to all of your users or just some?
• Does it happen if you follow a strict HTML schema and use a HTML mime type?
• Does outlook strip out the BR tags and replace with newline or carriage returns?
• For others on the thread, is this the primary reason to use forced_root_block, is to solve problems with email formatting?

I'd like to fully understand the context and the conditions this occurs before we start looking for solutions

[Daijobou]

I'd like to explore and discuss your use case for using BR tags instead of paragraphs.

I honestly don't understand this question. TinyMCE replaces textarea and textarea does not use paragraphs.
Text is written much more often without paragraphs. Pragraphs are needed in scientific texts or in news and blogs.

In comment system or forum posts or or or ... paragraphs are not needed. Most users make a line break after each sentence. This is not what paragraphs are for. If we need paragraphs, we press Shift+Enter. There are also situations where you edit a part of a paragraph and it should not contain any other paragraphs because it is already contained in a paragraph. This would destroy the formatting.

[vjsingh]

I'd like to explore and discuss your use case for using BR tags instead of paragraphs.

We use the TinyMCE editor to allow users to edit the description of a calendar invite. <p> tags in calendar invites get translated into two line breaks (one blank line) instead of one, which results in lots of extra vertical space and is unusable for our users.

See this example screenshot, which would be generated by this text:

Hi John,
We're looking forward to speaking with you on Saturday, October 9 at 9:00 AM - 9:30 AM (EDT).
Feel free to reach out to us if you have any questions.
Thank you,

[EkimChau]

Hi, based on the feedback so far, TinyMCE has a getContent api that returns only text and \n newlines. This takes a post processing approach to the situation, where you create rich HTML in the editor and upon exporting the content, you cleanup the content to suit the publishing needs, aka email calendar or outlook.

Have a try of tinymce.activeEditor.getContent({ format: 'text' }) on https://fiddle.tiny.cloud/ and see if this approach could work for your use case, you will need to filter out any unwanted double \n\n characters as paragraphs generally resolve to double new lines

[russpowers]

Paragraph formatting was confusing for our users writing emails in TinyMCE, they want line breaks to work like the Gmail editor. And I've found that <br /> tags tends to cause the least problems when sending emails. If TinyMCE removes forced_root_block we would be forced to stick with version 5 I guess.

[dav-sap]

Im trying to understand, what about using forced_root_block: 'div' doesn't that remove the extra space p gives you, and also uses new lines and everything. Are there any issues with outlook here?

[vjsingh]

Hi, based on the feedback so far, TinyMCE has a getContent api that returns only text and \n newlines. This takes a post processing approach to the situation, where you create rich HTML in the editor and upon exporting the content, you cleanup the content to suit the publishing needs, aka email calendar or outlook.

Have a try of tinymce.activeEditor.getContent({ format: 'text' }) on https://fiddle.tiny.cloud/ and see if this approach could work for your use case, you will need to filter out any unwanted double \n\n characters as paragraphs generally resolve to double new lines

Thanks @EkimChau. This doesn't work for us though, because we still want html tags such as links.

Our use cases:

1. Calendar invites, as mentioned above
2. We have an editor that allows for editing text which will be included in other text. We want that text to be inserted within a single line, and thus can't be wrapped in <p> tags.

[EkimChau]

This thread "forced_root_block deprecation" has been moved to Github discussions, you can continue to follow this thread here https://github.com/tinymce/tinymce/discussions/categories/general

This discussion seeks to find a suitable path forward for developers requiring the deprecated forced_root_block: false setting in TinyMCE 6.0, we wish to share possible alternative approaches with the TinyMCE community.

[robtree]

Our editors use TinyMCE to input rich HTML content which might later be displayed inside a <p> or <dd> element depending on the context, so we set forced_root_block: false to ensure that only HTML like H<sub>2</sub>O is saved.

It will be problematic if TinyMCE starts wrapping that content in <p> tags because the output HTML would be invalid. I've decided to pin to cloud-channel="5" in case this feature really is removed in TinyMCE 6.0.

[EkimChau]

Thanks for sharing your usage of forced_root_block: false. Would the forced_root_block: 'div' approach work for you? let me know of any negative affects with that approach

[robtree]

Not really, because we need to save fragments of HTML rather than standalone blocks of HTML content.

Let's say we want to record the HTML representation of the molecular formula for water. The correct data to store is H<sub>2</sub>O, not <div>H<sub>2</sub>O</div>.

Worse still, we lose the flexibility to display those HTML fragments as phrasing content. For example, <p>Formula: <div>H<sub>2</sub>O</div></p> is not valid HTML.

[vjsingh]

@EkimChau I'm not sure this approach would work for us either. We insert outputted HTML into calendar invites. These invites respect newlines, so if TinyMCE inserts both a <br/> and a newline, it will render as two newlines.

[Afraithe]

While not a complete solution to what is discussed here, setting CSS on P tags to make them only take up 1 line is preferred to using this config option. p {margin: 0; padding: 0}

[TheSpyder]

Would it help if we created something like keyboard_enter_behaviour to replace forced_root_block? This would be a very simple setting that makes it possible to have enter behave the same as shift+enter (i.e. always insert a br). Or even swap their behaviour, if that's the preference.

Additional integration config would still be required to prevent other ways users can create block tags, such as removing block format features and filtering pasted content, but a lot of the problems described here seem like they are focussed around preventing the creation of P tags through normal typing. We should be able to solve that specific need fairly easily.

[vjsingh]

Hi @TheSpyder, thanks for your response.

The option of customizing the behavior of enter vs shift+enter would get us most of the way there. The other thing missing is that we don't want newlines created in the HTML string, since these newlines render in calendar invites. Would that be supported as well?

We were running into an issue with <p> tags, since TinyMCE was inserting <p> tags and newlines, and it was rendering as a large space (see my screenshots above).

I agree that although the additional integration configs you mentioned are helpful, our main concern is the creation of P tags (and newlines) through normal typing.

[spocke]

From what I can see in this thread the use for forced_root_block: false to make BRs on enter is for very simple editor scenarios like a description field or email clients and the main concern is that paragraphs make double margins between them.

There are two solutions for this:

1. Use forced_root_block: 'div' or change the css as suggested above to p { margin: 0; padding: 0 }
2. Have a post renderer step that converts divs or paragraphs to newlines before sending the email. Most bigger email marketing shops has such a step to convert the html to email ready html.

The problems with supporting forced_root_block: false is in more complicated editors use cases. Here are some there are many more.

1. Pasting from common office tools like Word will produce paragraphs. So to fully support a BR only mode then that would have to be converted some how using complex rules.
2. Things like alignment becomes hard since aligning a line of text with just a BR as the separator you would have to wrap it in a DIV to set the alignment css styles and from that point that piece of text would be in a div anyway to support a BR only mode then alignment can't be used at all.

All other tools you use from day to day like office and Google docs uses paragraphs as their line separator and br like softbreaks on shift+enter why you usually don't see this space between the "lines" is that they have very small default paragraph margins this can be changed in layout settings in Word for example then it works exactly like tinymce does today in it's default mode.

Having a BR on enter mode will complicate things like alignment. If you enter two lines of text then those would get wrapped in a P or DIV element and when you align one of those lines either both lines gets aligned if the css alignment is set on the parent block, the block needs to be split in the P case since a extra DIV is not valid within a P tag or the line needs to be converted into a DIV within a DIV. As you see just this simple feature becomes quite complicated in a BR enter mode to deal with if you want it to work as you expect it to work.

[Daijobou]

What has changed suddenly? I have been using TinyMCE since version 3 with the option forced_root_block: false. It may not be perfect, but the support it has made so far is enough for us so far and would appreciate it if it could stay that way.

We also use paste from Word, but we remove all formatting and delete the <p> and replace the final </p> with <br>. In our case, we don't want to have any formatting from Word or unwanted tags, so we delete all of that. We have been working like this for years and are 100% satisfied.

We also use the Alignment function (left-aligned, centered, right-aligned), but this is not even used in the 0.0..% range. This is extremely rarely used. Use alignment converted a line into a <div> by TinyMCE and works so for us since years. By trick you could also set a <span> and define it as a block element.

We have tens of thousands of texts since years, which we (partly) also provide to partners via API. I am concerned about what will happen to edit our old texts, especially analysis tools that would have to be adapted and what partners will say if texts are now submitted in a different format.

[spocke]

It an option that has been on my personal please remove list for many years since it adds complexity and will never really work perfectly since it's not aligned with the rest of the world that uses paragraphs. We are currently doing a sweep of cleanup for 6.0 so this is part of that cleanup something that has been put of for way to long.

The alignment scenario is just one of these types of operations you also have blockquote that introduces a similar problem of a block being introduced and special care needs to be done to handle this br only mode. What happens when you make a blockquote will it take the current br line and quote that what happens when you press enter inside the blockquote will it insert a BR inside the blockquote how do you then exit the blockquote and if you press blockquote should it then split by the closest BR line or convert all lines within the blockquote to normal lines. This also applies to other blocks like h1 etc. It introduces some weird unexpected behavior or adds code complexity for the br mode case.

We are also using another model in the rtc plugin that doesn't really support this kind of mode so it would be a bit of work if we wanted to introduce it there as well and again the result will be a weird br mode that kind of works sometimes.

[TheSpyder]

It's really about developer time for us to maintain the feature. Supporting forced_root_block: false across the entire codebase is not only difficult, it is unnecessary; from what we've seen the majority of integrations using it don't need every editor feature but as it is a core setting we have to make it work with every feature. This slows down both new feature development and QA for the entire editor.

We have decided helping customers to replicate their specific requirements that lead them to use it - whether directly, through blog posts, or updated documentation examples - will be better for us in the long term than continuing to maintain it.

[Georg-Git]

spocke argues:
insert a BR tag at cursor position makes it so complicated.

So what?
Even in the wanted future of tiny a shift+enter will insert a BR tag at cursor position - so tiny has to cope with this complicated real world in every case.

But that does not mean, that we need a BR only mode inside Tiny.
I understood that a BR only mode (in addition to the standard mode with the mixture of P and BR tags) sometimes doubles the efforts.

So my suggestion is a combination of two features:

1.) a new config option like 'keyboard_enter_behaviour'
(see @TheSpyder proposal)

Different options for the behaviour when pressing enter:
1a) insert BR tag, shift+enter will insert P tag
1b) insert only BR tag, also with shift+enter
1c) insert P tag, shift+enter will insert BR tag (Tiny default)

But when pasting there is no automatic conversion of P tags into BR tags - P tags remain and will be inserted.
There will be no BR only mode inside Tiny.

2.) a new additional filter for getContent
tinymce.activeEditor.getContent({ 'htmlwithoutPtags' })

This function will export html text after

• removing all newlines (after closing P tags)
• converting all closing P tags into BR tags
• removing all opening P tags

[TheSpyder]

We are hoping to integrate the paste plugin into the core editor with version 6, in which case it should be possible to show an example paste filter that ensures no block tags are inserted.

Your idea to have a formatting option for getContent is a very interesting one. We were considering support for registering custom content formatters in version 6 but it turned out to be a lot more work than we thought.

I'll make a note to discuss this with the team as something to consider post 6.0, to aid customers who can't upgrade due to the lack of forced_root_block: false.

[vjsingh]

The described getContent function is exactly what we were using before discovering forced_root_block: false.

It seemed to work well for us - this may be a workable solution for our use cases.

[TheSpyder]

This change has been made in 6.0 (#7519). We accept that this means some people will be stuck on 5.x until we offer an alternative solution, such as the keyboard_enter_behaviour or custom getContent filter ideas.

[vjsingh]

This change has been made in 6.0 (#7519). We accept that this means some people will be stuck on 5.x until we offer an alternative solution, such as the keyboard_enter_behaviour or custom getContent filter ideas.

@TheSpyder Is there an ETA or roadmap for these items?

[TheSpyder]

Not at this stage. We've accepted something is necessary but haven't planned exactly how to solve the requirements here. Once that is done and we've scheduled the work I'll post an ETA.

I doubt we will have time to start this planning before our 6.0 enterprise release, currently scheduled towards the end of March. Rest assured we will be supporting TinyMCE 5 until well into 2023 so there's no rush to upgrade.

[vjsingh]

Hi @TheSpyder - any updates on this?

[TheSpyder]

No, sorry. I put this on the list to consider for 6.1 but it hasn't been scheduled yet so I'm not sure if it will make the cut.

[vjsingh]

@TheSpyder ok thanks. Is there any ETA on it?

[liesahead]

Any news about it? Several members from our team spent 3 days trying to update this editor. But there's always a problem with change tracker as it's not clear how to update existing texts as there are issues in tinymce itself related to that setting: #7821

So, currently we decided to stick to v5 and in future switch to some other WYSIWYG editor if forced_root_block: false will not be supported anymore.

[TheSpyder]

false is not supported in TinyMCE 6. We do hope to provide a way forward for scenarios that depended on it, but we don't have an ETA yet.

[TheSpyder]

We managed to squeeze this into the 6.1 release plan 🙂

For the moment we're just going to add an option to change the behaviour when pressing enter as summarised above by @Georg-Git. I suspect we can come up with a node filter configuration example to achieve the proposed getContent filtering rather than add an explicit getContent output mode. Will see how that goes.

I'll post a request for feedback here when the PR for the option is merged.

[vjsingh]

@TheSpyder thanks! I'll test it once it's out

[SuperChuck83]

thanks, force root block false deprecated is really annoying us too

[jordanade]

My use case is editing headline html and other single-line fields that are later wrapped in the appropriate block element. I need forced_root_block: false to enable these "inline-only" fields. I only give the users bold, italic, and maybe links. In other cases I have text-only fields that must be completely devoid of html tags.

[nylandis]

Same for me.

[jordanade]

I have inline editors that live inside a root block. If there's a required root block inside the editor, TinyMCE simply won't operate correctly for me. Anyone know of any alternatives?

[TheSpyder]

@jordanade we hear you, even if we are a bit slow to react this discussion is continuing.

TinyMCE 5 will be fully supported until at least April 2023, and if enough people refuse to upgrade I'm sure we'll re-evaluate that timeline while we work to solve the problems that prevent migration.

[C-racker]

The new option still requires a forced root block. I'm hoping to do up an example node filter configuration that unwraps the required outer block tag.

Is there any progress now

[jordanade]

Still looking for inline-tag only support or failing that some unwrapping code. Now will try vjsingh's solution below.

[TheSpyder]

The new option newline_behavior was merged yesterday in #7865 and is now available to try in our cloud dev channel (or you can build tinymce from the develop branch). Documentation will be written at a later date so I've outlined the details in an example fiddle:
https://fiddle.tiny.cloud/Teiaab

This doesn't replace false by itself, features that insert block elements will need to be removed from the configuration. Feedback is very welcome.

[TheSpyder]

The code that made lists and other block operations work with false is the stuff that was really hard to maintain. So yes block operations will now apply to the entire block, if the document is one block it will become one list (or heading).
https://github.com/tinymce/tinymce/pull/7519/files#diff-33f2225e767a5ea5c8808ab2308332f719cc0c81be01b6f3c672b632e369efc3

Something we've experimented with in the past is a way for these operations to stop at br tag boundaries, as a general concept rather than baked in to each feature the way false was, but I can't make any promises. This isn't on our roadmap at all.

[vjsingh]

Hi @TheSpyder - Got it. We unfortunately will not be able to use any solution that doesn't offer lists applied to only part of the block. Your solution of having operations stop at br tag boundaries sounds like it might be the solution we need.

We are really struggling with this since we're a paid enterprise customer, and have put a lot of effort into integrating TinyMCE into our product. But we are not sure if we can stick with TinyMCE if there's no roadmap for us to upgrade to 6.0.

[vjsingh]

Is there any update on option 2 suggested by george-git?

We have a function already written for that that mostly worked. It's possible we could just use that when getting content out of the editor, but it seems brittle, and would feel better if it was officially supported.

[TheSpyder]

@vjsingh as a premium customer you are entitled to lodge a support ticket and discuss your needs with our customer service team. They may be able to find another way to solve your requirements and upgrade.

I am happy to take suggestions for option 2 and improve them if necessary. It will be an example that eventually goes into our docs, not a core feature of the editor.

[vjsingh]

@TheSpyder thanks - I did reach out to support and they are aware of the issue. We weren't able to find another path to resolution.

Here is our old code. It's not ideal if we have to use this hack indefinitely, but I am going to attempt to migrate us off forced_root_block next week. If that goes well then we'll be able to upgrade to v6:

// <p> tags don't work well with TinyMCE and invites, since TinyMCE
// inserts a newline before p tags, which results in extra spacing.
// The core issue here is that HTML doesn't respect newlines, whereas
// calendar invites do (they are a hybrid HTML/Plaintext mashup).
// We'd prefer to support p tags, but need a way around the TinyMCE issue.
export function removePTags(html) {
    // Remove the first p tag.
    html = html.replace(/<p>/, "");

    // Convert all subsequent p tags to 2 <br />s.
    html = html.replace(/<p>/g, "<br /><br />");

    // And remove all p closing tags.
    html = html.replace(/<\/p>/g, "");

    return html;
}

[Georg-Git]

newline_behavior: "invert" - what is the meaning/expected behavior of this option?

In reference to the fiddle of @TheSpyder :
https://fiddle.tiny.cloud/Teiaab

[TheSpyder]

invert is 1a from your summary. Default enter changes to br, and shift+enter becomes p.

[vjsingh]

@TheSpyder I think we may have found a way to make this work, using forced_root_block: div. If it works I'll post the full solution here.

In regards to our newline behavior - is there a way to control what shift+enter does (other than by doing something like this)?

We want to make shift+enter behave the same way as enter - insert a block (<div>) instead of a <br/>.

Thank you

[TheSpyder]

yes, as @Georg-Git points out the new option in TinyMCE 6.1 provides for all 4 possible combinations of block or linebreak between enter and shift+enter. The documentation describing this is scheduled to go live next week, I believe.

[vjsingh]

@Georg-Git @TheSpyder Oh I see now - yes that's right. Thanks!

[TheSpyder]

yes, as @Georg-Git points out the new option in TinyMCE 6.1 provides for all 4 possible combinations of block or linebreak between enter and shift+enter. The documentation describing this is scheduled to go live next week, I believe.

Now live:
https://www.tiny.cloud/docs/tinymce/6/6.1-release-notes/#new-newline_behavior-option-controls-what-happens-when-the-return-or-enter-key-is-pressed-or-the-mceinsertnewline-command-is-used

https://www.tiny.cloud/docs/tinymce/6/content-behavior-options/#newline_behavior

[Daijobou]

I have two question about this.

1. I want set value to "linebreak" so all enter are <br>. How remove the Initial <p> in editor? https://fiddle.tiny.cloud/Lhiaab
2. In version 5 see https://fiddle.tiny.cloud/Mhiaab/1 select "Line 2" and press center button. Only "Line 2" is centered. Working perfectly. Now the same with version 6 see https://fiddle.tiny.cloud/Nhiaab. Not only "Line 2" is centered, all lines are centered. :(

[TheSpyder]

@Daijobou

1. There needs to be a root block while editing. That's the effect of removing false. It doesn't have to be p, but it needs to be there.
2. This came up in an earlier section of this thread a month ago, and I'm afraid the cost of maintaining that capability is a large part of the reason false was removed. I do have some ideas for bringing this back in a more sustainable way but it's not on the roadmap yet.

[TimMTech]

So what is the solution? Is this another library that needs 14 more libraries to hardcode and maintain? haha. What a joke. Consider other alternatives.

[liesahead]

Up

[vjsingh]

@TimMTech @liesahead We solved this with two different configuration options for our app

1. forceNoPTags
   For calendar invites, we prevent extra spacing by using forced_root_block: div and stripping newlines from HTML.

2. inline
   For inline text (meant to be rendered inline in other text), we stop newlines through blocking the return key, and stripping the outer div.

See full code below.

setup: (editor) => {
    // Prevent newlines (and <br/>s) on inline editors.
    if (inline) {
        editor.on("keydown", function (e) {
            return e.keyCode !== 13;
        });
    }

    editor.on("PostProcess", function (ed) {
        // Calendar invites don't render HTML in the standard
        // way (frustrating). They respect both HTML tags
        // and newline characters ("\n"). Because of this
        // quirk, we remove all newlines on calendar invites so
        // that there is not extra spacing.
        if (forceNoPTags) {
            ed.content = removeNewlines(ed.content);
        }

        // TinyMCE inserts a wrapper <div> around the content
        // for each editor. We prevent newlines for inline
        // editors above, but we also need to strip out the
        // enclosing <div> tags. This lets us insert inline
        // content inline into other content (e.g. for the
        // "{{Interviewer Format}}").
        if (inline) {
            ed.content = removeOuterDivTags(ed.content);
        }
    });
}

forced_root_block: inline || forceNoPTags ? "div" : "p",

function removeOuterDivTags(html) {
    if (_.startsWith(html, "<div>")) {
        // Remove the first div tag at the beginning of the string.
        html = html.replace(/<div>/, "");
        // And remove the closing tag at the end of the string.
        html = html.replace(/<\/div>$/, "");
    }
    return html;
}

[jordanade]

Thank you. This seems to be the only real solution, and if block wrappers are in fact needed for whatever internal technical reason, this should be built into TinyMCE, in my opinion, as an way to re-enable forced_root_block: false.
(By the way, you didn't include the removeNewlines() function.)

[nicojmb]

I've a translation system and not need to add the "p" tag,
And raw text not is the solution, in some trasnaltion key need a h1 or a img tag

[PubliAlex]

I use tinyMCE to edit content directly from website Frontend. Some of that editable zones are just single image, nothing else. I want to let the end user to edit image using tinyMCE (add alt tag, pick a new image with the file manager etc....)

The problem is the p tag added around my image when I initialize tinyMCE for that editable block.

Even if I can avoid to save that p tag when I call getContent() method, the fact that p tag is added when I activate the editor break my layout.

Best regards,

[witeck]

In tinymce 6, if I set the forced_root_block property to a non-tag value, then no tag was added by the editor (I expected the default value - paragraph)

forced_root_block: 'aaa',

[jordanade]

Great hack! Any side effects?

[TheSpyder]

We might close it off at some point. The code to safely deal with content outside of block tags was deleted as a part of this change.

[witeck]

"Any side effects?" - I'm afraid so :( , e.g. if you want to add text justification without a block element, it won't work, probably because it's unable to add the correct root_block

[kschaefer76]

No update here, right?
I have, like many others here, also the need to just edit content (image, text, etc..) without adding a wrapper.
If there will be no clear solution, unfortunately I have to integrate an other editor.

[TheSpyder]

No, I haven’t put any time into a filter config example that will remove the block wrapper. I’m confident our public api can do it, but this is an area that’s not very well documented so it might be challenging to do yourself.

[jordanade]

See the solution above: #7342 (comment)