Leaderboard

It's crazy sometimes how quickly the work week goes by. On Monday I started working on a Stripe Checkout integration for a client (using the FormBuilderProcessorStripe module), and somehow today I'm still working on it, and it feels like only a day has passed. This particular integration is a little more complicated than others I've worked on. The user makes a few selections that determine the final price, and when they submit the form, it has to authorize (but not yet capture) the amount due, so that the money is basically in a holding state. Then it has to send a notification to another company asking them to approve or deny the request. If they approve it, then it captures those funds through Stripe. Or if they deny it, then it releases the hold on those funds. It's also connected to multiple Stripe accounts in different currencies, and it has to use whichever one corresponds with the transaction details. In this particular form, some of the purchases also involve a 3rd party web service to confirm availability. And there's more to it as well, but I'll leave it at that... it's just a lot of moving parts, so I guess that's why I haven't done anything this week other than work on that. But the good news is that much of it has been added to the FormBuilderProcessorStripe module, so that the next this time need comes up for you or me, hopefully it won't take so much time. Here's a few of the things that have been added to FormBuilderProcessorStripe: Previously you could just accept a payment. Now you also have the option to setup a separate authorization and capture. And you can capture from a newly added API method, from the FormBuilder entries screen, or from our Stripe dashboard. On the API side, all you need to complete the capture is the ID of the payment (called the payment intent ID), which is saved with the form entry. The capture typically must be done within 7 days of the authorization. Doing an authorization (and later capture) is preferable to a charge when you think there's a reasonable chance the it'll need to be un-done. One reason is because an authorization costs nothing, whereas a charge (or capture) does, regardless of whether it is refunded. The module also has a new option to create a Customer in Stripe that you can charge later. This is different from authorization/capture in that creating a customer doesn't authorize any particular transaction or funds, but rather saves their payment info in Stripe, enabling you to charge it anytime later. This is useful for many cases, but one would be where a customer wants to save their payment information with their account, so they don't have to re-enter it every time they make a purchase. Several new configuration options were also added. New public API methods were added for capture, cancel and refund payments. You can now pass any data from the form into Stripe metadata. You can now specify the Stripe API version that you want to use with the module. And you can now send email receipts, even if not enabled in Stripe. More transaction information is now shown when using the "view entry" in the admin. Several new hooks were also added. Technically this update to FormBuilderProcessorStripe is ready to post now, but I'd like to do a little more testing first, so I'll be posting this module update in the FormBuilder board next week. I also have some updates to the InputfieldFormBuilderStripe module as well (which uses Stripe Elements rather than Stripe Checkout), and it may be updated at the same time, or shortly after. No core updates this week, but hopefully I got enough client work done this week that I can really focus on the core next week. Thanks for reading and have a great weekend!

As the project processwire-recipes.com went offline quite some time ago now, I took the repository and deployed a browsable version of it over on: https://processwire-recipes.pages.dev/ There is also a new repo: https://github.com/webmanufaktur/processwire-recipes/ ... on which this deployed version is based on. Changes, fixes, updates can be submitted there. Feel free to update links, fork the repo, submit changes for recipes layout or whatever. It uses 11ty for rendering .md to .html and all the other magic. I will add further details in regards to formatting recipes and submitting new content in the future. Further notice: @teppo: you link to the old domain on weekly.pw Changes/Updates: incoming - right now this is WIP (work in progress) Maintainers: feel free to let me know, I'll add you to that repo Details: the repo is on github: see above hosting/deployment: on Cloudflare Pages via 11ty updates: all updates against the master-branch will be deployed within 60 seconds after commit changes: right now only via pull-request maintainers: wanted - see above

