All Activity

Hi @David Karich, glad it looks useful! Fair question. The honest answer is that a lot of the module is genuinely image-specific – the thumbnails, the native crop/focus per-image editor, dimensions, and the byte-identical de-duplication of image variations. None of that maps onto plain file fields, so it’s not just a matter of flipping a “files too” switch. The core idea – one cross-site inventory of every file in your fields, with where-used, bulk metadata editing and dedup – isn’t inherently image-only, and could in principle be generalised. It just wasn’t the need this was built for (see the first post in the thread), so it’s not on my near-term roadmap. If you’re after a more general, file-aware media solution out of the box, it’s well worth looking at @Peter Knights MediaHub module – it approaches media / asset management more broadly and may already cover your file-field use case. That said, this one is MIT-licensed and the discovery / table / where-used layers are fairly self-contained – so a fork (or, even better, a PR that abstracts the image-specific bits behind an interface) would be very welcome, and I’m happy to point you at the right seams if you want to dig in. Cheers, Mike

Hi everyone, I’m preparing a new ProcessWire module for release: Panorama. Panorama is a media audit and maintenance toolkit for ProcessWire images and files. It is built for sites where media is spread across many templates, repeaters, galleries and file fields, and where you need one place to understand what is stored, where it is used, what can be cleaned up and what needs attention. What it does Media dashboard with totals, disk usage, average size, recent uploads and largest files. Breakdown by file type, field, page and template. Visual Explorer for browsing media by gallery, page or template. Detail drawer with owner page, template, field, dimensions, file size and image variations. Duplicate finder with background scan, visual cards and reclaimable space estimates. Alt text audit for images missing descriptions. Cleanup tools for broken references, orphaned originals and orphaned variations. Background image variation warmup. Bulk actions for selected media. CSV export. Support for Repeaters, Repeater Matrix and FieldsetPage ownership where possible. The heavier thumbnail-based sections load in the background, so the main admin page should stay responsive even on media-heavy sites. Requirements ProcessWire 3.0.227+ PHP 8.3+ Repository GitHub: https://github.com/mxmsmnv/Panorama

Hi @Mikel That looks like a very useful module for existing installations. I’m looking forward to testing it next week. Just one crucial question first: why only image fields? I’d have the same use case for normal file fields. Would it be possible to extend the module to work with files as well?

How small things can make life easier for your site editors One small (but big) thing we wanted on a recent RPB build: editors should only see the blocks that make sense for the page template they are editing. Project pages get the ~10 project blocks, landing pages get their own set, and nobody has to do per-page fiddling or choose from 25 blocks where they only need 10. Repeater Matrix makes this possible via per-template field overrides. RPB needs a little custom nudging here, but that can be pretty straightforward as you will see. The nice bit: RPB already has exactly the right hook point. RockPageBuilder::___getAllowedBlocks($field, $page) returns a BlocksArray, so we hook after it in our site/modules/Site.module.php and remove anything that is not in the template's allow-list. This runs with priority 1000, so RPB's own populate hooks have already done their thing. Shape of that hook: public function ready(): void { $this->addHookAfter( 'RockPageBuilder::getAllowedBlocks', $this, 'filterRockPageBuilderBlocksByTemplate', ['priority' => 1000] ); } public function filterRockPageBuilderBlocksByTemplate(HookEvent $event): void { $page = $event->arguments(1); $allowed = $page->template->get('rpb_blocks_allowed'); if (!is_array($allowed) || !$allowed) return; $allowed = array_flip($allowed); $blocks = $event->return; foreach ($blocks as $block) { if (!isset($allowed[$block->className()])) { $blocks->remove($block); } } $event->return = $blocks; } Allow-list implementation (the really smart bit) The allow-list lives on the template itself as a custom property called rpb_blocks_allowed, stored in the templates.data JSON column. Yes, templates support meta data just not exactly like pages. There's no public $template->meta() API. PW is cool nonetheless! We set that data declaratively in the template's migration file (config migrations to the rescue). RM picks that up and applies it via `setTemplateData()`. No new field needed, because a field would be per-page data, and that is the wrong tool here. At runtime it is just $page->template->get('rpb_blocks_allowed'). Templates without a list keep the full block palette and are completely unaffected. What that looks like in the template's migration file: // site/RockMigrations/templates/project.php return [ 'fields' => [ 'title' => [], // ... the template's normal fields ... 'rockpagebuilder_blocks' => [], ], // RPB block allow-list for this template, stored as a custom property // in templates.data and read by the getAllowedBlocks hook. 'rpb_blocks_allowed' => [ 'ProjektHeader', 'TextIntro', 'ImmobilienUeberblick', 'ImageModul', 'Video', 'BildText', 'Zitat', 'Awards', 'FAQList', 'NewsTeaser', ], ]; This also turned out to be nicer than expected: it is enforced in the editor add-menu and for API/programmatic block creation, it still composes with every block's existing info()['show'] selector, all template config stays in one clean migration, and there are zero core edits for RPB updates to clobber. Tiny gotcha we proved along the way: Template::meta() does not exist. Page has meta(), Template does not. That is exactly why templates.data plus a custom template property is such a neat fit here. Big thanks to @bernhard for making RPB so hookable. And @ryan for baking in meta data support into the Template class. This is one of those ProcessWire-ish solutions where the final code is boring in the best possible way: hook the right method, keep the config where it belongs, and let the rest of the system keep doing its thing. Happy blocking! BTW: RockPageBuilder is awesome and free on github: https://github.com/baumrock/RockPageBuilder. So what are you waiting for?

