Juergen

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!! ?

Ok, thanks @bernhard!! I have not seen that before and my thought was to keep it all inside the FrontendForms folder and not separated all over the site?. So I will add an extra folder beside the templates folder for the custom email templates.

Hello @ all On my FrontendForms module, users can add their own custom email templates inside the "email_templates" folder of the module. The problem is that after updating the module, these files are no longer present (only the ones shipped with the module exist). In other words the custom files get lost. During an update the"old" module directory will be renamed with a dot in the front position (.FrontendForms in this case) and the new version will be downloaded from the module directory. After the update, the module files exist twice: .FrontendForms and FrontendForms directory. The old directory contains the custom templates added by the user, the newly downloaded not. Goal: The custom files should be copied from the old folder to the new one. I have tried to use the upgrade function of the module to copy the files from the old folder to the new one, but this does not work properly, because it only happens if the user clicks the button "Continue to module settings" afterwards. Otherwise the files will not be copied to the new version. This is not working the way that I wanted. Is there someone that has created a module which also allows the user to add custom files to the module and has a working solution how to prevent those files to be gone after an update? BTW: I want to prevent storing the custom files outside the module folder (fe. in site/assets/files) if not absolutely necessary. Any help or idea will be appreciated. Thanks

Hello Martin and welcome!! Thanks for your report. Your custom templates should not be touched during an update. That was not the plan. At the moment there should not exist a method to add a custom folder. I will try to find a solution to keep custom files untouched without using a custom folder. At the moment please always make a backup of your custom template and I will try to add a solution to the next update. Best regards Jürgen

I must correct myself: I have written the wrong syntax for username check. Only the following characters are allowed: So the regex has to be: '^[-_a-z0-9]+$' Take a look at the ProcessProfile.module.

No, but I will take a look, because the implementation seems to be very fast ?

Ok, I have misunderstood the field a little bit ?. I have thought you only want to allow passwords containing the pre-defined words and symbols, so it will be easier for frontend validation to write the regex for. I find the idea great to offer password examples, that can be used or not. Maybe I am thinking of implementing such a feature to my module too. Yes, thats exactly what I have used too. For the username saniziation I have used "pageName" sanitizer instead.