Juergen

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.

Inspired by this topic, I have created my own solution: Creating dynamically a regex using positive look aheads. On my FrontendForms module I offer HTML5 browser validation beside the server side validation. Til now, it was not possible to validate the requirements of a password field by the browser, because I have not implemented a regex solution to this. Now I have created a method (function) to create a regex dynamically depending on the settings of the password requirements in the backend. The password field offers following options for the requirements: 0 => 'letter' // letter 1 => 'lower' // lowercase letter 2 => 'upper' // uppercase letter 3 => 'digit' // number 4 => 'other' // punctuation, symbol 4 => 'none' Starting form this array I have written the following method, which outputs a regex that can be used with the HTML5 pattern attribute to validate the password syntax. /** * Method to generate a regex for the password validation depending on the settings of the password field * @return string|null - returns the regex for usage in HTML5 validation attribute or null if requirements are set * to "none" in the backend * @throws WireException * @throws WirePermissionException */ public function createPasswordRegex(): string|null { // get the password field module $passwordModule = $this->wire('modules')->get('InputfieldPassword'); // get the password field module // get the password field by the name of the field inside the user template, usually "pass" $passwordField = $this->wire('fields')->get('pass'); // get the default requirements of the password module as stored inside the DB $requirements = $passwordModule->requirements; // password conditions can be overwritten on per field base, so check before if they are overwritten. Otherwise take the default from the module if (!$passwordField->requirements) { // if no requirements are stored in the database, take the default data from the inputfield default configuration $requirements = $passwordModule->requirements; } else { $requirements = $passwordField->requirements; } if(!in_array('none', $requirements)){ // create array of positive look ahead for all options of the password as defined in the backend $regex_requirements = [ 'letter' => '(?=.*[A-Za-z])', // at least 1 letter (upper and lowercase) 'lower' => '(?=.*[a-z])', // at least 1 lower case letter 'upper' => '(?=.*[A-Z])', // at least 1 upper case letter 'digit' => '(?=.*\d)', // at least 1 number 'other' => '(?=.*\W)' // at least 1 non-word character ]; $regex_parameters = []; foreach($regex_requirements as $key => $look_ahead){ if(in_array($key, $requirements)){ $regex_parameters[$key] = $look_ahead; } } // get the default min length value as set in the input field if present if($passwordField->minlength){ $length = (string)$passwordField->minlength; } else { // get the default value from the module $length = (string)$passwordModule->minlength; } // Concatenate all look ahead to working regex string and return it return implode('',$regex_parameters).'.{'.$length.',}$'; } return null; } Now I will show you some examples with different settings - please take a closer look at the pattern attribute. Just to mention: the min length of the password (in this case 5), will also be taken from the password settings. Example 1: only letters <input id="validators-required" name="validators-required" type="text" class="input" required="" pattern="(?=.*[A-Za-z]).{5,}$"> Example 2: letters with at least 1 uppercase letter <input id="validators-required" name="validators-required" type="text" class="input" required="" pattern="(?=.*[A-Za-z])(?=.*[A-Z]).{5,}$"> Example 3: letter, digits and symbols <input id="validators-required" name="validators-required" type="text" class="input" required="" pattern="(?=.*[A-Za-z])(?=.*\d)(?=.*\W).{5,}$"> Example 4: upper and lower case letters <input id="validators-required" name="validators-required" type="text" class="input" required="" pattern="(?=.*[a-z])(?=.*[A-Z]).{5,}$"> As you can see the pattern differs depending on the settings of the password field in the backend. Of course, this method needs a little bit more testing, but it works on every case that I have tested. The only parameter, that will not be taken into account is the complexity factor, but this could be solved with another Javascript function if necessary. Maybe this method helps or inspires others solving this issue. BTW: After testing, this method will be a added to the next version of my FrontendForms module😀

Very good work @bernhard!!! I think the number of possibilities is enough! I have never thought about this, but it is logical, because no validation takes place. I have always used the same requirements on the frontend as in backend for consistency. What comes into my mind by using pre-defined passwords is, that I do not have experience about the acceptance for choosing a given password instead of your own. Personally I prefer creating my own password. From the point of security I guess it is a very good technique, because a lot of people tend to use the same password in different accounts and these randomly created passwords are passwords that probably no human would think of. Do you think of to create a regex which only allows the letters which are used for the four words in combination with the separators or what is your plan to validate the password?

