kongondo

I don't understand this. What title are you referring to? The titles of menus that are displayed in the dashboard that shows all Menu Builder menus in the backend? What is the wrong language in this case? A screenshot with English explanations would help.

Hi @entschleunigung. Sorry for a very late reply! I missed your post. I have no idea what's happening. Are you able to please try with a different ProcessWire version? I don't recall anyone ever reporting a similar issue.

Good idea. I'll and this on my todo list. I have no idea. I'll test here and let you know, thanks.

Hi @gs-df Coupons/Vouchers are not currently supported so there are no files to look at ?. Some quick thoughts... I see three main components: Creating coupons Managing them (editing, etc) Using the coupons in the frontend and expiring them in the backend. Creating Coupons There's are a number of approaches. a. Coupons as a special type of product Add a custom text field to products template. Create coupons as products. Hide these 'special products' from the frontend. Advantages Easy to create. Not much coding needed; you can use the Padloper and ProcessWire APIs. Disadvantages Not intuitive; can confuse editors. Lots of unused fields relevant to product but not to coupons. Extra code to hide coupons from being displayed in the frontend as products. b. Coupons as dedicated ProcessWire pages Let coupons be dedicated ProcessWire pages. Could use own custom dedicated template (i.e. non-Padloper template). Can either hide these pages under admin or have them live under Padloper main parent page or have them as usual pages. Add custom fields to hold coupon details such as valid date(s), expiry, usage, number, etc. Alternatively, create a custom Fieldtype for coupons. Advantages Straightforward and easy to manage as separate pages. Not much coding needed; you can use the ProcessWire APIs. Disadvantages Extra code to hide manage coupons c. Coupons as items in a custom database table Create a custom database table dedicated to holding coupons data. Use $database to CRUD coupons. Advantages Straightforward and relatively easy to manage as separate records. Scalable. Disadvantages Knowledge of working with custom tables needed. Extra code for CRUD. Managing Coupons Depending on your chosen route above, you could directly edit the coupons as ProcessWire pages, or create a Process Module (not great as will be outside the Padloper 'environment') or use the Padloper addons and addons API. The latter is my preferred method as it gives you near unlimited ways to manage your coupons in a dashboard. You could use this dashboard to manually send coupons to customers. You could also automate the process. Using Coupons This is the easy bit. You will need to use a custom checkout form to add fields you need to capture details about the coupon details that the customer has provided. You can then use a hook(s) to process coupon details entered by customer (e.g. validate, etc). See demo 2 and demo 3 on how to use and hook into the order checkout to process custom form details. Hope this helps.

Oops! I'll update soon.

Hey @alexm. Currently there is no setting. You mean have the same title? I'll have a think about a setting.

Hi @PavelRadvan, Welcome to the forums. Thanks for your interest in Padloper. Do yo mean cross-selling within the same site? It is not supported by Padloper out of the box but would be doable with some custom code. You would need to take care of payments logic to sort out who is paying who. What challenges is the customer facing? Padloper ships with PayPal already integrated. There is no requirement to register to be able to buy. This is currently not supported by Padloper. It would require you to write some custom code. It sounds like a good candidate for a custom addon. You would need to write custom code for a profile page. it wouldn't be difficult (assuming you know ProcessWire well) since you are dealing with pages. Yes, but you will need to write custom code for certain aspects or get someone to help you with this. The cross-selling sounds like the most difficult aspect. If you have custom code in Prestashop, you might be able to port some of it to ProcessWire. Let me know if you want to discuss further or if you would like to discuss the custom work that will be required.

Hi @alexm, Yeah, sorry, not yet in the docs. The code below can get you started. It finds all orders of the logged in user. <?php namespace ProcessWire; /** @var PageArray $customerOrders */ $customerOrders = $padloper->find("template=order, order_customer.userID={$user}"); # ALTERNATIVE SELECTORS // $customerOrders = $padloper->find("template=order, order_customer.user_id={$user}"); // $customerOrders = $padloper->find("template=order, order_customer.userID={$user->id}"); // $customerOrders = $padloper->find("template=order, order_customer.user_id={$user->id}"); You can also use $padloper->findRaw() if you will be expecting lots of orders per customer. Order totals , shipping and payment info will be on the order themselves. Items are the children of the order pages. Line items info will be at the line items level. Let me know if you need more info. Thanks.

Hey @alexm. Found the problem. The issue was that by the time we were checking the session whether this was an invoice order or not we had already cleared the session plus we were return the opposite of that, hence !null became true. This meant it was always returning that the order was an invoice order...etc. I'll try and push tonight...I must warn you though, there is the little matter of a spherical leather object ...?. If you need this ASAP, I can email you the amended file.

I'll have a look. From what I can see, for some reason your payment is being considered an invoice payment. Since your shop doesn't accept invoice payments, the error is thrown. I need to find out why your Stripe payments are being 'classified' as invoice payments by the check.

Hi @alexm, Sorry, my communication and docs were not clear enough. We stopped supporting the 'equivalent_padloper_input_name' option. You need to use the input names specified here in the docs ?.

I have also tested with 3.0.200 and it works fine. I'd suggest starting on a clean install in a similar environment but without any custom modules. Test that. If it works, add your custom modules one by one as you test each time you add a module. This is bound to reveal the cause.

Tested @bernhard and it works fine Screenshots Environment PHP 8.1.10 ProcessWire 3.0.203 MySQL 8.0.30

Admin template already allows page numbers. Whatever is happening is a bug (but I am yet to try and replicate to rule out 'implementation'). Setup > Templates > Filters: Show system templates.

That would definitely be a bug. Lister Pro needs pagination. What ProcessWire version?

Do you have examples of modules whose pagination do not work?

I'll see if I can come up with something later...

Just adding that the pagination I am talking about in Lister is ajax powered.

Why would you think so? Pagination has been available in the backend ever since I can remember. Lister (page finder) uses pagination ?. I also know this since I have been using pagination in my modules.

Hi @Spiria Could you please test version 0.2.8 currently on the dev branch? You will have to install it manually. It fixes the issue: Please let me know if it works. Thanks.

Tailwind CSS is awesome! ?

Hi @Spiria, Sorry, didn't get a chance to look at it. There are two 'issues' you have reported: #1 If your profile is set in a language other than the default language, and you are building a menu with the MenuBuilder module, your menu won't appear correctly in the other language. I am working on a fix now. I hope to fix over the weekend. No promises though. #2 if you build the menu with language in your profile other than the default language, the menu will not translate correctly to the language chosen by a visitor, as my examples show. By default Menu Builder will display the title of the page as it was when it was added to the menu. If you want it to be dynamic depending on the current title and current language, you need to use the default_title option as documented here. For example: <?php namespace ProcessWire; $menu = $modules->get('MarkupMenuBuilder'); // render the menu by title and show the current title of the page in the user's language $content = $menu->render('My Menu', ['default_title' => 1]);

Hello @hanna clarke, Is your site a ProcessWire site?

Not sure I understand this bit. Is it related to the 'switching user language profile' issue you've mentioned?

What @teppo said. Apologies this slipped under the radar. I'll have a look this weekend.