Posted by leeksoup on Thu, May 25, 2023 - 10:11pm --- Updated: May 26 '23 - 1:22pm

Several of my posts got lost. I am recreating them, as @stpaultim suggested. This is an attempt to re-create the entire thread.

I've posted here quite a bit already with issues I've had with upgrading my D7 site to Backdrop. Here's one item I've noticed repeatedly but ran into again today.

When I edit an existing node that was saved in D7 with the "Filtered HTML" format, it loses all the paragraph breaks. The nodes are fine until I click "Edit" and then it turns all the text into one single paragraph with <p> tags.

This is a pain to fix by hand and it's frustrating. Why does it happen, and is there an easier fix than hand-editing to restore the breaks?

"Convert line breaks into HTML (i.e. <br> and <p>)" is enabled on both D7 and Backdrop. However, the body fields are not stored the same way. D7 stores the line breaks (without <br> or <p> tags) but Backdrop stores with those tags added (once I edit to fix).

Accepted answer

Posted by argiepiano: To solve your problem, you could run the value of the fields _filter_autop(). This function is the one responsible to convert the output into HTML. So if you run this:

_filter_autop("asdf asdf qwer");  

You'll get this:

<p>asdf<br /> asdf<br /> qwer</p>

Comments

Fri, May 26, 2023 - 3:32pm by leeksoup

Posted by Olafski, Thu, 25 May 2023 08:21:23.179 +0000 (UTC): Hm, I've upgraded a couple of sites from Drupal 7 to Backdrop, and this issue never happened to me, so I'm wondering if there's a particular setup of the D7 site. To make a startt, did you use CKEditor or another editor on the D7 site?

Fri, May 26, 2023 - 6:22pm by leeksoup

I used "none" (no editor plugin) on D7. In Backdrop, I am using CKEditor.

From the documentation, it looks like Backdrop (like D7) saves the line breaks without the HTML tags:

Why doesn't Backdrop filter text before saving input into the database? The answer is simple; flexibility. Changing the text a user has input before saving it in the database, would make it impossible to get back to the original state. By filtering on output, not on input, Backdrop gives the site administrator the option of changing how content is displayed at any time.

But if you use CKEditor, then the line breaks are saved with the HTML tags. This looks like the source of the issue.

Fri, May 26, 2023 - 3:31pm by leeksoup

Posted by argiepiano, Thu, May 25, 2023 at 1:55 PM:

It looks like in your D7 site, you had a filter that  converted line breaks into HTML. This conversion happened at display time. So, the value of the field did not contain any <p> or <br>. 

The problem is that now you are using CKEditor. CKEditor will read the value of the field, and since it finds not <p> or <br>, it interprets that as one paragraph. 

I bet if you install and enable CKEditor in your D7, the result will be exactly the same as in Backdrop? 

So, I'm not sure if this could be considered a bug. CKEditor will insert <p> or <br> as you type  your entry into the field, and those will get saved -that's expected behavior. But it will not  "reinterpret" line breaks that were previously saved as such as <p> or <br> when you edit a pre-saved field.  

Fri, May 26, 2023 - 3:26pm by leeksoup

You are correct. I agree it is not a bug, but it is an issue that can happen to anyone who switches from no text editor to CKEditor, even in a site that is new made in Backdrop.

There is an inconsistency in philosophy between the Backdrop / no editor and with CKEditor, with the first deliberately choosing not to save the line breaks as tags, and the second the opposite.

I believe at least this should be documented, and ideally there should be an option to push a button to convert existing text-area fields' contents to add the tags.

I am happy to help with the documentation.

Fri, May 26, 2023 - 3:28pm by leeksoup

Posted by argiepiano, Thu, 25 May 2023 12:41:34 -0700 (PDT):

Yes, I agree this is inconsistent and somewhat confusing. The key here is to understand that CKEditor is not a filter, and therefore your quote doesn't quite apply to it. Text filters act upon rendering of content. CKEditor is a "shorthand" way to avoid for the editor to enter HTML tags upon editing.  Those tags exist in the field, and are saved. So technically, this is not a filter, but rather a tool to help users avoid entering HTML tags. That said, it'd be nice to document this behavior for CKEditor. Perhaps here? https://backdropcms.org/project/ckeditor

Fri, May 26, 2023 - 6:21pm by leeksoup

@argiepiano -

How do I get permission to edit that page? I think it would be good to also point to it from the "deep dive" page that I quoted up-thread.

Fri, May 26, 2023 - 3:24pm by leeksoup

Posted by argiepiano: To solve your problem, you could run the value of the fields _filter_autop(). This function is the one responsible to convert the output into HTML. So if you run this:

_filter_autop("asdf asdf qwer");  

You'll get this:

<p>asdf<br /> asdf<br /> qwer</p>

Fri, May 26, 2023 - 3:30pm by leeksoup

Posted by argiepiano, Thu, 25 May 2023 12:43:45 -0700 (PDT):

Just a tip: entity metadata wrappers are a GREAT way to read and write values to fields without dealing with the multilevel field  array (e.g. [LANGUAGE_NONE][0][value] etc). It's part of  entity Plus, which you could enable just for this task.