Changing a textarea's allowed text format prevents any future edits

[swampopus]

Description of the bug

I had a textarea where I was allowing the Filtered text "Basic" text format. I had created a node. Then, I modified the field to only allow the Filtered text format "Plain Text", and suddenly I could no longer edit the field value, even though I was logged in as admin (uid 1).

Steps To Reproduce

To reproduce the behavior:

1. Create a new Content Type. Mine is called "Testing". Add a text (long) field, which allows Filtered text, and the Basic text format. Go ahead and create a node, like so:

2. Go back to the Content Type, edit the text (long) field, and change the allowed format to only be "Plain Text". As you can see, I renamed mine to "Plain Text w Line Breaks" for clarity.

3. Now, edit the node you just created. You can no longer make edits to the textarea:

Expected behavior

I would expect that any existing saved data would appear in the textarea, after having been passed through the selected filter. Or, just run it through check_plain() and display in whatever editor appears.

In my example case, I would expect to see something like:

<p>
Hello, I am a test
</p>

Instead, the textarea is disabled, and I cannot make changes at all, even as admin. Getting to a point where I could actually edit the textarea for this node is actually a bit of a pain (see Workaround below).

Workaround?

The only workaround I could find was to (1) remove the text (long) field from the content type, then (2) re-save the node, then (3) add the text (long) field back in with only "Plain Text" filter selected.

Note: Simply removing and immediately re-adding the field to the content type didn't work; you have to save the node in between.

Obviously this wouldn't be ideal if I'm working on a live site with hundreds of nodes by multiple users. Plus you completely lose any content which was previously there.

Additional information

• Backdrop CMS version: 1.34.0
• Web server and its version: Apache 2.4
• PHP version: 8.3.27
• Database sever (MySQL or MariaDB?) and its version: MariaDB 10.11.11
• Operating System and its version: Linux (Synology NAS)
• Browser(s) and their versions: Chrome v148.0.7778.217

[argiepiano]

I can't reproduce. It works as expected for me - I can edit the field. Any chance you have a contrib module related to permissions that is interfering?

[argiepiano]

Can you try to reproduce this on a clean install, perhaps spin off a new site at https://backdropcms.org/demo

[swampopus]

Hrmm. I'll try on a completely clean install.

[swampopus]

Confirmed. I just got the same situation on a spun up clean test instance:

(See the "Description" textarea at the bottom)

[argiepiano]

Hah, I must have missed something. Did you use the public demo? Can you share the url to log in?

[swampopus]

Sure thing. I made a video of me doing it start to finish too:

Video.webm

The site is at: https://latest-5imhmqrc61jfdzw0e3zbqj0pqlz8bajf.tugboatqa.com
admin/password Says it will only be there for a day.

[argiepiano]

Yes, I see the problem. The step I was misunderstanding was the switch to "Plain text" - I was switching in the "Text processing" radios rather than disabling the others in "Allowed text formats". It looks like Backdrop locks the field if its was created with a text format that is not available anymore. This may be a security thing - disallowing the edition of fields that have text formats that a user doesn't have access to.

The strange thing here is that this is locking the admin too.

[swampopus]

Yeah-- and I guess I get the intention, but it makes it so the user can NEVER edit that textarea on that node ever again! Even the admin can't intervene and fix it.

I feel like this has to be a bug.

The more I think about it, the more I think that if the user doesn't have access to a particular text format for content, then the default should just be to pass it through check_plain(). That seems like the easiest and most reasonable option.

[bugfolder]

I've long noticed the behavior that @argiepiano describes (when I, as admin, inadvertently set the format of a text field in a node to one that editors weren't allowed).

On an older (pre-1.34.0) site, I created a field that only allowed a format that I subsequently disabled, but when I went back to it as admin, I was still presented with the fallback format (Filtered Text) as a choice, so this looks like it might be a regression.

I think that if the user doesn't have access to a particular text format for content, then the default should just be to pass it through check_plain(). That seems like the easiest and most reasonable option.

Actually, I think if the format isn't available, it should fall back to the fallback format, since all users have access to that.

[swampopus]

Good point re: the fallback format. It seems like in pseudocode, it might look something like:

If (!user_has_access_to_format($element['format'])) {
  // Change the format to plain_text, the standard fallback format which is guaranteed to be there
  $element['format'] = 'plain_text';
}

EDIT: Also, I agree that this might be a regression. I feel like I've done this before with no problems.

[laryn]

I'm not sure if it's exactly what you are describing, but I recall seeing a text area greyed out in the past and I think it was when the text format was still available but just not to the current user. Switching the text format in that case could result in data loss if different filters run and then the result gets saved.

[bugfolder]

Switching the text format in that case could result in data loss if different filters run and then the result gets saved.

Text format filters don't change what is saved; they modify a copy in the course of rendering.

$element['format'] = 'plain_text';

plain_text isn't always the fallback format. (On my ancient site, 1 is the fallback format, which is now called "filtered_html" (or something like that). So the above should be

$element['format'] = filter_fallback_format();

[swampopus]

Oh cool, I didn't even realize that was a function.