Leaderboard

Many websites these days are the feeding ground for AI bots. Especially this site! In this post we look at a tool for taming all the hungry crawlers and bots… https://processwire.com/blog/posts/throttling-ai-bot-traffic-in-processwire/

We've long wanted a way to utilise a CDN to offload images/files/videos from ProcessWire sites without losing all the native greatness of ProcessWire image and file field types. Having read various discussions on here about ways to approach this that never seemed to reach conclusion, I've thrown myself into creating a module that allows offloading of files to Bunny.net CDN as we need a solution for a specific project. I think this would be easily adaptable to any S3 compatible CDN but I've only tested on Bunny. ⚠️ This is still very beta! Use at your own risk! I've been conducting basic testing and so far, so good but there's bound to be holes or things that others may suggest better ways of doing. But I'm now at a stage where the insight/experience of the PW community might add value to the project - so I'm sharing now! Full disclosure: Once past the initial project scaffolding I've been using AI/careful prompting to write some of the code so that I can arrive at a prototype as quickly as possible. This seems to have worked well, although some of the code looks a little verbose and could probably be refactored later on. Also not security/pen-tested yet. https://github.com/warp-design/WireBunnyCdn/ Features: Automatically uploads images to Bunny storage on page save, including all variants and mirrors assets folder structure for simple merging back to local at a later date if needed. Automatically cleanses deleted files (or files from deleted pages) from your CDN. Option to mirror files to CDN or delete local copies (this is the main aim for me, otherwise we could just use ProCache). Handles (basic currently) image sizing - either using standard ProcessWire `$image->size(X,X)` methods or by implementing Bunny Optimizer for sizing using URL params. Rewrites image paths via CDN so that you can use standard `$page->imageField->url` calls with the output being a Bunny path rather than local PW path. Also handles the image previews in admin view. Roadmap: Support for video uploads (with optional separate CDN endpoint for Bunny Stream buckets). Support for front-end video output to templates using Bunny stream players/optimisation etc. Implement chunked/background uploads for large files. Support for other size() method options, like cropping etc and mapping to Bunny Optimizer equivalents. Anyway - look forward to hearing any advice/feedback/bug reports... I'm sure there's many!

This week in the blog, we’ve got a new version of FormBuilder released, version 57. This new version of FormBuilder adds a lot, including… https://processwire.com/blog/posts/formbuilder-v57/

Show Image Custom Field Errors Makes custom fields for images visible when there is an error, e.g. empty required fields. Purpose Image fields have three view modes: square grid, proportional grid, and vertical list. In square grid and proportional grid modes only the thumbnail is visible and custom fields for an image are hidden until the thumbnail is clicked. This can cause an issue when any of the custom fields is an error state (e.g. a required field that has been left empty) because the relevant field will not be visible in the Page Edit interface, making it more difficult for the user to locate the field that needs attention. The Show Image Custom Field Errors module forces image fields into vertical list mode when there is an error in a custom field. When the error is resolved the image field is returned to the view mode that was in use before the error occurred. https://github.com/Toutouwai/ShowImageCustomFieldErrors https://processwire.com/modules/show-image-custom-field-errors/

