Leaderboard

I've got a lot of travel coming up in the weeks ahead, so there may be a few quieter-than-usual weeks in terms of core updates. I'll be in and out of town a few times, and I'm not much of a traveler, so will see how it goes. I'm not yet sure whether I can do work remotely, or what will be available in terms of internet access. There's a lot of client work to wrap up before hitting the road, so I've been focused on that this week and will have to next week as well. It's all ProcessWire related work though, so still having fun. There have been a few core updates this week, and there will likely continue to be in the coming weeks, but just not major core updates. By November hopefully all will be back to normal in terms of schedule. I'll be focused on getting a new main/master version out then. I also expect to have a new version of the CustomFields module (from last week's blog post) ready in the next week or so as well. Thanks for reading and have a great weekend!

Exactly. That's one of the advantages of this concept 🙂 The UI is the tricky part... Yeah a draft is already there 🙂 But there is more to it to cover all options. That's the next part to tackle 🤞

It will be a standalone module, but for the recurring events part you will need the "RockGrid" module. Other than that there will be no dependencies, no RockMigrations, no RockFrontend.

Some of you may know that I took over the ProcessWire Recipes project quite some time ago. Including the .com domain a few weeks back and the new .recipes domain right after my start. To make it clear: processwire.recipes right now uses AstroJS on Cloudflare so that there is no real need for a hosting, and it could run there forever. But here is the interesting part and question: Would you expect, maybe even demand, that those and similar projects were built with ProcessWire itself? I'd really like to and want to hear all your thoughts and opinions about this idea and topic. All pro and contra-arguments. Everything. Maybe even roast me for not using PW on that project.

@flydev I've played with ZipArchive recently and had some issues when unzipping on Linux (but not on Windows with 7zip), because I forgot to exit() PHP script after outputting headers and zip file. So I know a zip file can be opened on some software and not on other if it contains a problem. For the @MarkE issue, I'm wondering if it could come from the 2 lines in Duplicator.module where you update the zip archive without providing a flag in $zip->open()? Line 566 : if ($zip->open($pwbackup['zipfile']) !== true) { Line 939 : if ($zip->open($zipfile) !== true) { I don't really believe this solution, but I've seen a lot of posts like that when searching for my own issue: https://stackoverflow.com/a/17975009

Hi @MarkE there is no stupid question as they help others dev to get the right answer when they search for it. What’s the type of hosting? Webhosting or you have your hands on the server? the error seem to be due to the size of the zip as it say the object is not initialized, but I might be wrong, and about the native method, maybe its an issue with the zip extension. Please check the logs of the server and duplicator. edit: I suggest you to try with small setup, I mean you exclude some folders from the backup to get a smaller package just for testing.

Thx @erikvanberkum! Don't see the need to replace cal.com as it is free and works very well and has lots of options that I'd have to rebuild. RockCalendar will not handle timezones on its own. It will always store UTC dates in the database. If you need to support timezones than you can do so, but you have to implement that on your own. That should not be a big deal, as the part on how you present all dates to public users will be up to you anyhow. So in my case I manage events for a cave. They have a schedule with several dates for guided tours. For example on Saturdays at 14:00 from May to end of October. When testing this use case I realized that after passing the daylight saving change date all following events where @ 15:00 instead of 14:00 (or 13:00 instead of 14:00 I can't remember). To prevent this I let fullcalendar think that all entered dates are actually UTC dates. UTC does not have daylight saving so whenever anyone enters 14:00 it get's displayed as 14:00; That's it and that's how fullcalendar handles timezones itself, as far as I understood: https://fullcalendar.io/docs/timeZone When presenting those dates to users I will ignore that fact that dates are technically UTC dates and just present them as they are. That means that when anybody is browsing through the calendar he/she will see all tours starting @ 14:00 and he/she will expect that to be a local time, which is the case even though the date is technically stored as UTC. If I did that differently the user would see 13:00 as start date for events until October and 14:00 for events after 1st of October (or something like that, don't know when the actual change happens as my smartphone will do the switch for me 😄 ). This works for all websites presenting dates to local customers in one single timezone. 2 things to mention here: If anybody from another timezone was going to edit an event in the backend, he/she would still see 14:00 as time, which might be totally off his/her local time but will be correct for the local timezone of the location the event takes place. If the website presented events to users from different timezones the conversions would have to be done by the developer of the frontend. I think this should be quite easy though. Maybe we'd need to add a setting to the module in which timezone all dates are stored so that the frontend knows how to convert them to local times. Maybe it would need some modifications to the module. We'll see. If anybody knows that already please let me know. The plan is to handle all that by the single DaterangePicker field. So no need to setup any new templates. No need to setup anything else. No need to construct any complicated selectors. Just add the daterange field to your event template and that's it. And to query events it will be "template=event,daterange.inMonth=2024-08" or similar and you'll get all events including all recurrences. I use a hook to only show the daterange field of recurring events and hide everything else as everything else will be inherited from the main event. That means all occurrences are of the same type and have the same fields etc. just only the main event has all the fields populated. I'm working on that. It's not that hard, the only annoying thing is that I need to support both the calendar UI and the use case when someone edits events via the page tree. Both should be possible imho and unfortunately as it means more work. Yes. I thought of adding another grid that lists already created events that are part of the series, but not sure if that's good or not. Actually I have an idea that might also solve the problem mentioned above... I'll have to try this today or tomorrow! Generally speaking I'll add a switch that lets the user choose from edit this event edit this and all following edit all events But it's not so easy unfortunately as that could mean we need to update 1000s of pages and therefore I'll need a gui with a progressbar again... That's why I think it will be necessary to add a second grid to the daterange field. It adds bloat to the UI but the other option would be to save the job in the background and process it via cronjob, but that means a more complicated setup and no instant feedback to the user. I think a second table is the better and more flexible option. Yeah me too, thx 🙂 It's actually really easy. Just a Page::loaded hook protected function inheritFieldValues(HookEvent $event): void { /** @var Page $page */ $page = $event->object; if (!$page->hasField(self::field_date)) return; $date = $page->getFormatted(self::field_date); if (!$date->isRecurring) return; $mainPage = $date->mainPage; if (!$mainPage->id) return; foreach ($mainPage->fields as $f) { if ($f->name == self::field_date) continue; $page->set($f->name, $mainPage->get($f->name)); } } There are some downsides with this again, but that's only an issue for advanced calendars and should be no issue for 99,9% of use cases. Thx for the great use case!! This can quite easily be accomplished with how I developed the module. It would need some modifications but nothing complex I think. My idea would be to have one global description and then have an additional field that is explicitly not inherited. So the main description could show something like this: So every event would show the general info and then merge the individual book info. If the book-info is edited it only affects one event. If the general info is edited it would update all events (as it is inherited). The problem here is scalability. What if a user wants to create 1000 recurring events? Or maybe only 100. How would you do that? One option is to do that in the background. That means a possibly veeeeeery long loading time after save. Or maybe even a timeout. Or maybe the user hitting refresh several times and creating too much events or crashing the server or whatnot. The other option is a background job. Also with downsides as mentioned above. I think the preview table is the most intuitive and flexible solution. But if you have better ideas go ahead 🙂

@protro are you using any hook to generate images? I'm guessing here, but the behavior and logs suggest me that the slow issue is because your machine processing the images generation, probably not related with profields at all. Maybe similar? For the cache, try this https://processwire.com/modules/process-cache-control/

quite biased message Just my two cent's here. I tend to say - yes - just because I see third-party app/websites as a nice showcase on how pw can handle things and how versatile it is. I must admit that on my side I am using pw as second choice for a simple reason, I write websites in pascal (I can remember @LostKobrakai switching to Elixir). But, it's only depending on client needs and profile, and maintainablity. If a client absolutly require a setup based on php to be used with a standard web hosting, then pw come back as the first choice with no doubt. This piece of software is solid and deserve to power thoses tools made for processwire. I would have felt disappointed if weekly.pw was made as static website or worst, on wordpress, imagine. The real decison maker is I think, money. Domain names are more expensives then ever. About hosting, there is a lot of solid companies providing such web hosting, generaly you got 100MB free for ever on OVH or Alwaysdata (the second provide ssh access). For the domains fee's, the community could make some donations. It could be made using built-in page json feature with or without inertiajs and consumed from AstroJS, keeping ci github flow without any problem to let the community collaborte on it. You will won the right to add on the footer "powered by processwire" 🫡😄

@bernhard Found the culprit. RockMigrations is not compatible with WireCache: Filesystem. If both are installed it causes migrations to run on every PHP request that ProcessWire handles and may cause the UI to hang in certain instances. I disabled filesystem cache but given it's speed it would be great if that compatibility could be made. Possible? Found this a bit ago but I forgot to hit the submit reply button 🤷‍♂️

Good question, @wbmnfktr! When I came to PW from Joomla! that had an extension for everything including ecommerce and forums, I was kind of expecting PW to be the same. And I was waiting for a good shop and forum to be developed (by someone but me)) But time passes. I am not so idealistic now. I use ProcessWire for sites and some apps. I use other tools for online shops. I do not use nothing for forums as nobody I do stuff for really needs them. For a documentation site I would use VitePress, Docusaurus or MkDocs as they allow a more easy collaboration via github or such. Ryan doesn't use PW as a forum engine or to sell modules. But he does for the docs. But maybe he shouldn't so the community could participate @teppo uses PW for weekly.pw and wireframe site. I like the former and would argue about the latter for the same reasons. @kongondo uses PW for his site but VitePress for the docs. He is using PW and his own Padloper to sell stuff (he should!). @bernhard seem to do everything in PW with some of his numerous modules. Are forum and ecommerce coming?)) I would say that for the recipes the current collaborative approach is quite good. And it better be ready on Astro or you-name-it SSG than be in development in PW. But! I really love to see passionate people push the limits of possible with the tools of their choice. And would love to see recipes still in github to collaborate on, but wisely imported to PW. Especially if there is any additional value in that like more advanced filtering, interlinking or a form for less technical people to commit recipes. P.S. Frankly, I would go the easy way and stay on whatever tool is already in place. PW is great for some sort of things, but not for all.

I would advise you to use Docker or DDEV for that. You could use my composition here as a starting point. It uses MariaDB 10.6 and apache+php8.2 (custom image which auto-installs PW). You can then replace the web container with a Litespeed+php container and configure it. You can refer to the Dockerfile of my custom image to get started with that. As for Litespeed, from my very limited experience, any serious hoster should be using the enterprise variant because, as far as I know, only that really offers full drop-in replacement for apache. This makes it hard to run locally without a license.

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!

Isn't there one already? ;)

Process Render File A Process module that renders markup from files in /site/templates/ProcessRenderFile/. This provides an easy way to create simple admin screens where it might be overkill to create a dedicated Process module for the purpose. Process page When you install the module a page with the name "render-file" and the title "Render File" is created under Setup. To change the page name or title, expand Page List to Admin > Setup > Render File and open the page for editing. Tip: if you create a new text field with the name "page_icon" and add it to the core "admin" template you can set a custom menu icon for the page by entering the icon name into the field. E.g. enter "smile-o" to use a smiley icon for the page. If you want to use ProcessRenderFile for more than one Process page you can create a new page under Setup. Select "admin" for the template, enter a title for the page, and in the next step choose ProcessRenderFile in the Process dropdown. Render files for URL segments On install the module will create a "ProcessRenderFile" folder in /site/templates/. Any .php files you save to this folder will be rendered as the output of a matching URL segment for Process pages using ProcessRenderFile. For example, if you create a file foo.php containing code... echo "This is the output of foo.php"; ...then you'll see this output when you visit /processwire/setup/render-file/foo/ (assuming the default ProcessWire admin page name and the default ProcessRenderFile page name). In the render file you can use all the ProcessWire API variables like $pages, $input, etc, as you would in a template file. If you create foo.js and foo.css (or foo.scss if you have ProCache installed) then those assets will be automatically loaded when you visit /processwire/setup/render-file/foo/. When a file is rendered the filename will be converted into a capitalised format that's used as a browser title and a headline. If you want to set a custom browser title and/or headline you can do this in your render file: $this->wire('processBrowserTitle', 'Custom browser title'); $this->wire('processHeadline', 'Custom headline'); Render file for the Process page If you create a render file that has the same name as the ProcessRenderFile Process page then this file will be rendered when the Process page is viewed without any URL segment. So for the default ProcessRenderFile page name you would create render-file.php. Note that this will override the default list output described below. Configuration The module configuration screen lets you select URL segment render files to appear as menu items. The selected render files will appear in the flyout menu for the Process page, and also as a list when the Process page is viewed without any URL segment. The list is only shown if you haven't created a render file for the Process page as described above. If you've created more than one ProcessRenderFile Process page then you'll see menu options for each page in the module configuration. https://github.com/Toutouwai/ProcessRenderFile https://processwire.com/modules/process-render-file/

Padloper 009 I am pleased to announce the release of Padloper 009! It has been a minute! I apologise for the delay. Padloper 009 introduces a number of new features, bug fixes (especially in Multilingual sites) and improves overall code efficiency. Credits Before I get into the details, I would like to say massive thanks for all who have contributed to this release in various ways. You have contacted me via the forums, via PM and via email to report bugs, test Padloper and suggest and sponsor new features. In particular, I would like to thank (in no specific order) @Spinbox, @alexm, @joe_g, @ank, @csaggo.com, @Jan Fromm, @Pete, @Sonia Margollé and @kalimati. Whilst I will not name those who contacted me privately, please accept my gratitude for your help. Apologies if I forgot to give anyone a mention! Massive thanks to @ryan for ProcessWire. Padloper 009 is the most battle-tested Padloper yet! It has been tested and developed on high volume sites, sites that require lots of customisations and multilingual sites whose default language is not English. This robust development has helped fix bugs that I would not have been aware of otherwise as well as new ideas and features to improve the API, workflow and GUI of Padloper. Many of the suggested features have made it into this version. A few others are planned for the future. There is a lot to talk about in this version. Below I’ll just give a summary of the changes and where necessary, create separate topics to discuss some of the new features. Although Padloper 009 has undergone thorough testing, there might, inevitably, be some bugs. If you find one, please let me know in the forums under a separate topic. Thanks! Changes Features Home Customisable dashboard. You can render your own dashboard by creating a template partial named ‘padloper-process-render-shop-home.php’ and placing it at ’/site/templates/padloper/backend/padloper-process-render-shop-home.php’. Please see this thread for more details. Orders Customisable single order view. You can render your own dashboard by creating a template partial named ‘padloper-process-render-orders.php’ and placing it at ’/site/templates/padloper/backend/padloper-process-render-orders.php’. Please see this thread for more details. Order status actions: Can be applied manually for order, payment and shipping status. Quick filters e.g. ‘open’, ‘cancelled’, ‘abandoned’, etc. Products Configurable pricing fields. Sales and Normal Price (e..g WooCommerce) vs Price and Compare Price (e.g. Shopify). Please see this topic for more details. Categories can optionally be named ‘Collections’. Configurable via ‘/admin/shop/configure-padloper/’. Bulk clone existing products. Allow duplicate titles for products. Discounts (new) 4 discount types: Orders, products, free shipping and BOGO (Buy One/Get One - unfinished; see below). Can be applied manually or automatically at checkout. Please see this thread for more details. Add/remove via ‘/admin/shop/configure-padloper/’. Part sponsored by Nifty Solutions. Thanks @Pete! Customers and Customer Groups (new) Customer creation and management. Please see this thread for more details. Customer Groups. This feature will be expanded in the future. Please see the above thread for more info. Add/remove via ‘/admin/shop/configure-padloper/’. General Settings Redone interface Add ‘from email’ settings.. Add bank details settings.. Add order ‘least and most’ sales thresholds for orders’ quick filters. Settings for ‘low stock’ and ‘price fields’ for products. Add tab ‘user interface’ with settings for shop navigation (can have side menu and/or dropdown navigation) and search features (can use quick filters and/or advanced filter). Other Backend Quick filters on various dashboards. Custom Dashboards for Home and Orders. More to be added in future. Frontend Custom shop root page. This allows you to move product-related pages and legal pages to live under a frontend-accessible page. Configurable via /admin/shop/configure-padloper/. Please see this topic for more details. For instance, /myshop/products/, /collections/, /products/, etc. This means you can directly access products on the frontend using their real paths/urls instead of using URL segments. This setting can be changed anytime via configuring Padloper at /admin/shop/configure-padloper/. Custom URL segments for checkout out. E.g. instead of /checkout/success/, /checkout/confirmation/, etc., you can have custom, multilingual segments, e.g. /checkout/order-success/, /checkout/tilaus-menestys/, etc. Miscellaneous Various UI improvements. Dashboards tables sorted by title by default. Breaking Changes Template partials for the frontend have been moved from /site/templates/padloper/ to /site/templates/padloper/frontend/. Deprecated ‘Search Feature’ on the home dashboard has been removed. Use ProcessWire in-built search instead. Padloper hooks into it to group padloper related results. PadloperProcessOrder::orderSaved now becomes PadloperProcessOrder::orderSavedHook.The new approach is to have all hooks in one please for easier maintenance and usage. Bug Fixes Please see the bug fixes topic. How to Get It Padloper 009 is available at https://processwireshop.pw/products/padloper/. For those renewing subscriptions, you will have to wait a bit, apologies. I am finalising work on renewal codes. I am hoping this will be ready by tomorrow. Any issues with the (revamped ?) site please let me know ?. Upgrading This is a major upgrade. Lots of code has been moved around. Best way to upgrade files is to empty the contents of the root Padloper folder and upload the contents of the new version there. There are no data model changes affecting existing features but as always, back up your site(s) first! Next Steps In addition to fixing any bugs that show in 009, these are the plans for the next 3-6 months, possibly more, in order of priority. No new features will be introduced until these are completed. Documentation Documentation will cover all topics including installation, backend and frontend use and the API. ‘How to guides’ will consist of short videos with corresponding textual content on a dedicated Padloper site. Discounts Finish work on the Buy One Get One (BOGO) Discount and automatic discounts. Gift Cards Finish work on Gift Cards. Road Map I will talk about this when the ‘next steps’ tasks have been completed. Thanks!

You could do a check for existance of window.htmx and then conditionally include it from CDN. Sth along these lines if (typeof window.htmx === 'undefined') { var script = document.createElement('script'); script.src = "https://unpkg.com/htmx.org@latest"; script.integrity = "sha384-ujb1lZYygJmzgSwoxRggbCHcjc0rB2XoQrxeTUQyRjrOnlCoYta87iKBWq3EsdM2"; // Not sure if this works reliably with @latest script.crossOrigin = "anonymous"; document.head.appendChild(script); script.onload = function() { console.log("htmx loaded successfully!"); }; script.onerror = function() { console.error("Failed to load htmx!"); }; } else { console.log("htmx is already loaded."); }

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