kongondo

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.

Yes. this -> Repeater items markup are ready before the assets are. Have a look at Inputfield::renderReady(). https://processwire.com/api/ref/inputfield/render-ready/ Also have a look at example implementations in ProcessWire Inputfields. Written in a hurry; sorry cannot go into further details.

You are the man @bernhard! I don't recall ever seeing this API!

I haven't had the need yet. Yeah, I see your point. Would hooking into page edit form solve the multiple injections issue or does each repeater come with its own page edit form? Just wondering. Gut feeling is that this could work. Would it be just for loading Alpine.js?

Padloper 2 uses Alpine.js (and htmx) in lots of places, including Process modules and Inputfields. Without defer, as you point out, Alpine.js goes funky. My solution is to use inline scripts. ProcessWire does so itself, in several places. For Process modules, I have a method like below that I use to inject Alpine.js script where I need it: <?php namespace ProcessWire; private function getInlineScripts() { // @note: need to load alpine as 'defer' $url = $this->wire('config')->urls->$this; $alpinejs = "{$url}vendors/scripts/alpinejs/alpinejs.3.2.4.min.js"; $out = "<script src='{$alpinejs}'defer></script>\n"; return $out; } It might not look pretty for some people but your browser doesn't care and it doesn't bother me either . For Inputfields, I have this: <?php namespace ProcessWire; public function ___render() { // .....some code /** @var PageArray $value */ $value = $this->attr('value'); $form = $this->buildForm($value); $out = ''; //---------- // ...etc //---------- // MAIN render content $out .= $form->render(); // ------- /** @var str $preloadInlineAssets */ $preloadInlineAssets = $this->renderPreloadInlineAssets(); if (!empty($preloadInlineAssets)) { $out .= $preloadInlineAssets; } //---------- // APPEND any configs for this Inputfield that might be needed by JavaScript // E.G. translated strings. $out .= $this->renderJavaScriptConfigs(); //------------- return $out; } private function renderPreloadInlineAssets(){ // ...some code: conditions, etc // ---- $out = "<script src='{$source}'{$defer}></script>\n"; return $out; } I've been meaning to make a request to have this handled by config->scripts->add(), e.g. <?php namespace ProcessWire; $config->scripts->add($alpinejs, ['defer' => true, 'integriy'='some_hash', type="module"]);