Leaderboard

@mel47 - please test the attached version. There is a new option (on the Input tab of the field) for "Allow formatting characters in Input, eg. - ( ." Note that unlike the "Letters" option, the formatting characters will be stripped before saving to the DB. FieldtypePhone.zip

After probably 12 years with Processwire, I just discovered that pressing the 🌲 tree icon link, in the breadcrumbs, opens a modal with the page tree.

That worked, thank you so much! 🙌 🙂

Unfortunately it was not as easy as changing the version number. I had to find another workflow as the one used was archived and not maintained any more. But I have now added a dedicated auto-release workflow file to RockMigations which anybody can use to create fully automated releases (without nodejs deprecation notices) 😎 name: Auto-Release on: push: branches: - main jobs: auto-release: uses: baumrock/RockMigrations/.github/workflows/auto-release.yml@main secrets: token: ${{ secrets.GITHUB_TOKEN }}

I think you need to update to action/checkout@v4. Looking at their changelog https://github.com/actions/checkout/blob/main/CHANGELOG.md they updated to Node 20 in v.4.0.0. That should take care of the problem. Alternatively, if you, for some reason, must stay on v3, you can set an env var FORCE_JAVASCRIPT_ACTIONS_TO_NODE20=true But I would try to avoid that because of https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/#removal-of-operating-system-support-for-non-node20-os-versions Hope that helps :-)

@MoritzLost Just tested it out and it works great! Thanks!

Release 2.0.1 Bugfix: Fix PHP warnings regarding the usage of htmlspecialchars. https://github.com/MoritzLost/InputfieldHCaptcha/blob/master/CHANGELOG.md#201---2024-10-14 @combicart Thanks for letting me know, should be fixed in 2.0.1. Turns out some attributes might be null in InputfieldHCaptcha::getAttributes(), which was passed to Inputfield::getAttributesString(), which passes this to htmlspecialchars. Might also be addressed in core, but for now, I've filtered out all the null attributes. Let me know if you have any other issues!

Hi @adrian (and @Robin S if interested). I have forked your module and added a config field to use names/paths rather than ids. Fork is here: https://github.com/MetaTunes/ModuleSettingsImportExport, if you would like to have a look/play. I have tested it with some modules (but not all) and you can easily see the results in the multiple module settings box. Note that it deliberately gives some warning/error messages at the moment. They are not really necessary but do highlight where some modules are not perfectly constructed. Enjoy 😀

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 @adrian please apologise for the subject ? I love Tracy - This is either a feature request or a question to understand why you built it in the way it is and maybe just a question of where I find info in the docs ? I'm creating a custom panel for RockFrontend so that RockFrontend can even live-reload pages that throw fatal errors or where latte {include ...} tags point to a wrong file. Until now I needed to hit refresh manually for those files which is tedious in the long run. All I really need to do is to inject my javascript: <?php namespace ProcessWire; $rf = rockfrontend(); $secret = $rf->addLiveReloadSecret(); $script = $rf->addLiveReloadScript(); if (!$script) return; ?> <script> LiveReloadUrl = '<?= $pages->get(1)->url ?>'; LiveReloadSecret = '<?= $secret ?>'; document.addEventListener("DOMContentLoaded", function() { var script = document.createElement("script"); script.src = "<?= $script ?>"; document.head.appendChild(script); }); </script> I even wouldn't need a panel for this, just a hook that adds my markup whenever the debug bar is rendered on the page. But I did not find one. Is there one? But the question remains why adding simple panels is so complicated. I found out thx to @teppo's WireFrame panel that I need to place my panel in /site/modules/RockFrontend/TracyPanels/MyPanel.php, which is already great. But still... if I only want to show an icon in the bar, a label on the panel and some HTML inside the panel body, this is what I have to do? <?php namespace ProcessWire; use BasePanel; class RockFrontendPanel extends BasePanel { // settings private $name = 'rockfrontend'; private $label = 'RockFrontend Panel'; // the svg icon shown in the bar and in the panel header private $icon = '<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24"><g fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"><path d="M5 5a2 2 0 0 1 2-2h10a2 2 0 0 1 2 2v2a2 2 0 0 1-2 2H7a2 2 0 0 1-2-2z"/><path d="M19 6h1a2 2 0 0 1 2 2a5 5 0 0 1-5 5h-5v2m-2 1a1 1 0 0 1 1-1h2a1 1 0 0 1 1 1v4a1 1 0 0 1-1 1h-2a1 1 0 0 1-1-1z"/></g></svg>'; private $liveReloadStatus = 'disabled'; /** * define the tab for the panel in the debug bar */ public function getTab() { if (\TracyDebugger::isAdditionalBar()) return; \Tracy\Debugger::timer($this->name); $livereload = $this->wire->files->render(__DIR__ . "/livereload.php"); if ($livereload) $this->liveReloadStatus = 'enabled'; return "$livereload<span title='{$this->label}'>{$this->icon} " . (\TracyDebugger::getDataValue('showPanelLabels') ? $this->label : '') . "</span>"; } /** * the panel's HTML code */ public function getPanel() { $out = "<h1>{$this->icon} {$this->label}</h1>"; // example of a maximize button $out .= '<span class="tracy-icons"><span class="resizeIcons"><a href="#" title="Maximize / Restore" onclick="tracyResizePanel(\'' . $this->className . '\')">+</a></span></span>'; // panel body $out .= '<div class="tracy-inner">'; $out .= "LiveReload status: " . $this->liveReloadStatus; $out .= \TracyDebugger::generatePanelFooter($this->name, \Tracy\Debugger::timer($this->name), strlen($out), 'yourSettingsFieldsetId'); $out .= '</div>'; return parent::loadResources() . $out; } } Maybe it's already possible to do that in a simpler way? I'm thinking of something like this: <?php $wire->addHookAfter("TracyDebugger::getPanels", function($event) { $event->return->add([ 'icon' => '<svg ...></svg>', 'label' => 'RockFrontend', 'body' => $files->render(__DIR__.'/RockFrontendPanel.php'), 'allowMaximize' => 'true', ]); }); Where Tracy would on its own add all the necessary boilerplate that is necessary for measuring timings and memory consumption etc. Thank you for your time and for TracyDebugger in general!! PS: I have the same todo for RockFrontend's topbar ??

Pw converts pageArrays to a string in that formal automatically when inside selectors, so this should do the same: $results = $pages->find("tags={$page->tags}")->shuffle();