TL;DR Just copy this folder to your module and get fully automated releases, tags, changelog and with one additional line of code (see note below!!) also fully automated version numbers for your PW modules! Background/long story: @dotnetic asked me some time ago to use conventional commits for my modules. It was totally new to me, here is the link: https://www.conventionalcommits.org/en/v1.0.0/ I've since adopted that workflow to most of my modules, as it is really just copy and pasting the .workflow folder (and you can simply copy that folder from RockFrontend: https://github.com/baumrock/RockFrontend/tree/main/.github/workflows) This workflow is great, because It will create new releases automatically for you: https://github.com/baumrock/RockMigrations/releases It will create new tags automatically for you: https://github.com/baumrock/RockMigrations/tags (This is something that I always forgot and someone was asking for it long time ago, because tags are important if someone uses composer to manage their modules, as far as I understood. Now I can't forget them any more ? ) It will create a changelog for you automatically: https://github.com/baumrock/RockMigrations/blob/main/CHANGELOG.md And last but not least: It will create version numbers automatically for you. One thing that has always been annoying though is that you have to make sure that the version number that is automatically created matches the version number that you set in your modules .module.php or .info.php file. I have always tended to have everything in my .module.php file, but I just recently noticed that this can lead to problems if you are using PHP8 syntax in your module and the website still runs on PHP version <8 --> You end up getting a fatal error whenever the module is loaded, which totally breaks ProcessWires module backend. The solution is easy though: Just split your module config into two files - the .module.php with all the module's logic and the .info.php file with only the array that defines the module's info array. Thx for that reminder @BitPoet! Here is the HelloWorld's info.php file with some helpful comments: https://github.com/ryancramerdesign/Helloworld/blob/master/Helloworld.info.php I did that today for RockMigrations and I realised that you can even fully automate the version numbering of your module, because the conventional commit workflow creates a package.json file that holds the version number in a json string: https://github.com/baumrock/RockMigrations/blob/main/package.json All you have to do is to grab that json string and write that version into your module's info.php file: https://github.com/baumrock/RockMigrations/blob/92a33ba4e7146a69fb1f52d5b67270b66d9f1e54/RockMigrations.info.php#L5-L9 Afraid of a performance penalty? You don't have to. The module's info is cached by PW and only updated on modules::refresh! Maybe other module authors like @adrian or @Robin S or @kongondo or @teppo or @netcarver or @Macrura or @flydev want to adopt that workflow as well. Thx for reading and have a great weekend ?

Hey @dotnetic would it be possible to rename "bewegen" to "verschieben" in the page tree translation?

Done!

I've never worked with mysql spatial functions but I have a little background in GIS so I know things are usually a lot more complicated than you'd think before ? I've done a little research and found some helpful and interesting resources: Youtube video with a good overview over GIS and mysql: https://www.youtube.com/watch?v=6zJ0swD17ow A blog post how to find points contained in a polygon using mysql: https://marcgg.com/blog/2017/03/13/mysql-viewport-gis/ And a little more details about performance (link from article 2): https://www.percona.com/blog/new-gis-features-in-mysql-5-7/ I've done this mysql query on one of my VPSs (3vCPU, 4GB RAM) with - as far as I understand - 50k calculations and got a result in 3.7ms: MariaDB [(none)]> select benchmark(50000, st_distance_sphere(point(-78.7698947, 35.890334), point(-122.38657, 37.60954))); +--------------------------------------------------------------------------------------------------+ | benchmark(50000, st_distance_sphere(point(-78.7698947, 35.890334), point(-122.38657, 37.60954))) | +--------------------------------------------------------------------------------------------------+ | 0 | +--------------------------------------------------------------------------------------------------+ 1 row in set (0.037 sec) I might be wrong but I think that means that you can expect your calculations to be similarly fast. The same benchmark using 1 million instead of 50k tests took around 500ms. Maybe @Mats knows more? I think he also has a lot of experience with (web) maps?!

Just released the updated version of the german language pack for the just released stable core version 3.0.210 Download ZIP (github.com) @ryan @teppo

This isn't the first star rating module for ProcessWire, but I wanted some particular config options and to have the inputfield be usable within FormBuilder. FieldtypeStars The inputfield of FieldtypeStars uses a star rating interface to set a float value. The fieldtype extends FieldtypeFloat. The inputfield has no external dependencies such as jQuery or Font Awesome and can be used in FormBuilder. Config Using InputfieldStars in FormBuilder In order to add a Stars field to a FormBuilder form you must first enable "Stars" in the "Allowed Input Types" field in the FormBuilder module config. https://github.com/Toutouwai/FieldtypeStars https://processwire.com/modules/fieldtype-stars/

