🇧🇪Belgium @f0ns

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.

Thank you, i'll review this patch.

I just released a Drupal 11 update.

Just scanned the code of the module real quick and indeed this module would need a good portion of rewrites in order to work with Layout Builder.

Glad it worked!

Good luck with the project

I think this has to do with a z-index on your bg header.

Have you tried one of the following:

• Change z-index configuration from auto to for example 999.
• Alter the Header Z-index with Dev Tools in your browser to see if the issue is then resolved?

Best regards,

Fons

The patch in #45 did the trick and I could reinstall BigPipe. Thank you for the workaround!

Uninstalling Big Pipe fixed the issue for me so this is a temporary workaround.

I am experiencing the same issue after updating to Drupal 10.3

status-messages.html.twig is not being suggested.

I'm using a custom theme that I made.

Thank you!

I've updated the module page as it was still talking about the email address.

https://www.drupal.org/project/social_auth_strava →

Hey nginex,

If it is a new platform with no users that will work.

If you have an existing platform with users in it already and all of a sudden they start using the Social Strava button login instead of their emailaddress this will create a new account instead of logging in their existing account (no match on email address) so I do think this will have an impact.

Good luck!

Hello nginex,

I just checked the existing module and API to have an idea of the changes that will be needed to make the module work again.

When investigating this I noticed the following notification:

"January 15, 2019
Email address is no longer part of the profile:read_all scope and is removed from the athlete model."

I also checked the API documentation and it looks like Strava does not return an e-mailaddress anymore. When you would authorize there is no way of checking/matching the e-mail with existing users. So you wouldn't know if you need to login an existing user or create a new user.

This is something to look into before putting effort in this module as I don't think it's possible anymore.

I look forward to your feedback.

Dear nginex, that would be awesome!

I added you as a maintainer, if I can be of any help (for example testing).

Feel free to contact me.

Thanks a lot in advance!

Thank you for your input.

I deleted the link on the module page, I wasn't aware that the site was hacked and/or redirects to a russian website without a https:// link.

The module still has a lot of use cases as you can create a sticky element without the need of custom css and/or a custom theme. It works out of the box with for example the Olivero theme with the following setup.

Thank you all for your input, I don’t think the initial patch adds any value to the module so I’m closing this issue for now.

Thank you!

I'm sorry, I've added the release notes. This was a very small update that only adds D10 compatibility and doesn't change/add anything else to the module.

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