I have an issue with the sorting the orders pages:
The plugin prevents this by throwing an exception with the page.changeNum:before hook. The only reason I can think of why this is being done, is that the invoiceNumber, by default, is generated by the page sort number. But, if one replaces this function with a custom invoiceNumber function, then there is no need for prohibiting sorting of the orders. I tried overwriting the hook via the config: 'page.changeNum:before' => function ($page, $num) {}
But this didn’t work. Deleting the hook inside the plugin works though.
My guess is that the hook inside the plugin has a higher priority? How do I overwrite this hook without altering the plugin?
The reason why this would be helpful is, that changing the status of an order (listed/unlistet/draft), thus triggering a resort of all order pages, would then be possible. Currently this is not ‘allowed’. And consecutive invoice numbers would be handled by a custom function.
Hey @leuys,
thanks for your comment. You are right on all points. Unfortunately, there is currently no way for you to change the behavior without changing the Merx code. For reference: here is the code of the page hooks: merx/index.php at 1.4.1 · wagnerwagner/merx · GitHub
We had a similar discussion on Github. It’s good to know other use cases. I could add an option (e.g. orderPages.allow.changes: true/false) that toggles the default behavior.
Hi @tobiasfabian,
thank you for your, as always, quick reply!
Such an addition would certainly help. But it currently doesn’t have a high priority, at least on my end, and I will workaround by commenting out the code parts inside the plugin for now.
I’m back again with a new question:
We are currently setting up our page for multi language. English has no language code in the URL (www.example.com/), all others languages do (like www.example.com/de)
Everything works, except when completing the checkout in another language (not English). Interestingly, the checkout process is successful and the user is forwarded to the order page, also in the correct corresponding language, but all the data is missing. (Bad) When completing the processs in English the checkout works and all data gets written to the order page. (Good)
My current workaround is to redirect non-english buyers via the base URL route. But I would like to know at what point the data gets lost when using language specific URLs. Because then the user would then be forwarded to the correspond order page in the correct language.
Has anybody some leads for me at where I should start looking for made errors?
Ok, so here is my solution:
The checkout form is sent via the non-language-specific base url.
A hidden language code is set in the checkout form, depending on the current language. This code is then used to determine the forwarding URL in my success controller. And the code is also used for sending translated emails.
This is the easiest solution that comes to my mind right now.
On order completion, can I redirect to the success page of the user’s chosen language? I already have a language property in the $data passed to $redirect = merx()->initializePayment($data);
I want to add Gift Cards to a store, perhaps @tobiasfabian or someone else can help or comment. Here is how I am planning to do it.
A gift card is a regular product, but when a customer buys one:
We detect it in the ww.merx.completePayment:after hook.
Create a unique code
Send this code by email to the customer.
Store unique code, gift card ammount and an on/off status (in the order ?)
In the payment process we add a “redeem gift card” field. If a code is entered:
We check the code against the stored codes.
if there is a match
If the total price of the order is equal or less than the gift card ammount, we deduct the total price of the order from the gift card ammount and keep it ON
The order total price becomes zero (what does MERX do here? How to proceed)
If the total price of the order is more than the gift card ammount, we deduct the gift card ammount from the total price of the order (How can this be done?), switch the gift card to OFF
I would prefer not having to create separate discount products with negative prices, though. So:
I could use the relevant gift card product (which does exist), invert its price on the fly so it is negative (20 → -20) and add it to the cart. This way I can keep all the gift card product data, image etc…
I could also create a virtual page on the fly with the appropiate negative ammount and add it to cart (could that be done in this manner?)
How does that sound? any gotchas from the top of your head I should be aware of ?
@tobiasfabian the approach I describe above seems to work well. The store sells gift cards as products, and when a gift card is redeemed, it is added using that product but with price inverted on the fly.
The main problem I am having is dealing with zero sum orders.
As a gift card may be of higher value than an order, order sum can become zero and paypal rejects those.
Is it possible for Merx to complete an order skipping the payment gateway ?
First of all, I think this is a great plugin! I already played around with it and found it quite easy to set up. So thank you @tobiasfabian !
At the moment, I am thinking about what shop system to use for my next client. They use Wordpress and WooCommerce right now and one big pro of that is the handling of refunds. That means, that from within WooCommerce, they can issue refunds vie PayPal or Stripe and an email gets sent out to the customer.
Of course, this is not a built in functionality in Merx, but does anyone know how complicated it would be to implement by custom code? I am familiar with coding so I would probably do that mayself.
Hi @sigi,
You could add the Janitor Plug-in
And than you have to integrate the PayPal REST API and call this through the janitor button.
But this is only an idea for a possible way.
Hey @sigi,
thanks for you comment and your question.
Handling refunds via the Kirby Panel would be possible. As @JanStieler said you have to communicate with the PayPal REST API and/or with the Stripe API which is, in my opinion, a lot of work – especially working with PayPal API is not fun.
And you have to think of many other aspects, like partial refunds, sending mails automatically, make sure everything works 100%.
For the shops we created we tell our clients how to make refunds via the PayPal/Stripe interface (the shop admin needs to login to Stripe/PayPal). On the Merx site a negative refund “cart item“ could be added to the existing order or the shop admin could create a negative order by hand for the refund.