Open christinegotth opened 1 year ago
after further inspection with @christinegotth we found out that the error was probably caused by manually deleting test-orders from the system. when kirbys internal "fix page order numbers"-algorythm kicked in on subsequent orders, the exception of the merx-plugin was thrown, inhibiting confirmation-mail-sending and stock-count-updating. it might be a good idea to decouple the order number from kirbys internal page-ordering mechanism? maybe the newly introduced "UUIDs" can be of help here?
Thank you both for your comments.
As far as I know (* legal disclaimer), German law requires sequential order numbers. To meet this requirement, the sort numbers of the Kirby pages are used as order numbers. Also, deleting order pages, changing the sort number and changing the status via the Panel is not possible because the order pages contain critical "financial" information.
I understand the problem with test orders, but I think I won't give up the benefits described above and allow deleting pages or changing the sort number via the panel. But I am open to discuss this issue.
To deal with test orders, I would recommend two things.
If you have a separate test domain, you can use a separate test-oders directory for your test orders.
// site/config/config.test.example.com.php
return [
'ww.merx.production' => false,
'ww.merx.ordersPage' => 'test-orders',
];
while
// site/config/config.example.com.php
return [
'ww.merx.production' => true,
'ww.merx.ordersPage' => 'orders',
];
https://merx.wagnerwagner.de/docs/options#orderspage https://getkirby.com/docs/guide/configuration#multi-environment-setup
If you need to test orders in the live system, you can add a special marker field to the order blueprint. We did this to mark cancelled invoices – which should be basically the same as a test order.
One more note: As long as the test order is the very last order, you can safely remove the order via FTP. If you remove an order from the middle, you will most likely get an exception on the front end.
thank you for your reply. we can live with the current implementation if we know what we have to avoid. however it feels cumbersome to me to rely on kirby's sorting-functionality to generate sequential order numbers. maybe these two requirements should not be linked. also decoupling would allow for more flexibility (cancelling, archiving etc.) because for me "sequential order numbers" do not necessarily require all orders to be in the same list/folder. but i am a first-time-user – maybe i am overseeing things here.
For some reason we had two order pages with identical page numbers on our production server. This caused the changeNum hook to throw an exception, which caused heaps of chaos.
The order pages that caused the problem were named like this: 16_asfalsdkhfsgfk 16_fghksjfgslgfjsd 18_gslkgdjhalghf
One of the identical orders hat payment type prepayment, one paypal. I was wondering if this was a timing issue? Or if there is another reason why two orders could have been created with the same $page->num() when num should be incremental.