Leaderboard

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

Happy Friday, everyone. I'm starting this Friday with something I meant to do last Friday! The latest version of MediaHub (1.19.25) is now available, and thanks to our testers, we have improvements across the UI, module performance and some new features too. Existing Media hubbers: Download here New to hubbing: Read here Full changelog: Read here What's new and improved in 1.19.25... Upload screen refresh Uploading is one of the first things a new user will do, so the first impression should be positive, distraction-free and simple. But behind a screen that seemingly has 'just one job', people asked if they could organise their uploads from here. While organising uploaded assets within the Library is simple, being able to associate your uploads with your Collections and Labels from the upload screen will save you a lot of time and asset admin. An "Organise uploads" bar above the dropzone lets you assign Collections and Labels before the batch starts. If one doesn't exist yet, you can create it from here. A scrollable card queue replaces the old list. Each file shows a thumbnail or file-type icon, inline status, and a per-file progress bar. Oversized or unsupported files stage with a clear warning and are excluded from the upload. Inline filename editing on each card is possible before you upload. We'll introduce a table view shortly if you're uploading at scale and want to sort and filter at this point. Once your upload starts, you can see the progress of each file and a master progress bar. Custom fields on assets Adding custom fields to a MediaHub input field works the same way as the existing workflow. Should you wish, you can also assign custom fields to a master asset depending on your use case. You can assign custom fields to your master asset or just the MediaHub field on your page. They work indenpendently when you want, but also have a relationship with and inherit-with-override model. Inherit-with-override works the same way Title and Alt already do: The asset detail page (left) holds the canonical (library-level) value. Every reference inherits it by default. On a page, custom fields appear below Title, Filename, Description, and Tags. An editor can override the value for that one reference only. The override saves when the page saves, no separate save button A small reset control next to any overridden field lets you revert to the library value in one click On a MediaHub input field, a developer can choose to display custom fields in a different order than on the asset detail page Two tiers Some metadata belongs to the asset everywhere (a photographer credit, a licence URL). Other metadata belongs to how the asset is used in a specific field. Both are supported: Asset-level fields go on pkd-mediahub-asset. Master value plus per-reference override and reset Field-specific fields go on a template named mediahub-field-{fieldName} (mirrors ProcessWire's native pattern). These appear only in that field's drawer and are per-reference only, no library master I hadn't planned on allowing custom fields on the asset detail page, but it was straightforward once I added some of the standard text-based fields. It works in the same way you'd add a field to any template and doesn't even require the extra custom field to input field step (creating an extra fileless template). Anything on that asset template that isn’t one of MediaHub’s built-in fields: title, image, alt, labels, collections, and so on - is treated as yours. Should you wish to uninstall MediaHub, we have safeguards in place to keep your custom fields on your ProcessWire install, which is what I think you might want. The only real downside I have found so far is that custom fields on the master asset template show on every asset detail page, so a name like Photographer fits a photo but feels odd on a PDF or spreadsheet. What has worked for me is broader labels from the start (Source, Description). We plan to make this more asset-aware in a future release, but for now, name fields as if every asset type will see them, because they will. But, this is just a side note and doesn't affect input fields, which was the core feature and of the 1.19.25 release. Library thumbnails 1.19.25 takes a leaner approach to thumbnail generation and makes more effort to reuse thumbnails across the UI vs generating the full scope on upload and import. One preview at upload. Each image gets a single small proportional preview. That's 75% fewer auto-generated files at upload time. One library thumb per asset. Grid, Masonry, and List share one canonical thumbnail. CSS handles grid cropping. Built on first browse. The full library size is generated the first time you scroll an asset into view, not during upload. The upload preview is shown immediately as a placeholder so nothing looks broken while it's being prepared Import Existing Images and the asset picker use the same on-demand model. Bulk imports of existing assets from existing fields should feel noticeably lighter on disk and CPU. Library bulk actions and toolbar The search and filter area of the Library was cleaned up for consistency and clarity in advance of some architectural changes (more below) Selecting assets now swaps the breadcrumb row for a compact bulk action bar with actions for Collections, Labels, and Delete. There's a useful workflow change here: you can select assets first and then create and assign a collection in one step, rather than having to create the collection first. Library and picker consistency MediaHub looks like it has one central Library, but under the hood there are actually three slightly different versions of it: the main Library, the InputfieldMediaHub picker, and the TinyMCE picker. Over time I found that improvements made to the main Library were easy to overlook on the other two, since they didn't share any underlying code. To reduce that drift, 1.19.25 moves the toolbar, sidebar, filters, and tiles onto shared partials so all three surfaces stay aligned going forward. This isn't just a tidy-up under the hood either. It lightens the module overall, and it's what made it possible to introduce the Collections and Labels sidebar into Library screens that didn't have it before. Import page images The ability to import images from your existing fields was an early feature and has been in MediaHub since v1 1.19.25 gives it an overhaul. BTW the import Page Images button is optionally enabled in the field config so you can enable it on a field-by-field basis. Repeater and RepeaterMatrix support The scan now walks Repeater and RepeaterMatrix fields up to three levels deep. Results are grouped under breadcrumb headings so you can see exactly where each image came from. How matching works Each image on the page is scored against the whole Hub using four signals: filename stem file size dimensions and a perceptual hash (a 64-bit visual fingerprint that can match re-encoded or renamed copies). Each result gets a confidence badge: New - not currently in the Hub Exact match - identical file already in the Hub Likely match - looks like an asset already in the Hub Possible match - filename matches a Hub asset but the file content appears different Already added - already used in this field When a match is confirmed, MediaHub adds a reference to the existing asset rather than copying the file again. Hardening for large pagesThere's also longer scan and import time limits, JSON error handling, a 200-selection cap per request, and client-side checks so a timeout doesn't surface as a cryptic error. Import Page Images was one of MediaHub's earliest features, and I think there's more we can do here. The import modal in particular could use a bit more cleanup, so that's on the list. That's pretty much it. Thanks for reading and scrolling! MediaHub is currently available for single sites, developers of multiple sites and agencies. If you'd like to try it first, DM me. Have a great weekend, Peter

