Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order pages with identical page num created #63

Open
christinegotth opened this issue Dec 13, 2022 · 3 comments
Open

Order pages with identical page num created #63

christinegotth opened this issue Dec 13, 2022 · 3 comments

Comments

@christinegotth
Copy link

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.

@namlit4
Copy link

namlit4 commented Dec 13, 2022

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?

@tobiasfabian
Copy link
Member

tobiasfabian commented Dec 14, 2022

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.
Screenshot of Kirby Panel showing a Cancel Order toggle field

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.

@namlit4
Copy link

namlit4 commented Dec 20, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants