🇬🇧United Kingdom @fonant

fonant → created an issue.

I've managed to get the Donation pane visible, with the text I entered in the pane's settings for "Call to donate" next to a checkbox.

If I check the box I get "Sorry, Donation is no longer available for registration. It has been removed from your cart." and no donation amount is made available.

Any clues?

Patch #91 applies OK, and fixes the problem for me, thanks!

(You have to apply it in drupal/web/core)

Patch in #5 works for me, thank you!

Re-rolled patch to work with current Drupal 10, which uses "stable9" instead of "stable" for the base theme.

fonant → created an issue.

The problem on that site is that with "Lazy load map" turned on, the map doesn't load. No JavaScript errors, but no map either.

Yes, the problem only happens for me on that one site, but the problem appeared after a Leaflet module update, nothing else changed from when "Lazy load map" was working fine on that site.

Anyway, the workaround is easy, and there might be an issue with OpenLitespeed caching something wrongly. Thanks for looking into this for me :)

I may have been mistaken about other sites having lazy-loading broken since the last update: it could be just this one site.

It's an OpenLitespeed server. I did have trouble with the Litespeed Cache, but that's disabled for the site now. Restarting OLS and PHP doesn't help.

Here's a page with a lazy-loaded map that isn't currently working for me: https://bucks-composites.com/events

There should be a simple views-created map under the Events teasers.

The map DIV is created and sized, but no map is loaded.

Thanks for investigating!

This feature was working fine, until the latest Leaflet module update. Nothing special about the site setups. The problem was noticed by two of my customers on separate websites on different servers (one running Apache, one running OpenLitespeed).

Tested in Vivalid (Chrome) and Firefox, both showed the problem.

Maps generated as a field display, and from Views, both affected. Working fine without lazy loading, blank with lazy loading.

Difficult to debug a lack of JavaScript action, and I'm no JavaScript expert. Perhaps it's something specific I've done - at least the workaround is easy :)

fonant → created an issue.

Hmm... another difference I've found:

The maps that fail to open popups contain an additional command in the AJAX returned:

    {
        "command": "add_css",
        "data": [
            {
                "rel": "stylesheet",
                "media": "all",
                "href": "\/core\/themes\/claro\/css\/classy\/components\/node.css?sfkw3v"
            }
        ]
    },

whereas the maps the work only contain the popup HTML insert command:

    {
        "command": "insert",
        "method": "replaceWith",
        "selector": "[data-leaflet-popup-ajax-entity=\u0022node-2294-map_popup_balloon-en\u0022]",
        "data": "<pop-up-html-here>",
        "settings": null
    }

Could it be that the AJAX mechanism needs the page to be for a node?

The other maps that break with "< node entity via ajax >" are those for a View that's not embedded in a node display.

These views used to work in previous versions of Leaflet and Drupal. Only broke in the last few days.

More information, although I haven't narrowed down the symptoms enough yet:

I have a map that has working popups in the node view page (it's a View Reference field), that fails in exactly the same way when I edit the View (without making any changes) and try to get the popups in the View Preview.

Working:

• Leaflet map view, added to Node display as a View Reference.
• Map displays entity references from four different Node reference fields from the current node.
• Four contextual filters using "Content ID from URL" defaults for "When the filter value is NOT available".
• Popups loading content using "< node entity via ajax >".

Fails:

• Edit the above View.
• Enter the NID four times in the Preview arguments (e.g. 1234/1234/1234/1234).
• Click on a marker in the Preview: popup appears for an instant then disappears. Same error as in summary.

fonant → created an issue.

Patch in #12 works nicely here to fix the problems with facet selections and the browser's Back button. Thanks!

That was a nice fast fix! Thank you @geek-merlin!

Patch from https://git.drupalcode.org/project/drupal/-/merge_requests/5391.diff still works here to fix the problem:

patching file core/modules/views/src/Plugin/views/filter/NumericFilter.php
Hunk #1 succeeded at 420 (offset 16 lines).

Patch #18 works for me to stop the watchdog logs filling up with deprecation warnings. Thanks @gurvindersingh!

Yes, the code works for me as it now stands, thanks!

As a bonus example, I managed to add the Arctic Circle to my maps using this additional code:

        let points = [
          [66.564, -180],
          [66.564, 180],
        ];
        L.polyline(points, { color: '#0003', weight: 1.5 }).addTo(map);

I was quite surprised that "L" was defined :)

Unclear about JS filename: "map-script.js" or "js/map.js"?

Should this line:

lMap.bounds = [],

read:

lMap.bounds = [];

Doh! Of course the other way to fix this is to edit each email definition at /admin/commerce/config/emails and just re-save each one.

I've hacked a workaround for line 111 of commerce_email/src/EmailSender.php, which I think will fix the problem:

'reply-to' => $this->replaceTokens(($email->getReplyTo() ?? ''), $replacements),

Maybe we need an update function to add empty ReplyTo strings for older orders?

