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!

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/

@gornycreative Currently the fix for the issue you reported is the one i provided. I don't know the internal specifics, but the arrays are not reset when saving the value/processing the form the first time, which is why I had to force any array value to a new array. So you will end up with no [0] index item under some circumstances unless you apply the fix. You can test it by dumping the value and then adding items to any multi page reference field, and then removing them one by one and hit save and look at the arrays. Also note that any 2nd save of the settings page does reset the arrays fully. It must be something to do with where/which hook we are processing the form input; For now this is a safe fix, and i'll cary on researching any further optimizations, but this may be the resolution.

That was me ? @Sevarf2 I pushed a fix. Please download https://github.com/gebeer/FieldtypeImageReference/blob/master/InputfieldImageReference.module Sorry for the inconvenience!

As @Robin S explained, there is no reason to echo anything in a context like that. If you just put any other PHP code there, that will not be executed twice (at least it should not do that for sure). Only echo() is what gets executed twice but it should not even happen once, meaning not calling echo() is the "solution". I have sites with various code being executed in that context, none of them runs twice.

Hey folks! Just wanted to mention that ProcessRedirects 2.0.0 is now out. As far as I can tell it should fix most of the issues that have been reported here, as well as those reported via GitHub. This is a major update and the module now requires ProcessWire 3.0.112+ and PHP 7.1+, so please keep that in mind if and when updating ? Here's a kind-of-a-changelog for this release from the PR that got merged earlier today: In case anyone is wondering why update this module now even though we already have a very powerful alternative (Jumplinks), the thing is that this module still serves a purpose: it's super easy to use, and does what it needs to do — no more, no less. Powerful features can be a double-edged sword, as they also tend to increase complexity, at least to some extent. When it comes to "power users", Jumplinks is by far a superior tool, but for regular content editors who just need the occasional shortlink (or something similar), this module is often just the right fit. Hope that makes sense. Anyway, I still have some relatively minor additions in mind that I'd like to add to the module (assuming that Antti thinks they are a good fit), but again, for the most part this module already does what it needs to. Power users will likely feel more at home with Jumplinks ? If you find a bug or have a feature in mind that this module really needs to have, feel free to open an issue at the GitHub repository. Thanks!

Check if the sessions table is really innoDB (it should be). Also, maybe try to decrease this value: $this->set('lockSeconds', 50); // max number of seconds to wait to obtain DB row lock But most likely, the DB engine doesn't have enough horse-power to handle the load. Are you on a shared hosting environment? You might also try to install SessionLoginThrottle module (core), to prevent too many DB-hits from users who are trying to login without success (repeatedly).

Look at this module I think that's what you're looking for