Leaderboard

Hey all! This is a module to enhance forms built using the Pro FormBuilder module by providing the ability to submit them in place using AJAX and HTMX. FormBuilderHtmx works in harmony with FormBuilder by handling front-end rendering and AJAX and lets FormBuilder manage form configuration and processing. FormBuilderHtmx provides a drop-in replacement for the $forms->render() method and provides all native features and behavior (and adds a few extra superpowers to boot). Noteworthy features: Zero configuration, install and render AJAX powered FormBuilder forms immediately Render multiple forms on the same page. Supports both multiple instances of the same form or different forms. Each form is processed independently. Non-intrusive, can be used alongside FormBuilder's native rendering methods and does not modify core module behavior Perfect for forms embedded in popups and modals Does not conflict with styling and other JavaScript already in-place, only handles the form submission/response loop Automatically disables the `Submit` button on submission to prevent duplicate requests Provides the ability to add a custom 'spinner' shown when a form is being processed Gives you the ability to add additional HTML attributes to your FormBuilder <form> element. Add additional custom functionality using HTMX attributes, hook into form actions with your JavaScript, or even add AlpineJS directly to your forms. Compatible with FieldtypeFormSelect, let users choose which forms to embed, your code determines how they are rendered Uses HTMX, a stable, powerful, and tiny (14kb gzipped) library, installation documentation available here This module is BYOH (Bring Your Own HTMX) in that the HTMX library is not included or available within this module. This ensures long-term stability by not locking FormBuilderHtmx to external asset versioning. FormBuilderHtmx uses stable core HTMX features so use the library version that works for you and confidently add this module to both new, existing, and future ProcessWire applications. In some instances CSRF protection may need to be disabled to submit forms with this module. Just test your forms and you're good to go. Using this module is truly easy. <!-- Replace the native $forms->render() method with $htmxForms->render() --> <?php $htmxForm = $htmxForms->render('your_form_name') ?> <!-- Use native ProcessWire properties and methods as usual --> <?php echo $htmxForm->styles; echo $htmxForm->scripts; echo $htmxForm; ?> Presto. You can optionally include a helpful 'spinner' or activity animation that will be showed to users while their form request is being processed. Check out these ready-to-go examples you can use in your projects. <style> /* Add these styles to your CSS, the `.htmx-request` must be present as shown here. Be sure to include any CSS your 'spinner' may need, and style everything as desired */ .activity-indicator { display: none; } .htmx-request .activity-indicator, .htmx-request.activity-indicator { display: block; } </style> <!-- Optional second argument matches that of the $forms->render() method for pre-populated values The third argument is the CSS selector matching your 'spinner' element --> <?= $htmxForms->render('your_form_name', [], '#indicator-for-the-form') ?> <div id="indicator-for-the-form" class="activity-indicator"> <span class="spinner"></span> </div> Presto (again) Check out the documentation for detailed usage and other available features. Pull requests and issues filed on Github are welcome, or drop by here to get some help! Install as a ProcessWire module Install using Composer Download from the FormBuilderHtmx Github repository . Cheers!

Hey ProcessWire RockStars! ? Ever felt like your ProcessWire backend could use a bit more... pizzazz? Or functionality? Well, it's time to roll up your sleeves and dive into the world of RockAdminTweaks! ??️ Creating tweaks is as easy as smashing a power chord on your guitar! If you've got cool features from AOS you'd love to see, why not port them over? We even have a GUI for creating new Tweaks! Let's make the backend rock even harder! Github: https://github.com/baumrock/RockAdminTweaks Modules Directory: https://processwire.com/modules/rock-admin-tweaks/ Docs: https://www.baumrock.com/processwire/module/rockadmintweaks/

Hi @netcarver thx for clarifying. I wouldn't call such a collection "bloat". By bloat in AOS I meant that all features are not well organised. They are all put into the same files leading to large files with lots of hooks etc.; If one feature makes troubles it's hard to find all related lines of codes. Or if you want to remove it you risk to break something else. In RockAdminTweaks all tweaks are isolated and well organised, so that's not a problem at all. Also tweaks are only loaded if they are activated so it shouldn't be a problem to have many tweaks in the module performance wise. PS: I changed the place for tweaks from assets to templates, because multilang features don't work in assets!

