kongondo

Just a note, in case you haven't seen them, there are 5 demos currently ?. The READMEs explain it all. Thanks.

You cannot use $config (or other variables such as $page, $pages, etc) inside a function. They are out of scope. Use wire('config') instead.

Hi @kalimati, Apologies for the late response. I wasn't able to use the excellent idea by @flydev ??, i.e. HX-Redirect. It wouldn't work for me. Nothing happened at all. However, we can use htmx:afterSettle and redirect using vanilla JavaScript. I have created a demo for the whole thing here in Demo-4 in the demos repo. See the README for more details. Please let me know if you have any questions. Next I'll work on a demo with respect to your question about a minimal checkout form.

Thanks Ryan. The language bit was a weird one. After more tests, it seemed to be related to the use of ProcessDatabaseBackups. I couldn't replicate the issue a third time so didn't debug further. Will keep an eye out, thanks.

Same here. In fact, the upgrade changed my multilingual site's default language to German ?. Edit: It also converted a non multilingual site to multilingual and made German the default.

Forum for now. Would have wanted GitHub (or similar) but the issue is that this is not an open source project. No easy way to report bugs that I can think of given the situation. Good catch. Silly oversight on my part then. This will also affect products with variants and attributes. I'll fix today and re-issue as 005.

Hey @Spinbox, This is now fixed in the current (005) release. Thanks for reporting.

Hi @Spinbox, I have been way, hence the delay. Great catch! I'll fix this ASAP and report here. Thanks.

OK. I'll have a think anyway. Thanks.

Hi @Spinbox, Currently, it is not possible. Could you please explain the specific use case? E.g., Why do you need to change the order? Is it something you'd like the editor to be able to do? Will you have one criteria for the change? I am asking to see if you could at least do this using a hook.

Hi @Spinbox, Apologies for that and thanks for reporting. Fixed (but retained version 004). Please download again and try. Thanks.

Hi @Sonia Margollé, I have now released version 004. It updates the fieldtype order schema to include details of selected shipping rate name and delivery times. This is also now displayed in the GUI when viewing a single order as per the screenshot below: Please grab the latest version and test. Please let me know if you have any questions. Thanks.

Hi @Jan Fromm, The Hooks are now ready per the latest release today (004). A demo implementation is here (demo 3) in the demo repo. The hooks are (per demo linked to above): PadloperProcessOrder::checkCustomOrderCustomerFormForErrors This will allow you to reject business customer form and return it to them for amendment, .e.g., in case they stated they are a business customer but did not fill in the VAT number or VAT number is invalid. It is better to hook here instead of PadloperProcessOrder::processCustomOrderCustomerForm as it gives you early access to the form. Please have a look at the demo and let me know if you have any questions. and PadloperUtilities::isChargeEUDigitalGoodsTax Please see the demo for an example. This will allow you to apply/exempt EU digital tax per line item in the order based on complex conditions as you state above. Note that this demo is not a robust solution compared to the VAT library you have linked to. For instance, the demo doesn't check for country-specific prefixes in the VAT number. Please let me know if you have any questions. Grab version 004 using your purchase link, per usual. Thanks.

Thanks @Jan Fromm. Started working on this. Will let you know.

Yes. Good ideas, thanks. This is not future proof. Similar to things like products and products titles, rates can get deleted, renamed, etc. Hence, for orders we want to 'freeze' the state of things when the order was made.

@Jan Fromm. Just to add to my question, do you want to tell the customer if the validation fails?

@Jan Fromm, Sorry this slipped through the cracks! That would work..., yes. This could work. How do you intend to do the validation? I am asking to see where best to hook. Yes, good idea.

This is a great catch @Sonia Margollé! Currently we don't save this anywhere which is a design flaw on my part. I'll have a think but it looks like I'll have to add a field in the order table. I'll get back to you tomorrow, or latest Friday. Thanks.

Please note that I have augmented this method to take two more arguments, $orderLineItemsPages and $orderLineItems. You could always get these two from the first argument, $orderPage, but this change makes your work easier.

Hi @Sonia Margollé, Please have a look at this (demo-2) starter site/demo for an example of hooking into checkout and other order processing in order to collect, process, save and display product customisation details from customers. It also shows how to hook into and amend product weight during checkout (per your question here). If the READMEs are not clear, please let me know. Please use your download link to get the latest Padloper 003 files with some new/improved hookable methods. Thanks.

Hi @Sonia Margollé, Please have a look at this (demo-2) starter site/demo for an example of hooking into product weight calculation as well as collecting, processing, saving and displaying product customisation details from customers (per your other question here). If the READMEs are not clear, please let me know. Please use your download link to get the latest Padloper 003 files with some new/improved hookable methods. Thanks.

Demo & Starter Sites This thread is for me discussing Padloper 2 demo and starter sites. Thanks. Padloper starter sites can be found in this GitHub repo. Each demo branch is a standalone site demo/starter. Please see their individual READMEs for more information about a demo. This is WIP.

I had a feeling that this might happen after I posted my suggestion. This is indeed a better plan. Glad you got it sorted.

That's a good plan. Please let me know if you encounter issues. I'll look into where best to have a hook for order weight and let you know once I've implemented it.

This is much clearer now. So, you need to collect this information from the customer in the frontend when they make their purchase. I have some ideas which I talk about below. I see three parts to this challenge: Collecting extra information from the customer in the frontend. Processing the customer information in #1 so that it is in sync with the cart and the order. Storing and accessing the customer information from #2 when order is finalised. Product versus Order versus Order Line Items Given that what a customer may want to be customised is unique for that purchase, I don't think customising it at the product level is a good idea. The product needs to remain generic, e.g. a 'blank t-shirt'. Similarly, customising it at the order-level also doesn't make sense since an order is a collection of one or more products (line items) that have been purchased. Hence, customising at the order-level is too broad. I think the best place to customise the purchased product is at the Order Line Item level. An order line item is just a product that has been purchased. However, doesn't change post-purchase. I'll get back to this when we get to #2 above. #1 Collecting Extra Information from Customer This is the easy bit. You would have to use custom form for your checkout. At this stage, you will have access to the order items and you have several ways of gathering the details from the customer. You can loop through each item in the cart to find out which ones offer customisation and display extra inputs/text fields for each of them. #2 Processing Extra Information Collected from Customer Here you will have to hook into a checkout process method. I'll have a look at which one is best and make it hookable if it isn't already. Ideally you should hook after the order and order line items have been created (given my argument in product vs order vs order line items above). This will then give you the chance of storing the 'custom' information for each order line item in the order. #3 Storing and Accessing Extra Information Collected from Customer Here, I have two thoughts with respect to storing the extra information. Alternative 1: Adding a custom field to the order line item template. Use that information to store the 'custom extra information' from the customer. This could b a typical text field to something more complex. Alternative 2: Using the Notes feature of an Order. All orders store notes. This alternative means you already have somewhere to store the extra customer information. You would need to ensure that such a note is clear as to which line item (bought product) it is referring to in case there are multiple items in the order. Viewing the information in the shop admin could be a bit tricky. If notes, then that is already built in. If using alternative #1, then it will need a bit more work. I can make the order dashboard hookable so you can display extra information. Or you might be able to hook into Page Edit Form for order template and even insert an extra tab there for customisation. Please let me know if this is the sort of thing you were referring to. Thanks.