Juergen

Thanks for your quick response @bernhard I compared your example to mine and I see that you are calling the method ($foo->hello()) inside your ready() method. In this case it works on my side too, but this is not the scenario that I want. I want to manipulate the output not inside the ready() but before page render, so the markup of the method should be changed before the page will be rendered. public function ___renderAsterisk(): string { return '<span class="asterisk">*</span>'; } This is a render function, which will be called during the render function of the form and the form will be rendered during the page will be rendered. So I want to change the output of the renderAsterisk() method inside the site/init.php and this does not work at all. wire()->addHookAfter('Label::renderAsterisk', function ($event) { $event->return = ' - hooked aha :)'; }); So this works fine if the renderAsterisk() method will be called inside the ready.php separately. $foo = new Label(); bd($foo->renderAsterisk()); But it does not work if the renderAsterisk() method is included inside another render function (in this case inside the render function of the form. This should be the issue of the problem. To simplify: It works if the renderAsterisk() method will be called directly, but not if this method is included within another method and will be called there.

Hello @bernhard This is interesting, but in my case the hook does not get fired. It seems that that it will be ignored. The function is hookable by prefixing 3 underscores: public function ___renderAsterisk(): string { return '<span class="asterisk">*</span>'; } The class 'Label' itself (where the function above is part of) is derived from the Wire class (take a look here on the top parent class), so hooks must be implemented and should work. Only to mention: the top parent class called 'Tag' is an abstract class - could this have an impact on the issue? Do you have a working example in one of your numerous modules, where you use a hook inside the init.php to hook a method in one of your modules?

Hello @PWaddict I guess this is a namespace related problem, but I have not found a solution to this issue. Therefore I have written a blog post in the forum in the hope others could help. Best regards

Hello @all I have tried to apply a hook to a class of a module of my mine which runs inside a namespace. The hook is included inside the site/init.php. $this->wire()->addHookAfter('Label::renderAsterisk', function(HookEvent $event) { bd('render Asterisk'); }); This hook runs on the function renderAsterisk() which is hookable and part of the class "Label" (original File: Label.php). This class descends from Wire so hooks should work inside this class, but I guess the main problem is that this class runs inside its own namespace called "FrontendForms". So I tried different versions within the hook to define the class: FrontendForms\Label::renderAsterisk \FrontendForms\Label::renderAsterisk \\FrontendForms\Label::renderAsterisk FrontendForms\\Label::renderAsterisk None of the versions above work! After a search on the internet, I found a discussion about this problem here. It seems that other people have also stumbled upon this problem. My question: Has anyone already struggled with the same problem and found a solution on how to get hooks to work on classes with namespaces, or could there be another cause responsible for this behavior? Additional info: This issue comes from my FrontendForms module and I've used hooks in the past to manipulate the output a bit (look here). The hooks have worked in the past, but it seems that they don't work anymore in PW version 3. Thanks for your help!

Hello @PWaddict I can remember that someone has posted the same problem in the past. I will take a look at this issue tomorrow, but as I can remember the Hook problem was a PW problem and not a FrontendForms problem. Please be patient! I will try to trace the problem to its source Best regards

Hello @MarkE Thank you for reporting this issue on sites with many pages (and providing a solution). My websites don't have many pages, so I've never encountered such an issue. 😉 I've integrated your fix into the latest version (1.3.15), so the issue should be fixed by now. According to your suggestion to make the "move" of a child page optional, I will take a look at it in the near future. Thanks Jürgen

FrontendLoginRegister module is updated now (Version 1.3.6) The following last 2 issues have been fixed now: Support for usage of multilanguage fields inside user template added New configuration field to make the "Request deletion of user account page" public viewable added Screenshot of the new configuration field to change the access of the user account deletion page: In the middle you can see the "Allow public deletion of a user account" checkbox. If you check this checkbox, the deletion page will be public reachable. For more information check the changelog.md. Please keep in mind! This module is Beta stage, so it is not recommended to update live sites without testing it locally before! I have tested various scenarious, but I cannot test all possible cases - so happy testing 😉 As always, please report any issues here or on GitHub.

The following issues should be solved now: The position of the privacy check is now always at the bottom, regardless of the use of a CAPTCHA (bug fixed) New configuration field to select whether to use an internal or external page for the privacy policy added. This configuration supports multilingualism, which means you can select a different page for each language. These issues have been fixed in the FrontenForms module and not in the FrontendLoginRegister module. This means that you will need to update the FrontendForms module to the latest version 2.2.27 to fix these issues. The other problems (public deletion link, multilanguage user fields) directly affect the FrontendLoginRegister module and must be solved there. I will try to solve these issues in the next time. You can read the full documentation of changes in the changelog.md. Hope it works now as expected without problems!!

I will add an additional configuration field in the backend, where you can select if you want to use an internal page or enter the link to an external page for linking to the privacy page.

I will take a closer look on the weekend.

Ok, I see - There is an additional check if user is guest inside the DeleteRequestPage.php on line 35 // if user is guest -> not allowed to be here -> let's redirect to the homepage $this->redirectToHomepage(true); If you comment this out, it should work. I will add a new setting in the backend config, where you can choose if the page should be public reachable or not. For now, commenting out this code line should help you.

Hello @Frank Vèssia Thanks for your questions. I will try to answere them 😉 1) The translations should be still there... maybe you have not installed the files of this module??? The translations for the button texts are inside each template file for each page of the module. Take a look here: The files are for example for the DeleteAccountPage.php, DeleteRequestPage.php and so on. This files include the texts for the submit buttons. If these translation files are not present inside your installation, then you have not installed it. To install it, please click on the "Find files to translate" button and select all files of this module. Afterwards the translation files must be visible inside the language files. 2) This should not happen. I will check this if no Captcha is enabled. Link to an external page is a good idea for a feature request. I will add this feature to the module in the future. 🙂 At the moment it is not possible. 3) Only fields that can be edited by the user will be displayed in the select. If you do not have enabled it inside the user template, the custom user fields will not be displayed. So please check if you have toggled the checkbox next to the field inside the user template. In this example I have added the field "Age", which is an integer field. As you can see the custom field age is checked and now it can be selected inside the select too. 4) You can make the page public by changing the visibility inside the template for the deletion link. The templates name is "fl_deleterequestpage". So please go to "templates" select the template with the name ""fl_deleterequestpage" and change the access level to public by checking "guest" instead of "registered". Hope this helps!!

