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!

Hi, just a little idea i often think about, when you create a fieldset field and you give it one or more tags in the advanced tab, it may be a good idea that the fieldset_END gets the same tag(s) by default instead of ending in the fields with no tags list ? have a nice day

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 ?

The issue is here: https://github.com/uiii/AdminHelperLinks/blob/023a5bc75028713ebcfea1212132cbe00867a024/AdminHelperLinks.js#L134 There is no need for the extra forward slash before '/setup....: ProcessWire.config.urls.admin + '/setup/template/edit?id=' For some reason it no longer works in newer PW versions but it is not needed anyway.

@kongondo Yeah, I think it would be nice to be able to see the shipping and billing address on the order page at a glance, but as you say it would be interesting to get the others opinions. Also as I'm creating an active orders and past orders view for customers on their account dashboard and I can't currently see how I can get their billing and shipping address details from padloper_order. Is there a way of me grabbing the shipping and billing address for an order to output with relative ease?

@kongondo ahhhh!! So delivered is actually so you can update when you have had confirmation of delivery, I'm with you now.

Hi, without seeing the full form code it's hard to answer so don't take it the wrong way ? the first thing to check is that your form has the correct enctype="multipart/form-data" attribute then, have you checked the form really uploads the file into the right folder? i personally use native php move_uploaded_file, example for a simple file $cv = nom_fichier($_FILES['cv']['name']); // nom_fichier is a personal sanitizing function, yes, i'm a frenchie :) but you can use pw great one if ($cv != "") { move_uploaded_file($_FILES['cv']['tmp_name'], $filefolder . $cv); chmod($filefolder . $cv, 0777); } and then zip it server side (security...) and attach the zip file with wiremail attachment before deleting it after sending the mail but you can see a full pw example here https://gist.github.com/somatonic/5233338 one thing i can say for sure, $m->attachment works fine, i often use it for application form with two compuslatory file fields (that end in the same zip server side :)) hope it helps have a nice day

Thanks for the update, link fixed!

Hey @alexm, I see your point. I'll need to have a think. Padloper currently has a number of statuses for payment, order and shipment. Not all are currently in use/editable but we'll work them in in the future. There is a status for 'shipped' which would equate to your 'despatched', i.e. on its way. Delivered is exactly that; 'someone received the shipment' {unless....don't get me started about Evri, Amazon and you-know-who-stole-your-parcel'} ? I'll add to my TODO list. Good catch, ta.

Hi @alexm, Nope, it's not you, it's me :-). This is by design. I cannot recall what my thought process was then but now that you mention it, I think it makes sense to show the full shipping address. Unless others have a strong opinion, I'll change it to that. If there are strong opinions otherwise, then we can make it configurable or hookable. Will add to my TODO. Meanwhile, if you really must change it now, gimme a shout.

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

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

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/

Yes, it is used for many things in the admin panel. On the frontend you are free to choose whatever you like. I think you are talking about the frontend. IMHO you should avoid using a CDN to integrate jQuery into your site, because of GDPR regulations in the EU (if you reside in the EU) and also I experienced times, where the CDNs failed or took a long time, so the whole site was blocked because it could not load jQuery. Nowadays I don't use jQuery anymore and try to write everything as vanilla JavaScript. jQuery has a simpler syntax sometimes, but adds additional Kilobytes to the load and execution time of your website. It was great some years ago, to overcome browser inconsistencies, but that is not needed any more. You might read You Might Not Need jQuery To avoid discussion: This is MY opinion and everyone can decide for themselves what to use.