Hey again @kongondo, I don't know whether I'm tired/burnt out at this hour, or if I'm missing something, but only the Country seems to show on the order page not the customer's full shipping and billing address (screenshot attached) But if you click "print invoice" the full address displays.

Hi @kongondo Just a quick thought. "Mark as delivered" on orders would probably be better as "Mark as despatched"? Makes more sense. It's a nothing kind of point, but I do think it makes more sense. What say you?

Also... If you do mark as delivered and then confirm. when you come back to the order it still has the "Mark as delivered" action.

Could you first do a simple test to see if your lat and lng are between the highest and lowest values in your polygon (so treat it like a square on first pass). Then once you've got a (hopefully much smaller) list of pages that are in that rough area you can loop through the page array and see if they are actually within the polygon (either using Leaflet or there's bound to be some php code out there). It might not help in your particular case but it might be a good strategy to try first. And of course if you live near London (hello) or anywhere else at zero longitude then you'll have to deal with that...

Hi, original maintainer here. Sorry about the unplanned phasing out of ProcessWire Recipes too long ago. Haven't done PW or any CMS work for that matter for a long time, so it's a shame that the PR project is dormant - in case it is still of value for people out there. @wbmnfktr: Hit me up via DM if you're interested in taking over the Git Orga and/or domain

Hey all, hey @horst after trying to upgrade from version 1.1.15 to 1.2.0 I'll get following error: Call to a member function height() on null File: .../InputfieldCroppableImage3.module: 156 These are my crop settings for the affected field: full,1208,755,product-item vorschau-startseite,600,600,product-item,produkte-page ausschnitt,960,540,feedback-item vorschau,1200,900,news-item,section-box-1-3 boxed-third,700,450,product-item,produkte-page,repeater_rep_ImageTextBox,section-sing_person, product-item-externallink full-wide,1280,640,produkte-page two-third,1680,840,section-box-img-headline-link Any ideas what might have gone wrong? ... a few moments later... EDIT: Seconds after posting this, I've found the error: in crop definitions line 5 "boxed-third" there was an empty space in definition ? I apologise for bothering you. I'll leave my dumbness here in case someone else makes the same mistake, or in case I do it again ?

These files are third party classes from Manuel Lemos. I first thought to wait until he has updated his files, but a PR would be pretty fine!! ?? (There are already some parts in this third party classes, that we have enhanced and or fixed on our self here.) Thanks @monollonom!

Behind the scenes entries in a PageTable field are just regular pages in a regular PageArray. Lets say you have a field "pagetable" and it is configured to use template "blog-post" for items. You can create a new page with new items in the pagetable field like this: // create page that holds pagetable items $p = new Page(); $p->template = 'basic-page'; $p->parent = '/foo/'; $p->title = "Bar"; $p->save(); // get parent id for pagetable items from field config $parentID = $p->getField('pagetable')->parent_id; // create item page for field pagetable $item = new Page(); $item->template = 'blog-post'; $item->parent = $parentID; $item->title = "Item Foo"; $item->save(); // add item page to pagetable field $p->pagetable->add($item); $p->save('pagetable'); Since the value of $p->pagetable is a PageArray, you can find and manipulate the pagetable items with methods from Pages, PageArray and WireArray. To remove a specific item: $item = $p->pagetable->get('title="Item Foo"'); $p->of(false); $p->pagetable->remove($item); $p->save('pagetable'); You can also use WireArray manipulation methods insertBefore(), insertAfter(), append(), prepend() to add items in a specific order.

