🇧🇷Brazil @andre.bonon

I've got a similar situation with a webform where one field controls the visibility of another and it is replaced by an Ajax call. I tried out both Patch #2 and the MR, and I can confirm that the MR still hasn't fixed the issue, but Patch #2 has.
Drupal version: 10.3.1

Is openy_carnation still compatible with 10.0.x?

Regardless of what we decide, I've pushed a fix to ensure the exception is an instance of NotFoundHttpException, because in some cases the Exception might be of another type and the response doesn't have a status code.

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

This piece of code is no longer needed (these templates are suggested by default now):

// Adds template suggestions for 40x pages.
  $http_error_suggestions = [
    'system.403' => 'page__403',
    'system.404' => 'page__404',
  ];
  $route_name = \Drupal::routeMatch()->getRouteName();
  if (isset($http_error_suggestions[$route_name])) {
    $suggestions[] = $http_error_suggestions[$route_name];
  }

I understand, however, there are some sites that, for their own reasons, cannot be upgraded to version 7 of the module.
I appreciate your effort, but this is about a single line already merged on 7.x.

andre.bonon → created an issue.

I tested the #48 🐛 Error after update to Drupal 10.1.0 Active and works for me with 10.2.7.

Attaching patch file to be used with composer.

andre.bonon → created an issue.

I'm uploading the fix as a patch so devs can use with composer.

I saw on the module's homepage "6.0.x = is the current active development branch and currently supports D9 + D10", so I'm re-rolling this fix to the 6.0.x too.

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

+1 working for me.

A paliative solution has been pushed.

andre.bonon → created an issue.

I am adding the patch file so the devs can apply the fix.

Attaching a patch file from the MR 8779 which applies to Drupal 10.2.x. (tested on 10.2.7) , to be used with composer patches.
It fixes an Ajax error from happening with the Layout builder modal and Drupal-off-canvas that wasn't fixed by the #126.
The Ajax error was preventing the LB modal from closing.

I'm testing this module and as I can see the "Limit allowed HTML tags and correct faulty HTML" filter removes the data attributes responsible for alignment in the drupal-media tag:
On Ckeditor:
<drupal-media class="image_resized" style="width:359px;" data-media-width="359px" data-entity-type="media" data-entity-uuid="a77a9f7c-a834-4bea-9a80-bc8169ee7587" data-view-mode="cke_media_resize_large" data-align="center">&nbsp;</drupal-media>

On the page:
Expected:
<div class="image_resized align-center media-embed-resized" style="width:359px;">

Actual result:
<div class="media-embed-resized" style="width:359px;">

I also tried the Extended HTML Filter module, but I had no success even applying the following patches:

1. core:
   1. https://www.drupal.org/project/drupal/issues/3226368 🐛 FilterHtml accepts <*> but does not support it, resulting in inaccurate ::getHtmlRestrictions() return value Needs work
   2. https://www.drupal.org/files/issues/2024-02-26/3226368-40.patch →
2. extended_html_filter
   1. https://www.drupal.org/project/extended_html_filter/issues/3401513 ✨ Match the filter_html <> ckeditor5 integration in Drupal core Needs work
   2. https://git.drupalcode.org/project/extended_html_filter/-/merge_requests...

It is not possible to save the text format. This is what I get from validation:

Error message
The current CKEditor 5 build requires the following elements and attributes:
<br> <p> <* style dir="ltr rtl" lang>
The following elements are missing:
<* style>

I also tried to disable the "Limit allowed HTML tags and correct faulty HTML" filter, but the resize doesn't work without it.

Is there any solution for this issue?

andre.bonon → changed the visibility of the branch 2940605-10.0.x to hidden.

andre.bonon → changed the visibility of the branch 2940605-10.0.x to active.

andre.bonon → changed the visibility of the branch 2940605-10.0.x to active.

andre.bonon → changed the visibility of the branch 2940605-10.0.x to hidden.

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

I executed the steps mentioned and applied the patch.
That works for me.

This merge request broke ping pongs.
I rolled the version back to 9000 and tried to update again, and no new image style is created or displayed on the upgrade dashboard to be manually created.

andre.bonon → created an issue.

andre.bonon → created an issue.

Needs review and testing.

andre.bonon → created an issue.

andre.bonon → created an issue.

andre.bonon → created an issue.

Fixed.

andre.bonon → created an issue.

Fixed. Please check the MR.

andre.bonon → created an issue.

I tested your steps @froboy. That was very helpful.

Please check the fix.

andre.bonon → changed the visibility of the branch 1.0.x to hidden.

