Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/25/2025 in all areas

  1. Let's say you have a repeater field. ProcessWire renders it in the default ProcessWire way in the page editor, which is fine, however there are times where you may want to render a particular repeater field in a more streamlined way, like a table, while maintaining the ability for the user to make changes to field values of the respective repeater items. The problem with this however if that you must be very careful because if you do not represent a field of that repeater (and represent it correctly with the correct form "name"), then ProcessWire will wipe out the data because it expects it to exist when saving!!! This includes the "native" fields for a repeater item (which are "loaded", "sort" and "publish"). THOSE MUST ALSO BE REPRESENTED! For fields in your repeater that are hidden however, they do not need to be represented, so you can ignore rendering those. You have to be very careful here because you may one day decide to add a new field to a repeater and keep it as "Open", and forget this requirement and not add it to the your custom renderer. Then if you wrote data to the field in some way, and then a user went to edit a page that contains that repeater field and they save, your data will get wiped out!
    1 point
  2. 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/
    1 point
  3. @Robin S Thank you very much for your work. I was going to write a similar module myself, but yours is even better than I could have imagined.
    1 point
  4. @horst - there are lots of new theme issues being posted to Github
    1 point
  5. @Spinbox I'm not sure why that wouldn't be working if the fields are initialized with a translate button. I've never nested RPB fields. I'd like to support whatever features RPB has. I've reached out to @bernhard to see if there's anything that he may know of to help or confirm that nesting is supported. Will come back with more info when I can.
    1 point
  6. Perhaps give $user->isSuperuser() a shot instead. It's documented as faster and is my go-to since it's a dedicated method.
    1 point
  7. [Update] StripePlMailchimpSync — v0.2.0 Hey, all, a fresh update for anyone using StripePaymentLinks together with Mailchimp! Version 0.2.0 adds proper resync tools, better reporting, and a few smart fixes under the hood. ⸻ 💡 What’s new Resync from the module settings You can now trigger a Mailchimp resync right inside the module config. Pick a date range, filter by buyer email if you like, and choose between dry-run or live mode. Each run generates a detailed report — showing who was synced, skipped, or caused errors. ⸻ Real-world use case: Your client’s been happily selling with StripePaymentLinks for a while — but only now decides to start using Mailchimp. With this update, you can sync all past purchases into Mailchimp in one go, safely and transparently, straight from the module config. Always open for feedback or ideas — if you’re using this in production, let me know how it works for you or what you’d like to see next! 🚀 Cheers, Mike
    1 point
  8. Yes, mod_security would be my first suggestion as well.
    1 point
  9. As I already told you in a private conversation, you should contact your host provider or turn of mod_security.
    1 point
  10. @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.
    1 point
  11. Outstanding work! I also appreciate the botany refresher, this module is useful and educational.
    1 point
  12. Beautifully done as always Robin!
    1 point
  13. 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.
    1 point
×
×
  • Create New...