Hey folks, fun fact: this module was already featured in this week’s ProcessWire Weekly – even before we managed to post it here in the forum. So, here we are, finally giving it a proper introduction! 😅 TL;DR: This module connects Stripe Payment Links with ProcessWire and provides a simple checkout integration for sites that don’t need a full shop. 🎯 ✅ Drop a Stripe buy button anywhere ✅ Redirect back to PW thank-you or delivery pages ✅ Buyers get accounts, purchases are logged, access is granted ✅ Access mails are sent automatically ✴️ New in v 1.0.7: Sync existing purchases and buyers from Stripe to PW with test/write option First things first: What are Stripe Payment Links? Stripe Payment Links are basically hosted checkout pages that you can create directly in the Stripe Dashboard – no coding required. You define a product (or multiple line items) in Stripe. Stripe gives you a unique URL (the “Payment Link”). You can drop this URL behind any button, on any landing page, newsletter, or social media bio. When a customer clicks the link, they’re taken to a secure Stripe Checkout page (PCI compliant, supports all major payment methods, Apple Pay, etc.). After payment, Stripe redirects them back to your success URL. Super simple. But… on its own, Stripe has no idea about your ProcessWire site, your users, or your gated content. That’s where this module jumps in. 🚀 Why another payment module? We at frameless Media often work on small client projects where setting up a full e-commerce shop would be complete overkill. Think: Coaches selling a few courses or workshops Businesses offering a handful of digital products or subscriptions Creators who just need a buy button on a landing page Stripe Payment Links are perfect for this. But: ProcessWire on its own doesn’t handle redirects, user handling, or gated delivery pages. So we built StripePaymentLinks – a lightweight drop-in module to connect Stripe with PW. What it does Handles the redirect back from Stripe Checkout that contains the session id Creates or updates the buyer’s user account Records purchases in a repeater field Manages access to “delivery pages” (only available after purchase) Auto-sends access mails (configurable: never / new users only / always) Provides Bootstrap-based modals for login, password reset, set-password Usage examples Example 1: Sales page + delivery page Sales page has a “Buy now” button (Stripe Payment Link). After checkout, the user is redirected to the delivery page, which is access-protected. → Module logs them in, grants access, and if they’re new: a set-password modal pops up. → An access mail with product links is sent. Example 2: Product without a delivery page Some products don’t need protected pages (e.g. a consulting slot or voucher). → The success redirect goes to a generic thank-you page. → The module shows an access summary block with purchased products and sends the mail. Example 3: Mixed purchase (thank-you + delivery page) A checkout with multiple items: e.g. a “simple product” plus an addon that has its own delivery page. → Thank-you page shows the addon link(s). → The access mail lists all purchased products. Source & License The module is open-source under the MIT License. 👉 GitHub: https://github.com/frameless-at/StripePaymentLinks 👉 ProcessWire modules directory: https://processwire.com/modules/stripe-payment-links/ So yes: if you or your clients just need a few low-barrier buy buttons, not a full-blown webshop, this might be the module you’ve been looking for. If needed we can provide some screenshots and visual examples next week 😉 Happy to hear your thoughts, ideas, and testing feedback! Cheers, Mike

This week we've got several updates to the core on the dev branch. It's primarily focused on small issue fixes and optimizations. Though there's enough since 3.0.251 that I'm bumping the dev branch version to 3.0.252. Next week there won't be any new updates this time next week because I'll be traveling, but will be back right working on the core right after that. Thanks for reading and have a great weekend!

Hi all, if you log in since Friday and click the Notifications (bell) icon in the forums then you should see this message which allows the forums to send alerts for messages and topics you are subscribed to via browser notifications. There is also PWA (Progressive Web App) feature that I've enabled so you may also see "Install to Home Screen" as an option for both Android and iOS. If the PWA works as intended, you will have an app icon on your device and, I think, notification badges should appear there too, so if you're like me and have had email notifications switched on for followed content you can edit your notification settings and change this to Notification List I think. Apologies for the vagueness but the forum docs are a little unclear in places. It is all optional and if you don't want to use either feature you don't have to of course.

AdminQuickTree This module is great for productivity when editing many pages within the admin, as it gives you direct access to the page tree navigation without having to hover the tree icon first. Download from Github Donwload fom Module Directory For non-superusers the page dropdown currently looks like this (if no bookmarks are defined): With this module it looks like this: For super-users or users with all permissions set it looks like this: These changes are achieved width a small js file that triggers the ajax tree navigation after the dom has been loaded. While I have tested it already a bit, I release this for now as a beta version. I hope others find it useful as well.

Good day @ryan! After the launch of the redesigned admin theme and site I had private conversations with some community members about it. And I have to say that they were pretty harsh about it. Some of us are choosing words here in the forums keeping hard thoughts to ourselves. Was it the right move? Was it made with enough consideration? Didn't it cost too much breaking things that worked? Is it possible to rollback somehow? This is what at least some of us here are silently thinking. Ryan, a lot of us here like myself have always relied on your vision and gut. You have managed to deliver exactly what was needed so many times. We want to believe the redesign is the right move too and we are just are too accustomed to the familiar and struggling to change opinions... So let me ask this. You see the google analytics metrics, downloads and stuff. Maybe you can measure something else like forums activity rate. How did it change with the redesign? Did you get what you expected?

Version 2.2.44 includes a new feature besides some bug fixes (Thanks to @Stefanowitsch for reporting, testing and providing some fixes for the issues). New feature: File list below a file upload field Previous versions of FrontendForms have the "clear the file upload field" feature, which was a link below the input field to remove all files for upload from this file upload field. This was a nice feature to remove files from the file upload field, but @Stefanowitsch requested a better feature to remove not all, but only specific files from the field. The new feature is not just a link. Instead it provides a complete list of all added files below the file upload field and by clicking on the "X" you can remove a specific file from the field. The second advantage is that you can see all files that have been added to this field. Demo: demo-filelist.MP4 As always, please report any issues you discover here in the forum or on GitHub.

