strandoo

@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.