Recently Updated Topics

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/

Hello PW friends, Is it possible to hide a template and prevent all accesss to a template in the backend except certain users. Thank you

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

Thanks @zoeck - seems like the documentation for all this is spread all over the place which I don't think is helping Ryan get renewals. Honesty I would probably have renewed more often if I'd known about the cheaper price.

Hi @Morphosis - glad you found a solution! Based on the module documentation on Github, you can also define this in your site/config.php using an array-based syntax. Choose whichever method you would prefer! Example: /** * Module: SearchEngine * * Override any module settings or other config values here. Anything set here * cannot be overridden. * */ $config->SearchEngine = [ // Render arguments affect the rendered output from the SearchEngine module. 'render_args' => [ // Various attributes used by the search form and results list when rendered. 'form_action' => '/search/', ] ];

I think @Pete may have run updates on the forum software. If that is the case, it may be related.

Hook after Page::addable. $event->object will be the page to add a child to. Untested example code written off the top of my head: <?php namespace ProcessWire; // For ready.php wire()->addHookAfter('Page::addable', function(HookEvent $event) { $thisPage = $event->object; // Exit early if already disallowed if(! $event->return) return; // Only apply to pages with template article-list if($thisPage->template->name !== 'article-list') return; // Now check the fields on the page whether they allow // adding children. Adapt the field name to your use case. if($thisPage->dateslistrepeater->count() == 0) { $event->return = false; } }); This should disable the Add / Add Children button. You'll probably have to save the page after adding a repeater item before you can add children from the page editor.

I'm no longer maintaining any of my modules. If someone wants to take them over, let me know. It's been a long time since I first asked, but nobody has reached out.

@Peter Knight — if someone could fully take it over (along with any other modules that matter), that'd be the most ideal scenario. Imo, forking may as well be a new project… Larger PRs are a no-go I'm afraid, unless someone is willing to fully test them, in which case they may as well take a leap and become maintainer 🙃.

It appears the notifications on mobile when you use the PWA feature are in InvisionCommunity version 5 (we're on the latest 4.x branch) so that's coming later™ - major version upgrades in this forum software are usually complete rewrites 😅

Small update following a small issue I had: when saving a template the module now makes sure "sortfield_reverse" is unset, in case the user was previously sorting using a reversed sort direction

@BillH Thank you so much! Setting up a custom upload folder solved it! I wonder why some servers return an error when using move_uploaded_file, although its seamingly works just fine?

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

Hi community, is somebody having an answer or news on this? Kind regards, ottogal

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:

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

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

Hello all, @BFD Calendar - this did actually the trick. If no user is logged in the textblocks render once as expected. Thanks for the hint! I also figured out, that this behaviour depends on frontend editing, which is enabled for this particular field in my case. Once this is disabled, it also works fine even when logged on to processwire's backend. For my scenario I m fine, however, I think it is a small glitch and could be enhanced... any opinions if I should file a bug report for this and how and where? Many thanks!

FYI, you can view all the template access overrides for a field on the Overrides tab of Edit Field.

Ok, thanks. When I get a few minutes I'll take it up again and see what happens.

Thank you - this is really useful to know. If I’m understanding it correctly I think we’re ok in this instance as we’re only pushing content to Bunny via API rather than the CDN hitting the site itself. It’s definitely early days though and I think there will be lots of edge cases to look out for. We’ve thrown this together for a product MVP that will have some ad traffic sent to it, so there should be plenty of data to look at. The main motivation at the moment is to minimise the data storage burden vs local storage on the VPS where the rest of the site runs rather than performance optimisation. But caching/compression etc will be interesting next steps.

Thanks! I'll see what our host (OVH) says and keep you posted.

Hello! I want to find out if this plugin is able to take over all mail sending within ProcessWire automatically by simply replacing the default WireMail Class. If so, where can I configure "SMTP via OAuth" like it is described here: https://github.com/PHPMailer/PHPMailer/wiki/Microsoft-Azure-and-XOAUTH2-setup-guide Is that even possible, or do I have to manually go through all my websites forms and send the mail programmatically? Luckily, I do have all the Azure Application-IDs and secret codes right here, but where do I fill them in?

I don't get a notice from LRP either. For the backend, I tried both a dash and now an underscore and neither work. I did manage to login via the backend after a few attempts.