Thank you for your contribution. Right place in code spotted. Good work 💪🏻
Thank you for the reviewers as well. 🙏🏻
This bug has been introduced and been fixed both in ✨ Allow order to be created programmatically Active .
How will this actually land in the actual plugin? https://github.com/drupal/core-recipe-unpack
Shouldn't the MR here only contain test coverage? And then there be another MR directly to https://github.com/drupal/core-recipe-unpack?
How does this work?
Interesting discussion at drupal.slack.com and there's a very good suggestion:
1. Unpack recipes via composer drupal:recipe-unpack
2. Now run composer patches-relock and from the diff of removed patches you will now which patches to include in root composer.json before running composer patches-relock again
Adding a static patch here that can be used directly with the drupal/core-recipe-unpack dependency in the root composer.json to avoid error:
No available patcher was able to apply patch https://git.drupalcode.org/pro
ject/drupal/-/merge_requests/13442.diff to drupal/core-recipe-unpack
"patches": {
"drupal/core-recipe-unpack": {
"[https://drupal.org/i/3525727] - Recipe Composer plugin: support wikimedia/composer-merge-plugin": "https://www.drupal.org/files/issues/2025-10-27/3525727-18.patch"
},
By providing an extra option which by default is off and an extra page for this, we'll be fully backwards compatible. It'll just be a new optional feature and it will not disrupt existing setups.
Ah okay, so you also want the same as @vvs yeah? When you click on cart count block or any other /cart link you want to be able to immediately check out.
Maybe we should just have an option: "Provide fast checkout"
And when this option is set when you click on the basic cart count block you come to a page maybe /fast-checkout instead of /cart and on that /fast-checkout page there's the cart form (but with remove and update functionality) and the checkout form both and finally a button to "Place order"..
I think I'm starting to get it, but I think it's two separate issues.
I updated the description. @vvs, does this make sense to you? @vvs, did you mean it like that?
@scrat000 what you describe should actually already work OOTB by placing the cart block (the one without content) via block layout in the content region and limit visibility to just /checkout. Unfortunately this just displays the linked products but lacks options to remove and/or update quantity. I'll create a separate issue for fixing this and link it here.
Thank you @bernardopaulino!
I think it's really important that all config strings from Basic Cart are translatable. Your contribution is much appreciated!
I additionally provided a *.config_translation.yml and fixed the *.links.task.yml so now there's also that "Translate" tab on the settings pages.
Thank you everybody!
I think it's really important that all config strings from Basic Cart are translatable. You contribution is much appreciated!
I additionally provided a *.config_translation.yml and fixed the *.links.task.yml so now there's also that "Translate" tab on the settings pages.
The release will now contain:
- New Drush command
drush baca-ento enable add to cart for all nodes of all enrolled node types - New action plugin to be used on the admin content view to bulk-enable add to cart for selected nodes
But yeah, in a future major version this checkbox on the product node form should be "Disable add to cart" and all nodes of a type should simply be included to the cart functionality by default..
It will only do something for the nodes whose bundle was previously enabled for Basic Cart.
Problem was the form alterations unsetting certain form elements in the basic_cart_order node form made no differentiation if you were in the checkout form or the regular admin node form. Added a check to look if the form gets rendered on the checkout route and only then hide certain fields. Now the admin route is fully editable again.
This bug was introduced in ✨ Allow order to be created programmatically Active . I reverted it and added a different fix for it. Now the order items get added again.
Still huge thanks for taking the time to chime in and provide code and time. Credits incoming 💪🏻
Okay, !empty(Utility::getCartData()) never is empty, but $cart_data['empty']['status'] === FALSE is true when there's really stuff in the cart, so let's check on this instead.
This issue resulted in all of the logic inside basic_cart_entity_presave being skipped for everybody, see
🐛
Neither cart content, price or vat are stored in the newly 'order' node
Active
.
In the long run this needs to get refactored and all that logic removed from the presave hook.
But for now we could at least add a condition in the presave hook to check if !empty(Utility::getCartData()), because when placing the order, the cart gets only emptied a few milliseconds later in basic_cart_entity_insert. That way, the only thing you need to make sure when creating nodes programmatically is, that the user pressing the button to start the batch has their cart empty via an initial call to the $utility::emptyCart(); method in the beginning.
This sounds good 👍🏻
But.. how? Do you have any certain idea in mind you can outline here to get this going. So maybe we can get in the next major version 🤩
Hey, thanks for taking the time to write your ideas down and file them here.
But.. I must admit, that this is out of scope for a basic cart module.
But since Basic Cart is all about nodes being products, you probably can achieve what you are outlining here with just regular roles and permissions, maybe some workflows or moderation added on top. But not with Basic Cart, sorry.
Hey hey, thank you for your contribution. Credits rewarded. 💪🏻
Though I don't really understand why we should ignore the user's preferred language when sending Basic Cart mails. Isn't this what the preferred language field of a user is for: To have them decide in which language they want to receive their mails?
Thank you for taking the time to create this issue.
Please add more context to the issue description, so we can define actual tasks from it.
Thank you 🙏🏻
New maintainer here. Sorry, but I don't understand what this issue is about at all. 🤔
Can you please help me get the context and then set it back to active again. Thank you 🙏🏻
Hey, this sounds interesting.
Can you please just give a few examples so I fully understand where we're heading at? 🙏🏻
Then set the issue back to active again.
Friends, thanks for chiming in. I'm trying to understand this issue, so I've put a fixable task as issue title and put a description.
Question to all of you now: Does this sound correct with what I've put there?
If yes: Please set this issue back to active again.
If no: Please refine the issue and assign it to me.
This just got fixed. Gonna tag later.
Thank you! Credits going out 💪🏻
Okay, so https://www.drupal.org/project/entity_reference_quantity → now is compatible.
Huge thanks to everybody getting involved, getting it documented and providing workarounds.
Credits and out 🫡
I do absolutely agree. New maintainer here. Currently working the issues. Will come back later. ♻️
Ah damn, we need at least a little bit more context. But maybe I'll run into the same problem during clean-up, then I'll be back. 💪🏻
Oh this is big, we need this for sure 🤩
Hello, new maintainer here.
I'm currently working the issues, but if anybody here can help me get this into an MR to 8.x-8.x, will give this a major boost and has huge thanks and big credits deserved for sure.
I removed the dependency to easy_install, so composer require 'drupal/basic_cart:8.x-dev@dev' at least works now.
Gonna tag later.
Gonna review on the other stuff later.
But if anybody's able to help me out creating reproducible, separate issues for them, has some credits in their inbox secured. 💪🏻
Okay, so composer require 'drupal/basic_cart:8.x-dev@dev' at least works now. Gonna release later.
Thank you everybody for chiming in, credits going out 🚀
Thank you everyone for taking the time to report and discuss this issue. 🙇🏻♂️
As the Drupal 7 versions of this module are no longer supported, I’ll be closing this issue. 🔚
Huge thanks and credit to everyone who contributed in any way. ✨
Thank you everyone for taking the time to report and discuss this issue. 🙇🏻♂️
As the Drupal 7 versions of this module are no longer supported, I’ll be closing this issue. 🔚
Huge thanks and credit to everyone who contributed in any way. ✨
Thank you everyone for taking the time to report and discuss this issue. 🙇🏻♂️
As the Drupal 7 versions of this module are no longer supported, I’ll be closing this issue. 🔚
Huge thanks and credit to everyone who contributed in any way. ✨