🇧🇪Belgium @f0ns

I had the same error.

Applying and testing the code that is in the merge request (https://git.drupalcode.org/project/pathauto/-/merge_requests/91.patch) fixed it for me.

Thanks!

Then I can’t think of a case where you need to calc the height dynamically where it’s not 100% of the height for the sidebar.

I think it depends on how you see the sidebar vs the topbar.

Since the sidebar holds the logo I personally feel it should always be 100% height and the header shouldn't overlap it or push it down because the logo wouldn't be in the lefthand top corner in this case which feels visually weird.

The suggestion indeed also fixes the problem and seems to me that this is a better solution (delete one line of CSS instead of adding one line of CSS).

Please review!

Thank you sir and sorry for the extra hassle. Have a great day and thank you for the new release.

You might be right, I did not notice this css at first.

I’ll test this and get back on this.

Can you test with the provided patches if it also fixes it for you? Here everything works now. Thanks!

@xjm it should be fixed now. Thanks!

Thank you for testing, i’ll leave it on needs review for now and see if we can have an extra pair of eyes on this one.

I found two occurences and altered these to renderRoot(). This fixes the issue for me.

https://git.drupalcode.org/issue/leaflet-3531522/-/commit/f407deaf38e808...
https://git.drupalcode.org/issue/leaflet-3531522/-/commit/20835f5a6ae99d...

f0ns → created an issue.

I've added the css to fix this:

https://git.drupalcode.org/issue/drupal-3531516/-/commit/8fda91d0d4805a5...

I've patched my sites with it and everything works as expected now.

f0ns → created an issue.

Thank you for picking this up this quick!

I've added a merge request that fixes the problem for me.

The message is rendered above the sidebar, it disappears after a few seconds so this behaviour is more desirable than an unreadable message.

f0ns → created an issue.

That is weird, I just tested my initial patch and the MR and both apply correctly and fix the issue.

I'm on a Drupal 11 installation where I use:

• Conditional fields - Version: 4.0.0-alpha6
• Layout Builder iFrame Modal - Version: 1.3.6

When creating a block with /block/add/[block-type] everything was working as expected.

When creating a block in layout builder and in the layout builder iframe modal it was not working as expected because conditional fields didn't trigger anything.

After applying and testing the patch in #38 everything works as it should. Thanks a lot for your work on this, it helped me out a lot!

f0ns → created an issue.

f0ns → created an issue.

f0ns → created an issue.

I'm running MAMP on Mac OS X and I found this issue which helped me.

I'm adding it here for future reference if needed:

I was unable to send mails locally (and catch them with mailhog).

I got the following error:

An attempt to send an e-mail message failed, and the following error message was returned : Error creating transports: Unsupported sendmail command flags "/Applications/MAMP/Library/bin/mhsendmail --smtp-addr=0.0.0.0:1025"; must be one of "-bs" or "-t" but can include additional flags.

The solution was to add the following line in the php.ini file of the active php version:

; For Unix only.  You may supply arguments as well (default: "sendmail -t -i").
; http://php.net/sendmail-path
sendmail_path = "/Applications/MAMP/Library/bin/mhsendmail -t --smtp-addr=0.0.0.0:1025";

Thank you for the new release 🙏

I've tested the MR and everything works fine.

The patch in attachment fixed the issue for me.

f0ns → created an issue.

This patch fixed this behavior in the settings form for me.

f0ns → created an issue.

Somebody, anybody?

Would be nice to get a D11 release out there. 🙏

Upgrading to 3.0.0-beta1 fixed the issue. Thanks!

f0ns → created an issue.

I had the same issue and the MR fixed it for me in the form of a patch (in attachment for others that also need it).

I created a patch with replaces $.trim with .trim based on the JQuery documentation:

Note: This API has been deprecated in jQuery 3.5; please use the native String.prototype.trim method instead. Unlike jQuery.trim, String.prototype.trim does not work with types other than strings (null, undefined, Number). Make sure that your code is compatible when migrating.

Source: https://api.jquery.com/jQuery.trim/#:~:text=Note%3A%20This%20API%20has%2....

I have the same issues in a Drupal 11 environment using the Views Load More module with the following error:

An error occurred during the execution of the Ajax response: TypeError: $.trim is not a function"

Your reasoning on where this error comes from seems accurate.

Tested and works great, would be nice to get this in an official release. Thanks!

Added the correct patch and not the old one that did not apply =)

I applied MR 35 as a patch:

https://git.drupalcode.org/project/context/-/merge_requests/35.patch

But then the D11 compatibility patch didn't apply anymore after that so I made a new one (in attachment) that does work.

Apply it after the above patch.

Just tested the new patch on 4.2.2, it works great.

Thanks a lot!

Just checked if it was possible to alter the patch for it to work again.

Looks like it's more work than I anticipated due to https://www.drupal.org/project/simple_sitemap/issues/3484114 📌 Clean up UrlGenerator classes Active

Patch in #22 was working perfect with 4.2.1 but it doesn't apply anymore on 4.2.2 and the initial problem is introduced again.

Thanks works great, using the patch in #8 for now.

Small nitpick: I noticed on mobile the 80% width makes small edits, on a phone for example, a bit hard.

I'll try to find a solution for this when I can find the time.