@gebeer Throttling is what enables us to allow the AI bots, rather than having to block them for taking over the sites resources. So long as the bots adhere to the rules established in the robots.txt they'll never get throttled. But if they ignore the crawl delay, then those requests get throttled with a 429 error. We even include a retry-after header telling them when they can try again. I used to have to block these bots outright in order to preserve the resources for you and me. Now they can crawl as much as they like, so long as they follow the speed limit. The throttle feature provides a way to enforce the speed limit.

SSE (Server-Sent Events) would be a game-changer for ProcessWires core, and the trash functionality example perfectly illustrates why: The Current Problem: As you mentioned, the current trash system is painful - deleting hundreds of pages requires multiple confirmations, long waits, and often timeouts. Your clients shouldn't need API knowledge just to empty their trash efficiently. How SSE Solves This: One-click bulk operations: Start deleting 1000+ pages with a single confirmation Real-time progress: "Deleting page 234 of 1000..." instead of a frozen screen No more timeouts: SSE keeps the connection alive, bypassing PHP execution limits Graceful interruption: Users can safely stop/pause operations if needed Beyond Trash - Core Benefits: I have written several converter or importer modules for my clients, that import data and transform them into pages or a payment matcher module, which compares bank statements with invoice pages inside of ProcessWire. For all of these modules I wrote custom SSE Event handlers myself which is much boilerplate and duplicated code as Bernhard mentioned. Imagine every ProcessWire installation having this built-in: Import/export operations with live feedback Batch page operations (move, publish, unpublish) Asset processing (image optimization, file management) Search index rebuilding Module installations and updates Why Core Integration Matters: Standardized approach: All modules can use the same SSE implementation Better UX across the board: Every long-running operation becomes transparent Developer-friendly: No need to reinvent the wheel for each module Professional feel: Matches modern user expectations from enterprise CMS Addressing Adoption Concerns: I can't predict what percentage of users would use this feature - nobody can provide statistics for something that doesn't exist yet. But consider this: every ProcessWire user who has ever dealt with timeouts, batch operations, or large imports would benefit immediately. The feature would be invisible to those who don't need it, while being invaluable to those who do. Your modules already prove SSE works brilliantly with ProcessWire. Making it core functionality would elevate the entire ecosystem.

Well it looks like they're switching to Laravel for Craft CMS v6: https://craftcms.com/blog/laravel This is very interesting and speaks to the idea of the CMS and web application framework powering it being 2 separate projects (Craft, etc.) vs. it being built around each other (ProcessWire). In my opinion, ProcessWire wouldn't be what we all love about it if it had such a huge dependency.

Hi, everyone! We recently built a small add-on module for our StripePaymentLinks setup and thought it might be useful to share here. We’ve been working with StripePaymentLinks quite a lot lately, and one thing the clients always wanted was a simple way to get purchases synced into Mailchimp without relying on external paid add-ons. So we built a small ProcessWire module to handle exactly that. The idea is simple: every time a customer makes a purchase via StripePaymentLinks, their details (name, email) plus the purchased products (as tags) get synced directly into Mailchimp. That means you can instantly segment, automate, and follow up with buyers without any manual exports. We built this because we didn’t want to rely on a separate paid Stripe → Mailchimp connector. With this add-on, it’s all handled natively inside ProcessWire — lightweight, minimal, and no extra subscription fees. What it does right now: Hooks into the creation of purchase repeater items (repeater_spl_purchases) Pulls customer name + email from the User created by StripePaymentLinks Extracts product names either from the expanded Stripe session line_items or as fallback from the purchase_lines field Pushes everything to Mailchimp, creating the subscriber if you allow it in the config Assigns the product titles as Mailchimp tags Config is super simple: just drop in your Mailchimp API key, Audience ID, and decide if you want to auto-create subscribers or only update existing ones. We’re keeping this intentionally minimal — one module, no extra steps, no fuss. Install, configure, and you’re done. We’ve been running it in production for some clients and it’s working reliably. If you’re already using StripePaymentLinks, this could save you the cost of external integrations while keeping everything in one place. Get it here: ProcessWire: https://processwire.com/modules/stripe-pl-mailchimp-sync/ Github: https://github.com/frameless-at/StripePlMailchimpSync Happy to hear your feedback or ideas for tweaks. Cheers, Mike from frameless Media

