Leaderboard

The latest site of the week reminded me of https://senderkataster.rtr.at/ that I built with a friend some time ago and that I want to share. Tech: ProcessWire (obviously) https://getuikit.com/ (also quite obvious ? ) https://tabulator.info/ for all kinds of filters https://leafletjs.com/ for the map https://basemap.at/ using an Open Government Data License Some GDAL command line magic to transform the overlay source data into PNGs that are stored in ProcessWire pages and can then be queried and correctly placed on the map. ProcessWire has been a great platform for that project! If you need help with a ProcessWire project that needs some geo-magic or powerful web maps drop me line ? I'm not responsible for the red background ? Show details of a tower Choose a program by name or type and show its radio coverage (not in the screenshot): Expert mode for nerds:

Just a quick update this week, as yesterday was a holiday here and it becomes kind of a holiday week with kids out of school. On the core dev branch, the built-in PageFrontEdit module has been updated to support the new InputfieldTinyMCE rich text editor module. In addition. The $sanitizer->email() method has been updated with several new options. These include support for emails with Internationalized Domain Names (IDNs), UTF-8 local parts and an option to validate the DNS of the email domain. Currently all of these options are off by default but can be enabled with a new $options argument. These options will likely be translated to configure options for email fields (FieldtypeEmail) in the next week or so. In addition, a new version of the ProFields Combo has been released and this version also adds support for the new InputfieldTinyMCE module. I'm also working on updates for ProFields Table and Textareas for support of InputfieldTinyMCE as well, but those updates aren't quite ready to post just yet. If you opt to use TinyMCE with PageFrontEdit or Combo, make sure you grab the latest version of InputfieldTinyMCE, as it also received related updates this week. Thanks for reading and have a great weekend!

Eleven years later, but thanks for that, Ryan! It was exactly the explanation that I needed.

What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.

@kongondo Nice one!! Legendary work as usual. No drama pushing it mate I've got invoicing enabled anyways haha! Enjoy the footy!! It's a biggy too.

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 ?.

Tailwind CSS is awesome! ?

@Pete the pagination is not working example: click ok a Tag (Germany ? ) and click on next… and view more articles on the Front Pages gives a 404

@ryan - all the assets for Tailwinds are 404'ing for me