🇧🇪Belgium @joevagyok

joevagyok → created an issue.

joevagyok → created an issue.

The patch in #11 looks good. We are using it on our project.

joevagyok → created an issue.

This issue is not close to be merged and here are some reasons why:

• The MR still introduces a bug which creates more cloned entities in certain conditions that in should. This can be only detected with automated tests asserting the amount of entities in the database after each clone.
• The base class meant for content entities should not contain layout builder specific logic, not every site has layout builder.
• There are certain entity types and entity reference combinations that are not entirely clear how we should proceed.
• The MR needs automated tests.

These have to be addressed before we make a review.

joevagyok → created an issue.

joevagyok → created an issue.

Thanks for reporting the problem. It seems that the new version of AI module introduces change that the plugin needs to accommodate.

Currently, I am away for couple of weeks, but after I will fix the issue, unless someone contributes the fix before.

joevagyok → created an issue.

joevagyok → created an issue.

Thank you for the contribution.
Please add a test case functional test case to validate we actually have the issue and preferably the fix in a separate commit to show it fixes the problem.

dan2k3k4 → credited joevagyok → .

joevagyok → created an issue.

joevagyok → made their first commit to this issue’s fork.

Can we have an MR over 4.x please?

Thank you! :)

joevagyok → created an issue.

joevagyok → created an issue.

Thanks @tirupati_singh, small note from my side, if I may.

It looks good in general and the style looks similar to the examples mentioned. However, not sure how big the project browser will show these images, but if it will be small, then the numbers and the "Maxlength" text would be too small I think. But I would refer to @kristen pol in this matter.

If we wish to have the name of the module in the image, please respect the way it is on drupal.org page, "MaxLength" in this case.
Otherwise, the HTML attribute could be used, such as "#maxlength" which is self-explanatory as well.

Let's make a merge request out of this and an automated test!

Please create a merge request with the changes and provide/adapt tests!

@partdigital can we have another PR with your proposal in a different branch on this issue for us to evaluate and choose?

Thank you!

This will be merged in 2.x as well.

joevagyok → changed the visibility of the branch project-update-bot-only to active.

joevagyok → changed the visibility of the branch 3431839-automated-drupal-11 to hidden.

Thanks @berdir! The MR adds previous minor and next major to the pipeline to test and fixes the issue mentioned above with jQuery.

joevagyok → made their first commit to this issue’s fork.

Thank you!

Thank you all!

I agree with @justcaldwell comment to move it into RTBC!

Planning on to release it this week.

Reuploading the patch to use diff format instead of the gitlab patch format to avoid issues for those who want to use composer to patch the module.

Stabilized the MR and fixed a wrong use statement that went in there. Tests are passing now.
I attached the patch file version of the MR for composer patching and removed the patches from visibility to focus on the MR further on within this issue.

Opened an MR to continue the work there. Also attached a patch, for composer patching.

joevagyok → made their first commit to this issue’s fork.

Thank you!

Reviewed and tested, moving it to RTBC.

joevagyok → made their first commit to this issue’s fork.

I had a look and that is correct.

Was this tested over 2.1.x version too @chaitanyadessai?

@recrit When it is a "Hard limit" the source of the validation failure for the user should clear. We should make sure to do so and use soft-error when there is no "Hard limit" enabled.

That is most probably due to the version of Drupal your site uses. What version of Drupal are you on?
The support of D11 still pending to be released.

The whole point of pushing test before the fix was to prove the problem. Please see #16.
I really don't understand now what is the matter here.
Tests are there, they tell what is the exact problem, besides the multiple comments above.

Thanks, I thought it was something with the patch.

@simohell where do you see this "0/250" description exactly?

Can we have this issue checked on 3.x and update the MR? I will merge in 2.1.x too if valid and works.

@bharath-kondeti the README.md reads as follows:

MaxLength allows site administrators to set hard or soft character
limits on titles, text fields, and links.

Hard limit will prevent the user from typing further and will truncate the text after the given limit.
Without this it is a soft limit, meaning the user can time further and it will be saved, but the text count will be red in a warning state that it is over the defined limit.

So far the issue could not be reproduced, so I will move this to pending state until we get more details about the problem.

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.