Thanks!

Thanks works great, using the patch in #8 for now.

Hello thank you for your feedback, it does indeed steer me in the right direction.

The geocoding might overcomplicate it a bit.

I think I didn't take enough time to try to describe what I was looking for.

In the current module you can drop markers which is great but there is no out of the box way (as I can see) to add some context to a marker (which is shown in the tooltip).

For example it would be great to add markers in a neighbourhood to show locations like:

• Drop marker on the map and add a label "Post office" (that is shown in a tooltip when viewing the marker on the map)
• Drop marker on the map and add a label "School" (that is shown in a tooltip when viewing the marker on the map)
• Drop marker on the map and add a label "Bakery" (that is shown in a tooltip when viewing the marker on the map)
• Drop marker on the map and add a label "Coffee shop" (that is shown in a tooltip when viewing the marker on the map)

Thank you for the time to answer my questions and the work on this module.

Have a great day

Fons

Just tested it again and looks good to go.

Thank you for your answers, I was indeed referring to the widget (and not the formatter) my bad.

As I can see now there is no default way to drop a marker on the map and add some text to the pop-up in the widget.

I guess the only way to get around this for me is to add an address field (that gets geocoded) and a text field field and render that with a view / code on the map myself.

Thank you for your feedback.

f0ns → created an issue.

I got rid of the patch and added the preprocess block as suggested in comment #92 and #94.

This works with bigpipe.

Thank you, this is the cleanest solution for now (for me) as I don't have to patch core.

The patch #28 works for me. I would like to thank you for this work!

A small nitpick, please use - instead of . in patch filenames in the future.

[module-name]-[short-description]-[issue-number]-[comment-number].patch
# e.g. some_module-some-bug-123456-3.patch

I just tested the patch in comment #4 and everything seems to work fine.

I was wondering if this can get merged in a new release?

For now I'll use the patch as this is one of the modules that holds me from upgrading to Drupal 11.

Thank you!

Here is a patch that updates the README.

TODO: Update the project page with these instructions.

f0ns → created an issue.

Dear gausarts, thank you for the compliment and sorry to read that.

Just a thought:

If we would toggle this setting by default in the install file of the module it would only trigger / set it default for new installs.

Existing installs wouldn't be affected, if you want to affect those (which you don't and I totally get that) you would add this in an update hook.

If you are interested in a patch for the install file i'd be happy to make it but it is not a dealbreaker for me.

Thank you for all your work and have a great evening! There are a lot of good people out there so try to focus on those, that may help!

Thank you for your reply, I checked the Blazy settings page but it seems that I read over the checkbox to disable these classes.

If I may suggest an upgrade I think it's fair to check this setting by default as you a clean DOM is prefered over all these classes in most cases but that is just my view.

Thanks!

I created a patch that cleans out the function so the DOM is now a lot less bloated with unneeded classes.

I might miss the point why all these classes are added on every media element but they are not needed for the module to work and I don't see the value they add.

Feel free to enlighten me.

f0ns → created an issue.

Thank you for testing, looks good to go.

Concerning comment #6, personally I don’t see the need to add extra control statements to other regions as these elements have no containers that have any css markup in core.

Thank you, the patch provided works great here!

The notice in https://pagespeed.web.dev is gone now and the accessibility score increased.

Thanks!

The comment in #110 works perfectly (I only use the GA portion).

Thanks!

This patch fixes this behaviour for me

f0ns → created an issue.

Thank you for your swift reply and testing the patch.

🙏

I've added a patch to make sure "navigation_layout" can't be disabled anymore.

So for reasons beyond my control the "navigation_layout" seems to exist (core module navigation) and is something that is considered needed.

If that's the case it would be best to alter this module so you can't disable it (since it will throw the error I mention).

For now I disabled this module and disabled / hide the layouts with the following code in case somebody has the same problem as I do.

In this example I hide all the layouts except the one col layout.

/**
 * Implements hook_layout_alter().
 */
function YOUR_MODULE_layout_alter(&$definitions)
{
    // an array of layouts to keep.
    $layoutsWhitelist = ['navigation_layout'];

    // layouts that are required and cannot be removed.
    $requiredLayouts = ['layout_onecol', 'layout_builder_blank'];

    $layouts = array_merge($requiredLayouts, $layoutsWhitelist);
    
    $definitions = array_filter(
        $definitions,
        static fn(string $id) => in_array($id, $layouts, true),
        ARRAY_FILTER_USE_KEY
    );
}

/**
 * Implements hook_preprocess_item_list__layouts().
 */
function YOUR_MODULE_preprocess_item_list__layouts(&$variables)
{
    // For some reason removing this layout breaks the website so we hide it.
    $layoutToHide = ['navigation_layout'];

    $variables['items'] = array_filter(
        $variables['items'],
        static fn(string $id) => !in_array($id, $layoutToHide, true),
        ARRAY_FILTER_USE_KEY
    );
}

f0ns → created an issue.

You are welcome, enjoy the module!

The README file and the Project detail page have been updated to support installation via Composer.

Dear Duckydan

Thank you for this suggestion, this would indeed improve the developer experience.

I'll test this and add it the Readme after my vacation.

Thank for your patience

Fons

A configure link was added in the D11 release.