Juergen

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

Important information on updating to 1.5.2 I have changed the storage folder for custom uploaded fonts, so it will be outside of the module folder. The reason is, that your custom fonts will be deleted during an update if they are stored inside the module folder. This should not be happen and was not the plan. The new version fixes this problem and your uploaded fonts will now be stored inside a newly created folder (site/assets/files/JkImagePlaceholder). This folder will be created automatically during the update to 1.5.2 or on a fresh install. Please note: During this update all previously uploaded custom files will be deleted. So before you update to the next version, save your custom font files somewhere on your system and upload them once more after you have finished the update. This is only necessary during the update to 1.5.2. All other upcoming updates will not be affected. To prevent problems, the best way would be to delete the module completely and make a new re-install. Sorry for this inconvenience!

Hello @ryan Your update works ?! Thanks!!!

Ok, this is strange, because the deprecated version works and the current not ?. Thanks for the additional info - I will leave this thread open.

Yes, it does!!! But I swear, it has worked in the past with saveConfig!! Anyway, problem solved!! Thank you so much!!

Today I have discovered a strange behavior: On the latest dev version of ProcessWire my Modules::saveConfig Hooks does not fire anymore. This hook should fire after a module configuration has been saved. I got no entry inside the error logs and testing it with Tracy does not give me any information. The hook runs inside the init function inside a module: public function init():void { $this->wire->addHookAfter('Modules::saveConfig', function(HookEvent $event) { $event->message("You saved the module config"); }); } The method above is only for testing purposes, but it outputs nothing if I hit the save button of the module configuration (BTW: I have tested it with addHookBefore and addHookAfter and also with Tracy bd() calls). I am not sure that this issue is since the ProcessWire 3.0.219 but I have discovered the issue there and this hook has worked in the past. Does someone discover the same issue or has an idea, what a possible reason could be? Thanks in advance

New version 2.1.41 This version comes with 2 minor updates: - To prevent warning of depreciated dynamically declared properties if you are running PHP 8.2, 2 properties inside AbstractImageCaptcha.php will be re-written to static properties. - The second change improves the UI inside the fieldset for the "Statistics of blocked visitors": The statistic of blocked visitiors will only be created if logging of failed attempts is enabled. By default this is turned off, so the user sees the following message inside this fieldset. This only informs the user that there are no entries inside the log files of the failed attempts, but it does not inform the user that logging is disabled by default. If logging of failed attempts is never enabled, you will always get this message and no entries/statistics. To make this more clearer for the user, I have decided to add an additional message, which informs the user, that logging of failed attempts is not enabled. At the bottom you will find a link ('Go to the settings to enable logging of failed attempts'). If you click on that link, the appropriate fieldset for changing the settings for logging failed attempts will be openend automatically and you can make your changes. This will be done via the help of a little JavaScript. So this is just a minor improvement, but it is more userfriendly than before, because it helps the user to take the necessary steps to enable logging.

Hello @Martin M Thanks for another issue report - this will help me a lot to make this module more stable! ? I have bumped up the version to 2.1.40 and this version includes an additional check for templates inside the custom template folder. It first checks if the given template exists inside the default folder. If not then it checks for the template inside the custom folder and if the template is not found there it will throw an exception. But you were right, there was a missing link to the custom folder inside the function the loads the template.? This is what I cannot reproduce, because I have included a check before if the mail template exists and if not it should thrown an exception. In my case this check works and outputs the error message and the email will not be sent. Anyway, I have made an additional check inside the form.php. You can take a look at the changes here. Please download the latest version and let me know if it solves the problem in your case. Best regards Jürgen

New version 2.1.39 According to the issue reported by @Martin M there was a problem using custom email templates, which were deleted during the update. This problem is now solved. Custom templates can be added to a new folder called "frontendforms-custom-templates" which will be created in "site/frontendforms-custom-templates/" Important: People who are updating (not on a fresh install) have to do the following to create the new folder for the custom templates: Please read the full changelog here.

Ok, now it is much clearer to me - new thing learned!! ?