@bernhard Here's a function that solves the original problem of how to MOVE (not copy!) repeater items from one page to another, which preserves IDs. I tested it and I believe I accounted for everything, but I recommend testing it more before using it in production. // move the repeater items from fromPage to toPage // the same repeater field must be assigned to both pages // note: fromPage and toPage can be repeater page items as well since they are technically pages function moveRepeaterItems(string $fieldName, Page|RepeaterPage $fromPage, Page|RepeaterPage $toPage): void { // checks if(!wire('fields')->get($fieldName)) { throw new WireException("Field '$fieldName' does not exist."); } if(!$fromPage->id) { throw new WireException("From page does not exist."); } if(!$toPage->id) { throw new WireException("To page does not exist."); } if(!$fromPage->hasField($fieldName)) { throw new WireException("From page does not have field '$fieldName'."); } if(!$toPage->hasField($fieldName)) { throw new WireException("To page does not have field '$fieldName'."); } if($toPage->get($fieldName)->count('include=all,check_access=0')) { throw new WireException("To page already has items in field '$fieldName'."); } // store the parent_id $parent_id = wire('database')->query("SELECT parent_id FROM field_{$fieldName} WHERE pages_id = '{$fromPage->id}'")->fetchColumn(); // delete potential (and likely) existing toPage data placeholder // prevents this error: Integrity constraint violation: 1062 Duplicate entry '1491109' for key 'PRIMARY' in /wire/core/WireDatabasePDO.php:783 // remember, this will be empty since we checked above that there are no items in the toPage field wire('database')->query("DELETE FROM `field_{$fieldName}` WHERE `pages_id` = '{$toPage->id}'"); // update the record in table 'field_$field' where pages_id=$fromPage->id and change the pages_id to $toPage->id wire('database')->query("UPDATE `field_{$fieldName}` SET `pages_id` = '{$toPage->id}' WHERE `pages_id` = '{$fromPage->id}'"); // update the record in table 'pages' where id=$parent_id: change name from 'for-page-{$fromPage->id}' to 'for-page-{$toPage->id}' wire('database')->query("UPDATE `pages` SET `name` = 'for-page-{$toPage->id}' WHERE `id` = '{$parent_id}'"); } // example moveRepeaterItems( fieldName: 'order_line_items', fromPage: $pages->get("/orders/foo/"), toPage: $pages->get("/orders/bar/") );

Ryan, thank you for clarifying. This totally makes sense now :-)

Hi @gebeer While I understand your concern about blocking AI bots but what I get from Ryan's post is that he doesn't completely cut off AI bots. It is because they come too often. He just want to limit their visit rate. I think it is ok because I don't think the document part changes every few seconds. Gideon

@ryan still none of my paid modules show up in the modules directory. Also do you have some feedback on my questions/suggestions from 4 weeks ago here and here? I'd like to know if you plan to add the suggested improvements or if I have to update all my modules manually. When I look at the RockPageBuilder module it (still) looks like this: Is that warning really necessary? Why is that warning shown to regular (non-logged-in) users? IMHO it doesn't add any helpful information for them. How would a guest user add or update the readme of my module? I understand that my module does not have a readme, but it has extensive docs here: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/ I put a lot of effort into these docs so it is frustrating that all that is visible in the modules directory is an ugly red warning. Even worse I think this warning can make the impression that the module is dead or not actively maintained, which is not the case and which would be harmful to my business. The "Project" button does nothing when I click on it. What is it intended to do? And why does it appear on my modules page? And all that said, why does that lead to my modules not being shown in the list of paid modules? Or is there another reason for that? Next, a minor thing: Why does it show "Since 2025/01/10" and does it have to be like this? On my releases page the oldest release is v3.6.0 from January 2023 and it would be nice to make it obvious that this module has a long history and has always been actively maintained, updated and improved. I understand that this is likely the date when I added the module to the directory, but it's imho nothing that adds value to my module's entry. Could that be made configurable so that I can show the real release date or instead only (not additionally) show the last updated date there, which would be more helpful information for anybody I guess? Thx

@Stefanowitsch asked about using the File Mover module with a "media library" page that is accessed via a modal. I thought I would share some hook code publicly in case it's useful for others too. // Add a button to file and image fields to open a media library page in a modal // Hook InputfieldFile::render to affect file and image fields, // or InputfieldImage::render to affect only image fields $wire->addHookAfter('InputfieldFile::render', function(HookEvent $event) { $inputfield = $event->object; // The field associated with the inputfield (if any) $field = $inputfield->hasField; // The page containing the inputfield (if any) $page = $inputfield->hasPage; // Don't add the button to fields on the media library page // as we don't want the possibility of nested modals if($page && $page->template == 'media_library') return; // You can also check the field name if the button should only be added to a specific field, e.g. // if($field && $field->name !== 'article_images') return; // Get the media library page $media_library = $event->wire()->pages->get("template=media_library"); // Construct the URL to edit the media library page $url = $media_library->editUrl; // Add &modal=1 so the admin header isn't shown $url .= '&modal=1'; // We don't need other tabs or fields besides the image/file field(s), // so specify the field name(s) in the URL // Unfortunately there is this layout bug: https://github.com/processwire/processwire-issues/issues/1972 $url .= '&field=images,files'; /** @var InputfieldButton $f */ $f = $event->wire()->modules->get('InputfieldButton'); $f->href = $url; $f->value = 'Open media library'; $f->icon = 'picture-o'; // Add pw-modal class so the button link opens in a modal $f->addClass('pw-modal'); // Make it a large modal $f->addClass('pw-modal-large'); // Add a bit of space above the button $f->attr('style', 'margin-top: 10px;'); // Append the rendered button to the inputfield $event->return .= $f->render(); });

