Leaderboard

Image Hotspots Allows a Repeater field to be used to define hotspots on an image. Being able to add multiple fields of any type to the Repeater provides flexibility for the information you can store for a hotspot. Setup 1. Install the module. Two decimal fields will automatically be created on install: hotspot_x and hotspot_y. You can set custom hotspot and highlight colours in the module config if needed. 2. Create a "single" image field (i.e. maximum number of files = 1) that you will use store the image that will have hotspots defined on it. Add this field to a template. 3. Create a Repeater field and add the hotspot_x and hotspot_y fields to the Repeater. Add any other fields you need to store information about the hotspots you will create. Save the Repeater field. 4. In the "Details" tab of the Repeater field, expand the "Image Hotspots" section (this section appears for any Repeater field that has the hotspot_x and hotspot_y fields). For "Image field", select the image field you created in step 2. The "Image height" setting defines the maximum height of the image when displayed in Page Edit. 5. Add the Repeater field to the template you added the image field to in step 2. Usage in Page Edit When an image has been saved to the image field, the Repeater field will display a preview of the image at the top of the field. Click "Add New" to create a new hotspot. The hotspot appears at the top left of the image initially and can be moved by clicking and dragging it to the desired location on the image. The X/Y coordinates of the hotspot will be automatically updated as the hotspot is moved. For precise adjustments you can modify the X/Y coordinates directly and the hotspot position will be updated. To identify which Repeater item corresponds to a given hotspot, click on the hotspot. The corresponding Repeater item header will receive an orange outline. Click the hotspot again to remove the orange outline. To identify which hotspot corresponds to a given Repeater item, expand the Repeater item and focus either the X or Y coordinate fields. The corresponding hotspot will be highlighted in orange. On the frontend It's up to you to display the hotspots on the frontend in any way you need. The values of the hotspot_x and hotspot_y fields are percentages so when given absolution positioning over the image your hotspot markers can preserve their positions as the image scales up or down in a responsive layout. https://github.com/Toutouwai/ImageHotspots https://processwire.com/modules/image-hotspots/

ProcessWire’s API is accessible through API variables and it provides multiple ways to access them. There are benefits and drawbacks to each approach and this post aims to cover them all. We also look at how to add your own API variables as well. https://processwire.com/blog/posts/api-variable-best-practices/

Last week I was on a boat, far from any computer, so that’s why there weren’t any updates. This week I’m back in the office and back to work on the core. The focus has been primarily on optimizations and issue fixes (see dev branch commit log). There were also a couple commits related to PHP 8.4 support. Issue fixes and optimizations will likely continue to get more focus as we get closer to our next main/master version.There are also some Pro module updates in the works as well. Have a great weekend!

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 is an inputfield module I made as a replacement for InputfieldPageListSelect, due to frustration with it not opening the page structure to the currently selected page. Please note the requirement of ProcessWire >= v3.0.248 when using it as an inputfield for a Page Reference field due to this now fixed core issue. The module doesn't make the PW version a strict requirement in case you just want to replace instances of InputfieldPageListSelect via the bundled ReplacePageListSelect module. Page Tree Select An inputfield for selecting a single page from the page tree. This inputfield is similar to the core InputfieldPageListSelect, but it has the following advantages: It automatically expands the tree to the currently selected page. This avoids having to drill down through the tree when you want to change the selection to a sibling or child of the currently selected page. This was the primary motivation for creating the module. It's faster to navigate through because the whole tree is rendered at once rather than branch by branch. It provides a filter feature to locate pages by title anywhere in the tree. When the tree is filtered you can hover a page title to see the breadcrumb path to the page in a tooltip. It provides buttons to clear the current selection, to restore a changed selection, and to scroll to the selected page. Configuration The following config options are available when using the module as an inputfield for a Page Reference field: Exclude admin pages: excludes pages from the tree that have the admin template (only affects superusers who can otherwise see pages with this template). Exclude pages by template: pages having any of the templates you select here will be excluded from the tree. Descendants of any excluded pages are also excluded. Limit for total pages in the tree: this limit is applied to the selector that finds pages for the tree (default is 5000). Limitations and considerations Performance seems to be reasonable when the tree consists of up to 5000 pages. Your mileage may vary and the module may not be suitable for sites with a very large number of pages (unless excluding pages by template in the inputfield configuration). Pages in the tree show their titles rather than any custom setting defined for the template "List of fields to display in the admin Page List". Page titles are only shown in the default language. The module does not reproduce some of the quirks/features of ProcessPageList such as excluding pages that are hidden and non-editable, and forcing the sort position of special pages like Admin and Trash. ProcessWire >= v3.0.248 is needed for the inputfield to appear as an option in Add Field due to this now fixed core issue. Replacing InputfieldPageListSelect in the ProcessWire admin An autoload module named ReplacePageListSelect is bundled with InputfieldPageTreeSelect. Install the module if you would like to replace all instances of InputfieldPageListSelect in the ProcessWire admin with InputfieldPageTreeSelect. For advanced use cases there are two hookable methods: ReplacePageListSelect::allowReplacement($inputfield): set the event return to false to disable replacement on particular instances of InputfieldPageListSelect. ReplacePageListSelect::getPageTreeSelect($inputfield): set excludeAdminPages, excludeTemplates and limitTotalPages properties on the event return InputfieldPageTreeSelect object when replacing particular instances of InputfieldPageListSelect. https://github.com/Toutouwai/InputfieldPageTreeSelect https://processwire.com/modules/inputfield-page-tree-select/