fonant → created an issue.

fonant → created an issue.

@a.dmitriiev thanks, I was wondering how @djg_tram had managed with his method.

I now have this working with the patch and a custom module with a hook. Needs a bit more work and some tidying before I post it here.

Phew, this one is still fun to fix if you install geocoder before composer-requiring the providers. I was using just geocoder, and none of the other modules (using the geocoder field in Leaflet maps).

I think the method that finally worked for me was:

1. drush pm:uninstall geocoder
2. drush cr
3. Restart Webserver and PHP processes (Apache, php-fpm, OpenLitespeed, lsphp, etc.)
4. drush pm:enable geocoder

@djg_tram - I can managed to get the derived image written to the public filesystem, but how do I tell Drupal to use the public URL for this image, rather than the private /system/files/... one?

I'd find this useful for a couple of customer sites.

Uploaded full-scale unwatermarked images: private
Derived small-scale and/or watermarked images: public

It's possible to modify the permissions system to give anonymous users access to private derived images for certain styles, but for a site with lots of images it's process-intensive to check permissions for every image. Much better to store the derived images in the public filesystem, so they can be served direct by the web server without needing to bootstrap Drupal for every one.

Workaround:

Edit configuration to remove non-existent permissions, contained in user.role.*.yml configuration files.

fonant → created an issue.

Patch #2 works to fix the problem for me, too.

Hi there, development stopped while the Rules module, which this module depends on, was ready for Drupal 8 and later.

Looks like that's nearly the case, I'll have a look at what changes are needed here.

For what it's worth, the patch in #38 applies with a few small offsets to Drupal 10.1.7 and fixes the problem of active-trail not being applied to menus for View pages.

Fixed for me by patching with Merge request from #19 [https://git.drupalcode.org/project/drupal/-/merge_requests/5391.diff]. Thanks @very_random_man!

Patch #7 fixes the problem for me, but for a different situation: migration source is a CSV file with no headers, and PHP 8.1.26.

Have just contacted andriuzss and thelmer via their Drupal contact forms, offering to help and pointing to this issue.

fonant → created an issue.

Patch in #26 applies cleanly to 3.x-dev and fixes the problem, Drupal 10. Thanks @MukhtarM!

Patch in #11 works here too. Thanks!

Thanks for the speedy update! There's one other link to change, though, in the Description section.

fonant → created an issue.

#8 worked nicely here, too. Thanks @sebasgd

Using plain diff from MR 2 as a patch works to make the button work here :)

@PhilY I don't think that's possible, since we don't have direct access to the view in the query alter.

Patch #12 works to fix the problem for me.

Patch #5 applies but doesn't make any difference to me, this error appearing when upgrading from migrate_tools 8.x-5.x to 6.x

An Apache security update causes spaces in filenames to trigger "AH10411: Rewritten query string contains control characters or spaces" errors in the error log, and "Permission denied".

This is because the spaces get double-encoded during the rewrite process. I find that a fix is to change the index.php rewrite rule from

RewriteRule ^(.*)$ index.php?q=$1 "[L]"

to

RewriteRule ^(.*)$ index.php?q=$1 "[B= ?,L,QSA]"

The "B" flag says to not encode spaces and question marks during the rewrite, and QSA allows any itok= URL parameters to be appended to the query string.

Thanks @weseze for that code!

I found that it duplicated the existing "random seed" sort I had added to the View, calling it random_order_field_2.

That made the think that might be better to look for such a filter already existing, and to modify it, rather than adding a new filter to the view "behind the scenes".

Here's my version of the code:

/**
 * Implements hook_query_alter().
 */
function random_seed_sort_db_query_alter(Drupal\Core\Database\Query\AlterableInterface $query) {
  // Modify any existing random_order_field sort.
  /** @var \Drupal\Core\Database\Driver\mysql\Select $query */
  $order_by = $query->getOrderBy();
  $needs_seed = (array_key_exists('random_order_field', $order_by));
  if ($needs_seed) {
    // Add random sorting with seed by manually calling the service.
    $options = [
      'id' => 'random_seed',
      'table' => 'views',
      'field' => 'random_seed',
      'relationship' => 'none',
      'group_type' => 'group',
      'admin_label' => NULL,
      'order' => 'ASC',
      'exposed' => NULL,
      'expose' => [
        'label' => NULL,
      ],
      'reuse_seed' => NULL,
      'user_seed_type' => 'same_per_user',
      'anonymous_session' => NULL,
      'reset_seed_int' => 0,
      'reset_seed_custom' => 3600, // time in seconds for the seed renewal.
      'plugin_id' => 'views_random_seed_random',
    ];

    /* @var $random_sort \Drupal\views_random_seed\Plugin\views\sort\ViewsRandomSeedRandom */
    $seed = \Drupal::service('views_random_seed.seed_calculator')
      ->calculateSeed(
        $options,
        'MYVIEWNAME', // This is not correct, but only important for cache tag naming.
        'MYDISPLAYNAME', // This is not correct, but only important for cache tag naming.
        \Drupal::database()->driver()
      );
    // Replace rand() with rand(seed).
    $expressions =& $query->getExpressions();
    $expressions['random_order_field']['expression'] = 'rand(' . $seed . ')';
  }
}