hi, have you tried the simple RewriteRule ^(yourdirectory)/.*$ - [L] in pw htaccess ? it may be a simple and easy solution not to have to go and implement a more complex workaround have a nice day

@BigRed You could download the last version from here: https://github.com/trk/WireMailPHPMailer/releases Or if you upgraded using the upgrade module, then the old version would still be in your modules directory, with a dot. You can just delete the latest and undot the last one.

Do not make de-dust my Kinesis Advantage 2 or ... whatever is sitting somewhere in my shelves.

Understood. Thank you for answering my questions.

I'm planning to set up a demo shop tomorrow so you can get a first look. I'll update this thread once it's up and running.

You can send one that you do need to me. My niece is coming this summer too, just post it to her address first please :D

Working now 🙂 Thank you, Peter!

All done. Could you try again @dynweb P

Hey @dynweb Thanks for flagging that. I'll look at it now.

The download seems not to work:

If you keep discussing keyboards, I’ll end up with another keyboard I don’t need 🤪

Just a note for everyone to be aware of this critical bug in this version if you have any save hooks: https://github.com/processwire/processwire-issues/issues/2269

I don't think I actually remapped the space keys to something, but you could. You could make it a Hyper key or whatever. I rarely use that keyboard nowadays but I used it a lot for writing. It's such a great keyboard for typing for hours. Getting some special characters is quite hard and you need to learn a lot of different new and unnatural key combos, so not for daily coding tasks - neither in the past, nor today. Finally! 🤣

That's a really good use case, @adrian, thanks for spelling it out — "grab the original, tweak it locally, upload it back as the replacement" is exactly the kind of round-trip the library should make easy, and it pairs naturally with the Replace button that's already there. You're right that pulling the full-size original out of PW is unexpectedly fiddly without something like RockAdminTweaks. So I'm sold — a download affordance on each thumbnail earns its place. We'll add it. On the Replace/extension thing: glad that cleared it up. And on the back of this thread we've actually loosened one corner of it — .jpg ↔ .jpeg (and .tif ↔ .tiff) are the same format, and since Replace writes onto the original filename anyway, rejecting a .jpeg over a .jpg was just overly strict. That's fixed now, so the format match is about the actual format, not the literal extension string. Replace action now gives you visible, inline feedback right next to the affected row — a green confirmation on success and a red message with the actual reason on failure (so a problem like a non-writable file no longer fails silently). As for renaming: YES: Renaming a file through the library isn't just a cosmetic relabel — it rewrites the references too. It updates the field/file on disk and then rewrites the embeds in your rich-text (RTE) fields that point at the old URL, including embeds that live inside (Matrix)Repeaters, so the "Used in" links keep resolving and nothing 404s. That's the whole reason rename is a first-class action in the library rather than something you'd hand-edit. Cheers, Mike

My reasoning for wanting a download is so it's easy to get it, modify it in a local image editor and upload it again as the replacement for it. I feel like this is a good and valid use case. I do use RockAdminTweaks to add a download button to an image in the page editor, but without that, downloading the fullsize version of any image in PW is actually very fiddly. Thanks for the explanation about the replace restricting the extension. I didn't realize just how it worked, keeping the same filename etc. I am related note, does renaming a filename in the interface also replace all references to it in RTE fields?