Hello @ all I want to share a new module with you, which makes the creation and validation of forms easy. Take a look at the following example of a simple contact form: // A very simple example of a contactform for demonstration purposes $form = new Form('contactform'); $gender = new Select('gender'); $gender->setLabel('Gender'); $gender->addOption('Mister', '0'); $gender->addOption('Miss', '1'); $form->add($gender); $surname = new InputText('surname'); $surname->setLabel('Surname'); $surname->setRule('required'); $form->add($surname); $name = new InputText('name'); $name->setLabel('Name'); $name->setRule('required'); $form->add($name); $email = new InputText('email'); $email->setLabel('E-Mail'); $email->setRule('required'); $form->add($email); $subject = new InputText('subject'); $subject->setLabel('Subject'); $subject->setRule('required'); $form->add($subject); $message = new Textarea('message'); $message->setLabel('Message'); $message->setRule('required'); $form->add($message); $privacy = new InputCheckbox('privacy'); $privacy->setLabel('I accept the privacy policy'); $privacy->setRule('required')->setCustomMessage('You have to accept our privacy policy'); $form->add($privacy); $button = new 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(); This piece of code creates a simple contact form and validates it according to the validation rules set. Inside the isValid() method you can run your code (fe sending an email) Highlights: 30+ validation types Support for UiKit 3 and Bootstrap 5 CSS framework SPAM protection Highly customizable Hookable methods for further customization Multi-language You can download and find really extensive information on how to use at https://github.com/juergenweb/FrontendForms. Please report errors or suggestions directly in GitHub. Best regards and happy testing ? If you have downloaded the module in the past I recommend you to uninstall the module completely and install the newest version 2.1.14. There are a lot of changes in the new version, so please test carefully.

Hi guys, I was wondering if the action buttons for each page in page tree could be : All always visible (always immediately see Hide, Unpublish, Trash... when hovering over page link) Hidden selectively even if the action is possible (like always hide the Lock button) About the Add new button, I noticed something that is a bit weird : Let say I have a P template that may have children based on template C1 and C2. C1 and C2 can only have P as parent. So these conditions are enough to get a link with the "Add new" button, and it works perfectly. Now, let’s imagine I have two roles defined : chief-editor and contributor. Chief-editor can create pages based on C1 and C2 and can see both "Add new" links. Contributor may only create pages based on C2. They should only see "Add new C2" link. But they actually can see both links, and when they try to create a C1 page, they get an error saying "ProcessWire: ProcessPageAdd: Template page-post is not allowed here (/p-page-url/)". Which is absolutely right, as they are not allowed to create C1 pages. But it’s confusing for the user. Did I misconfigure something here? Or is it something that should be fixed?

Please have a look at RockAdminTweaks: Both things you mention have a tweak to solve it. You could also open an issue in the PW issues repository!

Hi @d'Hinnisdaël, Just wanted to say (again) how awesomissimo is your module. It’s a real asset in the scale when trying to convince a client to switch from WP to PW. They often fear to be lost with a new admin interface. But thanks to Dashboard, I can demonstrate how easier it is. ?

Hello @bernhard Ok, it actually isn't a module, it's a collection of tweaks. From my point of view, I'd rather just install the exact tweaks I'm going to use in to the assets/RockAdminTweaks/tweaks folder. If every possible tweak is accumulated in the RockAdminTweaks repo, wouldn't all of them will be copied in to the site when the module is installed or updated? In that case, RockAdminTweaks is likely to become somewhat bloated over time, and bloat is something you seemed to be moving away from when I read the original RockAdminTweaks documentation... The repo I started doesn't have to be the only pool. I started it to learn how how to write tweaks, and to experiment with how a pool could be accomplished. If the tweak pool idea survives, I'd actually much rather have a the pool under the baumrock/ namespace. There are probably other ways of dealing with avoiding bloat + provide a library of tweaks as well, but it seems to me that to avoid bloat the tweaks need to live somewhere outside the module, or there needs to be some mechanism (other than manually deleting unwanted tweaks from the server) that allows the install of the exact tweaks required. Yes, having those in separate files would be much better than inlining them in the addStyles() method. That makes sense.

