Juergen

Hello @Cybermano Thanks for the hint. I have fixed this. There was a writing mistake of the dateformat (d-m-Y instead of d-M-Y). If you have the module installed, you need to change it manually at the configuration of the "jk_publish_until" inputfield - if you install the module once more, it will be correctly set during the creation of the field (recommended). No, you are not wrong. The page will be moved to a new position and the new status is published (not unpublished). This is a little bit confusing I know, but I guess it would not make sense if you move the page to a new position and leave it unpublished. You can think of moving a page at a certain date to the archive - it would not make sense, if the page is in the archive, but not published. That is the idea behind it. I am not really happy at the moment with the module, because some code is too complex and probably needs a workover. Anyway, you can fork it and maybe you can add new features or simplify the code. Best regards

Hello @Cybermano I have published it again, with a fix for multilanguage sites, but it will take some time until the module will appear in the module directory again. In the meantime you can download it directly from GitHub. As fas as I know, an action on a parent page will have an effect on all childpages. Fe if the parent page will be unpublished, all child pages will be unpublished too. For example moving pages to another place. If you move the parent page to directory A, then all child pages will be also moved to directory A. But it is not possible to select between different templates of childpages. You cannot move child pages with template 1 to directory A and leave child pages with template 2 untouched. Sorry! It is also not possible to leave the parent page as it is and only move/trash/unpublish,.. child pages.

Hi @Cybermano Yes, you are right. I have discovered some problems by using the module on a multilanguage site, so I have decided to unpublish the module now in the module directory, because I have not the time at the moment to make it more stable and to work properly. Maybe someday I will publish it again, but for now I cannot recommend you to use this module. Best regards Jürgen

Version 2.2.15 is out! This update comes with a small performance upgrade. Now you can choose on which pages you want to embed the JS and CSS files of the FrontendForms module. This means that you can prevent the files from loading on pages that do not contain a form. This also allows these pages to load faster This version includes a new configuration field in the backend where you can select all the pages where you want the files to be embedded. Best regards

Version 2.2.14 is out! This new version comes with a new CAPTCHA type: a slider captcha. Now FrontendForms supports 7(!) different CAPTCHA types and I guess this will be the last one. There is a fabulous module in the module directory which also creates a slider captcha that can be used with other forms: Slide Captcha. But the slider Captcha in FrontendForms is an extra coded and integrated captcha, that has nothing to do with this module. To be clear: The slider captcha inside FrontendForms is similiar to the Slide Captcha module, but it has nothing to do with it. So there is no need to install the other module. The only thing you have to do is to enable the slider captcha in the module configuration - that is all. You have 1 additional configuration field where you can select the accuracy of the puzzle piece to the goal. 5 means that the distance of the puzzle pieces to the target must be less than or equal to 5px in order to solve the captcha correctly. Here you can see the new slider captcha in action: As always, please report any bugs on Github!

Version 2.2.13 comes with an upgrade for the FrontendFormsManager module. The FrontendFormsManager module shipped with FrontendForms was added a few versions ago. The usage of this module is optional. This module now also supports the management of suspicious IP addresses. These are IPs that have been temporarily banned due to many unsuccessful form submission attempts (logging must be enabled in this case). A new section for managing these IP has been added. As you can see, a table of statistical data and a chart have been added to the FrontendFormsManager. When you click on the "Go to all temporarily blocked IPs" button, you will be redirected to a new page that contains all the temporarily banned IPs. The data is taken from a log file. Below you will see a screenshot of this page. Inside this table you have a button to view more details about this IP and a button to add/remove this IP to/from the blacklist. If you click the "View details about this IP" button a panel will be opened with more information about the IP and the number of blockings. With this information, you can now decide whether you want to block this IP permanently by adding it to the blacklist or not. Happy testing!

Thanks @BitPoet I have never heard about this config settings property, but I will give it a try.? It happens only on a testing site, so I have changed the site from multilanguage to single language and then the error was gone. So the problem is only on a multilanguage installation in my case.

