Debugging issue with Webforms in Drupal 10

At work at the Studio Present company, a younger colleague faced an exceptionally unusual problem. In short, after upgrading a project to Drupal 10, it became impossible to add a new Webform.

When I got home out of curiosity, I had to analyze the problem and try to solve it. I will now demonstrate how I identified the problem and take you through my entire thought process during debugging. 

This article is mainly for those struggling with debugging issues like this. The most challenging part is getting started, but once you begin unraveling the mystery, it gradually becomes easier.

The issue in this case was that upon attempting to add a new Webform, we encountered the error message: Text format field is required.

Hmm, that's interesting because it seems this Webform does not have the Text format field. So, the very first step is to see if that is indeed the case. If we inspect the HTML code, we'll see that the Text format field is actually hidden with CSS.

Now, if we disable the CSS property display: none; we'll see that the field is marked as required (there is an asterisk) but contains no value. This is not good!

Whatever should be in that field is not present, creating a problem because it is impossible to submit a form where a mandatory field is empty.

The next step is to determine what should be in that field and understand why it is missing. This will bring us one step closer to solving this mystery.

Let's take a sufficiently unique string from the form, such as Administrative description and search the Webform module code for it.

We will find that this form is defined in the WebformEntityAddForm.php file, and the form field appears as follows:

$form['description'] = [
  '#type' => 'webform_html_editor',
  '#title' => $this->t('Administrative description'),
  '#default_value' => $webform->get('description'),
];

Interestingly, this is not a form element (webform_html_editor) that exists in the Drupal core, but a new element defined in the Webform module in the following file: WebformHtmlEditor.php

This new form element is created for entering HTML content. If we take a closer look at the processWebformHtmlEditor() method, we'll notice the variable $format. If the value is not falsy, the method tries to load the Filter format config entity of that name and then sets that format in the text_format form element:

$format = $element['#format'] ?: \Drupal::config('webform.settings')->get('html_editor.element_format');
if ($format && FilterFormat::load($format)) {
  $element['value'] += [
    '#type' => 'text_format',
    '#format' => $format,
    ...
    ...
  ];
...
...
}

If we debug the value of the variable $format, we'll see that it is equal to: webform_default.

Since the Filter format is a config entity, we can analyze it using Single export form (/admin/config/development/configuration/single/export). Let's now look at the Filter format config entity under this name and see if it exists and if there are any problems with it.

It appears that on the project where the problem occurred, this filter format was disabled for some reason.

However, in the code, there is no check to determine whether the filter format is disabled or not. There is only this:

$element['value'] += [
  '#type' => 'text_format',
  '#format' => $format,
  ...
  ...
];

We need to investigate further to identify the issue. Since the text_format element is used here, let's examine the class where this text format render element is defined. That's in the file TextFormat.php.

Upon closer inspection there, we'll notice on line 133 the following code:

// Get a list of formats that the current user has access to.
$formats = filter_formats($user);

Now, if we examine the filter_formats() function, we'll see that it checks whether the text format is enabled or not, as it only loads filter formats that have a status of TRUE:

\Drupal::entityTypeManager()->getStorage('filter_format')->loadByProperties(['status' => TRUE]);

 So, to solve the issue we have to enable the webform_default filter format.

How to solve the problem?

To solve the problem, delete the filter format config using, for example, Drush or another method for deleting configuration in Drupal:

drush cdel filter.format.webform_default

then import the following config via the Single import form found at /admin/config/development/configuration/single/import:

uuid: null
langcode: en
status: true
dependencies:
  enforced:
    module:
      - webform
name: 'Webform (Default) - DO NOT EDIT'
format: webform_default
weight: 100
roles:
  - authenticated
filters: {  }

You can find this config in the Webform module here: webform/config/optional/filter.format.webform_default.yml.

This was an example of one of my debugging processes for a problem I faced. I hope it will help someone to get, if nothing else, at least an idea of how to start and carry out their debugging process.