Leaderboard

I have tried that twice. The first try was for a client and I implemented everything in PHP. That kind of worked and it still works... But I don't really like the solution because it feels very old-school. The second one was a great implementation using alpinejs for reactivity for the cart, very similar to snipcart. Very nice gui and look and feel (using uikit). I wanted to use snipcart first, but I was not able to get that running with things that seemed to be quite common requirements. So I started building my own solution. But the project was never finished. So we kind of failed with that second try. What I realized: I totally underestimated all the things that are necessary to build such an "easy cart + checkout" thing... And I guess it was the same thing for padloper1 (which was abandoned) and padloper2 (which was delayed for a year or so?). That's no offense in any way, it's just a warning that you might be underestimating things as well ? Take the screenshot below: What if the user wants to change the cart at that step? What if he/she enters wrong details? What if you need coupons? What if the payment fails? What if you need multiple languages? etc etc... But if you want to build it, go ahead. I'm always a fan of doing things on your own. I just have a feeling that this statement is a little... underestimating things... that's all ? I guess that both snipcart and padloper are easily worth their price ?

https://github.com/baumrock/RockMigrations

@formulate, it sounds like you want to have some prioritised subset of the results interleaved with the rest of the results, so they are distributed rather than grouped near the end where they would otherwise appear. There isn't any "sort" value you can use in a selector to do this because sort can only work by ordering results based on some specific column in the database, and no such column exists for your case. So like @DaveP said, you need to get all the results and then apply the sort order yourself. But when you have large numbers of results you want to avoid loading all the results in a PageArray. It's more efficient to work with just the IDs and then get paginated results from those IDs, and to do that you can use the id.sort feature that @Jonathan Lahijani mentioned. Here's a demo of how you might do this. This is simplified to just use templates to distinguish between the priority results and the other results but you will be able to adapt it to your case. // Do the custom sorting using only page IDs for efficiency $priority_ids = $pages->findIDs("template=colour"); $other_ids = $pages->findIDs("template=country"); $merged_ids = []; // Loop over the $other_ids (this should be the larger of the two arrays) foreach($other_ids as $key => $id) { // Use modulo operator to insert one priority ID for every two other IDs if($key % 2 === 0) { $merged_ids[] = array_shift($priority_ids); } $merged_ids[] = $id; } // If there happen to be any priority IDs left over when the loop is finished, add them at the end if(count($priority_ids)) $merged_ids = array_merge($merged_ids, $priority_ids); // Now use id.sort to get pages matching the IDs in paginations of 20 $results = $pages->find([ 'id.sort' => $merged_ids, 'limit' => 20 ]);

Do you know Padloper? https://processwire.com/talk/forum/62-padloper-support/ But it’s Not free: https://processwireshop.pw/padloper-2/padloper-2-buy-now/

@bernhard You're right, a simple setup like that is unlikely to break. That's also close to the setup my tutorials recommend and that I'm using for all ProcessWire projects. What I had in mind are smaller problems / incompatibilities that crop up between PW and Twig from time to time. We recently did a round of updates to 3.0.200 and ended up with some exceptions because of the way we were accessing fields that may or may not exist on some pages. The way Twig tries to access object properties was causing some unusual errors. If you don't know both ProcessWire and Twig very well, this can be really hard to debug. If you're using an actively maintained plugin that comes with some integrated features, the developer will probably notice those problems as they come up and either fix them or provide guidance on how to avoid them. What I meant above was that with a custom setup, you can end up with a bug that you don't know how to fix and have nobody to turn to for help. But maybe those points apply regardless of how you include Twig, manually or through a plugin … in any case, I wasn't thinking about your upcoming module there, I'm sure it'll be a useful time-saver!

I think you don’t need to manually set the Content-Type header if you send a URLSearchParams object: secondAJAXXHR.send(new URLSearchParams(request)); (no support in the old IE though)

SOLVED! second post uses POST too, the comment where it says GET is a typo. Anyways, I think to have figured it out, as often, the problem is with the headers. It needs both: secondAJAXXHR.setRequestHeader('X-Requested-With', 'XMLHttpRequest'); secondAJAXXHR.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); This seems so random to me, at least until I understand this headers stuff. That said, will that cause issues in different browsers, clients and whatnot?

Hey @MoritzLost that statement confuses me a little bit. What I'm doing is simply having a main markup file in PHP (_main.php) and from there I render template files (LATTE, Twig...). That's a super simple setup and I can't see any reason why this should break with any future PW update. All the other template engine modules for PW seem to use a different approach, more or less completely replacing the rendering strategy of PW if I understood that correctly? Do they? I don't really understand what's going on there to be honest, as I've only been using my simple approach which has worked extremely well. Though I might be missing something important here? There might be a reason why a more complicated approach is preferable over my slimmed down one? I have the same problem with translating strings, but there are easy workarounds (either manually or there is also one built into $rockfrontend->x('my_translatable_string')). Thx for your insights!

hum.. looks like the second call uses POST too: secondAJAXXHR.open('POST', '', true); do you fill the $action variable in the "some logic" code? // some logic $response['action'] = $action; if not, will be empty for a GET request

@wbmnfktr Fair enough! For now I've added a disclaimer with a link to this post to the Twig setup tutorial (just below the introduction) so people looking for reasons to use Twig can understand my reasoning. Maybe in the future I'll rework this article a bit and put it all on processwire.dev. Probably not a good idea to just copy it over as is, Google will think I'm a spambot ? That tutorial already exists on processwire.dev though, see the links in my initial post (part one – part two). Those two tutorials go through the complete Twig setup and a basic structure for Twig templates that should fit most use-cases and integrates nicely into the existing PHP templates, as well as some pointers on extending it with custom functionality. Or is there something that you feel is missing there? ? Well, in the end my setup is just one way to integrate Twig into ProcessWire, and there are a couple of different options (like Bernhards upcoming module). And there are definitely some edge-cases that arise from Twig not being "officially" integrated into ProcessWire – like the translation system that can't detect translatable strings in Twig. There are workarounds for those, but you often have to invest a bit more time to get things working. I think Twig is a great benefit and wouldn't want to miss it in any of my projects. But it comes with some strings attached, and the setup might break in unexpected ways with every new ProcessWire update. So a community-provided module might be the 'safer' option if there's an active maintainer behind it who will keep everything up to date and working with new PW versions, and do all the Twig setup and config 'under the hood'.

Just in case somebody needs to get the override label in the current language… I did… // Get label in current language echo $templates->get('template_name')->fieldgroup->getField('my_field_mame', true)->getLabel(); // OR directly from the page (no matter how the templates name is): echo $page->template->fieldgroup->getField('my_field_mame', true)->getLabel(); This is a way faster than using translate stings in the template: __("I'm an in english headline, translate me!")

Just wanted to share the simplest language switcher possible if you only have two languages: <a href="<?= $page->localUrl($languages->findOther()->first()) ?>">DE/EN</a> ??

nice and besides that it is easy to add i think it would be nice to have it in the core. maybe you can add a PR @Martin Muzatko ?

Create another template to those pages and edit the template. Then go to the Files tab and specify another file in the "Append file" section. Plus you may need to tick the checkbox to disable automatic appending of _main.php.