Version 2.2.21 comes with an UI upgrade! The new version has no additional new features, but a UI upgrade for better userfriendly selection of the global email template. As you can see, the old select input field has been replaced by a stylish image picker select. Now you can see how the template looks like. This is realized via a Jquery image picker script and thumbnails of each template. The templates you will see above are the default email templates shipped with this module. If you have created your own custom template, you can also display it here. You will find more information inside the changelog file.

Version 1.3.6 comes with 2 new features: New configuration field to limit the filesize of uploaded files globally Save mails as pages too (user request by @Flashmaster82 in the forum here You can read more about the new features here in the changelogs. Please test it carefully before using it on live sites and have fun! 🙂

Hello @bernhard I have tested your module and it works very well!! Unfortunately it does not exactly what I want, because it imports json files. What I need is to get all language files of a module as csv, not json. The reason for this is that the language files of a module should be shipped as csv files inside the languages folder, so they could be imported by the user. So I am looking for an easy to use solution to get all all language files of a module as csv files. Then I use the command line interface to copy all these files into one. At the moment PW only supports the download of each csv file separately, which is very time-consuming. It would be great if there would be a possibiltiy to select if the language files should be imported as json or csv. This is only an idea for a request - I know you are very busy and if you do not agree with me, it is ok. Wish you nice weekend and thank you for all your work you have done till now for the community! Best regards Jürgen

Hello @DrewPH I have added your request to the new version 2.2.18. Now you can find a new text field inside the module configuration under the AJAX tab, where you can change the info text for the user during an AJAX request. If you enter a custom text into this field, then this text will be displayed globally on each form on the site. In addition I have added a new method too, where you can change the text on per form base, which means that you can use a different text on each form (if needed). I guess this is a use case, that will not be needed very often, but if so.....you can. This new method is called setAjaxMessage() and has to be used with the form object: $form->setAjaxMessage('This is my custom submission text'); This method overwrites the default or global text on per form base. BTW, I have discovered 2 other JavaScript problems beside the problem you have described during the development of this new feature and I have fixed these problems too. You will find the complete description of all changes inside the changelog of this version. As always, please keep an eye if everything works as expected after the update!! Best regards Jürgen

Hello @DrewPH Thanks for you issue report and your suggestion for a new feature!! I have fixed the JS error. Please replace the JS file with the new one on GitHub (https://github.com/juergenweb/FrontendForms/blob/main/frontendforms.js) and let me know if the error is gone now. Your suggestion to be able to customize the info message during an Ajax request: I will take a look to add a new configuration field in the backend to change the message text to your needs. BTW, it is not really hard coded - it is a translatable string, so you can change it in the backend to your needs if you have the language option installed in PW. But I will take a look to make it possible to change it independently. Best regards Jürgen

Hello @DrewPH Thanks for reporting this issue and you are absolutely right. I have changed all class names (not only the "block" class name) of the CAPTCHA element by adding the prefix "ffm" to all classes. Now it should be very unlikely to get class names conflicts in the future. So please update to the latest version 2.2.17 in order to get all changes. You can read the full changelog here. Important information to all other users: If you have modified the styling of the Slider Captcha by adding your own CSS by overwriting the default CSS, please take care that the class names have been changed now and your changes will no longer affect the the styling of the CAPTCHA. So please adapt your custom CSS with the new class names.

Thank you @bernhard for your work!!!! This sounds very useful and I will try it out in the next time.

Thanks for reporting this issue!! 😃 I have fixed this bug yesterday, but I have not bumped up the module version, because I am optimizing the code at the moment. So please replace the current file on Github with yours and everything should be fine. Best regards

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!