Merge Requests

Recent comments

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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!

πŸ‡§πŸ‡ͺBelgium f0ns

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

I’ll test this and get back on this.

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

@xjm it should be fixed now. Thanks!

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

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!

πŸ‡§πŸ‡ͺBelgium f0ns

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";
πŸ‡§πŸ‡ͺBelgium f0ns

Thank you for the new release πŸ™

πŸ‡§πŸ‡ͺBelgium f0ns

I've tested the MR and everything works fine.

πŸ‡§πŸ‡ͺBelgium f0ns

The patch in attachment fixed the issue for me.

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

Would be nice to get a D11 release out there. πŸ™

πŸ‡§πŸ‡ͺBelgium f0ns

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).

πŸ‡§πŸ‡ͺBelgium f0ns

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....

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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

Thanks a lot!

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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!

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

Just tested it again and looks good to go.

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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
πŸ‡§πŸ‡ͺBelgium f0ns

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!

πŸ‡§πŸ‡ͺBelgium f0ns

Here is a patch that updates the README.

TODO: Update the project page with these instructions.

πŸ‡§πŸ‡ͺBelgium f0ns

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!

πŸ‡§πŸ‡ͺBelgium f0ns

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!

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

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.

πŸ‡§πŸ‡ͺBelgium f0ns

Thank you, the patch provided works great here!

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

Thanks!

πŸ‡§πŸ‡ͺBelgium f0ns

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

Thanks!

πŸ‡§πŸ‡ͺBelgium f0ns

This patch fixes this behaviour for me

πŸ‡§πŸ‡ͺBelgium f0ns

Thank you for your swift reply and testing the patch.

πŸ™

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

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
    );
}
πŸ‡§πŸ‡ͺBelgium f0ns

You are welcome, enjoy the module!

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

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

πŸ‡§πŸ‡ͺBelgium f0ns

A configure link was added in the D11 release.

πŸ‡§πŸ‡ͺBelgium f0ns

Thank you, i'll review this patch.

Production build 0.71.5 2024