This works with MariaDB/MySQL, not sure if it's reliable for all databases.

Update: spelling should be "Cloudflare" not "Cloudlare" in "Additional CAPTCHA Modules" section of the captcha project page.

fonant → created an issue.

The code is working as designed.

Be careful if you want to modify order data using PayPalEvents::CHECKOUT_CREATE_ORDER_REQUEST => 'addCatnums' and PayPalEvents::CHECKOUT_UPDATE_ORDER_REQUEST, the data is in different places in each.

Found the problem!

It was my own custom code, that modified the order line item titles sent to PayPal using PayPalEvents::CHECKOUT_CREATE_ORDER_REQUEST and PayPalEvents::CHECKOUT_UPDATE_ORDER_REQUEST.

For the first event, CREATE, the line item titles are stored in $params['purchase_units'][0]['items'].

For the second event, UPDATE, the line item titles are stored in $params[0]['value']['items'].

Don't know if this is related, but a site I migrated from Drupal 7 to Drupal 9 was failing to display shipping panes for orders.

Turns out I was missing the order shipments field configuration. It seems this is added pragmatically on installing the commerce_shipping module, and I wasn't including it in my site configuration.

Adding these two configuration files re-instated the field and shipping works!

field.storage.commerce_order.shipments.yml
field.field.commerce_order.default.shipments.yml

Same issue here, copying search_api.settings.yml into the configuration sync directory fixed the issue.

Most odd. I now catch the Guzzle exception, and log the details. This allows the PayPal orders that fail in the PATCH to continue anyway.

GuzzleHttp\Exception\ClientException

Client error: `PATCH https://api.paypal.com/v2/checkout/orders/xxxxxxxxxxxxxxxxxxxxx` resulted in a `400 Bad Request` response:
{"name":"INVALID_REQUEST","message":"Request is not well-formed, syntactically incorrect, or violates schema.","debug_id (truncated...)

{"0":{"op":"replace","path":"\/purchase_units\/@reference_id=='default'","value":{"reference_id":"default","custom_id":"1234","invoice_id":"1234-1234567890","amount":{"currency_code":"GBP","value":"7.5","breakdown":{"item_total":{"currency_code":"GBP","value":"7.5"}}},"items":[{"name":"1296px \u00d7 864px JPEG download","unit_amount":{"currency_code":"GBP","value":"1.25"},"quantity":1,"sku":"DD1296x864"},{"name":"1296px \u00d7 864px JPEG download","unit_amount":{"currency_code":"GBP","value":"1.25"},"quantity":1,"sku":"DD1296x864"},{"name":"1296px \u00d7 864px JPEG download","unit_amount":{"currency_code":"GBP","value":"1.25"},"quantity":1,"sku":"DD1296x864"},{"name":"1296px \u00d7 864px JPEG download","unit_amount":{"currency_code":"GBP","value":"1.25"},"quantity":1,"sku":"DD1296x864"},{"name":"1296px \u00d7 864px JPEG download","unit_amount":{"currency_code":"GBP","value":"1.25"},"quantity":1,"sku":"DD1296x864"},{"name":"1296px \u00d7 864px JPEG download","unit_amount":{"currency_code":"GBP","value":"1.25"},"quantity":1,"sku":"DD1296x864"}]}},"purchase_units":[{"items":[{"name":"AGc19877, 1296px \u00d7 864px JPEG download"},{"name":"AG19650, 1296px \u00d7 864px JPEG download"},{"name":"AB00516, 1296px \u00d7 864px JPEG download"},{"name":"AG06613, 1296px \u00d7 864px JPEG download"},{"name":"AG06615, 1296px \u00d7 864px JPEG download"},{"name":"AG01394, 1296px \u00d7 864px JPEG download"}]}]}

(some possibly-sensitive data replaced with equivalent random text)

This was a shorter order, so nothing to do with the length of the JSON.

According to PhpStorm the JSON is valid.

My best guess is that the problem occurs when the JSON body is more than 2,040 characters, so for an order with a LOT of line items. I'll do some more testing when I get a spare moment, using an order with a huge JSON description.

Works for me with Drupal 9 if I patch with #3 then #18.

I might have found a possible problem, but can't see what is causing it.

Emailing myself the json_encode() of the data, for one order the JSON is broken into two lines, with "! " at the end of the first line and a space at the start of the second line. The first line is 2040 characters long.

This makes the JSON invalid, causing the problem.

Is this a red-herring, caused by emailing the JSON? I don't think so, but could be.

If this is a real symptom, what is inserting "! \n " into the JSON text?

Added description to Comments.

Added brief descriptions to the Comments column.

Added summary comments for each library.