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).
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
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:
But if you use CKEditor, then the line breaks are saved with the HTML tags. This looks like the source of the issue.
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
The problem is that now you are using CKEditor. CKEditor will read the value of the field, and since it finds not
<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
<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
<br>when you edit a pre-saved field.
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.
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?
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.
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:
You'll get this:
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][value] etc). It's part of entity Plus, which you could enable just for this task.