🇧🇪Belgium @joevagyok

You can work around this by creating your own filter plugin to ensure name tag is maintained.

class FilterAnchorLink extends FilterBase {

  /**
   * {@inheritdoc}
   */
  public function process($text, $langcode) {
    $result = new FilterProcessResult($text);

    $dom = Html::load($text);
    $xpath = new \DOMXPath($dom);
    foreach ($xpath->query('//a') as $node) {
      $href = $node->getAttribute('href');
      if (!empty($href)) {
        // If there is an "href" defined, we should not do anything.
        continue;
      }
      $name = $node->getAttribute('name');
      if (empty($name)) {
        // If there is no deprecated "name" defined, we should not do anything.
        continue;
      }
      $id = $node->getAttribute('id');
      if (!empty($id)) {
        // If there is an "id" defined, we should not do anything.
        continue;
      }
      $node->setAttribute('id', $name);
    }
    $result->setProcessedText(Html::serialize($dom));

    return $result;
  }

}

Temp fix applied for the issue, I will still leave it active until we get the related issue fixed.

Uploading a patch file for composer patching.

I pushed a basic test involving the CasHelper::EVENT_PRE_REGISTER event.

joevagyok → created an issue.

Indeed @StryKaizer, I am looking into a robust solution as we speak. Thank you for your support on this issue!

CKEditor4 and D9 have reached end of life state, therefore we don't support 2.1.x any further.

However, I agree to adapt the listened event to "change:data".

I can't reproduce the problem over 3.x on D10.2.

joevagyok → changed the visibility of the branch 3366798-failure-in-support to hidden.

joevagyok → changed the visibility of the branch 3366798-ckeditor-fix to hidden.

joevagyok → changed the visibility of the branch 3.x to hidden.

joevagyok → changed the visibility of the branch 2.1.x to hidden.

Issue is fixed in a new PR, the merge commit will be pushed to 2.1.x as well.

joevagyok → changed the visibility of the branch 3375880-maxlength-does-not to hidden.

joevagyok → changed the visibility of the branch 3.x to hidden.

I had 2 of my colleagues review the MR. It is ready for merge.

Thanks for the quick action. I will check it and will report back.

joevagyok → created an issue.

Great job! I will make a review.

Please see 🐛 Revert "Inline Blocks on Layout Builder" issue which introduced a bug of duplicate entity clones Needs review issue for more information where this is originating from. It most likely will be reverted.

joevagyok → created an issue.

The merged code from this issue introduced a bug on the latest beta5 release!
I understand the urgency of the layout builder issue, but we can't merge code without tests!

I see code fragments from #3258535 🐛 Translatable entity reference fields are not cloned correctly Needs work ended up in the merge request, which basically looping through the languages and cloning entities all over the place without actually preventing creating several duplicates and filling up the database with orphan entities.

I will open a merge request to revert this issue and make a new release as it is broken and create an opportunity to fix the problems and implement tests.

For me this seems to be a similar issue to the one with text formats.

Thank you for the contribution! Would be nice to see a test for this without the solution to validate the issue and in a new commit adding the fix should make the test pass.

@matthieuscarset we are using the solution in a paragraph field with Seven theme and Claro. I think the problem will be theme related, so the selector in the JS might not apply for Gin theme.

Pushed the fix which made the test pass.

Pushed the test only to the MR which will fail.

Thanks for the feedback!

I don't really understand what is going on now.
The work is ongoing in the merge request and not patches! I clearly stated that the patches in #53 are meant to be used for composer patching. Also, changes missing from your patch which are in the present merge request. Nevertheless, issues are not addressed from #47.
Removing patches for clarity.

Double check which patch you applied for you admin theme!

@szato, we faced the same issue, however we felt changing the logic around the thumbnail name generation might be an overkill and we refrained from solving front-end cache issue with changing the back-end logic.

We have varnish configured on our sites, which further complicates the issue.
So we applied the changedTime of the thumbnail entity to the URI of the image style served, as a get parameter, in an md5 encoded format.
Browser cache relies on the URI too, like varnish does, so cache-busting by get parameter is an acceptable solution which is well separated from the back-end logic of thumbnail generation.
However, we found that the changedTime on the thumbnail entity is not update when we trigger this action, so that might be something to address here!

@geekygnr, I understand your good intentions here! Please take no offence from my side!

Changing the UI/UX behaviour of the module, which is not a small change and definitely not a patch release, patch release suggests there was a bug which needed fix.
That is the reason making changes without tests is risky and if this module had been used by thousands of sites, would cause problems for them. We caught it because we have automated tests on our side and have nightly builds, but we all bear the responsibility when providing for a community.

I will take some time to write tests for the module. For example, the #states required won't work if the field is in field group or paragraphs.
Thanks for making the requested changes!

Left another review on the code, please make sure to load up the config to check the string is correctly saved, beside asserting the success message.

PR merged in github and will be pushed to Drupal.org.

Other test cases are still failing.

This needs to be checked over 3.x-dev if it can be reproduced.

Please re-check this if it can be reproduced on 3.x-dev!

Thank you all! Will be released as a beta release today.

Thank you for noticing, I fixed the typo in the MR and re-upload the two patches for composer patching.

Thanks for the contribution to this.
However, the way this was orchestrated bothers me. I leave my thoughts here for consideration in the future releases.
Firstly, this change is missing tests.
On the other hand, our builds are failing because we relied on the fact that the type selection was a required field. Such change, should not be introduced in a patch release, because you change the behaviour of an existing feature.

None of the above proposed patches offer the right solution here, by hardcoding a maxlength number on the translation form element.

Since config_translation is not aware of the form used for the given config, it relies on a basic mapping between config types and field elements.
Therefore, config_translation has no idea about the fact that in the parent issue → , maxlength was set to 255. The label config type is mapped to Drupal\config_translation\FormElement\Textfield which uses the default 128 char maxlength setting.

So either we change the slogan config type from label to text which will allow more characters on translation too, or come up with way to set core from Element properties within config_translation per field.

As a workaround, developers can make their own class and change the mapping to override the Drupal\config_translation\FormElement\Textfield class to their own class where they set all desired properties to the Textfield element.

And as for the test failures with ajax, see this change record → . We also started to have the same failures, and we are asserting on elements appearing on the screen instead of using waitForAjaxToFinish().

Please note that, tests are failing on core v9.5 which I am not sure how relevant at this point, since it will not be supported further I believe. I leave that to the maintainers.

Patch #85 works fine for us. Moving to RTBC.

Patch #55 works well for us!

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 workaround this 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]);
                  }
                });
              });
            }
          });
        }
      });
    }
  };

Adding the same patch, only changing the isInsideTabledrag selector to make it work with Seven administration theme.

@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 custom fields with multiple subfields (columns) shipped by several contributed modules which might require such logic on any site. So I believe it is a real issue, just like others mentioned before me.

Uploading patch version of the merge request for composer patching for the meantime.

Strange because I checked with multiple CKEditor 5 editors on the page and it was working fine. Nonetheless, it is covered with tests.
Can you re-check your setup or give more information about your environment in question?