All Activity

Yeah the 2.0 seems it runs smoothly with no issues. If on your tests is working great too then sure make the 2.0 the new master version.

Update (1.1.1) – image downloads and UI improvements Hi all, A couple of releases on from the grid-view update, with a proper new feature this time. @adrian asked for a way to pull images back out of the library, so downloads are in: every thumbnail now has a download button that hands you the original file, not the table thumbnail. Tick a few images first and instead of separate downloads it bundles the whole selection into a single ZIP. It uses the same selection you already use for bulk edits, so it stays consistent with the rest of the module. A few things around it got nicer too. The small per-thumbnail actions (replace, delete, download, select) now use a custom tooltip instead of the browser's native one, and on a multi-selection they tell you what the action will actually do, e.g. "Download 8 selected as ZIP". And replacing a file in place finally gives proper feedback right on the row, success or error, instead of failing quietly. One under-the-hood change worth a mention: the module no longer loads on anonymous front-end requests. There was no reason for it to run on a normal public page view, so now it doesn't, and a guest hit carries zero overhead. Admin, logged-in editors and front-end inline editing all behave exactly as before, and the hourly de-duplication / where-used maintenance still runs. (thanks @adrian for the nudge on that one too) Feedback and bug reports welcome, Cheers, Mike

I (+the firm I working) don't give clients superuser (and for that in the consequence TracyDebugger + Modules Config) control as long they are not self-hosting + don't want support from me/us. They get a very clear communication, when they give superuser/admin control in the CMS, that they can break things and when they also don't maintain the backups, that it can lead to data lose and will be costly to repair. Most costumer don't need superuser access. We have one instance where a costumer has a separate account as superuser because of a module configuration they have to update periodical (WireSMTP). But that individual know what his competence limits are and LLM's are not trustworthy to make change on the live stage of a site. It is not about that they always wrong, but on a live site, it is enough when they are one time fail big time. A customer that begin to "re-write" files of the template, on his live website, is not a customer for us. Not as a "hate" thing, but that is a complete different customer cycle. Our customer use us as a "trust agent". So when they have an idea, we are taking care and also is that what a LLM prompt suggest really the best way of doing it. They also expect from us, that we test that before we break their live website. When a customer want to prompt their website, there are better service and cheaper one to fulfil that goal. Sorry I have the feeling I rant a little bit. It is not against you or your customer. I want only share how we are doing it and try to avoid that particular problem.

I agree with @Peter Knight - I set --pw-main-background: #fbfbfb; on all my sites, but I am sure#f5f5f5 would also be a better default.

So does that mean that 2.0 fixed all the issues that you just reported as being present in 1.4.1? Can I make 2.0 the new master version?

There've been a few instances published about AI models going to extremes to solve a question. It's not that AI is malicious or over-eager to please. It's how it's wired. Find an answer or best guess or stop if there's an off-switch in the prompt when the goal cannot be reached. I have a non-technical client who thinks AI is the bee's knees and the answer to his content/SEO/GEO prayers. Client has no DDEV/SSH/FTP site access or coding knowledge. Claude app navigated the owner to the TracyDebugger console in admin to fulfil the owner's request to update site content. Client had no clue about TD until that moment. Claude did. It took client through a questionnaire about installed modules. Claude only had a 'snapshot' of pages, no holistic understanding of db, templates, etc. Client now thinks TD console is the best thing ever. He asks Claude a question. Claude answers and tells client to copy/paste it into TD console. Am now busy trying to bring Claude under control with audit trails, approvals and convincing client to use @ryan AgentTools to minimise risk. Yes, on live production site. OMG! No matter what your views on AI, it's out there and loves PW.

Following up on my earlier comment about the background colour - here's a quick side-by-side to illustrate (bottom of post). The proposed change is simple: lighten --pw-main-background from #eee to #f5f5f5 (a shift of less than 3%) Three reasons it's worth considering: #f5f5f5 is already the background colour used on processwire.com, so it brings the admin in line with the brand. It feels noticeably lighter and less industrial in practice. A few of my clients have used that exact wording. For module builders, it opens up more tonal room to work with subtle layering and contrast. I know it's not quite a single variable change. Borders and dividers calibrated against #eee might need a look too, but it's pretty close. You'll see below that it's just a whisper lighter. But in practice users get brand consistency, general lightness and approachability. In practical terms, this is involves transitioning from 93% to 96% white. Copying in @diogo in case this is useful feedback as the theme evolves and celebrates its birthday around now. And finally, in case it needs to be said, the KonKat theme is clean, considered and feels like a proper step forward for the ProcessWire admin. It's a really thoughtful piece of work by people who sweat the details, so I hope this feedback can be taken in that spirit.

Hi @adrian, sorry for taking so long. 1.4.1 Version I did some testings and the problem is almost fixed. With a core image field it's working fine but when having also a "CroppableImage3" field on the same template there is an issue. After I upload and insert an image on the body field, press save and view the frontend source of that page, all the UTF-8 characters from the body field is converted to html entities. I have to press one more time the Save button to convert those UTF-8 characters back to normal. 2.0 Version Didn't noticed any issues.