andre.bonon → created an issue.

Works well for me.

The fix works for me.

Hi, I've experienced the same issue with the message being displayed to users who don't have permissions to rebuild permissions. I'm going to apply the patch and let you know if it works.
I'm attaching a patch file from the diff so we can use it with composer.

I've added the 'layout-node-form' class to the form wrapper, so it displays the taxonomy form as the node does.
Also, I'm attaching the patch so we can use with composer.

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

Attached is a patch file so it can be used with Composer.

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

Attaching a patch to use in composer.json with the 2.1.2 version.

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

Attaching patch from the MR diff to use in composer.json

Works for me.

Attaching patch to use in composer.json

Attaching a patch to use in composer.json

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

@dineshkumarbollu it works. Thanks for providing a patch for that.

Hey, I'm attaching the code that helped me to hook it in case others need something similar.

Additionally, the code below shows how to use the Observer pattern:

  // Alter the Fullcalendar Options before rendering the calendar.
  const fullcalendarViewObserver = {
    update: (calendarOptions) => {
      // Add custom buttons.
      calendarOptions.customButtons = {
        previousMonth: {
          icon: "chevron-left",
          text: "Prev",
          click() {
            // Get some stuff done when users click on Prev button. 
          },
        },
        nextMonth: {
          icon: "chevron-right",
          text: "Next",
          click() {
            // Get some stuff done when users click on Next button. 
          },
        },
      };

      return calendarOptions;
    },
  };

  // Add a custom observer to Fullcalendar view Subject.
  Drupal.FullcalendarViewSubject.addObserver(fullcalendarViewObserver);

Ok, I've added your suggestion and fixed the other selector as well.
Also, I unbind the event so it doesn't bind the event twice. (That was happening on the /admin/content page)

Attached the patch from MR to use in composer.

andre.bonon → created an issue.

@aaron, we have more issues with the z-index and modals when LB is enabled for other entity types such as Blocks.
I updated the ui-dialog's z-index so as to be the same as Claro's (1260) and pushed it to the MR.
Also, I'm attaching the patch from MR to use in composer.

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

I reported this core bug https://www.drupal.org/project/drupal/issues/3380021 🐛 Stable9 form-element template misses form-type-* class Fixed , so it might avoid issues with themes based on stable9.

andre.bonon → created an issue.

Hi, thanks everyone for your contribution to this issue.
I tried to fix the issue using your approach for webforms (clientside_validation + webform_clientside_validation + inline_form_errors), but the issue was still happening.
In my case, my theme extends from stable9 that doesn't add classes like "form-checkboxes", "form-radios", or "form-type-[type]" to the form elements, which are used in the webform_clientside_validation js selectors.
Stable9 adds "js-form-type-[type]" and forgets about the "form-type-[type]" as in the snippet below:

{%
  set classes = [
    'js-form-item',
    'form-item',
+        'form-type-' ~ type|clean_class, (THIS IS MISSING)
    'js-form-type-' ~ type|clean_class,
    'form-item-' ~ name|clean_class,
    'js-form-item-' ~ name|clean_class,
    title_display not in ['after', 'before'] ? 'form-no-label',
    disabled == 'disabled' ? 'form-disabled',
    errors ? 'form-item--error',
  ]
%}

I fixed the placement issue by overriding the form-element.html.twig and adding the code above. For the fieldset.html.twig, I added the following:

{%
  set classes = [
  'js-form-item',
  'form-item',
  'js-form-wrapper',
  'form-wrapper',
+  'form-' ~ element['#type'] (THIS IS MISSING)
]

andre.bonon → created an issue.

I was trying to find the same feature, but I just found out that if you add the following param "&initialDate=2023-07-28" to the URL, the JS will handle that for you.
So, if you combine the inialDate param with an exposed filter "between", I think you can achieve what you want.
i.e.: ?field_date[min]=2023-09-01&field_date[max]=2023-09-30&initialDate=2023-09-01

Note: I'm using the SmartDate module field.

I did a test setting the "Allowed number of values" to unlimited in the field storage settings and set the cardinality limited to 4.
In the entity form, Drupal was displaying 2 fields and the 'Add another item' button before this patch was applied.
Once this patch is applied, I can see the 4 fields displayed.

Closing this issue in favor of the Clean up UI for 1.x → .

Patch with fixes as described in the issue description.

andre.bonon → created an issue.

+1 patch from #17 worked for me in D10.

Adding a "snapshot" patch from #8, as the MR's Diff might change.

Updating the patch to apply to the D9.4.1.