Thanks for the module! htmx is awesome and absolutely the right tool for such things.

What is your intention with this module? I think it would make more sense to add the tweaks directly to RockAdminTweaks, no? https://github.com/netcarver/RockAdminTweaksPool/blob/697240eb651dd873585b7f2630a81f2d905192ca/assets/RockAdminTweaks/AdminOnSteroids/BypassTrash.php#L28 --> this is not needed any more, because tweaks are only loaded in the backend, so it will always be template == 'admin' Regarding styles and scripts: I've added a "loadJS()" method on the Tweak base class. This will automatically load the corresponding js file from the tweak. See docs here: https://github.com/baumrock/RockAdminTweaks/tree/main/docs/assets Personally I'd prefer to have all the JS in dedicated JS files. It's a lot easier to write, a lot easier to read (no escaping, working color highlighting etc) and it's also easier to develop and debug (as you can set breakpoints, for example). I think the same concept makes sense for CSS files as well, what do you think? I'm just not sure from a performance perspective. Does it matter if we load multiple scripts with just a few lines of code? Would it be better to inline them into the HTML? But I don't like this ugly script and style injections via str_replace... So I've just added loadCSS() method as well! Regarding the AdminOnSteroids folder: I think it's nice to mention tpr's module, but I'd like to group tweaks based on what they do or where they add magic. For example I've added a "PageList" folder for tweaks that relate to the pagelist/pagetree and a "Forms" folder that relates to all kinds of forms or inputfields (page edit etc). If you have suggestions for other folders please let me know. The folder "AdminOnSteroids" makes no sense in my opinion.

Very old indeed, but still useful... and still working ? Who said plugins needed to be updated every week ? Oups... wrong forum... ? I’ll open an issue on Github.

@Robin S I was thinking that since a JS callback is necessary to make it do anything, it was simplest just to keep it all JS, contained to one definition. At least for the case that prompted adding this feature (PageEditChildren module). But for cases like what you are describing, what you say makes a lot of sense. I will add an $inputfield->addHeaderAction([ ... ]); that does the same thing, maybe like these examples? // click action $inputfield->addHeaderAction([ 'icon' => 'hand-stop-o', 'overIcon' => 'hand-peace-o', 'tooltip' => 'Hello world', 'event' => 'myEvent' ]); // toggle action $inputfield->addHeaderAction([ 'onIcon' => 'toggle-on', 'onEvent' => 'MyOnEvent', 'onTooltip' => 'Click to toggle off', 'offIcon' => 'toggle-off', 'offEvent' => 'MyOffEvent', 'offTooltip' => 'Click to toggle on', ]); // link action $inputfield->addHeaderAction([ 'icon' => 'fa-link', 'href' => 'https://processwire.com/api/ref/', 'tooltip' => 'API reference', 'target' => '_blank', // or 'modal' or omit for '_self' ]);

Hi all, I am turning out to be a liar at this rate! I really should stop talking about 'tomorrow'. I can only apologise. Projects and Padloper 009 kept me very busy the last many months! I wasn't able to do much on MM next. During that time, I realised that a number of underlying concepts of MM had to change. Hence, I started a re-write of MM but the pace was slow due to afore mentioned reasons. Now that Padloper 009 is out of the way, my main coding focus is on MM! I am quite confident that I'll be able to have a release within a month. This will be a late alpha or early beta, but at least something that can be tested. I don't take your patience for granted. I am trying my best not to let you down this time ?. Thanks!

Just remembered this site. It was created many years ago with some really (really) humble beginnings to translate jQuery into JS as features became supported enough to be safely used. Ironically, it's aim is to suggest you don't need jQuery- but the content has grown so much now it could just as easily be used as a reference of sorts to show everything you can do with it. https://youmightnotneedjquery.com/ Even now with feature parity, jQuery really does shorten and simplify a ton of things.