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!

This is my first module. It is primitive, like my neighbor who loves to fire up his new Makita breaker hammer after 21:30h. Please, feel free to do whatever you want. I don't promise I will add better functionality but maybe... If you do, please ping and send me back. Thanks! It loads every page on the backend. It calculates the text width in two fields you choose on the configuration page.. If there are any updates, I will post them here. Happy ProcessWiring! PS: These measurements are specifically for desktop and Google's SERP (Search Engine Results Page). UPDATE on 15 May 2024: Google started to calculate (truncate) the meta title for 20px Arial yesterday. The Module has been updated. Here is the link to download/install the latest version: https://processwire.com/modules/seo-text-width/ EDIT: The version 0.0.5. Added two dropdown fields on the configuration page of the module. PROVE IMAGE: You can check the meta title, which was measured with 18px Arial and it was less than 512 pixels.

@wbmnfktr I created an issue on Github for this.

Welcome to the plugin-author's club, @Leftfield!

If I understand correctly, you want to make the connection between contract and product pages after data import. In the imported data you have a numeric ID that connects contracts to products. Can you please clarify if that numeric ID has been saved to a field on both contract (multiple IDs) and product page (single ID)? Once we know that, it would be quite easy using a small script to make the connection through a page reference field on the contract page that references one or more products.

https://nativephp.com/docs/1/getting-started/introduction "NativePHP is not a GUI framework. We don't want to tell you how to build your app. You can choose whatever UI toolset makes you and your team feel most productive." "#What's in the box? NativePHP comes with a bunch of useful features out of the box, including: Window management Menu management File management Database support (SQLite) Native notifications" What can I build with NativePHP? Honestly, anything you want. The only limit is your imagination. Now for building Windows apps too: https://github.com/orgs/NativePHP/discussions/278

Yay! Thank you, @FireWire looking forward to trying this out later.

Thanks @bernhard for being awesome again. This worked flawlessly!

You can use this hook to do what you want: $wire->addHookBefore("InputfieldFile::render", function (HookEvent $event) { $inputfield = $event->object; if ($inputfield->name !== 'your_fields_name') return; $inputfield->appendMarkup .= "<script> document.currentScript.parentElement.querySelectorAll('a.InputfieldFileName').forEach(function(link) { if (!link.href.endsWith('.pdf')) return; link.removeAttribute('download'); }); </script>"; });

Yes, that is why we went with the page tree option. Less headache for developing. Definitely more work, but also more flexibility for the editors.

That's a quick solution, indeed ? EDIT: I never used that module CustomAdminMenus. Just saw that it supports hooks to hide menu items based on user role: https://github.com/Toutouwai/CustomAdminMenus?tab=readme-ov-file#showinghiding-menus-according-to-user-role

@wbmnfktr just tried it locally and got the same error "Unknown character set: utf8mb4mb4". Not sure if it was always like this or if it's a new thing. Usually I stick with the default utf8 formatting. But for the support of emoticons, I try to use"utf8mb4" lately. Would be nice if the site exporter/importer takes care of this. Edit: If I keep default utf8 settings, I can install the utf8mb4 formatted site, but the fields containing emoticons are empty.

This is a quite common problem, but I haven't seen a good solution for it. Probably there is none, because the problem is not the technical solution, the problem is the problem itself. Does that make sense? We have different languages and we have different regions, so we have a multidemensional thing to show an a single-dimensional website. Even if we had a technical solution (like url segments or page tree) the problem is still a problem in my opinion, because content get's tedious to manage. But I'd be curious if anybody has found a good solution for it, as I've once talked to someone looking for something similar and he said PW would not be a good solution for this task. I don't think that this is true, but maybe my feeling is wrong and there are other platforms that already solve that challenge properly? Please let me know if you know any. --- I think if I'd had to build this I'd go with the page tree for regions and a global "data-pages" section for pages that can be shared as needed by the region pages. But it depends on the priorities of the specific project. Maybe reusing content is more important, maybe something else... What I could think of would look like this: -- home -- content -- foo -- bar -- baz -- about us -- europe -- about us -- asia -- foo -- bar -- about us -- america -- baz so all content would go into /content and all the regions would be reflected in the tree and only reference those content pages. Routing would be easy and all regions would support all language, eg /en/europe/about-us Think of it similar to a menu builder. Editing would get a little more complex, but I think that's a small price to pay and I can't think of an easier solution to this multi-dimensional problem ?