Really pleased the documentation is included with the main documentation. It would be great to have the documentation for all the pro modules that allow API access included in the same way. ListerPro sort of is, as it extends lister. Although all Pro modules are mentioned on the site, they're not necessarily in the API reference even if they can be accessed via the API. Also there's not a single page that lists all built in fieldtypes and pro fields that can offer additional functionality. I'd really like there to be a page like this: https://docs.umbraco.com/umbraco-cms/fundamentals/data/data-types/default-data-types (In addition to PHP, I also work with .Net and Umbraco is the closest thing to ProcessWire I've found in that space.) Thinking as a developer, one of the first things I want to know when I'm evaluating a platform is 'What can it do out of the box?'. If I've got to jump around amongst multiple webpages to find out then I immediately start losing interest. I'm happy to contribute to ProcessWire by helping with documentation if that would be useful.

I've only played around with the new admin theme and haven't committed to it yet. That was one thing I noticed as well and I feel the color difference in the original theme definitely makes it easier to visually separate nested fields.

Wow, I missed that. That is the beauty of the friendly ProcessWire Community. You always learn something new. Thank you!

You can set custom icons for your Repeater Matrix elements in the item header. 😉 https://processwire.com/blog/posts/new-repeater-and-repeater-matrix-features/#custom-icons-for-repeater-types

Based on driving myself completely insane with noHooks for the last 2 years, and based on what Ryan specifically said here: ... I completely agree with Ryan. noHooks option should be absolutely avoided. Seriously, if you use it in advanced cases like I have been doing, you will hit every WTF issue known to man. It is not made for developer use, even though it gives off that vibe. I think that is a mistake. I will write more about this in depth soon, but at least in my situation, my goal was to ultimately update a page and all of its descendant repeaters (repeaters within repeaters) only after the page is its descendant repeaters have been saved completely first without hook interference. Using noHooks basically fucks up everything up (saying it's been frustrating dealing with it is an understatement) and there are unintended consequences everywhere! The correct way to do what I described is to do something like this, which took forever to figure out (every line has a specific reasoning behind it): // // /site/classes/OrderPage.php // class OrderPage extends Page { public function getAggregateRootPage() { return $this; } public function finalize() { // your code to finalize the page, such as populating an order_total field, etc. } } // // /site/classes/OrderLineItemsRepeaterPage.php // class OrderLineItemsRepeaterPage extends RepeaterPage { public function getAggregateRootPage() { return $this->getForPage(); } } // // /site/init.php or /site/ready.php (doesn't matter) // wire()->set('finishedPages', new PageArray()); // hook 1: use Pages::saved only to build list of pages to finalize wire()->set('finishedPagesHook', wire()->addHookAfter('Pages::saved', function(HookEvent $event) { $page = $event->arguments('page'); if(!method_exists($page, 'getAggregateRootPage')) return; wire('finishedPages')->add($page->getAggregateRootPage()); // duplicated pages won't get stored }, [ 'priority' => 1000 ]); // hook 2: use ProcessWire::finished to finalize the pages 🤌 wire()->addHookBefore('ProcessWire::finished', function(HookEvent $event) { wire()->removeHook(wire('finishedPagesHook')); foreach(wire('finishedPages') as $finishedPage) { $finishedPage->finalize(); } }, [ 'priority' => 1001 ]); When I demo my system one day which is way more complicated than the example code above, it will become clear. // TLDR: don't use noHooks when saving a page. DON'T! Instead, create a log of what pages need to be finalized, and act on those pages in ProcessWire::finished hook, which is when you can be absolutely sure the coast is clear. I wish I knew about that hook earlier. If you follow those simple rules, you don't have to think about CLI vs non-cli, ajax vs. non-ajax, whether the current page process implements WirePageEditor, uncache, getFresh, saved vs. saveReady, before vs. after hook, hook priority, editing a repeater on a page vs. editing the repeater "directly", where the hook should go (it should be in init.php/ready.php or in the init()/ready() method of a module), etc. Note: there's a whole other aspect to this in terms of locking the a page to prevent multiple saves (like if a page was being saved by an automated script and the same page was being saved by an editor in the GUI).

