@Joe Huggans: I came across the "Using empty file as ZipArchive is deprecated" issue, too. But I found a solution to prevent the deprecation notice, that I want to share:
$options = [
'filepath' => 'public://my-path-to-zip/my-zip-filename.zip',
'flags' => \ZipArchive::CREATE,
];
$zip = \Drupal::service('plugin.manager.archiver')->getInstance($options);
The relevant part is the 'flags' value is \ZipArchive::CREATE (and there is another possible option \ZipArchive::OVERWRITE), but \ZipArchive::CREATE seems to do both: create a non-exisiting file AND replace an existing file with a new (empty) ZIP archive (that can be filled with $zip->add(...); afterwards).
And I know that it is better to open new issues if an issue has been closed, but my solution fits perfectly to this issue and the other linked issues didn't help me. And maybe my solution is only for some PHP versions etc., but it works for me.
I tested the patch #10 for Drupal 9.5.9 and Commerce 8.x-2.31 and it works perfectly.
A promotion that has reached the maximum usage and gets deactivated after a cron run.
Don't forget to clear cache after patching the commerce_promotion sub-module.
+1 RTBC
Some should test the patch for Drupal 10 and latest Commerce version!
@tinto : Thank you for checking my bug report and I am glad to hear that there is no longer an issue for Drupal 11.
I tested it for Drupal 10.2 and can confirm that my reported bug is still present for Drupal 10.2.
Maybe you or someone else could re-test for Drupal 11.x-dev with exactly my paths and URL aliases from my bug report above.
(I didn't specified a language for my manually created URL aliases.)
I want to thank everybody who is still working on that issue that I reported more than 8 years ago (for Drupal 7). My initial bug report contained the solution to fix this bug. I also posted a solution to fix this bug for Drupal 8+ more than 4 years ago. I don't think that tests are useless, but this core bug could have been fixed years ago.
There aren't tests for all PHP lines in the core code. I'm not quite sure if the test for this issue is that essential and relevant. Other "if" statements in core code haven't a corresponding test coverage, too.
I would suggest to fix this bug in the near future and maybe add a follow-up issue for test coverage. But maybe all the hard-working helpers in this issue are near the finish line to get this solved inclusive test coverage...
I came across this issue and want to report how you can manually trigger an order refresh if you have an order type with shipping.
On the /admin/commerce/orders/ORDER_ID/shipments tab you can "edit" an existing shipment for your order.
You can active the checkboxes for all shipment items and then click the "Recalculate shipping" button.
Don't forget to click the "Save" button at the bottom.
Afterwards you should see the correct tax values in the order summary on /admin/commerce/orders/ORDER_ID tab.
This workaround-like solution should work for a shop administrator with proper permissions.
------
(For developers you can use devel_php or a custom module to execute the following code for the $order entity that should be refreshed:
$orderRefresh = \Drupal::service('commerce_order.order_refresh');
$orderRefresh->refresh($order);
But this solution isn't suitable for a typical shop administrator, so I want to share my shipping refresh solution above.)