strandoo

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