Do not use an illegal message type

Maybe it could work if it was fixed in Drupal Core https://www.drupal.org/project/drupal/issues/3100473 →

Created MR with solution to separate the add to cart confirmation message from other messages before render.

Maybe another approach we could use - save message in private storage and render it in custom block?

Private storage is a good idea, but I wouldn't save the whole HTML there, I'd simply save the data that I need to render the message, so just the order item ID?
Then whenever the private storage is accessed, you can just load the order item, and render the theme function?
But yeah, using the messenger is kind of hackish (that is how it was done in D7 as well as far as I remember).

I've created another on MR with the solution to use the private store https://git.drupalcode.org/project/commerce_add_to_cart_confirmation/-/m...

hm... Helper is a weird name, maybe too generic... And why would you need to have a method to delete the order item ID?
Also, surprised it isn't the case already, but we night need to store the quantity that was added as well in case somebody decides to not use Views for the cart confirmation.
Also the MR has code commented out.
We can maybe keep the code simple, just store directly into the private temp store...Once you introduce an interface then you have to maintain it and you can no longer break BC so you have to think carefully :p.

@jsacksick, I used delete method to delete stored ID and do not show the same message multiple times.
Could you, please, explain this:
We can maybe keep the code simple, just store directly into the private temp store

We shouldn't use additional service and just store value in the event subscriber, right?

Introducing a new service is not bad idea in general, the problem is that with the current methods defined, there's no room for additional arguments in the future.
Let's say you'd like to store the quantity that was added, or even the order ID, then your methods are suddenly obsolete.
Maybe you can go with:

CartConfirmationManager as the service name?
Then define the following methods:

• recordAddToCart(), from here you can accept an array (quantity, order_item_id)...
• getCartItemInfo()
• clear()

@jsacksick thanks for your help! I've improved code. Please, review.

Reviewed, what was the problem with page attachments again?

@jsacksick regarding page attachments alter. When I tested there were caching problem. So there were no dialog until clearing a site cache. I can re-test

hm... You might miss cache context / tags then perhaps...

re-tested. when using code inside commerce_add_to_cart_confirmation_page_attachments() it doesn't work - need to clear cache to see the dialog.

I can confirm we're running into the same issue in Radix currently. Console says:

The message type, commerce-add-to-cart-confirmation, is not present in Drupal.Message.getMessageTypeLabels()

We'll take a look at this issue now.

Grevil → changed the visibility of the branch 3387351-do-not-use-illegal-message-type to hidden.

@khiminrm I can't seem to get the patch from MR !15 to work for me locally.

My theory is, that once the js is called at the end of commerce_add_to_cart_confirmation_page_attachments, simultaneously the page reload of the add to cart submit gets triggered, killing the modal appearing.
The old implementation worked for me (except for the bug this issue is originally about). Do you use any third party modules, that prevents the page reload?

Ok, I fixed it through attaching the library right away in "commerce_add_to_cart_confirmation_page_attachments". If the drupalSettings doesn't hold the message from the private temp store, the javascript will return early. If the message is present (after adding a product to the cart), the dialog appears.

I also removed the jquery dependency and other unused dependencies and cleaned the js from jquery (apart from drupal.dialog, which internally still uses jquery).

Furthermore, I am not a big fan of displaying the title of the view twice, once through the template and once through the dialog title:

I would make a change to the template removing the title, but that would be a breaking change and has nothing to do here, so we keep it as is and keep the old title rendering logic.

And one last thing. When the dialog appears, we currently get the following error message in the console:

Uncaught TypeError: Cannot read properties of undefined (reading 'settings')
at HTMLDocument.resetSize (dialog.position.js?v=10.3.1:83:32)
at later (debounce.js?v=10.3.1:37:23)

But this has nothing to do with the changes, but is related to a core dialog resize bug, see 🐛 Error: Cannot read properties of undefined (reading 'settings')
 with dialog.position.js Needs work .

So I guess that's all. I had no caching issues, so I removed the cache statement. Please review!

Thanks for the fixes. Can we address the phpcs, stylelint and cspell issues too? At the very least the phpcs one which is an easy fix.

Great stuff!

Automatically closed - issue fixed for 2 weeks with no activity.