Thanks for the reply. I used the "support request" option as I wasn't confident whether it qualified as a bug, but I'd note that this workflow does work for commerce orders when shipping isn't enabled, so you make a prescription that commerce core does not (in my usage so far).
It's not desirable for the user to have cart-level access to the items of an order that's customised to the extent that it needs a bespoke form to generate it. To get this far I looked at other examples of people who were doing it the same way in their builds.
Based on your feedback I will look instead at ways of ensuring the cart gets re-emptied whenever the user makes a page request outside of the checkout flow, which is fairly scorched-earth compared to what I was hoping for.
headbank → created an issue.
headbank → created an issue.
headbank → created an issue.
Just to be clear, do you still expect the migrations to be those generated by migrate_upgrade, or do you look to broaden the scope?
If you restrict to migrate_upgrade's migrations, then I would suggest that the naming not be entirely freeform, as a way of soft-enforcing this (it would be sensible to make that point clear in README.md as well). The drush command allows to specify a prefix ("upgrade_" is the default) so that could be the same setting you offer, while requiring the rest of the ID to match.
As a matter of fact, the issue you've just added is the same I was thinking about raising just yesterday! I'll comment there.
I'm not schooled in contributing (beyond commenting) on issues here but I'll do my best as I've found your tutorial series (through which I discovered this module) very helpful.
Although migrate_upgrade is not a runtime dependency, you do depend on specific migration configs generated by it, so documentation should make this clear.
LOL, and what would be the response time on the new one?
No worries chief, I already took the hint about 9 years and 6 months ago. All the best ;)
Hi @Shreya_th,
The fix is perfect. Thanks!
headbank → created an issue.