Worth a read! "The lesson here is to never mix manually constructed SQL fragments and bindings when using PDO emulation. You are opening yourself up to a huge risk by doing so as a single misparse results in SQL injection. If you are a developer: Disable PDO::ATTR_EMULATE_PREPARES if possible; If not, ensure you are on the latest version (PHP 8.4) and you do not allow null bytes in your queries." https://slcyber.io/assetnote-security-research-center/a-novel-technique-for-sql-injection-in-pdos-prepared-statements/

Interesting that those prices aren't listed! Here are a few data points for you; perhaps others can flesh this out with more, or maybe @ryan will post them officially! 😉 $39 -- ProFields $39 -- ListerPro (dev) $39 -- ProDevTools $35 -- FormBuilder (single) $14 -- "Likes" (single)

News: "...npm got rocked by a record-breaking exploit..." https://youtu.be/QVqIx-Y8s-s And self-driving cars, AI agents, refrigerators, cat feeders, and who knows what else are and will be based on code written by who knows who...

FieldtypeSelect is very old module from 2013 that "produces a drop down list (via a "select" input) that would allow you to define a list of options in the field's configuration from which to select a value. After installing, you'll have a new "Select" fieldtype that will allow you to define the items you'd like in the drop down. You'll be able to define these options in a text box on the field's configuration screen. Just put each option on it's own line." Github Repo: https://github.com/Hani79/Processwire_FieldType_Select_Drop_Down My fork: https://github.com/matjazpotocnik/Processwire_FieldType_Select_Drop_Down You should use FieldtypeOptions nowdays. Can't answer that, see if the fieldtype Select is used in any template?

@BrendonKoz it should just be a matter of replacing the module files with the new ones. Then do a modules refresh. Then go to the module config page to setup throttling features. It should install the new ProcessRequestBlocker module automatically, which will appear on the Setup top nav menu.

A quick note: Keep in mind that the clone will not occur (ProcessPageEdit::processSubmitAction is never executed) if there's a required field on the page being cloned that has not been populated and/or the page is statusFlagged.

Hello @Stefanowitsch Thanks for reporting these issues. I have fixed them (point 1 and 2). Instead of adding the class "uk-form-label" I have added the class "uk-margin-small-right" to the label tag because I find it looks like better. I have updated the version of FrontendForms, so please update and test it. I hope it works fine, because it is very late here in Austria, but on my local installation everything looks good. I find your idea of showing the files for the upload very good, so I guess I will try to find a nice JavaScript solution to realize this. The best option would be that I will find a ready-to-use JavaScript which offers this feature, so I can include it in the next update. Thanks for giving FrontendForms a try and to make it better by reporting issues and sharing ideas to improve it with us. Best regards Jürgen

@BrendonKoz I've got all those buts in our list as well, except for Bingbot. As far as I can tell, Bingbot follows the crawl delay, so is one of the good ones.

I hope to give it a try tomorrow, but if I can't get to it, the first chance I'll have is next week. That said, I will definitely let you know! From a cursory search with recent logs, the following bots were problematic: Bingbot (Microsoft, USA) Bytespyder (ByteDance, so TikTok, China) MJ12bot (Majestic, SEO Tool, UK) AhrefsBot (Ahrefs, SEO Tool, USA) PetalBot (Petal Search Engine; China) CensysInspect (Internet Vulnerability Scanner, USA -- I think this is being abused and used as an attempted attack vector on our site, but they say it abides by crawl delay) I honestly did not realize there was/is a crawl speed directive for robots.txt (that some bots follow). I would've implemented that a long time ago. I do intend to implement ProCache at some point as well but this will be a very nice intermediary.

Hi @Juergen! I tested your module, you did a great job and I found two small details that I would like to point out: 1. "for" attribute missing on labels (when using InputCheckboxMultiple and InputRadioMultiple) 2. <label> elements (when using InputCheckboxMultiple and InputRadioMultiple) need "uk-form-label" classes to apply margins (of course only when UI Kit styling is selected in the module settings) By default the <label> surrounds the input so that the "for" attribute is not needed. But if you use this option: $form->appendLabelOnCheckboxes(true); ...then clicking on the label does not activate the checkbox/radiobutton next to it (because of the missing for-attribute). Another thing that would be really convenient: Is it possible to allow multiple file uploads via the InputFile class and to show each file that is chosen for upload under the field (before submitting). Something like this: The idea is to get an overview over the files that should be submitted and also give the user the option to remove specific files.