Hello @all I am struggeling with the following error message, which appears after the first install of a module on a brand new PW installation by viewing log files: Short description: After a fresh install of PW-dev 3.0.240 (latest dev version) on a server running PHP 8.3 and MySql 8.0 everything works fine if I go to the log files. I can view the log files for errors, exceptions, modules,... without problems. After I install my first module (in my case I have installed the ProcessDatabaseBackups module from Ryan) this error message will be thrown if I want to view a log file. To be clear again: This error message will be thrown if I want to view a log file in the backend AFTER I have installed a module. Before the first install of a module everything works fine. On my localhost running on PHP 8.2 there is no problem. Could this be a PHP 8.3 problem? Does anyone struggle with the same problem? I have found some older posts of a similar problem in the forum, but none of them helps me to solve this problem. Maybe someone can point me into the right direction, what the problem could be, because the error message does not help me to find the cause for this error. Edit: Ok, it seems that this is a MySQL safety rule on shared hosts, but is there a possibility to change this like inside a php.ini for PHP? Thanks in advance

Thanks @Andy I have added your site to the live examples. ?

Thank you @Andy If you have a live site online with FrontendForms, you can give me a link to your site and I will add it to the "Live examples" section of the readme file. This is a brand new section so there are only 2 examples there at the moment, but I will add more examples over the time. In this case you get a backlink for free to your site, but I will point it to the page where the form is included.

Hello @Andy I have seen this CAPTCHA and it looks good. I have to test it first to see how it works and if and how it could be implemented into FrontendForms. But this is not on top of my priority list. At the moment I am working on an upgrade of the FrontendFormsManager to implement an UI for blocked IPs. Currently this will be handled inside the module config, but I want a better UI outside of the module config. This should help site owners to identifiy and block suspicious IP addresses, so I am working on to include this inside the FrontendFormsManager. But I will keep the new CAPTCHA on my list ?. Best regards

Version 2.2.11 contains a new feature: Use FrontendForms inside CKEditor fields This new feature allows you to load forms inside CKEditor fields via the usage of placeholders. It supports the loading of the same form multiple times in one or more fields. Short description: Use placeholders like {{myform}} inside your CKEditor field. The placeholders will be replaced with forms during the page render process on the frontend. A more detailed description about how it works and containing a code example can be found inside the docs. This is a brandnew addition, so test it carefully before using it on live sites. Jürgen

I would like to see SEO support integrated into PW by default. I know that there is the SEO Maestro module, which is fabulous, but I think every CMS should have a good SEO support by default. So it would be great if a new tab will be added to the pages like this: In addition to this, there should be a new property inside the configuration file to disable/enable the tab globally in the way like this. $config->seo = false; // or true And in the settings of the page, there could be a checkbox to enable/disable the SEO tab per page. The content of the SEO tab could be as it is in the SEO Maestro module.

Hello @dotnetic Version 2.2.10 contains your feature request. Read more about it in the changelog.md. Jürgen

Hello @dotnetic It is possible to store the file everywhere as long as the permission for this directory allows it. I can add the possibility to choose a custom directory, lets say a text input where you can add the path to your prefered directory. As the default directory path 'site/assets/files/FrontendForms/frameworks' will be set and you can overwrite it with your path. I'll inform you, if the update is ready ?

Hello @dotnetic Could you please update FF to 2.2.9. The bug should be gone now. Best regards Jürgen

Hello @dotnetic This is weired, because I do not have changed something like that ?. I will check this and try to add a fix today. Thanks for reporting this issue. Jürgen

Hello @marie.mdna I hope I have fixed the problem now ?. For testing purposes I have added the profile form inside segment 2 so it was reachable under /profile/segment1/segment2. After form submission it redirects successfully to the same url (on success and error) - so everthing works fine. I have tested it on a single and a multi-language site and with/without Ajax. On my local installation it works as expected. So please update FrontendForms to 2.2.8 and FrontendLoginRegister to 1.3.4 and let me know if it works for you now. Best regards

Hello @marie.mdna You are right, it does not work inside url segments. The failure is inside the form action attribute and/or the redirects which does not recognize the segments after the url, so every redirect leads to the base url instead of the base url including the segments. I try to fix this now!

Hello @marie.mdna It seems that there is an Ajax problem in the JS file. As far as I can see, you have an older version installed (2.2.2). Please update FrontendForms and FrontendLoginRegister to the latest version, but I recommend you to make a backup first (just for the case) and try it again. I can remember that I have also updated the JS file since 2.2.2. Please give me a short info, if the problem persists after the update. Glad to hear that you like it ?!