@HMCB, happy you like it! Everything is handled by PW, no need to change anything in your templates or editing behavior. The module is admin-only and never touches front-end rendering. In templates you use the normal API ($image->size(), ->width(), ->url, …) and PW generates/serves variations exactly as always. Rename: PW has no immutable ID column for files. The filename is the identity (stored in the field’s data column). So a rename is a real on-disk rename, and PW core (Pageimage::rename(), 3.0.172+) cascades it: the original plus every size variation (foo.300x200.jpg → bar.300x200.jpg) and any .webp sidecars are moved, not deleted or regenerated. The new name is committed on the next $page->save(). Our module adds two things on top: it re-keys its dedup fingerprint rows and rewrites rich-text embeds that referenced the old URL, so disk, DB, dedup index and embeds stay consistent. For a new project I would strongly recommend having a look at @Peter Knights MediaHub instead! The main purpose of the module was to handle existing installations. Cheers, Mike

Hi Gabor, sorry this one slipped through and thank you for being one of the first users to test it — that feedback is exactly why we can improve it. You’re right about this: upgrading from 1.1.9 could hit a config-time issue with ContextConfigFields, which made the module fail to load in some setups. I’ve fixed this in Context 2.0.1 (it now properly loads the config helper before the static config method uses it). You can grab the latest version here: https://github.com/mxmsmnv/Context/releases/tag/v2.0.1 If you can, please try reinstalling/updating to 2.0.1. That should remove this error. Sorry again for the trouble — thank you for the patience and stay tuned, I’ll keep these upgrade paths as stable as possible.

hi @BrendonKoz exaclty like you said in your answers, the first thing i thought about was all those directories i use outside pw /site one for special cron jobs (not lazy ones :)) downloadable files and so on without any problem... but you're right, first thing to check is if the host allows htacces protection (if not, time to change because it would sound a bit prehistoric 😄 ) afterwards, maybe the url he gives as pw htaccess prevents direct access to php files for exemple that why my second thought was to exclude the directory from pw htaccess rules and then put his own ones in the directory htaccess and see what happens, it's a bit harsh but also a simple debug attempt 🙂 have a nice day

Good suggestion, @virtualgadjo! I'm still confused at why floko's attempt, as described, did what it did. Maybe I'm just too focused on the problem as opposed to the solution! 😅 Still, a 404 error should provide an error log somewhere, but if it's an Apache-level error, ProcessWire wouldn't handle it. PW would display its 404 because it's been configured to do so whenever a 404 error was created by the Apache webserver. Apache logs don't show up in ProcessWire, they'd be at the host (account) level. Unless there's proof otherwise, it may even be possible that the host doesn't allow basic auth using htaccess and htpasswd files...?

Simply amazing. This will go into w Rey one of my PW installs. Thank you big time. Questions: Image sizes for the front end are handled like we normally do through PW? If an image is renamed, the alternate size versions are also or does PW handle that through an ID column which never changes?

Hello @maximus Thank you for the new version. I could not upgrade to it, so I uninstalled the module instead, but I guess you are interested in the error I got after upgrading from Context 1.1.9 to the latest. I am not sure if I will try to use Context 2 or not, as currently I am into Ryan's AI modules to learn how they can aid my workflow.

FYI - latest commit fixes that bug.

Yep, that was the main motivation behind this implementation. Now I only have to touch one file per template.

Hi @gebeer - great write-up! RockPageBuilder already has a built-in show key in each block’s info(): 'show' => 'template=project', // selector string // or 'show' => fn($page) => $page->template->name === 'project', That filters the add-menu via getAddableBlocks(). For a handful of blocks with simple rules, it’s the quickest path — no hook, no template metadata. Your rpb_blocks_allowed + getAllowedBlocks hook is better when: the same RPB field sits on multiple templates with different palettes you want the allow-list in the template migration (one place), not scattered across block files you need enforcement at getAllowedBlocks level — show is UI-only; API/programmatic creation goes through isAllowed() and ignores show So: show = per-block, UI convenience. Your hook = per-template, centralized, actually enforced. Also worth noting: RPB already scopes by field folder (/site/templates/RockPageBuilder/{fieldname}/) — that’s a third axis, useful when different fields need different palettes regardless of template. Ask your AI if you want to know more. Thanks for documenting the hook pattern — it fills a real gap show doesn’t cover.

@floko my pleasure, il's usually a very easy way to exclude a directory from the rules of an htaccess that is at the root level and, of course, allows to submit this directory to its own htaccess rules have a nice day and nice 14 days away from your computer 🙂

Hi, Thanks a lot, I will definitely try! (I have no access to my computer for the next 14 days) Thanks again!

I stepped into some minor issues whilst setting up the demo shop. So please be patiant, I guess I'll get it together tomorrow.

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