Because this question came up: No, the user does not have to enter any data before checkout. All user data is pulled via Stripes PHP SDK (included with the module). Therefore the only thing needed for the module to work is that the redirect link configured in Stripe contains the session_id param. You configure this directly in the Stripe backend by simply adding ?session_id={CHECKOUT_SESSION_ID} to your desired redirect-URL: Thats all. With this session id the module has access to all data of this specific purchase. Cheers, Mike

I'm dredging up an old topic here but had a need to go and look for something like this - not for a ProcessWire field - and ended up deciding TipTap looked like the best bet. It also turns out that Invisioncommunity (the forum software in use here) also uses TipTap: https://invisioncommunity.com/forums/topic/478170-invision-community-5-the-all-new-editor/ (so expect this forum to use that editor when we finally upgrade to v5 as there is no choice when upgrading forums unlike the unlimited choice you get in ProcessWire 😅). Now I am interested in a TipTap field for ProcessWire for a few article-heavy websites where we have mostly text but sometimes need to add in an image, a CTA block (some editable per article, some locked), image/text in a column with some settings and as far as I can tell TipTap allows for all of this because you can just build any widget you want and make them drag-droppable. Before I get too far down this rabbit hole has anyone investigated this sort of thing since 2019? Searching the word "editor" on the forum naturally returns a lot of results, many of which not actually related to alternative rich text editors I'm basically interested in the simplicity of having just one editor versus repeater matrix pages where it's not technically needed a lot of the time. I did also look at editor.js which looked really cool but that one doesn't seem to have been updated in years and TipTap is both open source and has some big customers so will still be here in a few years. my brain got confused because some folders were last changed 2 years ago but it is still in development and also looks good - possibly better in fact as the demo on the homepage is already more the way I envisioned.

Module version is updated including the fixes. Changelog

Thx for the heads up. That's perfectly fine, but it would help if you let us know if something is considered to be implemented in a day, a week or a year or not at all. It would be very frustrating if I went through all my modules and then on the next weekly post get informed that the the requested update is ready and all efforts were useless. I'm confused. My modules are in private git repos. How would I do that? I also tried to add content to the README.md textarea input in the modules directory but it didn't work because I didn't provide a Github url. But providing a Github url to a private repo makes no sense to me. I understand it is like this, we can see that. My question was does it have to be like this. I don't think it adds value to anybody, especially not to guest users, as I tried to point out. RockCalendar has had this category selected but still doesn't show up. At first I thought the issue might be that I used "premium modules" as second category, but still it does not show up even though I flipped both selected categories. I guess it's because I don't fill the Github url field.

Thank you very much @Robin S I modified the code a little bit to fit my needs and now it is a rally simple but very effective solution for handling global media / file management in ProcessWire.

@Mike-it - the latest version supports the Options field type but note that you need to use the numeric key for the option rather than the label, so 1 or 2 rather than Yes or No, for example.

Of course RockMigrations can do that. Example migrate.php: <?php namespace ProcessWire; $rm = rockmigrations(); // install modules $rm->installModule('TracyDebugger'); $rm->installModule('RockDevTools'); $rm->installModule('RockFrontend'); $rm->installModule('AdminThemeUikit', [ 'toggleBehavior' => 1, // consistent 'themeName' => '', // original theme ]); $rm->installModule('RockAdminTweaks', [ 'enabledTweaks' => [ 'General:QuickAdd', 'Inputfields:CopyFieldNames', 'Inputfields:ImageDownload', 'PageList:TemplateLink', 'PageEdit:PrevNextPage', ], ]); $rm->installModule('Less', [ 'useCache' => 1, ]);

I just published an update that might be of interest to some: the ability to transpile any MJML code without it being part of a template. From the release note: This new release extracts the transpiling of MJML to HTML into its own public method allowing you to call it for any arbitrary piece of MJML code, instead of having to have the code in a template file: $mjml = "<mjml></mjml>"; /** @var PageMjmlToHtml $pmh */ $pmh = $modules->get("PageMjmlToHtml"); $result = $pmh->transpile($mjml); if($result->code === 200 && empty($result->errors)) { echo $result->html; } By default the options’ values are the ones set in the module’s settings. This new method is also hookable, which means you can for example set different options depending on the template: $wire->addHookBefore("PageMjmlToHtml::transpile", function(HookEvent $event) { $mjml = $event->arguments(0); /** @var Page $page */ $page = $event->arguments(1); $options = $event->arguments(2); if(!$page->id || $page->template != "specific-template") return; $options["relativeLinksParams"] = "utm_campaign=new-campaign-title"; $event->arguments(2, $options); });

@ryan Fantastic work. I was just doing some heavy development around FormBuilder earlier this year and this is all awesome stuff. Thanks!

