Juergen

Hello @PWaddict You are absolutely right - the position change will not taken into account. I have fixed this now. Please replace the following file: https://github.com/juergenweb/FrontendForms/blob/main/Formelements/Inputelements/Inputfields.php After that the position change should work, but please give me a feedback if everything works now as expected. After that I will bump up the version of FrontendForms. To get the desired markup, you have to do something like this: $form = new \FrontendForms\Form('inputfieldtest'); $form->setMinTime(0); $form->setMaxTime(0); $form->setMaxAttempts(0); $form->setErrorMsg('Ouups! There are some errors.'); $form->setSuccessMsg('Congratulation! There are no errors.'); $form->appendLabelOnCheckboxes(true); // set it here to true or in the backend config // add checkbox $checkbox = new \FrontendForms\InputCheckbox("checkbox"); $checkbox->setLabel("Checkbox Label"); $checkbox->getFieldWrapper()->setAttribute('class', 'uk-grid-small'); $checkbox->prepend('<div class="uk-width-auto">'); // add div before the input $checkbox->append('</div>'); // add closing div after the input $checkbox->getLabel()->removeAttribute('class')->wrap()->setAttribute('class', 'uk-width-expand'); // wrap the label element $form->add($checkbox); $button = new \FrontendForms\Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if($form->isValid()){ print_r($form->getValues()); // do what you want } // render the form echo $form->render(); Take a look at the checkbox element. I have done some manipulations to add some classes and extra divs. I guess you are using the UIKit markup and if so, I think you also have to add the data-uk-grid attribute to the form if you are using grids (but not sure). I think you can image how it could be done to get the desired markup at all. If you have problems, please post the complete code for the form . Best regards

Problem is solved in latest version 2.2.29

Hello @MarkE The issue you reported sounds a little strange. I have tested it on localhost and on a live site, with the module installed and not, but I cannot reproduce this issue. On localhost: On a live site: As you can see, there is no difference between localhost and the live site. I was logged in as a superuser and as a manager. The manager role allows me to add new pages. There is no difference whether the module is installed or not (both on the live site and on localhost). Therefore there must be another reason for the behavior. I'm guessing you have different permissions for your roles on the development and live site. The module does not include a hook that affects the Save and Publish button on an admin page. Therefore, the module is unlikely to cause such an issue. The publishing of the pages works as expected too. I am sorry, but I guess you need to check if your roles or your template permissions could be responsible for your issue. Jürgen

Ok, thanks!! I will mark this as solved - mmhh, sorry it is not possible 😂

Hello at all! From time to time I get mails from the PW forum that I should mark a solved topic that I have started in the past with the "Mark as solution" button when the question asked has been answered . Did any of these replies answer your question? There may be more replies than those shown here. Help others by going to the topic and use the 'Mark as Solution’ button on the post with the best answer Stop receiving these reminder emails. — ProcessWire Support Forums Does anyone know, where this button should be? I cannot find it next to a post (even if I am logged in). Maybe someone can tell me. Thanks

Hello @Frank Vèssia! I have replaced size() function with length attribute on Github.

Hello @Frank Vèssia Thanks for reporting this issue. Unfortunately I cannot reproduce this error in my console. size() and length should return the same. Take a look at this discussion. Could you please replace the size() function with length to see if the error is gone now. If so, I can replace it on Github too, because it should not have a negative side effect. Thanks Jürgen

Hello @Andy I have added your rule as the first community provided validation rule to FrontendForms. Take a look here. This validation rule is included in the next update, but if you do not want to wait until the next update, you only have to replace the code of the CustomRules.php from Github with yours and you are done.

Hello @Andy Glad that it works like you want!! For this check, it is not really necessary to write a custom rule. You can also use the regex validation rule and add the regex there, but it is not wrong if you need this validation rule often.😉

Thank you @PWaddict I have corrected in inside the docs.

Hello @Andy I will write a new section in the docs in the next time about this possibility. Please note: If you want to use API variables inside your custom validation rule I guess you need to add this rule to the site/ready.php instead of the site/init.php. I have not tested it, but I guess you need to do it this way, but you can try it out. That is a good idea and if a validation rule seems to be useful for others I will add it to the FrontendForms validation rules file, so everyone can use it. I guess there are around 60 validation rules available at the moment, but more is more in this case. 😉