Hello @marie.mdna Just to clearify: It happens not on pages created by the FrontendLoginRegister module, but it happens on pages that you have created for the user profile. The template of this pages allows url segments and a form which is on such a page cannot get submitted. In other words if a form is on a page which contains an url segment, than the form cannot be submitted successfully. What means "not successfully" exactly in this case? Does the form output error messages, or is there a PHP error. Please specify the problem a little bit more precious. Thanks

@HMCB I guess the new feature is exactly what you are looking for ? Every rule that has been added to an inputfield is only active if the field is visible. If the field is hidden every rule added to this field is disabled. For example: You have an input field that is hidden by default and you have added the required rule. As long as the field is hidden, the required rule is inactive. If the field is visible, than the required rule will be checked during the form validation.

Version 2.2.5 is out! It includes 2 bug fixes and 1 new feature: Inputfield dependencies! Most of you will know Inputfield dependencies from the ProcessWire backend. This is the same feature for FrontendForms, but it relies on a different code than the one used in the backend. I have found an interesting script on Github written by Ali Khallad and I have implemented it into FrontendForms. If you are interested in: Here is the the code on Github. Short description of Inputfield dependencies: Let's say you have two fields in your form: a number input field (field 1) and a text input field (field 2). Field 2 should only be visible if the value "1" is selected inside field 1. Otherwise, field 2 should be hidden. The input field dependencies allow you to add the condition directly to field 2 without having to write a line of JavaScript. $field2->showIf([ 'name' => 'field1', 'operator' => 'is', 'value' => '1' ]); Here is an example in action: I have written a very detailed documentation and added a lot of examples. You will find all about the new feature here. As always: This is a brandnew feature, so keep an eye if everything works as expected. Report issues or suggestions here or directly on Github. Before using it on live sites make a backup.? Jürgen

Hello @marie.mdna Here is the code that should make what you want: $form = new \FrontendForms\Form('myform'); $form->setSuccessMsg('<div class="success"><h2>Everything is fine</h2></div>'); // some more inputs ...... $file = new \FrontendForms\InputFile('fileupload'); $file->showClearLink(true); // show an link to empty the input field under the input field $file->setLabel($page->p_title); $file->setDescription('<span>'.$page->p_upload_label.'</span>')->setPosition('beforeLabel'); // $file->setNotes('Description fileupload notes'); $file->setRule('allowedFileSize', '60KB'); // you can use the unit, if you want $file->setRule('allowedFileExt', ['jpg','png']); $file->setRule('uniqueFilenameInDir', true); $file->setSanitizer('pageName'); // set sanitizer $form->add($file); $button = new \FrontendForms\Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if ($form->isValid()) { // save the content as page $p = new Page(); $p->template = $form->getValue('newPage'); $p->parent = wire('pages')->get('template=parent'); $p->title = $form->getValue('title'); if($p->save()){ $destPath = wire('config')->paths->assets.'files/'.$p->id; // the path to the destination directory foreach($form->getUploadedFiles() as $file){ wire('files')->copy($file, $destPath);// copy the file to the new folder wire('files')->unlink($file);// remove the file from the old folder } } } echo $form->render(); A little bit information about the code: First of all, add the sanitizer "pageName" to the file input field instead inside the foreach loop You can set the max filesize now using units (so instead of writing allowedFileSize('60000'), you can write allowedFileSize(60KB) which is more handy I think. This is relatively new and I have added it a few versions before - but it is not wrong if you enter the value in Bytes ?. To get all uploaded files use the getUploadedFiles() method, which outputs only the file paths of the currently uploaded files. You can use the file paths for the next steps to move the files to another directory The copy and unlink methods are PW methods and they are the best way to move files to another directory. Hope this helps!

This is a good idea for an addition, but you have to keep in mind that it would probably not work for all frameworks. The problem is that not every framework has the same markup structure for inputfields. As an example would be the difference between UIKit and Boostrap: There are slightly differences in the markup, especially on checkboxes. Only changing the classnames does not work in this case. The markup rendered has to be changed too. That is the reason, why I have written the code to be able to use different render functions depending on the framework set. That is right, but do you know that you are able to change the classnames directly inside the module configuration, so the classnames will be stored inside the database? In this case the classnames will not be overwritten during an update. The main disadvantage is that you cannot use it on another installation. You will find it under "Markup and styling/Settings for markup and styling/Own CSS classes Best regards