Thanks @kongondo You are right, I have overread this 🤪 - it was Sunday morning!! Maybe the regex for the username could be used with Javascript too. The validation of the password is not so easy in this case but you can use the password requirements as posted above, put them inside a Javascript variable and check them against multiple if conditions. This is what comes into my mind. Something like this: if(contains letters){ if(contains number){ if(contains symbols { .... } else { return false; } else { return false; } else { return false; }

Hello @bernhard I have created these validators for my FrontendForms module, maybe this can help you to create your own validations. Check username syntax This is the regex that I use: $regex = '/[a-z\d\-_.@]$/'; It contains all the allowed characters. I guess all allowed characters are listed somewhere inside a file of PW or in the API docs. I have found them somewhere, but I cannot remember where 🤪 You will find the code of my validation here. Check password syntax The password is a little bit more elaborate, because you can set the characters that can be used by yourself. This is the code, that I use: $value = $_POST['yourpasswordfield']; // the post value of your password field on the frontend // get the password field module $passwordModule = $this->wire('modules')->get('InputfieldPassword'); // get the password field module // get the password field by the name of the field inside the user template, usually "pass" $passwordField = $this->wire('fields')->get('nameofyourpasswordfield'); // get the default requirements of the password module as stored inside the DB $requirements = $passwordModule->requirements; // password conditions can be overwritten on per field base, so check before if they are overwritten. Otherwise take the default from the module if (!$passwordField->requirements) { // if no requirements are stored in the database, take the default data from the inputfield default configuration $requirements = $passwordModule->requirements; } else { $requirements = $passwordField->requirements; } // set the requirements for the validation on the next line, so you can be sure that you take the correct requirements $passwordModule->set('requirements', $requirements); // Now check the password if the syntax fits the requirements return $passwordModule->isValidPassword($value); // returns true or false You will find the code of my validator here. As you can see, I take methods from the ProcessWire password module class to validate the password. I hope this helps you to solve your issues. Maybe you will find a better solution and I adapt my codes to your changes too. Have a nice Sunday!!

Version 2.1.38: This version now supports HTML5 validation for the 4 new validators added in 2.1.37 by using Javascript. It works by adding min and/or max attribute on the fly to the appropriate input field, if a value has been changed inside the reference field. Please read the full changelog here for more detailed information.

Hello @Andy Please update to FrontendForms 2.1.37 I have added 4 new validation rules for dates: dateBeforeField validator: Checks if a date is before a date entered in another field inside the form dateAfterField validator: Checks if a date is after a date entered in another field inside the form dateWithinDaysRange validator: Checks if a date is within a given time range in days depending on a date entered inside another field inside the form. Fe date must be in a time range of 7 days in the future starting from a date entered inside another form field. Example of time range: start date: 2023-05-15, timerange: 2023-05-15 - 2023-05-22. Value must be inside this time range. Supports a positive (future) and negative (past) days value. dateOutsideOfDaysRange validator: Checks if a date is outside a given time range in days depending on a date entered inside another field inside the form. Fe date must after the end of a time range of 7 days starting from a date entered inside another form field. Example of time range: start date: 2023-05-15, forbidden timerange: 2023-05-15 - 2023-05-22. Value must be outside this time range -> after 2023-05-22. Supports a positive (future) and negative (past) days value. You will find the explanations on how to use here: https://github.com/juergenweb/FrontendForms/tree/main#datebeforefield The complete examples on how to use them on inputfields can be found inside the examples folder: https://github.com/juergenweb/FrontendForms/blob/main/Examples/field-validation.php#L221 This is full PHP validation - no JS or JQuery. Just to mention: HTML 5 validation does not work for these validation rules. HTML5 validation have to implemented via JS - maybe I will add this in the future, but not for now. Just take a look if this solves your problem. Best regards

Hello @Andy Thanks for your input on date fields. To be honest, I have not focused on date fields, because I did not use them a lot, but you have inspired me to enhance them. At the moment, only these 4 date validations can be performed: date - Field is a valid date dateFormat - Field is a valid date in the given format dateBefore - Field is a valid date and is before the given date dateAfter - Field is a valid date and is after the given date You will find examples of these validations at https://github.com/juergenweb/FrontendForms/blob/main/Examples/field-validation.php#L210 I will take a look of what can be implemented of your suggestions. To sum it up once more.: You will need to set a time range on a date field, where dates in between are allowed, others are forbidden You will need a validator, that checks if the date entered in a second date field, is inside a specific time range depending on the date entered inside the first field To the first point, I guess I can write a new method, so you will be able to set the range ( fe $field->setRange('15-05-23', '15-06-23')) or something like this, where first parameter ist the start and the second parameter, the end point of the time range. To the first point: you can set a time range with dateBefore and dateAfter validators: $inputDate = new \FrontendForms\InputDate('date'); $inputDate->setLabel('Input Date'); // add the time range between 01-05-2023 and 30-06-2023 $inputDate->setRule('dateAfter','2023-04-30'); $inputDate->setRule('dateBefore', '2023-07-01'); $form->add($inputDate); For the second issue I guess I have to write a new custom validator, which takes care of the date in the first field. I will take a look what I can do :-)

No other issues have been reported till now and I have tested the module once more and have fixed some problems. Now the module works as expected in my case without problems. Today I have added the module to the module directory - please download it from there after it has been published. Thanks!

Version 1.2.3 is ready! PLEASE DEINSTALL THE OLD VERSION OF FRONTENDLOGINEGISTER AND UPGRADE FRONTENDFORMS TO THE LATEST VERSION BEFORE, BECAUSE THERE ARE A LOT OF CHANGES AND NEW FEATURES!! OTHERWISE YOU WILL GET ERRORS! Beside fixing a lot of bugs, this new version supports upload for an user image too. Supported Fieldtypes for images are FieldtypeImage and FieldtypeCroppableImage3. Please note: You can only use ProcessWire image fields with single upload - multi-upload fields will be ignored and cannot be selected. So if you want to use an existing image field or you need to create a new one, take care to set the image upload only to 1 single file. After you have added this field to the user template, you can select this field inside the module configuration and add it to the profile form and/or to the registration form. Take also care that this field is editable by the user, otherwise it will also not be selectable. Just to mention: Technically you can add as many image fields as you want to these 2 forms, but it would not make sense, because each user needs only one image. But if you want.... you can. There were a lot of changements taken, so please let me know if you discover issues. Best regards

Hello I have also tried to implement this solution to one of my modules, but I cannot get it to work and there are some questions open: Should I create this file manually and store it inside the module folder? I have tried this, but I cannot point the update url to this file by changing the config values as pointed out in this post: I have replaced "http://domain.tld/" with my GitHub account url "https://github.com/juergenweb/" but this points not to my manually created json file. It leads to "https://github.com/juergenweb/nameOfMyModule/?apikey=pw300" and not to "https://github.com/juergenweb/nameOfMyModule/myupdatefile.json". So the "?apikey=pw300" will not be resolved to point to the json file. Is there a special naming convention for this json file, if it should be created manually? Is this important to change too? Can someone give me an example of how I should do it by using a module located on a GitHub account?