Leaderboard

This week I’ve been working on updates for ProcessWire 3.0.168 as well as a new Stripe payments module for FormBuilder. In the core, the ProcessPageView module that handles all requests got a pretty significant refactoring. While it was largely focused on optimization, I also just like to go in every few years and rewrite stuff in high traffic modules like this to keep the module fresh, as well as keep my mind fresh on how it all works. I find there’s often room to do something better. The ProcessLogin module also got some upgrades this week that are primarily focused on maintaining the contents of a request URL in the admin between guest and admin user states. Now it can retain most query strings in a request URL after login. There’s still more to do in 3.0.168 so the version bump isn’t being made this week but may be ready next week. So far there are also a couple of GitHub issue resolutions and $sanitizer method improvements as well. On the FormBuilder side, we have the Stripe payments Inputfield, but since that module has been built, Stripe has released new APIs to handle SCA payments (soon required for EU transactions). With these types of payments, as I understand it, a multi-factor type process takes place where the user confirms the transaction with their credit provider. So it changes the payment flow quite a bit… enough that I’ve found the current Stripe payments module can’t really be adapted for it, at least not in a reliable way. That’s because the new API requires that the payment take place interactively before the form is submitted, since the user has to manually confirm it outside the form. So this will inevitably lead to cases where a payment has been charged but the final form isn’t submitted for one reason or another. Maybe it would work most of the time, but it just doesn’t seem like a reliable transaction flow to me. For this reason, I’m building a separate module for FormBuilder that provides a better alternative for the SCA transactions. With this module, the user submits the form, but FormBuilder saves it as a partial/pending form submission. Following form submission, the user goes through the SCA payment process with Stripe. When that completes, Stripe sends a webhook to FormBuilder that converts the form submission from pending to completed, at which point emails are sent, FormBuilder actions executed, etc. So it's Stripe that submits the final form, rather than the user. I’ve got a lot of work still to do here, but since a few people have contacted me looking for SCA support with Stripe payments, I just wanted to keep you up to date and let you know it’s in progress. The existing InputfieldFormBuilderStripe module will of course continue to be developed as well, as most regions outside the EU do not require SCA. Thanks for reading and have a great weekend!

Repost from Autosmush topic: In regards to .webp if anyone should be interested: If you're using Cloudflare free plan, it doesn't matter anyway. Cloudflare free plan doesn't support HTTP vary header so this : – Will NOT do anything useful. Because Cloudflare will serve your webp version NO MATTER WHAT. Which means that Safari on Mac and all iOS devices will not show any pictures... ? Source: https://community.cloudflare.com/t/cloudflare-cdn-cache-to-support-http-vary-header/160802 , https://community.cloudflare.com/t/cloudflare-displays-broken-images-on-my-website/183212/13

BayTech360 is a System Integrations Specialist serving the US out of San Francisco. They wanted to revamp their website and asked Pigtail Pundits to help with it. The new website is built to storytelling standards of StoryBrand and other direct response advertising frameworks. This site features, sell-focussed copy which is our trademark. This is mapped to an elegant, clean design. Built atop ProcessWire, our favourite CMS, with ProCache for speed. Check it out at: https://www.baytech360.com/

I'm really starting to think that camel case / pascal case should be avoided... well, just about everywhere ? Recently ran into a similar issue where a piece of code worked flawlessly on my machine, yet on the live server it spat out nonsensical errors. Turns out my local (Mac) env is case insensitive (which also applies to the virtual machine I use to run Linux on it) while the server is case sensitive. Spent half an hour or so debugging the issue and tearing things apart just to find a tiny typo in the filename. So frustrating! ?

I keep getting an error for an frontend page to import csv. $wire->modules->get('TableCsvImportExport'); // load module $options = array( 'delimiter' => ',', 'enclosure' => '"', 'convertDecimals' => false, 'multipleValuesSeparator' => '|', 'namesFirstRow' => false ); $page->importTableCsv('importTableCsv', $csvData, $options); For testing page table field is also called importTableCsv

@adrian Hi Adrian, the latest version is throwing a warning if there are no external panels: I think this will only occur if there are no external panels, if the glob pattern is empty static::$externalPanels will be undefined (see TracyDebugger.module.php#L320-327). Should be fixed by initializing $externalPanels to an empty array (see L143). Thanks!

Yes, it's still the same as it was, it's just that in the documentation the getById() method has been replaced with getByIDs() since v3.0.156. See "joinFields" here: https://processwire.com/api/ref/pages/get-by-i-ds/ Example with $pages->find(): $items = $pages->find("template=colour", ['loadOptions' => ['joinFields' => ['headline', 'text_1']]]);

OK - pretty sure this is broken since processwire 3.0.160 when a "Major refactor/rewrite of ProcessWire's Database classes" was implemented: https://github.com/processwire/processwire/commit/06acbe57a32e18625248382499bb31527484c315#diff-83091c78a3273da557616affcb670296, specifically, the use of $sanitizer->wordsArray was used to clean the BOOLEAN query value (https://github.com/processwire/processwire/commit/1f293cc4f4092883b4eaf915950ba3c7c5430a7a#diff-83091c78a3273da557616affcb670296R633). The use of this words array function means that "Jul/2021" in the underlying DB query changes to: MATCH(field_event_dates.data) AGAINST('+Jul/2021' IN BOOLEAN MODE)) ) )) (which previously return results) to: MATCH(field_event_dates.data) AGAINST('+Jul* +2021' IN BOOLEAN MODE)) ) )) (which does not find any matches). I'm not sure if the issue of stripping out "\" from ~= searches (and other sanitization via the wordsArray) is a cause for concern generally - or a good thing from a security standpoint? Looking at the use of "~=" in the recurrme module, I'm somewhat convinced that this can be switched to %= without loss of functionality or unwanted side effects (also, performance?) but need to do more testing to tell if this is the case or not.

You can use : getLanguageValue($language->id, 'url') or $page->localHttpUrl($language->id); or $page->localUrl($language->id); for get language values Example usage for get all urls for all languages: <?php $getLanguageValues = ""; $localHttpUrls = ""; foreach($languages as $language) { $getLanguageValues .= $page->getLanguageValue($language->id, 'url') . "<br />"; $localHttpUrls .= $page->localHttpUrl($language->id) . "<br />"; } echo "getLanguageValue() => " . $getLanguageValues; echo "localHttpUrl() => " . $localHttpUrls; ?>