All Activity

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

@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 🤪