Today there’s a new version of ProCache (4.0.7) available for download in the ProCache support/upgrades board. Here’s what’s new in this version of ProCache: ProCache has been updated throughout for PHP 8.4 support. Upgraded the SCSS compiler to the latest Leafo SCSSPHP 2.0.1. This version requires PHP 8.2, so ProCache also lets you choose from two older versions if you prefer. Upgraded the LESS compiler to the latest Wikimedia LESS 5.4.1. Past versions can also be selected, including Wikimedia 3.0.0 and Leafo LESS 0.5.0. Upgraded the CSS/JS minifier to the latest available version (1.3.75 latest). Because we had customized the CSS/JS minification quite a bit, the older version (1.0 stable) also remains selectable, just in case there’s anything the older version handles that the new one doesn’t yet. LESS, SCSS and Minifier versions can be selected and changed in the ProCache configuration: Setup > ProCache > JS/CSS. Likewise the ProcessProCache module has a new JS/CSS tab for configuring the settings mentioned above. ProCache now logs LESS/SCSS and Minify status and errors to the JS console (when in debug mode or for a logged-in superuser). ProCache now has a proper API reference page available here: https://processwire.com/api/ref/pro-cache/ Because this is a brand new version with several upgraded libraries, it should be considered beta until it's been out a couple of weeks. Thanks for reading and have a great weekend!

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.

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.

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.

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!

For modules that are not premium/pro modules, I'd love to see if their inclusion in core would be of benefit to the greater community. Many of, for instance, Robin S.'s modules aim to make the interface experience better for the end-user. Even if the code may not be 100% compliant to what the core expects, the very idea of the module may prove useful in improving the total user experience without the need to discover it elsewhere. Some extremely popular modules (ex: Tracy Debugger) may not be directly suited to being added to the core, so thought should be taken over its usefulness to all, not just specific circumstances or groups of people. Alternatively, is there a preferred way to request addition to core via the Feature Requests Github repository?

🎉 Now with Subscriptions & Webhooks! (v 1.0.8) In the past months, several frameless clients asked for an easy way to sell their content as subscriptions — without manually managing access. Think of a coach publishing daily audio files and offering a weekly subscription for them. That’s exactly what this update makes possible. 💡 🆕 What’s new in 1.0.8 Stripe Webhook support The module now listens at /stripepaymentlinks/api/stripe-webhook and reacts in real-time to subscription events — cancel, pause, resume, renew, or failed payment. → Access updates instantly. No cron jobs, no manual actions. Subscription handling Each purchase now stores a period_end_map, so the module knows exactly when access should expire. Pause or cancel a subscription → access is blocked immediately. Resume or renew → access restored automatically. Smarter access logic hasActiveAccess() now distinguishes between: recurring products (time-limited access) one-time purchases (lifetime access) Config update Added a field for the Webhook Signing Secret in module settings. ⚙️ Setup (2 min) In Stripe → Developers → Webhooks → Add endpoint https://yourdomain.com/stripepaymentlinks/api/stripe-webhook Choose either “All events” or only the relevant ones: customer.subscription.updated customer.subscription.deleted customer.subscription.paused customer.subscription.resumed invoice.payment_succeeded invoice.payment_failed Copy your Signing Secret into the module config. Done ✅ — test by pausing, resuming or cancelling a subscription and watch access update live. Short, clean, and 100 % ProcessWire-native. Perfect for creators, coaches, and anyone who wants to sell recurring access without maintaining users manually. Cheers, Mike

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