Today, I am happy to showcase one of Fruitcake Communications AG's latest projects powered by ProcessWire. Ausgleichskasse des Schweizerischen Gewerbes AK105 AK105 is one of Switzerland's long established trade compensation funds, serving over 10,000 companies with first and second pillar social insurance, family allowances and pension administration since 1947. The multilingual site gives employers, employees, the self employed and pensioners clear access to all services, news and the connect online portal for paperless administration. The website is only part of the whole project as we also refreshed the existing logo, created a new corporate identity from that, and reimagined all business materials. The result is a modern, professional brand identity that accurately reflects the organization’s values, also perfectly reflected on the new website. We have developed a portal for existing business customers, parties interested switching to AK105 and also the actual people to whose benefit the trade compensation funds are. The goal is to answer questions and provide further information directly on the federal government portal. We knew one of the most important aspects of such a challenge is the search function and improved accessibility. ProcessWire has ready-to-use tools for both of these goals whilst our frontend is purpose built in-house like always for Fruitcake. Search We are making heavy use of @ryan's RepeaterMatrix which allows any component to be used literally anywhere on the website. Searchability becomes a challenge just because of that though. Most of the actual content lives either inside RepeaterMatrix pages or is fetched from other meta content. Thus, a front-facing page will be stitched together from many different sources like repeaters and other pages. To actually make the website searchable, we have developed a sophisticated set of hooks and functions which will search through all repeaters, nested repeaters and then from these results, backtrack to the actual front-facing pages so that the search result shows the precise content found whilst then linking back to the correct place where that content is located. Accessibility Not only just because the target audience is people aged 50+, accessibility is another key requirement for such a project. Apart from following accessilibity standards, we also have included a text-size switcher to allow for better readability whilst keeping the rest of the content concise. Most of the work here is invisible though: Styles for prefers-reduced-motion switches, proper handling of any navigation and control element using just the keyboard and flawless screen-reader support. Actually selling this invisible work to clients is a challenge in itself. Luckily, our client is already familiar with the necessity and the benefit of the endeavour and thus there was almost no discussion needed. Admin impressions Technical details The site is powered by ProcessWire 3.0.255 of course using the new admin theme which we ❤️! Modules in use: RepeaterMatrix SeoMaestro ProcessRedirects TracyDebugger ProtectedMode WireMailSmtp FileValidatorSvgSanitizer InputfieldAssistedURL FieldtypeColorPicker Links Case study on our website: https://fruitcake.ch/cases/ak105/ Website: https://ak105.ch/ Showcase on processwire.com: coming soon

@eelkenet I've added the ability to run single migrations from the CLI, as well as re-run, so they should be there now. The CLI --flags options should be more clear now, if you type "php index.php" the help will show all the flags under the CLI commands. As for MCP, we'll be implementing local MCP for most AgentTools commands, probably within the next two weeks. I'm told by GPT 5.5 that agents will likely still prefer to use the CLI in AgentTools most of the time, and that it's more token efficient to do so. But there are also benefits to MCP too so it makes sense to support. I doubt we'll have as many MCP tools as what you see in PromptWire, and AgentTools and PromptWire are completely different tools, so if you find them both useful it makes sense to use both.

Fixed in 1.0.3 (just pushed). Thanks a lot for the report, @eelkenet, that one's on us. Since the introduction of image tags we use them on every image field. The module now requests tags per field only when the field actually has them. After the upgrade it should run cleanly on your test setup now. Let me know if anything else trips up. Cheers, Mike

Thanks, that makes sense. I updated the Bulk Editor so it now shows the rendered title below the editable Meta Title field when Title Format adds a suffix or other text. The input still contains only the raw editable title, so the suffix is not accidentally saved into each page override, but the rendered title is visible and the length count continues to include the configured Title Format.Thanks, that makes sense. I updated the Bulk Editor so it now shows the rendered title below the editable Meta Title field when Title Format adds a suffix or other text. The input still contains only the raw editable title, so the suffix is not accidentally saved into each page override, but the rendered title is visible and the length count continues to include the configured Title Format.