<textarea>s using Text Editor always fail HTML5 validation when "required" is added via #states

Conditionally marking a field as required using #state makes no sense to me, because it means Form API (the server side) can't enforce it. What am I missing?

Also, this is minor at best, this is an extreme edge case that will at most affect 0.01%.

This is still an issue even though #1954968: Required CKEditor fields always fail HTML5 validation was already merged a long time ago. That solution did not account for a change of states.

Also, this is minor at best, this is an extreme edge case that will at most affect 0.01%
Conditionally marking a field as required using #state makes no sense to me, because it means Form API (the server side) can't enforce it. What am I missing?

I think there are two assumptions being made here.

1. Assumption: It doesn't affect a lot of users. - I think it does, I have run into this on the past several large govt projects I have worked on. Each time we have to come up with less than ideal solutions.
2. Assumption: Conditionally marking it as required is nonsensical because the api can't enforce it. - This is not always true. Sometimes we go to the extent of writing constraints and validators to enforce it. Unfortunately it never gets that far because html5 validation prevents it from ever making it that far, but the editor has no idea because CKeditor mangles the field id so it no longer is focusable.
3. Assumption: it is not a bug. - #states supports requiredness, so it is a bug that any field using ckeditor can not properly get passed html5 validation if it was set by #states.

I agree with swirt, I am facing this issue a lot with too many projects as well!

This is reported on Drupal 8, which is no longer supported. Does this problem exist on a supported version of Drupal? If so, update the version value. Thanks

Yes this is still an issue in the D9. Can not say for certain on D10

Ignore me, this is a separate issue entirely

@Wim Leers, here is the 0.01%! :)

We have many fields conditionally marked as required by states and having that enforced by symfony constraints on API level.
There are several contributed modules shipping custom fields with multiple subfields (columns) which might require different form logic on different projects by developers.
So I believe it is a real issue, just like others mentioned before me.

The patch didn't work for me, and for some reason even when it worked, for some paragraph fields, the reinitialization placed an additional editor after the first one, so I ended up having 2 complete editors rendered for a single field.

So I tried to come up with a simple and clean solution to work around the problem, which basically keeps the editor's source element up to date via a listening to the change event inside the editor model. So when submit happens, the source element contains the data from the editor.

Pasting the JS code here:

/**
   * Handle CKEditor change event to keep the source element up to date.
   *
   * @type {Drupal~behavior}
   */
  Drupal.behaviors.ckeditor5SourceElementUpdater = {
    attach: function (context, settings) {
      let $context = $(context);

      // Iterate through all CKEditors on the page.
      $(once('ckeditor5-states', $context.find('[data-ckeditor5-id]').filter(':input'))).each(function () {
        if (this.dataset.ckeditor5Id) {

          let editorId = this.dataset.ckeditor5Id;
          // Using setTimeout() in order to ensure all CKEditors are loaded.
          setTimeout(function() {
            const editor = Drupal.CKEditor5Instances.get(editorId);

            if (editor) {
              $(once('ckeditor5-states-binding', editor.sourceElement)).each(function() {
                editor.model.document.on('change', function () {
                  if (editor.getData() !== editor.sourceElement.textContent) {
                    editor.updateSourceElement();
                    $(editor.sourceElement).trigger('change', [true]);
                  }
                });
              });
            }
          });
        }
      });
    }
  };

Off-topic: I actually worked on something related a few weeks ago: #3409525: Regression from #3341682: #states + #required do not automatically work together, resulting in an unsubmittable AccountSettingsForm, but almost the opposite direction.

On-topic: let's start with writing a failing functional JS test that shows the problem, so that we can fix this and never regress again! 😊 Then the JS snippet in #13 should make that test pass. 👍

Pushed the test only to the MR which will fail.

Pushed the fix which made the test pass.

Issue summary appears incomplete. Please use the standard issue template.

I just updated the summary to use the template.

Left 2 comments on MR, one is nitpicky but believe return docs should be included.

Fix from related MR worked for me on Drupal core 10.2.2 and Conditional Fields 4.0.0-alpha5.

Needs review from community and we can include it in next release to fix this and related https://www.drupal.org/project/conditional_fields/issues/2988937

Reading early comments I should of also tagged for steps to reproduce early on. It helps reviewers/committers to be able to quickly see how to reproduce the problem.

I updated the description to include the steps to reproduce.
The point of pushing test before the fix was to prove and show the problem, that should be the single source of truth for the reviewer, not what is in the issue description. But that is just my opinion.
Please see commits from #16.

Purpose of the issue summary is to be able to quickly get up to speed just fyi

Issue summary appears clear and all feedback on MR resolved.

few comments

Exported MR into patch file.

deleted by user.