strandoo

@marie.mdna Hi Marie. Sorry for the delay, but if you still need it, here is a bit more info that may help. My site sells educational courses, (not products) and each instructor conducts classes in various locations for various fees. There is a master Stripe account for the website owner and each instructor has their own Stripe account which is set up as a ‘Connected Account’ via the master Stripe account. (For me, getting the Connected Accounts set up (onboarded) was the most confusing part; see the Stripe documentation). In ProcessWire, I set up pages for instructors, courses, dates (events), etc with the necessary fields to link these. You’ll have to set up your PW for whatever you are trying to sell; make sure you can save an order with at minimum the buyer info, seller name/id (instructors in my case) and seller’s Stripe account number (this will be their ‘connected account’ number), and price. Then here’s what I did: - Installed the Stripe PHP Library (via Composer or manually) and set up your Stripe development stuff (secret and publishable keys, web hook endpoints, etc; you’ll have to look up how to do this in the Stripe documentation). - created a Stripe form processor template and page using code/examples from the Stripe documentation. This page gets my stored API keys and sends the order info to Stripe to create the payment page. - created a template with a form to collect the buyer’s name, email, etc. and the course info, instructor’s name, etc. This page contains a second Stripe form (essentially one hidden field and a hidden button) that works with the Stripe form processor page. On order submission, the form processes via Ajax: it does some checks for required fields, etc, then saves the order as an unpublished page. On success, js populates the second (Stripe) form with the id of the saved order page then submits it to the Stripe form processor, which fetches all the data to submit what it needs to Stripe. - created a webhooks.php file to receive data back from Stripe to verify success or failure of an order and do any post-order processing (get and publish the order page, set fields with order confirmation data, send confirmation emails to the customer and store owner, etc). It’s supposedly more reliable to use the web hook data for this rather than rely on the form submission success page. If I recall, you can find an example/template of webhooks.php from Stripe. I hope this is enough to get you started. - P

Thanks of the reminder though. I need to add a bit of disclaimer or something in those cases. Cheers.

@benbyf Did you consent to the cookies? We use Termly to manage our cookie settings and permissions. If you don't consent to all the cookies, you will get the errors (on all pages, not just the booking form). If you click on the 'Consent Preferences' in the footer, you will be able to accept all cookies. Please try that and see if you can submit the form. TBH, adding the consent stuff is sometimes a pain, since not accepting sometimes break scripts in non-obvious ways.

Hmm. Thanks for the heads up. I just tired it on Firefox, but can submit the form no problem. I see the jquery errors and will investigate. I'm on a Mac w/ Firefox 129.0.1. How are you stopped from proceeding?

@marie.mdnaI've been a bit busy this week, but I'll try to get you some details. In the meantime, this is the site: https://www.collegeofbowenstudies.co.uk and the process starts on the Booking page. You can fill out the form and proceed to payment without having to enter any payment details. This will at least show you what the Stripe-hosted page looks like. I'll try to have a closer look later in the week. - Paul

@marie.mdna I did something similar using one of Stripe’s hosted pages (I think it’s their Checkout system: https://docs.stripe.com/checkout/quickstart?lang=php). Stripe has something called Connected Accounts, which allow you to take a payment through a “main” account and pass on it (all or a portion of it) to a Connected Account. When you onboard someone’s account (I.e, you make them a Connected Account on your site), you get a special account number which you pass to Stripe during a transaction. I built a form that saves the product details, buyer info and the seller’s name as an unpublished page then redirects the user to the Stripe Checkout page. When a successful transaction occurs, the order page is published and an email is sent to the buyer, seller and site owner so the order gets fulfilled. It works pretty well, but it’s a bit fiddly setting up the accounts.

Hi @benbyf I've just downloaded, installed and tried out the module. It worked fine to start with: I could send between 2 users and see the messages. I was viewing source and accidentally hit one of the 'delete' thread buttons and since then, I am unable to see any message threads. I can send between clients and it acts like there are messages (with unread message counts, etc), but no messages are displayed. Not hidden by CSS either (they don't appear to be in the DOM). Any suggestions? PW 3.0.210, PHP 7.4.33. Thanks.

@gmclelland Thanks! This is just what I was looking for. (I'm not sure how I missed it).

Hello folks. I've got a site with lots of images (large hero images, people's bio images and company logos mostly). I've noticed the site takes up a lot of disc space and then saw that many of the uploaded images are quite large (5MB). I use ImageSmush, but until now hadn't limited the file size on upload. I'd like to be able to give the client a list of the largest images so that they can re-upload a smaller version and/or smush them, clear variations, etc. Basically see if we can get some disc space back. I would love a page/system/module to give a report on all pages with images overs XX kb (for instance). Also, many photos have been uploaded as pngs (less than ideal), so having an option to find all pngs, for example would be nice. Has anyone seen a module like this or has a suggestion to create a report like this? Or any other thoughts. Thanks.

@LMD Yes, that's a great point. I'll check with the client to see if they are unique or not. Either way though, if the user fails to log in, the change/recover password system could be amended to include instructions i.e. 'Please ensure that you have selected your original country yada yada...' But I still think the requested changes will make things more complicated than they need to be.

@flydev Brilliant! This looks very helpful. I'll be starting on this again this week. I do have an older version of LoginRegisterPro and I'll have a look at that. I think this would also be a good time to purchase/upgrade it. Thanks, flydev.