Good news @Andy I have taken a look at the Valitron library, which I use to validate form fields and this library offers an easy to use solution to add custom rules. Take a look here. To add a custom rule to ProcessWire you need to add it to the site/init.php. For demonstration puroses I use the example from the Valitron docs. So please add this code (which always returns false) to your site/init.php \Valitron\Validator::addRule('alwaysFail', function($field, $value, array $params, array $fields) { // here you can write your validation code - this should return true or false return false; }, 'Everything you enter is not correct. You fail.'); Now you have added a new custom rule, which you can use sitewide like all other validation rules. Here is a form example containing this rule: $form = new \FrontendForms\Form('test'); $inputText = new \FrontendForms\InputText('text'); $inputText->setLabel('Input Text'); $inputText->setRule('required'); $inputText->setRule('alwaysFail'); // here is the new validation rule $form->add($inputText); $button = new \FrontendForms\Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if ($form->isValid()) { } echo $form->render(); If you validate the form, you will always get the error message "Everything you enter is not correct. You fail." because this rule always returns false. You can take this example as a starting point for your own validation rule. The validation code must return a boolean value (true or false). Hope this helps

Hello @Andy I will take your issue as an idea for a new feature and I will take a look if I could find a good working solution. At the moment I will wait if there are some unwanted negative side effects concerning the last update. If everything works as expected and no issues occur/will be reported I will go on to the next step and try to find a solution to your issue. Best regards

I have updated FrontendForms to support hooks to customize the markup of certain elements. As written in a the blog post above there was a problem of using hooks, because they never fired. This should be solved now. You will find a working example on this website. If you press submit without filling out the form, all error messages will get an exclamation sign in front of the error message. This is done via the following hook inside the site/init.php: $wire->addHookAfter('Errormessage::render', function(HookEvent $event) { $msg = $event->object; $errorText = $msg->getText(); if($errorText){ $fontAwesome = '&#9888; '; $event->return = $fontAwesome.$errorText; } }); This is for demonstration puropose that it works now! In addition I have added some other hook examples inside the Hooking section of the docs. This bug fix includes the change of really a lot of files of FrontendForms, so please that care that everything works after the update as expected. Make a backup before you update the module!!! Best regards

The form will be always submitted after pressing the send button 😉 You have the choice, what should be done inside the isValid() function. This method returns always true if the "standard validation does not fail". It is up to you to make another validation inside the isValid() method, but there is no possibility to make isValid to false manually. As I explained in the example some post before, you can do addtional checks inside the isValid() method. Depending on the results of your custom checks you can send fe an email or not. The only problem could be that the form will not be displayed after isValid() is true. The code is not designed to handle such special cases, sorry!

Try $alert0 = $form->getAlert(); $alert0->setText($e_msg); $alert0->setCSSClass('alert_dangerClass'); // or alert_successClass or alert_warningClass setErrorMsg() is a method of the form object

I need to check the whole module files 🤪. After that I will bump up the version number, so you can download the latest version with the fixes.

How can I miss that - I've always overlooked that! Thanks for the relevant information - this will save me a lot of time and troubles in the future.🙂

Hello @PWaddict It seems that @Robin S has found the problem. Take a look here. I'll test it on mylocalhost and on the live site over the weekend and post my results here, but I'm sure this solves the problem.

I have tried it and now it is working well on my localhost!!!! I will test it on a live site too, but it should work there too. Thank you!!!!!

This could be the possible reason for the strange behavior. I will try it! Thank you so much!! 🙂

I have no clue why this works under certain circumstances. I will take a look at the weekend. Otherwise I delete the hooking section if it does not work properly.

You are right! It works on my localhost, but not on my live site. This is very strange!!!!

It is a little bit difficult to explain: Direct call of a class method on a page: $form = new Form(); echo $form->render(); The method will be called directly on a page, so hooking Form::render works. Direct call of a method of another class inside a method on a page: public function ___render() { $out = ''; $object = new Element(); $out .= $object->renderElement(); return $out; } As you can see the method renderElement of the class Element will be called inside the render method of the Form class so Element::renderElement is hookable too. The problem occurs if a method of the Element class should be hooked that is not directly called inside the given renderElement() method. class Element { public function ___test() { return 'Test'; } public function ___renderElement{ return 'Element'; } } So if you want to hook Element::test it will not be triggered, because it will not executed inside the renderElement() method. That was my experience with the hook problem

Could you please post the code of your init.php. I have taken the screenshots after adding this code to my init.php and as you can see it works in my case.