I published the MR with the proof of concept. Below is a screenshot from UI with the exposed checker from ✨ Add an availability checker which checks if the entity is accessible or not Needs work .
This is a valid addition. However, with 3.x already released, we missed the opportunity to introduce it in a new major version—especially since it might not be backward compatible. That said, this is actually a good thing. We should ideally avoid introducing backward-incompatible changes even between major versions, when possible.
I believe this new checker can still be added, as long as it only affects new sites and existing sites retain their current behavior.
To make it easier for our core audience—ambitious site builders—to enable or disable availability rules and checkers as needed, I’ve proposed ✨ Expose Availability Checkers in the Admin UI Active .
zaporylie → created an issue. See original summary → .
- We not only use the availability manager in the context of the order processor but also in the context of validation constraints. That's what prevents non-available items from being added to the cart.
- We can replicate the context in the cart links module and use it to validate the order item, in fact if we call
validateon the order item, that would trigger the same code/behavior as the add to cart form.
I added MR with a proposal.
zaporylie → created an issue.
zaporylie → created an issue.
Chiming in as this is a blocker for my contrib module that aims to inject an additional link to be shown next to the installed module. Currently, the list of potential links is fixed to only 3 options - help, permissions, and configuration. IMHO, the module interface should make it possible to inject any link. Dropping support for icons could and moving onward to dropdown, operation-style links could make that much easier.
I am not sure if skipping default content support for modules was intentional, so I created this issue to also serve as documentation in case the issue status is changed to "won't fix".
zaporylie → created an issue.
MR needs to be rebased.
I don't feel comfortable about this behavior in the context of a promotion form, otherwise all should be good.
As part of my MR I only added support to selected entities:
- order
- product
- product_variation
- promotion
- coupon
- store
Some notes:
- Not all content entities support sidebars (ie. coupon), which makes the form look a bit weird (very subjective opinion)
- For config entities we are better off without gin content form support as these forms are rather simple, featuring only handful of fields
- Some content entities are not to be edited in the context of admin UI (ie. payment_method) hence no need to support it either
I removed support for D10; otherwise, LGTM. Tested and works precisely like Centarro Claro. I also checked that the theme is not installed nor available after the site is installed which is expected. Thanks
I appreciate the feedback in #10 and #11. Routing recipe application d.org update requests to the queue, with the update module acting as the queue consumer, sounds like a clean approach that respects global tracking settings.
I’m curious about one more thing — the issue summary mentioned the name as one of the properties featured in the request. I’d like to clarify two points:
- The recipe directory name—which is essentially what the recipe name comes down to—has only a loose connection with the project on d.org. I believe we should only send an application update if the recipe includes a composer.json file, so we can verify that it belongs to the drupal/ namespace as outlined in one of the conditions in the issue summary. This would filter out all custom recipes added at the project level (i.e., not available on d.org even if the recipe name matches a general project on d.org), as well as recipes under other vendor namespaces.
- This also means that all core recipes would never be tracked. Are we okay with that, or should we support core recipes too? If so, we’d need to collect version information from the drupal/core package.
The site name is set by the installer based on the provided input. I just tested it with and without the demo content, and my site was named with the name I provided.
I wonder about a scenario in which a recipe is applied multiple times because it might be a dependency for many other recipes. That would be a common case for starter/base recipes. Said recipes can be deduplicated, which is an approach the recipe installer kit is promoting, or simply applied multiple times. The main issue I see here is inconsistency, which results in slightly off telemetry data.
Re #5: while I agree that the proposed approach is clean, I wonder how this could be respected if the recipe is applied via installer (no option to opt-in/out) or the site is installed from the recipe (drush si ../recipes/drupal_cms_starter).
Re #7: Recipe Tracker (thanks for mentioning it here) is meant to track the application of recipes locally, within your Drupal instance, and never sends any data outside the Drupal instance context.
Thanks for the catch, and if you are interested in contributing, feel free to propose a patch/MR. Once again, thanks!
I discovered that most of the duplications I am seeing are coming from strict comparison when batch tasks are containing instances of Recipe object representing the same Recipe.
All blockers were addressed. Therefore, closing as fixed.
zaporylie → created an issue.
All issues were addressed. I will be tagging the stable release soon.
I tested this MR and happy to report that the horizontal scroll is now gone and no incorrect overlaying could be spotted anywhere. LGTM
zaporylie → created an issue.
That works, the validation is happy, I am happy. Thanks :)
I set it up locally and the MR seems to do the job. Local tasks stick to the right and are visible most of the time. Only when off canvas sidebar is opened do they get hidden but at least they are not in the way which is a major improvement. Thanks!
zaporylie → created an issue.
zaporylie → created an issue.
https://www.drupal.org/project/commerce_recipe_core → is now in place.
Fixed via 🌱 Consider using Recipe Installer Kit Active
zaporylie → created an issue.
This was fixed as part of 📌 Convert commerce_kickstart profile installation to recipe Active . We may want to expose the currency selector in the installer down the road but for now we decided not go this way for the initial release.
This will likely be fixed as part of 🌱 Consider using Recipe Installer Kit Active . Postponing for now.
zaporylie → created an issue.
I removed Commerce Product Tax from the recipe in https://git.drupalcode.org/project/commerce_kickstart_demo/-/commit/bdea...
Given Commerce Kickstart 5 will be based on Recipes we decided it makes sense to proceed with Recipe Installer Kit
MR for changes in Commerce Kickstart Base are in https://git.drupalcode.org/project/commerce_kickstart_base/-/merge_reque...
The recipe itself can be found in https://github.com/zaporylie/commerce_recipe_admin_ui
While I put the recipe in commerce_recipe namespace I don't believe now this is a good choice. This would not be a general commerce recipe but part of kickstart ecosystem hence it should belong to the commerce_kickstart namespace.
zaporylie → created an issue.
New Config Action was introduced in ✨ Define grantExistingPermissions config action Active and utilized in this recipe.
zaporylie → created an issue.
This still happens even if the theme is enabled via Recipe. Applying drupal/drupal_cms_admin_ui recipe on the existing site with customized block placement makes these blocks also appear in the Gin admin theme.
This has almost no impact on the current sites and change is minimal therefore, in order to avoid applying patches, lets merge it in.
zaporylie → created an issue.
zaporylie → created an issue.
zaporylie → created an issue.
The recipe can temporarily be found in https://github.com/zaporylie/commerce_recipe_core/ but will be pushed to drupal.org once the respective project is created.
The recipe is temporarily available in https://github.com/zaporylie/commerce_kickstart_base but will be pushed to drupal.org once the respective project is created.
zaporylie → created an issue.
zaporylie → created an issue.
zaporylie → created an issue.
The scope here is slightly bigger than what's described in the issue title and summary, as suggested in #9. In short, commerce condition plugins are not correctly handled due to form decoration at the eca deriver level. I am bumping the severity to Major as reusing commerce Condition Plugins is one of the biggest potential value of using ECA with Commerce.
Backstory: I am working on recipes and want to react to the add-to-cart event (that part works fine) but only if a certain condition is met - order type is X (doesn't work). The issue is that bundles are stored as an array, but the eca_commerce_commerce plugin expects them to be string
zaporylie → created an issue.