Text format webform_default can not be used outside of webform module

I upgraded yesterday and i'm getting this error on two different sites, same as Screenshot from 2023-01-04 16-48-28.png
the location is always (website url)/quickedit/attachments?_wrapper_format=drupal_ajax
and I get several at least 5 or more error entries at once when going to /admin/reports/dblog
It appears to happen every time I clear the cache at /admin/config/development/performance takes about a minute or two afterwards for the errors to show up in the logs.

Same issue here. Doesn't repeat consistently. Can trigger it with a cache clear.

Location https://www.mysite.platformsh.site/quickedit/attachments?_wrapper_format...
Referrer https://www.mysite.platformsh.site/user/36045?check_logged_in=1
Message Disabled text format: webform_default. This text format can not be used outside of the Webform module's HTML editor.

Okay, it seems that the quickedit.module needs to be enabled.

I am still not able to reproduce this issue in a plain vanilla instance of Drupal.

I'm also facing this issue with quickedit. I'm not sure yet how to reproduce it, because I cannot find a way to trigger it yet.

However, I did encounter the same error when being in Webform self. That may be a different issue. Though the resemblance is that in both situations I get the alert logged exactly 7 times.
Location: /admin/structure/webform/manage/contact/element/message/edit?_wrapper_format=drupal_dialog.off_canvas
Referrer: /admin/structure/webform/manage/contact

In Drupal\webform\Element\WebformHtmlEditor I added the following line to preRenderProcessedText()

file_put_contents('/tmp/webform-element-' . microtime() . '.txt', print_r($element, TRUE));

Which made the method look as follows:

  public static function preRenderProcessedText($element) {
    $format_id = $element['#format'] ?? NULL;
    if ($format_id === static::DEFAULT_FILTER_FORMAT) {
      file_put_contents('/tmp/webform-element-' . microtime() . '.txt', print_r($element, TRUE));
      $message = "Disabled text format: %format. This text format can not be used outside of the Webform module's HTML editor.";
      \Drupal::logger('webform')->alert($message, ['%format' => $format_id]);
      $element['#markup'] = '';
      return $element;
    }
    return $element;
  }

That resulted into 7 files where #text was <h1>TEST</h1>, <h2>TEST</h2>, <h3>TEST</h3>, <h4>TEST</h4>, <h5>TEST</h5>, <h6>TEST</h6> and <pre>TEST</pre>.

See also attached files.

I see if I can reproduce the issue on a clean install too, though I hope to trigger the error in the quickedit situation.

The same results were produced when the location is /quickedit/attachments?_wrapper_format=drupal_ajax

Meanwhile I found the following piece of code on Drupal 9.5 in core/modules/ckeditor/src/Plugin/CKEditorPlugin/Internal.php:

  /**
   * Builds the "format_tags" configuration part of the CKEditor JS settings.
   *
   * @see getConfig()
   *
   * @param \Drupal\editor\Entity\Editor $editor
   *   A configured text editor object.
   *
   * @return string|false
   *   A string containing the "format_tags" configuration or FALSE if the
   *   editor has not an associated filter format.
   */
  protected function generateFormatTagsSetting(Editor $editor) {
    // When no text format is associated yet, assume no tag is allowed.
    // @see \Drupal\editor\EditorInterface::hasAssociatedFilterFormat()
    if (!$editor->hasAssociatedFilterFormat()) {
      return FALSE;
    }

    $format = $editor->getFilterFormat();
    $cid = 'ckeditor_internal_format_tags:' . $format->id();

    if ($cached = $this->cache->get($cid)) {
      $format_tags = $cached->data;
    }
    else {
      // The <p> tag is always allowed — HTML without <p> tags is nonsensical.
      $format_tags = ['p'];

      // Given the list of possible format tags, automatically determine whether
      // the current text format allows this tag, and thus whether it should show
      // up in the "Format" dropdown.
      $possible_format_tags = ['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'pre'];
      foreach ($possible_format_tags as $tag) {
        $input = '<' . $tag . '>TEST</' . $tag . '>';
        $output = trim(check_markup($input, $editor->id()));
        if (Html::load($output)->getElementsByTagName($tag)->length !== 0) {
          $format_tags[] = $tag;
        }
      }
      $format_tags = implode(';', $format_tags);

      // Cache the "format_tags" configuration. This cache item is infinitely
      // valid; it only changes whenever the text format is changed, hence it's
      // tagged with the text format's cache tag.
      $this->cache->set($cid, $format_tags, Cache::PERMANENT, $format->getCacheTags());
    }

    return $format_tags;
  }

That looks like to be the place where <h1>TEST</h1> is coming from.

Yes, I am able to reproduce this!

Steps to reproduce

On Drupal 9.5.x

1. Install modules CKEditor (Deprecated), Webform, Webform UI.
2. Go to /admin/structure/webform/manage/contact
3. For element "Message", click "Edit".

7 alert messages get logged.

I cannot reproduce this issue because I understand the concept of what is happening.

Should we ignore that very basic markup?

Maybe someone can post a patch.

@jrockowitz
I could reproduce this issue on Drupal 9.5 + CKEditor 4 (or CKEditor (deprecated)). When using a fresh install of Drupal 9.5 using the standard profile, you'll need to uninstall CKEditor 5 first.

(Perhaps it is also possible to reproduce this on Drupal 10 + the contrib CKEditor 4 module → , but I haven't tested that.)

The reason the webform text format is used outside of the Webform context is because the CKEditor 4 module is doing the following:

$output = trim(check_markup($input, $editor->id()));

See comment #9 for the method where the above code is used.

It is passing test data to the current text format to check which tags are allowed. Based on that information it makes these tags available in the format dropdown on a CKEditor instance:

H1, H2, etc. are not available now because Webform clears the processed text, so CKEditor 4 assumes now that these tags aren't allowed.

I was finally able to reproduce the error. Please review the attached patch.

I think makes sense the ckeditor's verification. I'd just suggest using t() function to be able to translate that for sites with multi-languages. For example here: https://git.drupalcode.org/project/webform/-/blob/6.2.0-beta5/modules/we...

Implemented the suggestion above: https://git.drupalcode.org/project/webform/-/merge_requests/300

The DbLog class should explain that $message should not be a translated string, but that translation placeholders should be given in $context.

@see #3059567: DbLog doens't explain how to correctly translate log messages →

Patch #15 solved the issue. Thanks.

The DbLog class should explain that $message should not be a translated string, but that translation placeholders should be given in $context.

@see #3059567: DbLog doens't explain how to correctly translate log messages

Got it. I didn't know that. Good to know

I didn't find some examples with translation placeholders in the $context, but I can find it and if I have question I can ask there in the core ticket #3059567: DbLog doens't explain how to correctly translate log messages →

I did a roolback to the previous solution without t(). Thank you so much for the clarification

Automatically closed - issue fixed for 2 weeks with no activity.

Any news on when this fix will be in the non-dev version? Is there any known roadmap/release schedule for this module?