Hello there! Since I started creating sites with ProcessWire I wished there was a central media management option. You know - a place where you can upload all sorts of data (well, mostly images) to use them throughout the whole website. It is something that nearly every other CMS offers and many clients of me which used Wordpress or Typo3 are used to this kind of media management and it's kind of hard to tell them that this is not possible (in that way) with ProcessWire. I know from the past that there was a Media Manager Module from @kongondo but this module seems not to have been updated in years. Are there any other solutions or techniques that you developers use?

@KrlosThat is strong looking to https://processwire.com/modules/seo-maestro/ The JSON Schema is not coming from that.

@Jonathan Lahijani - not sure if this is what you are looking for, but all Tracy's settings can be overridden in config.php like: $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, ]; Not sure if those are the exact options you want, but hopefully that approach works for you.

Hello, This is the closest but also not being maintained: https://processwire.com/talk/topic/22665-module-imagereference-pick-images-from-various-sources/ Not a media manager, but it can fulfill certain requirements: https://processwire.com/modules/process-media-lister/ and "combined" with this https://processwire.com/talk/topic/29985-file-mover/ they can fulfill even more requirements. Not being overly complex, Robin will probably be able to update these whenever needed. That's an advantage....

What will happen to developer directory?https://directory.processwire.com/ It is not mentioned anymore on the website but you can still find it on Google. You cannot login anymore. At this point I think it should either be deleted or relaunched. 😆 Regards, Andreas

First of all, hats off to everyone involved in the redesign! I can only imagine the countless hours that must have gone into this project – really impressive work. Of course, a redesign will always divide opinions. Some will love it, some won’t – that’s the nature of design (a bit like beer: there’s no accounting for taste). But let me share a perspective from my three decades of experience working with clients: 99% of paying clients couldn’t care less about what CMS powers their site. What matters to them is that the website looks good and feels professional. The ones we really need to convince are the second tier of decision-makers: the people who will actually use the system day-to-day. These users are rarely designers. They don’t care much about animations or typographic finesse – what matters to them is clarity, ease of use, and a sense that the CMS won’t get in their way. That’s why, in practice, we almost never show clients a backend during the decision-making phase. Instead, we show them beautiful, carefully crafted frontends, and sometimes highlight the inline editing capabilities. That sells. Clients are impressed when they see polished websites that “might be running on ProcessWire” (since, let’s be honest, you can’t tell a CMS from the frontend anyway). How this focus on real-world client priorities could be reflected more strongly in the redesigned ProcessWire website is something I’d love to explore further. Cheers, Mike

I've built this over and over in several of my modules (RockDevTools for Livereload, RockCalendar for creating events). Always a lot of work. Always a lot of boilerplate code. Always a lot of issues to fix. I think it's time to bring SSE (Server Sent Events) to everybody. Simple example (Empty Trash): Client-Side: // create stream const stream = ProcessWire.Sse.stream( 'ssedemo-empty-trash', (event) => { const textarea = document.querySelector('textarea[name="empty-trash-status"]'); try { let json = JSON.parse(event.data); stream.prepend(textarea, json.message, 100); } catch (error) { stream.prepend(textarea, event.data); } } ); // update progress bar const progressBar = document.querySelector('#empty-trash-progress'); stream.onProgress((progress) => { progressBar.value = progress.percent; }); // click on start button document.querySelector('#empty-trash').addEventListener( 'click', (e) => { e.preventDefault(); stream.start(); }); // click on stop button document.querySelector('#stop-empty-trash').addEventListener( 'click', (e) => { e.preventDefault(); stream.stop(); }); Server-Side: public function __construct() { parent::__construct(); /** @var Sse $sse */ $sse = wire()->modules->get('Sse'); $sse->addStream('ssedemo-empty-trash', $this, 'emptyTrash'); } public function emptyTrash(Sse $sse, Iterator $iterator) { $user = wire()->user; if (!$user->isSuperuser()) die('no access'); $selector = [ 'parent' => wire()->config->trashPageID, 'include' => 'all', ]; // first run if ($iterator->num === 1) { $iterator->max = wire()->pages->count($selector); } // trash one page at a time $p = wire()->pages->get($selector); if ($p->id) $p->delete(true); else { $sse->send('No more pages to delete'); return $sse->stop(); } // send message and progress info $sse->send( $iterator->num . '/' . $iterator->max . ': deleted ' . $p->name, $iterator ); // no sleep to instantly run next iteration $sse->sleep = 0; } Code + Readme: https://github.com/baumrock/SSE/tree/dev What do you think? Would be nice if you could test it in your environments and let me know if you find any issues!