🇳🇿New Zealand @djroshi

Hi, sorry I posted here because this was working fine and stopped working 3 weeks ago with #c2f70843a5764450659bb8a2d4f82ea287d50313: Issue #3446781 by strykaizer: Rewrite facets exposed filters to be native views filters

I suspect it might be connected what was reported in #17.

I spent some time trying to track down the issue. Exposed facet filters seem to work unless they are placed in a block using layout builder, in which case they aren't rendered at all. Specifically, the render array for the filter looks like it hasn't got any options in it, it's just a generic empty filter array. Which sounds a lot like what you talk about in #18. Other non-facet filters in the same blocks are rendered fine.

Hi, exposed filters in blocks don't seem to work anymore when using layout builder. The facet filters don't seem to render at all.

I think this may depend on which mailer you are using? In my case I am using Drupal Symfony Mailer ( https://www.drupal.org/project/symfony_mailer → ). A quick debug of commerce_store_mail_alter() reveals that, in my case, $message['params']['from'] is not empty, so $message['from'] is never rewritten.

From the docs for hook_mail_alter:

'params': An array of optional parameters supplied by the caller of MailManagerInterface->mail() that is used to build the message before hook_mail_alter() is invoked.

I'm not sure how necessary the empty($message['params']['from']) check is so not sure what the workaround might be...

djroshi → changed the visibility of the branch 3463217-payment-not-created to active.

djroshi → changed the visibility of the branch 3463217-payment-not-created to hidden.

djroshi → created an issue.

djroshi → created an issue.

Can confirm.

This doens't work:
$visitor_addr = ip2long(Drupal::request()->getClientIp());

This does:
$visitor_addr = inet_pton(Drupal::request()->getClientIp());

See: https://stackoverflow.com/questions/2754340/inet-aton-and-inet-ntoa-in-php

I'm going to post this as it might help someone who stumbles over this issue (as I did). This is using Drupal 10.2.6 with Bootstrap5 subtheme.

When placing a menu block in a region (pretty normal thing to do) I get the following suggestions, prioritized first to last (as suggestions are array_reversed)

1. menu__region-name
2. menu__menu-name_region-name
3. menu__menu-name

This is counterintuitive because (in my mind at least) theme suggestions should be ordered from most specific to least specific i.e.

1. menu__menu-name_region-name (that menu when it appears in that region)
2. menu__menu-name (all instances of that menu)
3. menu__region-name (all menus in that region)

Can someone perhaps confirm if this is happening on other installs of Drupal? Or is it just me :D

Hey, I stumbled across this as I was wondering the same thing. Turns out this checkbox is on the order item type (as opposed to the product or product variation)

1. Go to /admin/commerce/config/order-item-types
2. On the order item type click the arrow next to edit and select Manage form display
3. At the top, next to Default, click Add to cart
4. Next to Purchased entity select Product variation title
5. Click the cog wheel to display the widget settings
6. Check the Hide if there's only one product variation checkbox

There is more information about configuring the add to cart form here: https://docs.drupalcommerce.org/commerce2/developer-guide/products/displ...

Thanks Andrew. I appreciate that. I'm a little confused as to why user chetan11 didn't review my patch and instead committed their own code to the issue fork and marked the issue "needs review". But then I haven't been active in the community for wee while so maybe things have changed.

I got this working by installing the dev branch and patching https://www.drupal.org/project/menu_token/issues/3404802 🐛 TypeError: unserialize() upon install (Drupal 10, PHP 8.1) Needs review

You can do this by:
1. composer require 'drupal/menu_token:9.1.x-dev@dev'
2. composer require 'cweagans/composer-patches'
3. add the following or similar to composer.json

"patches": {
  "drupal/menu_token": {
    "TypeError: unserialize() upon install": "https://www.drupal.org/files/issues/2023-11-29/3404802-typeerror-unserialize-9.1.x.patch"
  }
}

If you are already using menu token I would suggest removing existing menu_token menu items and uninstalling as the schema has changed and there is no update hook.

djroshi → created an issue.

djroshi → created an issue.

OK so I've been looking into this as I need this for a client upgrade from D7.

First things first: this issue is tagged against 9.1.0-alpha1 (released 2 December 2021). I mention this because the dev branch (9.1.x-dev, last updated 21 Feb 2023) is WAY ahead of the alpha version, and already reports D10 compatibility.

I'm fairly new to the party so I can't tell why an alpha2 release hasn't eventuated in the last 2 years, but just comparing alpha1 with what's currently on the dev branch...

There was a complete rewrite of the storage mechanism as a result of ( https://www.drupal.org/project/menu_token/issues/3162925 → ) which completely removes the ConfigEntity (LinkConfigurationStorage) and now stores menu_token config directly on the \Drupal\menu_link_content\Entity\MenuLinkContent entity. I mention this because there doesn't appear to be a hook_update_N() which converts from the old storage to the new storage (and therefore no upgrade path for existing users).

As I see it, the way forward will be to fix any major bugs on the dev branch, provide an update hook, and tag an alpha2 release.