Deleting a Store can make its Orders unloadable, undeletable, and crash the site

One problem with disallowing store deletion is that we'll get support requests / bug reports from people that do not understand why they can't properly uninstall Commerce, or delete a store they don't need, because of test orders.

Perhaps we need code in the order refresh that just reset the store to the default store in case the referenced store no longer exist to prevent a crash? That could be a good first step I guess?

> Perhaps we need code in the order refresh that just reset the store to the default store in case the referenced store no longer exist to prevent a crash? That could be a good first step I guess?

Hmm. Deleting a store assigns its orders to a completely different store? In GDPR age this may get someone handcuffed ;-/.

OK then a store delete must delete its orders.
Looked a bit around. If we want to delete its orders on store deletion, we need a batch.
Fortunately \Drupal\system\Form\PrepareModulesEntityUninstallForm does all that, we just need to override the redirect.

I don't think we should automatically delete orders on store deletion. A better approach might be similar to Content Type deletion:

Store name is used by 1,579 orders. You may not remove Store name until you have removed all of the Store name content.

And then perhaps set up your Orders view so that you can select by Store and use a "Delete orders" bulk action. I think most sites in production would want to strictly block any order bulk-deletion functionality. Deleting draft orders is generally fine but unless you're exporting all your orders to an external management system, deleting Completed orders (with payments!) could be very bad.

#5: Yes, this also makes sense.

In this case we inspire from \Drupal\node\Form\NodeTypeDeleteConfirm and friends.
10 lines, easy to adapt.
Create \Drupal\commerce_store\Form\StoreDeleteForm as subclass of \Drupal\Core\Entity\EntityDeleteForm
Copy adapted code from \Drupal\node\Form\NodeTypeDeleteConfirm
Adjust handlers.form.delete in \Drupal\commerce_store\Entity\Store

If maintainer signs this off, we can tag this novice.

I completely agree with #5, you almost neve really want to delete orders... (unless these are test orders, or exported to a 3rd party system).

I approve copying the node approach. but yeah it should I guess be more than just displaying a message, we should forbid the deletion of the store too.

Yes, forbidding deletion with message indicating reason sounds good.

May also want to look at implications for references from products, promotions, shipping methods (commerce shipping module, but also references more general.) Make sure that references to missing store entities don't break anything else.

> I approve copying the node approach. but yeah it should I guess be more than just displaying a message, we should forbid the deletion of the store too.

Yes this is that the form then does, by not calling parent::buildForm (so it does it on the form, not on the access level, which is good enough as a first step).

Tagging novice for the approach described in #6.

@geek-merlin: Sorry I meant forbidding the access at the API level as well, not at the form level only. Forbidding the deletion at the form level would be a nice first step I guess, at least this should solve 80% of the cases where an average user performs a store deletion without thinking it through.

Update IS with agreed solution.

I encountered this same error after deleting all old orders that were imported from an imported Drupal 7 Ubercart store. After I deleted the old orders, when visiting the Order page I encountered this same error message.

In PhpMyadmin I found the old orders where still there in the commerce_order table. Next I emptied (truncated) the commerce_order table and this solved the problem. I can view the Order page again and all old orders were deleted.

Crosslinking an older dup.

Untagging as of #10/#11

Note: I ran again into this on a dev site.

How to reproduce that even loading an order throws:
vendor/bin/drush ev 'foreach (\Drupal\commerce_order\Entity\Order::loadMultiple() as $order) print $order->id();'

As @jsacksick said in #2:
> Perhaps we need code in the order refresh that just reset the store to the default store in case the referenced store no longer exist to prevent a crash? That could be a good first step I guess?

Rolled a trivial MR that does this.

Patching my commerce with this (need to do a manual rebase), i can
- access the product and cart page
- run this cleanup script:

vendor/bin/drush ev 'foreach (\Drupal\commerce_order\Entity\Order::loadMultiple(
) as $order) { if ($order->getStore()) {print "Checked ";} else {$order->delete(); print "DELETED ";} print $order->id() . "\n"; }'

Merged your MR, thanks! Let's just do this for now...

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