I want to show you a project that I started developing in summer of 2022 and that went online in january 2023. Kulturhaus Wilster ("Arts Centre Wilster") https://www.kulturhauswilster.de The Kulturhaus Wilster - also called "Wilster's living room" by many visitors - is a socio-cultural center in the heart of Wilster. Wilster is a small City located north from Hamburg, germany. Despite the fact that this is a small venue they offer large amount of events. The events range all the way from concerts to theatre and everything inbetween! The old version of the site was a super simple WordPress website in a black-and-white only color scheme. In my opinion it did no justice to the very colorful program that the Kulturhaus offers so I tried my best to bring some color into the game. The whole website should have a shabby-chique look combined with clean, modern elements. The Homepage offers a preview of the next 8 upcoming events. A blog section is also included and the latest post is displayed next to the event calendar book as PDF download. The event pages offer a quick-reservation form (tickets are not sold online) and a quick look to the next upcoming events in the sidebar. The website features a large event calendar. It was a really nice exercise in using ProcessWires very own paging and selector features. Events can be searched and filtered by type (and month), too. All with a few lines of code only. For example "Look for events that take place in the future in a specific category" $events = $pages->find("select_event_cat.title~|%=$c, template=event, date_event>=today, sort=date_event, sort=time_from, limit=6"); Besides that the website features some colorful content pages with large images, galleries, textboxes and some teaser elements. The editors of the website are able to display all facets of the Kulturhaus this way. Tech Talk: Frontend Framework is Bootstrap 4.6 ProcessWire Modules used on this one are: - WireMail: SMTP (https://processwire.com/modules/wire-mail-smtp/) - SEO Maestro (https://processwire.com/modules/seo-maestro/) - All in one minify for asses (https://processwire.com/modules/all-in-one-minify/) - PageImageSource for webp image srcsets (https://processwire.com/modules/pageimage-source/) - JkPublishPages is used for time-controlled publishing of the blog posts. Please check out this module! Thanks @Juergen - @bernhards great RockFrontend was also used. In this particular project only the autorefresh feature (because this module was brandnew back then and development of the page was almost done). But even "only" using autorefresh makes it worth using it! Please have a look:

Maybe some PW API changed so it broke it. I'll try to check it soon.

This week in the blog we’ll look at the new WireSitemapXML module, a new WireNumberTools core class, and a new ability for Fieldtype modules to specify useful ready-to-use configurations when creating new fields— https://processwire.com/blog/posts/pw-3.0.213/

@szabesz you are right, it's not considered as a bug (I might disagree), see https://github.com/processwire/processwire-issues/issues/1322 @saschapi I've forked tpr's repo and amended some changes, https://github.com/matjazpotocnik/FrontEndEditLightbox

You can use $this->animal $this->animal = 'cat'; $this->addHookAfter('Page::render', function($event) { bd($this->animal); }); or you can also do this: $animal = 'cat'; $this->addHookAfter('Page::render', function($event) use($animal) { bd($animal); });

Loving this module - perfect for a site I'm currently developing. Just noticed a bug: allowed parents selected from Setup > Templates > Edit Template are not saved successfully (no selection is saved). Allowed parents selected from Setup > Template Parents are saved okay. Another thought: how about a sister module for Template Parents, "Page Child Templates"? So for any page you can define allowed templates that may be used for child pages. Now I'm just being greedy

$a->import($items); . or one of the other methods that are available with pagearrays / wirearrays.

I respect Drupal, but strongly dislike using and developing in it. This comes from a couple years of developing sites in it. The problems with Drupal have certainly been a motivation in making ProcessWire happen. Out of the box, ProcessWire is going to be a lot better at the large scale than Drupal. ProcessWire's architecture, foundation and API are far better than Drupal (captain obvious). People may use Drupal at large scale, but I don't believe the product itself was ever truly designed for it. Like with WordPress, being used at the large scale is something that happend to Drupal rather than something it made happen. Drupal is a pig that people have affixed wings to because there wasn't any other way to do it at the time. You see similar things happen with the other big platforms (WordPress, Joomla). As far as pigs go, Drupal is a good one. There are some things to respect (though not necessarily agree with) about Drupal's roots and the original thinking behind it. There's no doubt that it is far better than Joomla, for anyone that cares about this stuff. Beyond that, where it excels is in all the 3rd party stuff written for it, to do just about anything. It's a diesel-powered cuisinart in that respect… whatever you need to blend, it will blend… but it'll be messy. Working at large scale, 3rd parties have built all kinds of caching, CDN and load shifting things to throw on top the pile (and likewise with WordPress). Even a pig can fly if you strap wings on to it. And Drupal has a lot of folks thoroughly invested in it to the point where they are making that pig fly. Drupal is also such a household name that it represents a low-risk position for decision makers (low risk of job loss from choosing Drupal). None of this makes it a good product, just a safe one for people that don't know any better. But for people that do know the difference, we want a panther, not a pig.