Juergen

Good choice! I guess (hope) that this will put spam bots into troubles. The "every second letter" captcha should also be a difficult task to solve for spam bots, but time will tell and we will see what happens. I am already curious 🙂! Good luck

Thats bad! Do these spam mails always come from the same sender?? The problem is that spam bots are going to get always better and better. You are using the math captcha and I know that some spam bots can solve this captcha type. They can also solve random string captchas, because they can read the content of images. My tipp: You have got multiple different captchas to choose - use another one like the image captcha. You can also try to increase the level of distortion lines which makes it much more difficult for spam bots to read the content behind. All captcha configuration can be done in the backend. It will be trial and error to find the right captcha which works best. Would be interesting if someone else struggles with spam mails by using this module. Best regards

There is also a commercial form builder module available for Processwire, which have a UI to create the forms. This will be easier than my approach, but you have to pay for it. 🙄

You are welcome in the world of PW! At the beginning it is always a hazzle to learn how the system works and how you can adapt it to your needs, but in the end it is much more flexible than others CMS 🙂

Hello herr rilke! I have added an additional wrapper for the CAPTCHA input field, so you can style it according to your needs. You have to replace the following 2 files with the one from Github (alternatively you can also download and install a fresh copy from Github). AbstractTextCaptcha.php AbstractImageCaptcha.php Now the following wrapper will be added: <div class="captcha-input-wrapper"> <input id="contact-captcha" name="contact-captcha" type="text" class="input" required=""> </div> As you can see a new wrapper with the class "captcha-input-wrapper" will be added arround the CAPTCHA input field. Hope this helps. Best regards

Glad you get it working 😃!! Every phrase of the module is translatable. You have to do it in the admin area under (setup->languages) or in German (Verwaltung->Sprachen). If you need the German translations, you can use the language pack, that is shipped with this module and you can install all the German translations (for frontend and backend with one click). (look for languages inside your module configuration). Only just to be clear: Do you mean only the input field where you have to add the CAPTCHA value or the whole CAPTCHA (image and input field)?

Ok, before we try to find the cause, please deinstall and install the module again. Sometimes errors occur and disappear during a new install.

Yes the path is correct, because the captcha image must be reachable for public viewing. If the file is not present at this place (for what reason ever) please add it manually to the root (like the index.php). The file will be copied during the installation process of the module to the root directory and will be deleted afterwards from the original place under FrontendForms/Formelements/Captcha/. So this is a usual behavior ;-). After de-installation, the file will be copied back to the original place. So it will be inside the directory again.

Strange! On my side it works without getting an error. Can you please check if the code in the captchaimage.php is exactly the same as the one at Github. Best regards

Hello herr rilke. CSRF is implemented by default using the Processwire CSRF API. Take a look here, so no need to inplement it by your own. Best regards

Not at the moment, but maybe in the future... but I like this idea.

Hello @marie.mdna Glad to hear that you are using the module. 🙂 What you are describing is a security feature (especially for SPAM bots). Refreshing the page does not help, because a session to prevent the form display is active. You have to close all browser windows to delete the session. Afterwards the form will be displayed again. This security feature is enabled by default, but you can disable it if you want. You only have to set the max time value to 0. You will find more information here. You can change the setting inside the module configuration or on per form base inside the template. By default a value of 1 hour is set as max time, but you can set a higher number or 0 to suppress the measurement of the time. Hope this helps! Best regards

Thanks! This is an interesting approach, that I have never used before. This is what I get so far: 0 =>array 'file' => 'C:\xampp\webseite1\wire\modules\Process\ProcessPageView.module:184' 'call' => '$page->render()' 1 =>array 'file' => 'C:\xampp\webseite1\wire\modules\Process\ProcessPageView.module:114' 'call' => 'ProcessPageView $process->renderPage(Page $obj, PagesRequest $obj)' 2 =>array 'file' => 'C:\xampp\webseite1\index.php:55' 'call' => 'ProcessPageView $process->execute([ true ])' 1) returns the string as expected -> OK 2) returns the string as expected -> OK 3) returns the string as expected -> OK Unfortunately, every 3 calls return the HTML code as a string as expected, but thank you for this tip - I will keep this in mind for the future 😃

I only can confirm that $event->return is null inside the addAssets() method, but I cannot find out, where it probably happens earlier. So the $event variable which will be entered as the parameter inside the brackets has null as return parameter. Is there way to find out WHERE the problem could be?

