MoritzLost

v1.0.1 Bugfix: Fix warnings in PHP 8.2 (contributed by esszett in #1)

Release 2.0.1 Bugfix: Fix PHP warnings regarding the usage of htmlspecialchars. https://github.com/MoritzLost/InputfieldHCaptcha/blob/master/CHANGELOG.md#201---2024-10-14 @combicart Thanks for letting me know, should be fixed in 2.0.1. Turns out some attributes might be null in InputfieldHCaptcha::getAttributes(), which was passed to Inputfield::getAttributesString(), which passes this to htmlspecialchars. Might also be addressed in core, but for now, I've filtered out all the null attributes. Let me know if you have any other issues!

@AndZyk Thanks Andreas! Looks like that was it, I updated to 3.0.229 and the query works correctly again. Not sure why my colleague updated to a non-Master version, we usually don't do that. Lesson learned, I guess.

We have a query that's used to find all users with the member role, but without any of a number of other roles: $users->find('roles=member, roles!=member-confirmed|login-disabled|superuser|editor, sort=created') This used to work in previous ProcessWire versions. However, we recently updated ProcessWire (currently on 3.0.226). Now the query just returns all users, regardless of role. Anyone know when this behaviour was changed? And how can we fix the query? @ryan Since this is a breaking change, why wasn't there a minor or major version increase for whichever release changed this behaviour?

ProcessCacheControl version 1.1.1 Just pushed a maintenance release to fix a potential installation issue. See this issue for details: https://github.com/processwire/processwire-issues/issues/1462 Note on support: I'm not actively testing my modules with current ProcessWire or PHP versions any more, but I'm happy to continue to support those modules. If you encounter any errors with new ProcessWire / PHP versions, please open an issue on GitHub so I can fix it.

@ngrmm The snippet above hooks into ProcessPageEdit::buildForm – this would add hCaptcha to the page edit forms in the backend, not to Form Builder forms. The example code would add the hCaptcha code to all page edit forms, but you could limit it to pages with specific templates. Through $event->object you have access to the ProcessPageEdit instance object, and $event->object->getPage() will get you the page being edited. If you want to insert the hCaptcha field to all Form Builder forms programmatically, something like this should work, though I haven't tested it: $forms->addHookBefore('FormBuilderProcessor::renderReady', function (HookEvent $event){ $processor = $event->object; $form = $event->arguments('form'); if ($processor->formName !== 'contact_form') { return; } // insert hCaptcha }); This should insert hCaptcha into a form named contact_form. Keep in mind that the selected embed method still needs to support this, so the caveat regarding embed method D still applies.

@ngrmm Ok, I see the issue now. I have never used the generated markup (embed option D), so I haven't run into this issue yet. The problem is the new bypass permission added in 2.0.0. Any user with this permission (the superuser has all permissions) will not see the captcha, the inputfield doesn't output any markup in this case. When you're generating the form builder markup, FormBuilder just renders the form with the current settings and outputs the resulting markup as a template (with some adjustments) as far as I can tell. But you're logged in while doing this, so the resulting markup will not include the hCaptcha code. Not sure if I can solve this from within the module. I think you're going to have to manually add the hCaptcha markup to the generated template. Place this in the generated markup in the place where the hCaptcha is supposed to go: <?= $form->getChildByName('hcaptcha')->render(); ?> Replace hcaptcha with the name of the hCaptcha field in your form. If this doesn't match the custom markup you need for this form, embed the form using one of the other embed methods, open the page with the form as the guest user and copy the generated markup from there. Then you can modify it as required. Or just include the inputfield manually.

@ngrmm Not sure what's going wrong there, but some ideas: Are you sure you're not logged in, and your guest user doesn't have the permission to bypass the captcha? Maybe the form was cached while you viewed it as the admin, and the guest user is seeing the cached output without the captcha input? What happens if you submit the form (as the guest user) while the captcha is not visible - do you get an error or does the submission succeed? Depending on selected strength and hCaptcha subscription (if any), the script may not always show a visible captcha if it's confident you're a real user. Try reloading the page with the DevTools open - is the hCaptcha script being loaded? If so, maybe it's just using a hidden captcha. If not, the inputfield is probably not included at all, then it's probably an issue with your template. Can you post your form builder template? Depending on how your template is built, you might need to include the hCaptcha inputfield manually.

For our starter kit for new projects, we used Site Profile Exporter to include a database dump in the site folder. While working on that folder, everything was inside the site folder. When we set up a new project based on that starter kit, we use Composer commands to rename that folder to something like site-starterkit. This is recognized by ProcessWire as a site profile, so we can normally install ProcessWire using that site profile, at which point it will be renamed to site again.

@eydun Yeah, I don't think this has ever been tested or officially supported. It will definitely not work out of the box, as ProcessWire expects a specific folder structure and doesn't work if it's placed in the vendor folder. Not sure why this is even in the docs.

@eydun Yeah, but it's a bit involved. ProcessWire expects its core files in the webroot and won't work properly if they're inside the vendor folder. What you can do is use Composer scripts to hook into the Composer installation and put all of ProcessWire's files in place. What I've done in the past is use a custom Composer script to download the latest version of ProcessWire from Github and unzip it in place. Something like this: "prepare-installation": [ "git clone --single-branch --branch dev https://github.com/processwire/processwire.git processwire-temp", "cp -r processwire-temp/wire public/wire", "cp -r processwire-temp/site-* public/", "cp processwire-temp/index.php public/", "cp processwire-temp/install.php public/", "cp processwire-temp/htaccess.txt public/.htaccess", "rm -rf processwire-temp", ], This can be run with composer run-script prepare-installation. If you want this to happen automatically during composer install, use post-install-cmd instead of a custom script name. There's probably a simpler way to do this, this was for a project template with a couple of other caveats.

@gebeer We're running the module on a couple of sites on PHP 8.0 and 8.1 with no issues. If you do find any issues running on PHP 8+, open an issue on GitHub or let me know here and I will fix it as soon as possible!

It's right here ? Anyway, glad the module is working for you! Let me know if you run into any more issues.

@MarkEWere you viewing the form while logged in as superuser? Since version 2.0.0, the module comes with a permission to bypass hCaptcha. This permission also hides the widget from the frontend. The superuser skips all permission checks, so they never see the widget. Make sure to test the form in a private browser window where you're not logged in.

@thetuningspoon I completely disagree, because that is farther removed from the goal of having a declarative dec config and closer to the territory of migrations. You don't want to give the system a list of instructions on how to build the correct state, you want to have a declarative list of configuration values that describes the correct state. Getting there happens under the hood. Similar to the difference between declarative or functional programming and imperative programming - you only describe what to do, not how to do it. The system can compare the list of fields in the config and in the database, add and remove fields as needed, and update config values. Combined with version control, this allows you to go back seamlessly to any previous state, revert changes to the declarative config etc, which is something that migrations struggle with, as mentioned. I understand the hesitation to have the system outright delete anything that's missing from the config, but that's just a combination of not going 'all-in' on the declarative config, or not embracing some important workflow changes along with it. You want the config to be the single source of truth for the state of the project, independent of any existing installation or database. If you take an existing 'base' state (for example, tracked in version control as a database dump of an existing installation) and only include changes relative to that base state in your config, you're not there all the way. You want the config to include everything, every field, template, setting, installed plugin, etc. This way, a new installation (for example, a staging environment for a specific feature) can ideally be created with a single console command. Once you have that, you don't have to worry about having the system delete fields that aren't in the config, because deleting a field from the config requires the same amount of effort and has the same visibility in your quality control pipeline as adding one. The rest is just a question of workflow. Changes to the config should be tracked in version control, and merging those changes should require an approved pull request (if you're working in a team). Deleting a field is just as much of a change that is visible in the PR as adding one, since you will see the deleted field config in the PR and make sure that this is really what you want to do. Once you have a solid workflow in place, you can confidently delete everything that you no longer need, because you know you this change will go through review and quality control, and you can get it back through version control if you really need it again in the future. Of course, mistakes still happen. Turns out the client still had some vital data in that field you removed? Well, that's what backups are for. The first step in every deployment script should be a backup. Yes, absolutely. Though in a perfect world, changes to the config are only made in development environments, tracked in version control, and then deployed to the live site (after any staging environments in between). Pulling the config and applying it should be done as part of the deployment script. This way, there is rarely a need to have a button in the backend that applies the config (though this is still useful for development). The more you can automate deployments and get rid of manual steps, the better. This allows you to work in smaller iterations and get features out faster and with more confidence. The Phoenix Project is a great read on that subject!