@LMD I think the number part may not be unique. In any case, that user name format pre-dates the website. It’s what the company has been using for customer/dealer ID numbers for years and they are part of their internal ordering system. I agree that what they want complicates things. But the idea to hide the country code comes from the company’s Managing Director, so I’ve got to try to implement it. ?‍?

@bernhard Good question. There’s also a drop-down ‘region’ selector in the navbar to select your region. Presumably, once the new system is instigated, there will also be text on the login page along the lines of “Please ensure your region matches yadda yadda.” The site is live; the log in is the DealerNet link in the footer: https://teak.com. (Regions are currently limited to 3.)

Ok, it turns out it's very easy to do this with the 'normal' /processwire/ login form: https://processwire.com/api/ref/process-login/login/ A quick test hook confirmed this. But I'm using the form generated from the LoginRegister module and that one's not so obvious (to me anyway). Maybe the Pro version would permit me?

Hello ProcessPeople. I need some help, please: I've built a site that's mainly a catalogue of products, but certain approved Dealers can login to gain access to dealer-related stuff (mainly place orders with the manufacturer). Each Dealer is pre-assigned a username in the form of Country Code and Number (UK-12345, FR-56789, etc). I'm using this with the LoginRegister module and it works well. Not content with this simple setup, the client would like me to modify the login so that the Dealer only types the numeric part of the Username (12345) and have the Country Code (UK-) invisibly prepended to the user-supplied part when the Submit button is clicked. The user's Country Code is captured when they first arrive at the site with an IP-based geolocation service, so getting the Country Code is easy. Is there a way to hook into the ProcessLogin module (or the LoginRegister module) to quietly insert the Country Code? I'm still a bit new to hooks. Thanks for any suggestions.

I haven't tried these fixes on any of my forms with the Recaptcha yet. But I did try changing that line back to '!$form->getErrors()' (the original) and it seems to still work. By the way, are you getting 2 emails sent for every form submission?

@Java Doesn't EmailObfuscation just works on email addresses and not forms? Many of my clients request contact forms (although they can be such a pain in the ass (the forms, not the clients (well, maybe them too!?))).

@PWaddict Yeah, that's because the newer InputfieldForm.module creates a new hidden field before the closing </form> tag (<input type="hidden" name="_InputfieldForm" value="[your-form-name]">). The presence of that field throws off the 'spam count'. That's another anti-spam measure in the module which makes sure the total count of form fields is what is expected. See the comment around line 206. I tried to figure out how to target and exclude the new hidden field, but I gave up and just changed line 211 to '$excludeFields = -1;'. Not very elegant and of course, this will break the form if used on a pre-3.0.210 installation, but it gets it working until I can spend more time on it.

Ok, more digging and I think I've got it. The InputfieldForm.module made at least 2 changes that effected the no-longer-supported-but-heavily-used SimpleContactForm (by me anyway): 1) it appends a hidden field at the end of your form ('$landmark', line 178). I don't know it's purpose, but I'll now see if I can subtract it from the field count in the Spam Protection of SimpleContactForm. 2) $form->getErrors() doesn't work the way it did previously. Thanks to a post by @da² that I came across, I've been able to use $form->getErrorInputfields() instead on lines 203 and 245 in the SCF.module. For now, I'll just edit the module, but maybe there's a more elegant way to do it.

Ok, I had a look and but couldn't figure out exactly what is going on. I'm filling in the honeypot to test and that's getting logged as spam, but isSpam doesn't seem to be working and I'm not clever enough to know why. But since SimpleContactForm + PW 3.0.210 is adding a hidden field (<input type="hidden" name="_InputfieldForm" value="contact-form">) where PW 3.0.200 isn't, I thought I'd try the replacing 210's InputfieldForm.module with the one from 3.0.200. Once I did that, no more hidden field and the spam filter works as expected. So maybe someone more knowledgeable than myself can spot the difference and see if SimpleContactForm can be patched?

@PWaddict Yes, I was looking into this with a non-recaptcha form. I've got probably a dozen or more sites using SimpleContactForm, some probably now updated to 3.0.2xx, so I'd like to solve this! Yesterday, I noticed this error in TracyDebugger: PHP Notice: Undefined offset: 0 in .../modules/SimpleContactForm/SimpleContactForm.module:238 So when I get a chance, I'll try to see what that's all about.

@Flashmaster82 I had a quick look at some forms on a few sites and it appears that under PW 3.0.210, a new hidden field is being inserted at the end of the form, just after the token field: <input type='hidden' name='_InputfieldForm' value='contact-form'/>. I suppose this is why the count is off, but I don't know why the form gets sent anyway. I found https://processwire.com/api/ref/inputfield-form/ that might explain it somehow.

@PWaddict I'm getting the same as you: either 'Number of fields does not match' or 'Honeypot field was filled', then followed by [SUCCESS] a second later. But this is happening with my own tests, so it's probably not so much clever spammers as much as something broken with recent PW updates. Any idea where this might be failing?

Do you have ‘scf-website’ as one of the fields in the module settings > Select Form Fields settings? If so, try removing that.

Thanks @Guy Incognito. Yes, now that I've dived in a bit, I can see that handling the communication may be tricky. (Logged-in sales rep initiates a 'stock query' > check if exists, creates a new DB record > writes file > waits for response > checks if new response file matches my stock query > parse file and update DB record > display result > rinse and repeat.) The php module 'Inotify' looks promising as far as checking for directory/file changes, but I haven't gotten there yet. Thanks again.