Disabled webform text format -- unable to reenable

Created on 28 February 2025, 6 months ago

Problem/Motivation

I inadvertently disabled the Webform text format as I was trying to clean up some formats.
I am now unable to re-enable the Webform text format ("webform_default").

When I try to enable it, I get an Access Denied and a login link (I am logged in as an administrator).

Proposed resolution

If I can't enable the text format -- it seems as though, I shouldn't be able to disable it to begin with.
This led to other issues -- which I assume is they the text format says don't edit.... if its not possible to prevent disabling it, perhaps it could say "don't Edit or Disable" to be explicit. I'm not sure why it should be stopped from being enabled.

I made various attempts to reenable it (tweaking the DB on my local dev, re-importing with the new status) but have been unsuccessful. Is there any way to get it reenabled (I have lots of forms and submissions so I think uninstalling and reinstalling would be impractical at best)

๐Ÿ› Bug report
Status

Active

Version

6.2

Component

User interface

Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States adriancotter

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @adriancotter
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States adriancotter

    Looking on Drupal Stackexchange, I see that I should not be able to see the text format -- I'm not sure how I was able to disable it if that was the case...

  • Most of that work took place at ๐Ÿ’ฌ The hidden webform text format leads to text format selects with only one option Active . I don't think it needs to be enabled. It is disabled by default on install. What actual problem is this causing to the site you are working on?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States adriancotter

    Well the format choice for the webforms reverted to plain text. I thought that was likely a result of me disabling it, but I don't actually see that having changed in config in GIT, this is what I do see. There were some other WYSIWYG text format settings that got changed along with webform.settings:
    - element_format: webform_default
    - mail_format: webform_default
    + element_format: plain_text
    + mail_format: plain_text
    This was not something I did deliberately. So I am not sure what caused that to switch.

    The problem that resulted was that all our emails started having email appear in them - the html all converted to >p<>/p<

    I see that it uses webform_default if "default" is selected in the HTML Editor dropdowns here
    https://sierraclubdrupal.ddev.site/admin/structure/webform/config/elements

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States adriancotter
  • ๐Ÿ‡น๐Ÿ‡ผTaiwan junsuwhy

    I encountered the same issue. Somehow, I unintentionally changed the #status of the format to false. Initially, after installation, it was set to true (although it appeared as disabled in the formats list). This caused the system to repeatedly prompt me that the format was empty and couldn't be saved whenever I edited webform fields.

    The solution that worked for me was running:

    \Drupal\filter\Entity\FilterFormat::load('webform_default')->setStatus(true)->save();
    

    You can execute this command via drush php or any PHP-executable environment.

    I suspect this issue occurred when I added a new format and modified the order of formats, which somehow set webform_default's #status to false. However, I've been unable to reproduce this behavior afterward.

  • ๐Ÿ‡น๐Ÿ‡ผTaiwan junsuwhy

    I encountered the same issue. Somehow, I unintentionally changed the #status of the format to false. Initially, after installation, it was set to true (although it appeared as disabled in the formats list). This caused the system to repeatedly prompt me that the format was empty and couldn't be saved whenever I edited webform fields.

    The solution that worked for me was running:

    \Drupal\filter\Entity\FilterFormat::load('webform_default')->setStatus(true)->save();
    

    You can execute this command via drush php or any PHP-executable environment.

    I suspect this issue occurred when I added a new format and modified the order of formats, which somehow set webform_default's #status to false. However, I've been unable to reproduce this behavior afterward.

  • ๐Ÿ‡น๐Ÿ‡ผTaiwan junsuwhy

    I encountered the same issue. Somehow, I unintentionally changed the #status of the format to false. Initially, after installation, it was set to true (although it appeared as disabled in the formats list). This caused the system to repeatedly prompt me that the format was empty and couldn't be saved whenever I edited webform fields.

    The solution that worked for me was running:

    \Drupal\filter\Entity\FilterFormat::load('webform_default')->setStatus(true)->save();
    

    You can execute this command via drush php or any PHP-executable environment.

    I suspect this issue occurred when I added a new format and modified the order of formats, which somehow set webform_default's #status to false. However, I've been unable to reproduce this behavior afterward.

  • ๐Ÿ‡ฎ๐Ÿ‡นItaly apaderno Brescia, ๐Ÿ‡ฎ๐Ÿ‡น
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States jrockowitz Brooklyn, NY

    I think the webform_default is no longer visible via the UI, and we might be able to close this ticket since we can't reproduce the issue and the suggestion from #6 is a valid fix.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States jrockowitz Brooklyn, NY

    I think the webform_default is no longer visible via the UI, and we might be able to close this ticket since we can't reproduce the issue and the suggestion from #6 is a valid fix.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States adriancotter

    A counterpoint jrockowitz -- just uploaded a screenshot from a different site where webform_default is visible. This is a different site from where this problem occurred.

  • Are those sites on the same Drupal core versions?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States adriancotter

    Yep. The are on the same Drupal Core versions 10.4.5
    webform 6.2.9

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States jrockowitz Brooklyn, NY

    The short answer is people have to upgrade to resolve this issue

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States adriancotter

    Upgrade to what jrockowitz? to have the webform text format hidden?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States jrockowitz Brooklyn, NY

    6.3.0-beta2

  • Status changed to Needs review 3 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States davidandersonencsd

    I have the same problems the OP. I did not disable the Webform (Default) text format. However, I discovered it was disabled when I was trouble shooting why I couldn't create a new webform. Upgrading to 6.3.0beta2 doesn't reenable the Webform (Default) text format and now it's hidden. What is the solution to the OP's problem that the Webform text format is disabled?

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom The Daily Clobe

    Thank you! The drush command (drush config-set filter.format.webform_default status true -y) worked for me.

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada Liam Morland Ontario, CA ๐Ÿ‡จ๐Ÿ‡ฆ

    If this can be re-produced, please re-open so that we can fix 6.2.x.

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada aarantes

    Hello,

    I'm adding this comment here as I can reproduce this on Webform 6.2.9, running on Drupal 10.4.6. Hopefully it will be useful to someone.

    In my case, this is what I found:

    Reordering the Webform text format ("Webform (Default) - DO NOT EDIT") in "Configuration > Content authoring > Text formats and editors" causes more than the "weight" parameter to change (the weight controls the order).

    Looking at the exported YAML configuration file, I can see that the "status" and "dependencies" also changed (see image below).

    If it helps, here is the code of the screenshot:

     langcode: en
    -status: true
    -dependencies:
    -  module:
    -    - webform
    +status: false
    +dependencies: {  }
     name: 'Webform (Default) - DO NOT EDIT'
     format: webform_default
    -weight: 100
    +weight: -5
     filters: {  }
    

    Thanks,
    Alex

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada Liam Morland Ontario, CA ๐Ÿ‡จ๐Ÿ‡ฆ

    Please add the steps to reproduce to the issue summary.

  • Status changed to Active 2 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States joakland

    I am having a related issue that was fixed by the drush command in #18. Here are my steps to producing the problem:

    1. If you have email handlers for a form, navigate to `/admin/structure/webform/manage/purchase_request_form/handlers`
    2. Click "Edit" for any handler
    3. Make a change and click the "Save" button
    4. "Text format field is required" error is thrown.
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada OMD

    I'm suddenly having this issue as well. I can't save any form elements, nor can I even save a new form created as a test without getting the "Text format field is required." error message. I've not adjusted any of my text formats for a very long time so I think that is not the cause, nor have I disabled any of them in recent memory. I'm running Drupal 10.5.1 and Webform 6.2.9. I have another Drupal site with identical versions for core and Webform and it does not have this issue though. Both sites do have the Text Format: Webform (Default) - DO NOT EDIT visible and it's disabled.

    Running drush php:eval "\Drupal\filter\Entity\FilterFormat::load('webform_default')->setStatus(true)->save();" on the site that was throwing the error fixed the issue for me as well.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States jrockowitz Brooklyn, NY

    A few options to move forward

    1. Tag stable release of 6.3 and encourage people to upgrade
    2. Add check to status report to ensure the "Webform (Default) - DO NOT EDIT" text format exists and is enabled.
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada OMD

    I think you're missing something because even though now I'm able to save webform fields again without the error message, the Webform (Default) - DO NOT EDIT Text format is still showing as disabled. It's also showing as disabled on another production site of mine that has not been throwing the error at allโ€“same core version, same webform version.

  • ๐Ÿ‡ท๐Ÿ‡บRussia urix

    I have the same problem: "Text format is missing".
    I can't add new form, or edit any form that has a text field.
    I can't select text format in the drop-down menu - there's no available formats.
    I wasn't tracking the exact moment when it stopped working.

    Drupal 10.5.2, Webform 6.2.9

  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany kreatIL

    I ran into the same problem: after upgrading to Webform 6.3-beta4 the issue with the hidden text format showing up in the list was fixed, but I still could not edit any existing Webforms.

    In my case the root cause was that the filter.format.webform_default configuration had become corrupted:
    โ€ข status was set to false (disabled)
    โ€ข Wrong dependency (slick) was added
    โ€ข An extra slick_filter was attached

    This meant the special Webform (Default) โ€“ DO NOT EDIT format was no longer valid, so Webforms with #format: webform_default could not be edited.

    Solution:
    1. Overwrite the broken config file: filter.format.webform_default

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

    2. Re-import it via drush cim

    3. Clear caches

    After restoring the config, editing existing Webforms works again in my usecase.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States jrockowitz Brooklyn, NY
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States jrockowitz Brooklyn, NY

    jrockowitz โ†’ changed the visibility of the branch 3510410-disabled-webform-text to hidden.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States jrockowitz Brooklyn, NY

    I think our best option is to add an update hook that restores filter.format.webform_default, just in case it was disabled or changed.

    Do we also need to reimport the ckeditor configuration?

    We should only do it for 6.3.x since 6.2.x is already deprecated.

  • Pipeline finished with Success
    4 days ago
    Total: 657s
    #578392
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States jrockowitz Brooklyn, NY

    The MR feels like a very safe way to help mitigate this situation since I user just needs to update the webform module to address the problem. Moving to RTBC

  • Pipeline finished with Failed
    about 17 hours ago
    #580591
Production build 0.71.5 2024