Back to the basics. Great stuff! Most of the forum posts are about new features. But I really enjoy reading about how to use PW, tips and tricks and such. Would love to see more of those and from Ryan himself especially.

New feature in StripePaymentLinks (v 1.0.7) 🎉 Hi, everyone! We’ve just added a sync helper to the modules config screen that can pull past Stripe Checkout Sessions into ProcessWire. Super handy if you want to… backfill older purchases migrate existing users or just double-check what’s in Stripe vs. what’s in PW How it works: Scans Stripe sessions (with date range + email filter if you like) Matches them to PW users by email Creates missing users (optional) Creates/updates purchase repeater items exactly like live checkouts Has a test-run mode so you can preview before writing You get a nice report right on the config screen (below "Sync now") with totals and per-session actions (SKIP, LINKED, UPDATE, CREATE) plus the line items. Makes it a lot easier to keep things in sync — especially if you had sales before installing the module. Note: since each run fetches sessions and line items directly from Stripe’s API, the total duration depends on network + Stripe’s response times. In our tests with ~120 sessions the sync took about 15 seconds. Grab the latest version and give it a spin. We already tested this version on some live projects and everything works fine, but always backup before you mess with data 😉 Feedback welcome! 🙌 Cheers, Mike

Beautifully done as always Robin!

@Robin S Good question, theoretically it's more efficient to hook to an object directly when it suits your need, though I'm not sure if it is in practice... I've not done any tests to measure. When hooking '$pages' it's called a "local" hook because it's local to just that instance named $pages (and the hooks are stored with the instance), whereas when hooking 'Pages', it's called a "static" hook and it keeps track track of it in the WireHooks class, as it would apply to any current or future instance of the Pages class. But there's only ever one instance of Pages (named $pages) so it doesn't matter in this case. https://processwire.com/api/ref/wire/get-hooks/ Another way of saying it: The $pages->addHook('method') and $wire->addHook('Pages::method') are technically different calls in that $pages->addHook('method') is saying "Hook method in JUST THIS instance of Pages" and $wire->addHook('Pages::method') says "hook method in ALL instances of Pages". While it may not matter in the case of $pages (since only ever one instance), it does matter in cases where there can be multiple instances of the class, such as with the $page class. In that case, you have a choice to make of "do I want to hook JUST THIS $page"... $page->addHook('method', ...); ...or "do I want to hook ALL Page instances" or "do I want to hook ALL BlogPostPage instances", etc. $wire->addHook('Page::method', ...); $wire->addHook('BlogPostPage::method', ...); What's more efficient about local hooks: If hooking just a single $page instance (or other type), then the attached hooks disappear when the $page instance does. When hooking all instances of a class, then that hook sticks around for the entire request, or until manually removed. When a single instance is hooked (local) rather than all instances (static) then ProcessWire only has to consider that hook for the one instance, rather than all instances. So less work. For $pages vs Pages, there's only one of them either way, so it probably doesn't matter much one way or the other in that case.

This is great! The filter feature alone is so good! Will save a lot of time. Thank you very much for this fantastic module!

Maybe one of these?

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 ✴️ New in v 1.0.8: Full Stripe subscription support with real-time webhook updates (cancel, pause, resume, renew) and smarter access control logic 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

Hi welcome back to paradise 😄 In my case, let's keep it simple. - blank profile for all sites - and generally speaking, no CSS framework. sorry, I realize that's a bit brief... let me elaborate a little, i used bootstrap a lot which once was a good selling point for agencies: “the website will be responsive with bootstrap” boom, sold... i still use it sometimes, but more for tools made up of forms and tables. In that case, i use purge.js and end up with a bootstrap of about 30 kb. today, the trendy selling point would be tailwind, for me, no way!!! 😄 i love css too much (scss for me) and clean HTML without 20 utility classes per tag. In the semantic vs. utility class debate, let's say I'm 90-95% semantic and 5-10% utility (my own little scss "framework" easy to modify and override without !important everywhere). well, I'm not sure if any of this is very useful 🙂 but the idea is simple: processwire offers so much freedom in coding, the least i can do is taking full advantage of it so, starting point... bare pw 🙂 have a nice day

https://github.com/processwire/processwire/archive/refs/tags/3.0.123.zip