Hello I have discovered a strange issue after running a hook after page render. So this is the hook that I run within the init() method inside a module: public function init(){ // add CSS and JS links to the frontend template $this->addHookAfter('Page::render', $this, 'addAssets'); } protected function addAssets(HookEvent $event):void { $page = $event->object; // don't add this to the admin pages if ($page->template->name === 'admin') { return; } $version = $this->getModuleInfo()['version']; if (!$this->input_removeJS) { $js = '<script src="' . $this->wire('config')->urls->$this . 'frontendforms.js?v=' . $version . '"></script>' . PHP_EOL; $event->return = str_replace('</body>', $js . PHP_EOL . '</body>', $event->return); } if (!$this->input_removeCSS) { $css = '<link rel="stylesheet" type="text/css" href="' . $this->wire('config')->urls->$this . 'frontendforms.css' . '"/>' . PHP_EOL; $event->return = str_replace('</head>', $css . PHP_EOL . '</head>', $event->return); } } This hook method adds a javascript script tag and CSS link tag to the page on the frontend. So far so good. It has worked til now until problems. Now I have added this code to a newly created module, but now it does not work in this case. Take a look what Tracy says: You can see the calls of 2 different modules using the same hook after page render code: The first one is the new module and the second one is from my FrontendForms module. Just to keep in mind: both modules use the same hook and the same hook function to add script and CSS to the frontend. As you can see, the first module returns "null", but should return a string. The second one (the FrontendForms module) returns a string as expected. I cannot see any problems via Tracy, so I have no idea, why this happens. The only difference that I can see is on the id key: 'id' => 'Page:100.3:render' 'id' => 'Page:100.0:render' Does anyone has an idea, what could be the cause, that the first hook returns null instead of a string???? Thanks in advance

Hello @Matze No, not by default, but I have added a new method which counts the times set: getNumberOfTimes() You can use this method to do a check, but you have to update to version 1.2.0. Best regards Jürgen

Version 1.1 out now! This version includes feature requests according to mark-up rendering and a new field configuration to show/hide Holiday. As always, please test it carefully after update and report problems. You will find the full list of changes here: CHANGELOG.md Please read it carefully to see, what is new

Hello @ngrmm I am sorry, but this does not work out of the box, but if you want to display a default image if no image was uploaded, you can do it the way as explained here: https://processwire.com/talk/topic/18761-solved-when-default-field-value-is-an-image-file/?do=findComment&comment=163685 Best regards

Please be patient - I will add surrounding tags for the dayname and the time(s) for that day, so you will be more flexible. The tags will be variable, so you can choose if you want fe dt and dd or div and span or whatever. The other tags (ul and li) should be also flexible, so you could change them to your needs. Every tag should also be disabled by adding false instead of a tag name - thats my plan. Maybe I can bump up the version with the changes today - we will see 😉

Hello @wbmnfktr Thanks for your post! No, not at the moment, but this seems to be a useful feature to implement. I will try to add a new field to the field configuration, where you can choose, if you want to display the holiday field or not.😀 This is where the things starts going complicated - I guess this is not really easy to implement. You have to create a field containing all exceptions. This is not what can be achieved very easily, so I guess this feature will not be realized. Best regards

I guess PHP 8.3 coming out in autumn 😀 I know, but usually you do not enter opening times very often 😉

Ok, I guess I found the issue...... PHP 8.2: The types null and false can now be used standalone. Take a look here https://www.php.net/manual/en/language.types.declarations.php I am running on PHP 8.2 and therefore I got no problems, so removing the return type on GitHub removes this error message on lower PHP versions. So this should work, because null is not standalone.😉 Anyway, I am wondering a little bit that no others discover this issue, because a lot of users are running lower PHP version than 8.2. Best regards Jürgen

Hmmm, what you are describing is the return type (:null). So your PHP version is high enough to understand this. I am not sure, but I guess it was introduced in PHP 7. So it makes no sense, that the parser complains about this. The method itself returns the correct type (null) too, so everything is ok. public function ___getCompatibleFieldtypes(Field $field):null { return null; // returns null as expected } I am pretty sure, that other modules do not conflict with this method, because it will be used in a lot of fieldtypes. What you can try is if it allows ": string|null" instead of ":null" (makes no sense, but only for testing purposes). BTW: I have removed the return type on GitHub, so it will not affect upcoming updates. Jürgen

Hello @Matze First of all, thanks for reporting this issue. No it is not. I have tried to reproduce the issue, but (fortunately) the module works as expected on my site. I have done the complete installation process including creation of the OpeningHours input field and saving some values. The error that will be printed is also a little bit strange, because it comes from a default ProcessWire method and not from a method that I have written. This should be the method which leads to the error according to your provided error message on line 60: /** * @param Field $field * @return null User is not allowed to change this fieldtype to another * User is not allowed to change this fieldtype to another */ public function ___getCompatibleFieldtypes(Field $field):null { return null; } It seems that there was going something wrong during the installation process in this case. Could you please uninstall the module and reinstall it once more. It would be also interesting which PHP version do you use and which ProcessWire installation. Please let me know if a new install solves the problem. It is a little bit strange because no one has complained so far concerning problems during the installation process. Best regards

Important Update 1.2.2 After a long time of beeing online in the forum, the module has now been added to the module directory and will be published probably the upcoming friday. This version differs from the old one, so if you have downloaded and installed this module before, you need to do a complete fresh install. You do not need to wait until it has been published in the module directory for download, you can download it everytime directly from GitHub if you want. IMPORTANT: Please read the instructions in the changelog before you update to this version carefully, otherwise you will run into errors. Due to the numerous changes, the module needs a little more testing by the community. Therefore I have been added the status "Beta" to the module inside the module directory, but it should be stable. As always, please report any issues directly on GitHub. Thanks