Remove all traces of fallback format concept from the (admin) UI

Created on 3 March 2013, over 11 years ago

Updated 9 February 2024, 10 months ago

The fallback format concept was originally introduced to allow Filter module to cope with unforeseen edge-case configuration scenarios, but was never intended to be exposed as a configurable text format.

The plain_text fallback format was only ever meant as a (literal) fallback format.
Its introduction was caused by technical edge-case scenarios only. Specifically:
1. When all existing formats are accessible to certain user roles only,
2. and the currently logged-in user does not belong to any of those roles,
3. but a text-format-enabled text field happens to be exposed to that user,
4. then Filter module logically has no idea what to do, because it was told to accept user input that needs to be filtered, but there is no format the user is allowed to use.
That's the one and only reason for why the fallback format exists. There are multiple possible ways to reach that situation, so we were not able to say "Stuff that, that edge-case is caused by a bogus configuration, fix your configuration instead." Hence, we introduced the fallback format to resolve that problem.
That is also the reason for why the plain_text fallback format is super-restrictive and escapes all HTML.
- It is only used in situations when the current user technically does not have access to any format.
- That's also why the fallback format ID is not configurable from the UI.
It was a pretty big mistake to expose it as a configurable format in the administrative UI and we need to fix that.
The fallback format was not meant to be exposed in the visible way it is today.

Remove all traces of the fallback format from the administrative Filter module UI.

This inherently means that the fallback format is no longer configurable.
Add an API-level condition to disallow filter configuration changes to the fallback format.
Since we do not know whether the fallback format was reconfigured on existing sites:
- Introduce a new fallback format 'none' in D8, as a replacement for the previous plain_text format.
- For sites upgrading from D7, the plain_text format becomes a regular, configurable format.
- The new none fallback format will not be exposed in the UI and its configuration cannot be changed.
Remove the additional configuration setting that was introduced with #788114: Unprivileged users should only get one text format by default →

With properly set up text formats, anonymous users are able to access (at least) one actual text format.
- The fallback format is not intended to be used as "default format" for anonymous users.
- Anonymous users should still get an actual text format along the lines of filtered_html. They should be allowed to enter basic HTML.
- In most Drupal site use-cases (but certainly not all), anonymous users only get one format and should not see a format selector.

📌 Task

Status

Active

Version

11.0 🔥

Component

Filter →

Last updated 3 days ago

No maintainer

Created by

🇩🇪Germany sun Karlsruhe

Live updates comments and jobs are added and updated live.

API clean-up
Refactors an existing API or subsystem for consistency, performance, modularization, flexibility, third-party integration, etc. May imply an API change. Frequently used during the Code Slush phase of the release cycle.

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 10 months ago →
🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
FYI this came up again in 📌 Add validation constraints to filter.settings Fixed . filter.settings:fallback_format is impossible to validate.

This issue would allow removing that from config!

Production build 0.71.5 2024