@adrian, its very simpel activating columns and reordering them, on desktop its simply drag and drop, on mobile you got arrows. The checkboxes are shown only when active, clicking on the column name (or row) checks/unchecks. Bildschirmaufnahme 2026-06-19 um 20.08.51.mov Download button: I'm not sure this one fits the concept, to be honest. The library is meant as a central audit/management view of images that already live in your fields — where they're used, duplicates, inline metadata edits — and the original files are already reachable through their normal URLs (and via the page editor). A "download" action sort of cuts across that purpose, so before we add UI for it I'd rather understand what you're actually after. What's the use case? A few things it could mean, and they'd point at different solutions: grabbing originals to re-use elsewhere on the site → that's really what Insert/Choose from library already covers pulling files out for offline backup / handing to a client → more of an export concern than a per-thumbnail button just quick access to the full-size original → a click on the thumb takes one to the file and all variations. If you tell me the scenario, I can figure out whether it belongs here at all, or whether there's a better-fitting way to get you there. Replace and extensions: That one's intentional, though I can see why it feels off. Replace deliberately keeps the exact same filename — and therefore the same URL — so that every existing reference to the image (field relations, rich-text embeds, the "Used in" entries) keeps working untouched. Since the extension is part of the filename, allowing photo.jpg → photo.png would actually change the URL and silently break all those references. So Replace pins the format on purpose; it's a "swap the bytes behind this exact file" operation, not a "change the format" one. Our daily use case is replacing unretouched layout files with the finished images. If you genuinely want a different format, deleting the old image and uploading the new one is the right path — that gives you a new filename/URL, which is what a format change really is under the hood. The field's allowed-extensions setting is a separate thing (it governs new uploads); Replace is intentionally stricter than that. I could probably make the error message clearer about why, though — point taken. Cheers, Mike

Sorry, I just noticed the column ordering options - I know it explains what to do, but I think a move icon next to each one would make it clearer. I also do feel like there needs to be an option to set the default order in the settings because site editors will likely not realize they can reorder them.

Sorry @Mikel - the page column was staring me in the face, but because of the order my columns are appearing it was right next to the image and I think I sort it felt it was an image label or something. But I am curious how you are changing the column order? I also can't get the Used In column to appear. Should there be a checkbox to check here: Another request, but could you add a download button to each thumbnail? Also, when I use the "Replace" button, it won't let me upload an image with different extension to the existing image - is this intended? It feels off - surely any extension supported by the image field should be allowed?

Good catch, @adrian, thanks. It was the user page, not the separate tab. Confirmed and fixed. Already on main if you want to pull it. (via GitSync) If I understand this correctly, we already have this feature (and more): Just activate the columns "page" and "used in" and these show you all pages the image is uploaded to (page) or placed in a rich text field (used in). Page column is showing duplicates and the Used in modal shows the corresponding fields. And of course all with links to their pages. But maybe you meant something different? Always open to improvements 🙂 Cheers, Mike

Hi @Mikel - what do you think about having a column that lists (and links to: edit and view) the page that the image is uploaded to? Obviously the parent page, not repeater item pages. Also, I am seeing an issue where editing an image that is on a user page and on separate tab (not the main content one) doesn't strip out all of the other fields - I actually get the full page edit interface. I haven't tested, but I expect it's the user page issue, rather than the separate tab.

Update (1.0.4) – a grid view, and revamped icons Hi all, small but nice update. A client asked for a square-tile grid view, so it's in: alongside the existing masonry gallery and the data table, you now get a uniform thumbnail grid. The three layouts sit behind one toggle (grid / masonry / table), styled to line up with ProcessWire's own image-field view switcher so it feels native rather than bolted on. While doing that we also reworked the toolbar icons. The upcoming core moved its icon set to FontAwesome 6, where a few of the names we relied on changed or dropped out, so the toggle could end up blank depending on your core. To keep it stable across versions, the view/columns/manage icons are now bundled with the module itself instead of leaning on whatever FontAwesome the core ships – so they render the same on current and upcoming ProcessWire. Update via GitSync or the modules directory. Cheers, Mike