Good luck to the Craft team, but to me it looks like they need to reinvent the wheel every now and then. Luckily, we have our own genius, Ryan, who figured that reinventing the wheel is not for everyone. At least not for us ;)

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).

In case you are using this module and want to sync customers/purchases to Mailchimp – we just released an add-on for this module:

Great post, thanks @ryan. I remember you saying somewhere that when hooking a $pages method it is more efficient to add the hook to the API variable. So better to do this... $pages->addHookAfter('saveReady', function(HookEvent $event) { // ... }); ...than... $wire->addHookAfter('Pages::saveReady', function(HookEvent $event) { // ... }); Is that still true? And if so, is it just the $pages variable that the advice applies to or is it broader than that?

I can confirm that the code I posted still works.

Yep, I confirm this still works today. However, the website in question is still using an earlier version of ProCache. 😄

With anything new that gets designed (a website, operating system, interface), there's always that initial cringe feeling because it's no longer familiar and comfortable, but after a couple weeks, that goes away. I'm developing a new site and using the new Konkat admin theme, which at first felt totally wrong, but now it feels just right (with 1-2 CSS tweaks, like to make repeaters jump out more). My brain is very picky about adjusting to new fonts... Inter in this case. I like the font a lot, but I just need to adjust to it, get used to the curves. Same thing with new versions of Windows when they change the default font. It's kind of like when Facebook went through a few major design changes at during the 5-10 mark and everyone would complain, then everyone got used to it. Anyway, great work. It's grown on me.

Hey @gebeer thx for that report! I have pushed your suggested fix on the dev branch of RockFrontend 🙂

[Update] Notify existing buyers and update purchases when products gain gated content (v1.0.10) Hi everyone, we’ve extended StripePaymentLinks based on a customer request. Some products evolve over time and later receive gated content (downloads, course pages, etc.). We now handle that case automatically. What it does: When an existing product is later marked as gated and has a stripe product id the module will: Notify existing users via an access email that new gated content is available for something they already own. Update all relevant purchase entries for those users so the meta object and the purchase_lines reflect the actual delivery page (page ID scope), keeping historical purchases consistent with the current site structure and enabling access control. No manual migration needed; it all happens in the background once the product is flagged as requiring access and the corresponding stripe product id is pasted. Available from now on in v1.0.10. Thanks for the request and feedback that led to this improvement! Cheers, Mike

PAGEGRID makes no assumptions about CSS or markup. This means that all CSS frameworks also work with PAGEGRID. I don't work with CSS frameworks myself, so I can't really recommend any (I prefer to use modern vanilla CSS like variables, grid, etc.). But I think it's totally fine to use them. I don't think it will have big impact on performance (depending on how large the CSS file for the framework is), just make sure to load your CSS fraemwork files inside the <head> tag so it's not blocking the rendering of your page. There are basically two approaches to working with PAGEGRID, but these can also be combined: No-code approach: You can create entire websites with PAGEGRID without writing any code yourself. To do this, you can use the “Ready-Made Blocks” and create CSS classes and styles with the Style Panel. This works similarly to Webflow or Figma and is particularly interesting for people who want to customize their website visually (which can be faster then doing it in code). Code only: If you prefer to work in code, you can disable the Style Panel in the PAGEGRID settings (Setup > PAGEGRID). You can then use any CSS framework with PAGEGRID. If you want to use your own CSS code or a framework, you can load it into your page template (take a look at the pagegrid-page.php template as an example). If you want to create your own blocks, you can copy the ready-made blocks from “site/modules/PageGridBlocks/blocks” to your “site/templates/blocks” folder and customize the markup there (e.g., add classes and markup for your CSS framework), or create your blocks from scratch. Learn more here: How do I create my own blocks? or here: how styles work in PAGEGRID. Here is an example of an accordion block using the UIkit framework as an example: <?php namespace ProcessWire; ?> <!-- UIkit accordion block using PAGEGRID's children option --> <ul uk-accordion pg-children="true" pg-children-label="Accordion Items" pg-children-tab="append" pg-autotitle="false" pg-wrapper> <?php foreach ($page->children() as $item) : ?> <li> <a class="uk-accordion-title" href><?= $item->title ?></a> <div class="uk-accordion-content"><?= $pagegrid->renderItem($item) ?></div> </li> <?php endforeach ?> </ul> In this example we use PAGEGRID's children option to render the accordion items (as child pages). Users can then add child items using the backend editor. You could also use repeaters to render the child items for PAGEGRID. The point here is that you can easily add whatever markup is neede for your CSS framework by creating your own custom blocks.

Unfortunately, only my PageGridBlocks are available so far. But it would be nice if the community created and shared their own blocks as well. My PageGridBlocks module makes it easy to install and uninstall block templates. It could be a good starting point for others. Another good option would be Bernhard's RockMigrations module to create the block templates. I think it would be best if those blocks would be installable as modules. It would be cool, for example, if someone created blocks for a specific CSS framework. Since I don't work with frameworks myself, this isn't particularly useful for me. However, there seem to be many people in the PW community who work with frameworks. If someone were willing to create and share their own block library, I would be happy to grant that person free access to PAGEGRID.

I assume that almost everyone who develops a new website in Processwire works with the Blank profile 🙂 The other existing profiles are more suitable for familiarizing yourself with the system 🙂

Strange I know, but you will want to remove the space after -f for this to work

Ah, I've found the answer to my question already. See phpMailAdditionalParameters on here: https://processwire.com/api/ref/config/ I assume this will do it in config.php: $config->phpMailAdditionalParameters = '-f bounce@example.com';

Tip: In Symfony Console, if you run code and an Exception or WireException occurs, ProcessWire will not be able to log it (and also send an adminEmail). There were cases where I was calling an undefined method on a page object and not knowing about it erroring. I used AI to work through this and ultimately it said I have to basically manage this myself because Symfony Console will catch things if I don't and never hit ProcessWire. Therefore, you may want to do something like this in your handle method: public function handle() { try { nonExistentFunction(); // purposely cause an error } catch (\Throwable $e) { // log the error $this->wire()->log->save('errors', $e->getMessage()); // consider adding additional code here to send an email notification using WireMail // ... // Re-throw so it still displays in console throw $e; } return self::SUCCESS; } I wonder if there's a more efficient way to do this? It took me too long to figure out what was happening in the first place so I haven't spent time optimizing the approach (if it's even possible).

I have found the issue: This only happens if the ID and name attribute are exactly the same on a single upload field. If there is a difference, everything works as expected, so I have added an additional suffix to the ID attribute of a file upload field to prevent this behavior. display-change.MP4 Now everything should work fine! Module version is updated, so please test if everything works now as expected.

@BFD Calendar Make sure you've got /site/config.php setting $config->debug = true; just so you can see errors. You may want to set it so that it's only in debug mode for your IP address, i.e. $config->debug = $_SERVER['REMOTE_ADDR'] === '123.123.123.123'; Keep an eye on the files in /site/assets/logs/, especially errors.txt. If you have shell access, you can "tail errors.txt" in that directory to see what the latest error messages are. You don't need to be able to login to the admin to view these logs, you can just locate them on the file system. Most of the time they will reveal whatever the issue is. If it's not clear, then post the last few log entries here to see if we can identify anything from it. The errors you mentioned may be expected, as it looks like they are trying to access something related to cgi-bin or a .well-known file, which are specific to your hosting and not to ProcessWire. So if your host blocks those addresses, then you'd expect to see this in the apache error log. Basically, I don't think those error messages are related to whatever is preventing your site from running.

Snapshot of the moment, got a Mac Studio with 64GB of ram and running around 8-10 projects everything goes smooth. Got the docker provider using around 16GB of memory. I do this too, but I don't auto run it on login. I can see how this could be a bottleneck, I don't think it's unbearable to start every project when needed since like you mention, you actively work in a few of them. With your 128GB of ram I'd definitely give it a shot because yolo haha. "ddev start --all" let's go!

Hi, @Jonathan Lahijani! I am pretty sure that your existing setup is superior for the multiproject needs of yours comparing to ddev. You try to standardize while ddev is all for making something custom. I would play with some new php stuff on ddev to keep up with the hype. But would stay with you current setup for the paid work.

Outstanding work! I also appreciate the botany refresher, this module is useful and educational.

Is there a way to remove sites from the ProcessWire Sites directory, that are no longer powered by ProcessWire or does this happen automatic? https://processwire.com/sites/ Sadly, I have a few websites, that are no longer powered by ProcessWire anymore. 🙁

Awesome. I use BunnyCDN as well (previously KeyCDN) configured with ProCache, mainly because they publish the list of IPs they use if their edge-servers need to pull assets (and then serve) from your website. While this post isn't directly related to your module, it matters if you are using WireRequestBlocker for the reasons I explained here (post only viewable if you have access). Long story short, if a CDN makes a request to a URL on your site that matches a blocking rule in WireRequestBlocker (rare, but it's bound to happen by accident) then the IP of that particular BunnyCDN edge-server will get blocked. Then if a visitor on your site is being sent assets from that edge server, then it will error because the CDN was never able to obtain it due to the edge-server being blocked. This is why the site might look fine in California, but broken in New York for example, as the user is being sent assets from different edge-servers. To prevent this from happening, I have a cronjob set up (runs every 24 hours) to grab the list of BunnyCDN edge-server IPs and I insert it into WireRequestBlockers "IP addresses to whitelist" field. This is a function that can do what I described above: function bunnycdnWhitelistIps() { if(!wire('modules')->isInstalled('WireRequestBlocker')) return false; // Fetch BunnyCDN edge server list $url = 'https://bunnycdn.com/api/system/edgeserverlist'; // Use cURL to fetch the content $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true); curl_setopt($ch, CURLOPT_TIMEOUT, 30); $response = curl_exec($ch); $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); if($httpCode !== 200 || $response === false) { throw new WireException("Error fetching data from BunnyCDN API. HTTP Code: $httpCode\n"); } // Parse the JSON response $data = json_decode($response, true); if(json_last_error() !== JSON_ERROR_NONE) { throw new WireException("Invalid IPs."); } // Extract IP addresses into an array $ipAddresses = []; if(isset($data) && is_array($data)) { foreach($data as $ip) { if(filter_var($ip, FILTER_VALIDATE_IP)) { $ipAddresses[] = $ip; } } } // Remove duplicates and sort $ipAddresses = array_unique($ipAddresses); sort($ipAddresses); $data = wire('modules')->getModuleConfigData('WireRequestBlocker'); $data['goodIps'] = implode("\n", $ipAddresses); wire('modules')->saveModuleConfigData('WireRequestBlocker', $data); }

The largest problem with the JSON-type WYSIWYG implementation of editors is that they all have their own custom implementations and conventions of how they represent the DOM via JSON. Quill was one of the first (that I was aware of) to have a complete and somewhat sane implementation therein. That said, since that seems to be the way editors are moving in general, I think it makes sense to go in that direction as well, but choosing should be made with care, determining as many pros and cons of features and technical decisions for the choice as possible. The topic that covers editor.js is: https://processwire.com/talk/topic/24876-pw-30170-– core-updates/ There was another one (I believe the next update by Ryan in News & Announcements) that partially continued the discussion, but most of it, if I'm remembering correctly, was here. Statamic's Bard uses TipTap, and prior to that used ProseMirror (TipTap uses ProseMirror under-the-hood which is likely why they were able to easily switch to TipTap; the same underlying JSON representation). EDIT: I think @jploch's module, PAGEGRID, originated out of that discussion. 🙂

I think having seen Kirby CMS' blocks editor last week that that sort of UI with the JSON storage behind the scenes could be the way to go. I think some mashup of the JSON storage from one of those editors, Kirby's UI and the way the Pro Custom Fields module has its fields configured would be the perfect blend and then get rid of the need for Repeater Matrix for a lot of things. Some limitations would be that you have to store images/files somewhere but it's easy enough I guess to just have a field for each that acts as a bucket and the block editor references them. If the UI was advanced enough they could be there but hidden or something. I'll see if I can track down that other discussion - sounds interesting, thanks Brendon!

I think experimenting with a block-style editor would be great. In the very large discussion over WYSIWYG editors (I don't recall of this was a 2025 wishlist, or a discussion of the future of TinyMCE/CKEditor, but it had a LOT of paginated responses), a few people even experimented in creating a proof-of-concept with editor.js, showing their results. I gave it a shot but determined the end result (interface) was too cumbersome for most of my users (and I usually try to aim for a very low bar as a standard; less complaints / support needed). Even in the demo (tried today) I was able to cause a rendering bug in both of the editors mentioned (TipTap, Editor.js) above. That said, if a true module is attempted to be released, since they render and use JSON as the underlying structure, I would recommend using a similar database structure to TinyMCE and/or CKEditor, and save the HTML-rendered output in a field just in case someone wished to switch back to a standard text editor for a particular field. (Unfortunately that means only one-way compatibility, however - and increased storage costs/size...so maybe an option for that in the module.)

@ryan was there ever any movement on this, they are now up to version 8.1.2. I don't keep up with the WYSIWYG landscape, does it matter that PW is so far behind?