Search the Community

Hi everyone, I’m happy to share the first public testing release of Mercato, a ProcessWire-native commerce toolkit. Mercato is not just a “shop template” or a simple cart module. The goal is to provide a flexible commerce layer that works the ProcessWire way: pages, templates, fields, permissions, hooks, and site-level customization. The basic idea is: Your website should not have to become “the shop system”. The shop should become part of your ProcessWire site. Mercato can be used as a full storefront, but it is also designed for custom ProcessWire websites that need commerce features without being forced into a rigid shop structure. What Mercato includes Products as ProcessWire pages Cart and checkout Orders stored as ProcessWire pages Stripe, Mollie, PayPal, bank transfer, and demo payment support Discounts and coupons Inventory handling Preorder and backorder support Digital products and downloads Fulfilment: carrier delivery, store pickup, local delivery Customer records Abandoned checkout recovery tools Refunds and payment operation tracking Webhook/event logs Reports and CSV exports Launch-readiness checklist Public order status and receipt pages Headless/read API surfaces A complete installable demo storefront Demo storefront A fresh install creates a real demo storefront called Arlberg Ceramics. It is not just placeholder content. The demo includes: physical products digital products gift cards product collections product images discounts low-stock products sold-out states preorder/backorder examples checkout policy pages order confirmation pages delivery, pickup, and local delivery scenarios The demo is meant to help developers test the full commerce flow immediately after installation. Existing sites Mercato is designed to add commerce functionality to an existing ProcessWire site without taking over the whole website. It creates Mercato-specific fields, templates, pages, permissions, products, collections, and order storage. It does not remove existing site content. Bundled storefront template files are copied into /site/templates/ only when the target files are missing. Existing template files are not replaced unless template overwrite is explicitly enabled in the module settings. That said, this is a commerce module and it changes the site schema, so please test on a staging copy first and make a backup before installing it on an existing/production site. Current status This is the first public release and should be treated as a testing release. I have tested the installer, demo storefront, checkout flow, admin screens, and basic payment workflows, but I would really appreciate feedback from real ProcessWire projects and different hosting setups. Things I’m especially interested in: installation issues gateway setup issues checkout edge cases admin UX feedback missing hooks or extension points template customization feedback real-world commerce scenarios I have not covered yet Repository GitHub: https://github.com/mxmsmnv/Mercato Requirements ProcessWire 3.0.200+ PHP 8.1+ Final note This is a big personal milestone for me. I have wanted ProcessWire to have a serious, modern commerce foundation for a long time. Mercato is my attempt to build that foundation in a way that respects how ProcessWire developers actually build websites. Feedback, testing, issues, and ideas are very welcome.

I just wanted to check this is okay before I roll it out. I'm pretty sure it is but I wanted to be sure. Let's say you have: Parent page [template=parent] Child page [template=child] In the back end site tree if I want Child page to be viewable and editable by the current user but I don't want Parent page to show in the site tree. If I remove all view permissions for template=parent but allow for template=child, will they still be able to view Child page and edit it (if I supply them with the direct link)? I stupidly asked AI this question and it's adamant permissions are inherited regardless so if you can't view a parent there's no way at all to view the child. 🤔

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, This module completely replaces the default ProcessWire image sizing engine with the powerful Intervention Image v3 library. The goal was to modernize how we handle images in ProcessWire, bringing in features like AVIF support, superior resizing quality, and strict aspect-ratio handling, while keeping the API compatible with what you already know. 🚀 What does it do? Replacement: It hooks into Pageimage. You can keep using $image->width(300), $image->size(800, 600), or $image->crop(...) just like you always have. Modern Formats: Automatically handles WebP and AVIF generation. Smart Responsive Images: It introduces a configuration-based approach where you define Breakpoints, Grid Columns, and Resizing Factors. The module uses these settings to automatically calculate and generate the perfect srcset for your layouts. ✨ New Methods: render() and attrs() While standard methods work as expected, I’ve added/updated methods to handle modern HTML output: 1. $image->render(string $preset, array $options) This outputs the complete HTML tag. It automatically handles: The <img> tag with srcset and sizes. The <picture> tag with <source> elements if you have enabled extra formats (like AVIF/WebP) in the settings. Lazy Loading & LQIP: It automatically generates a Low Quality Image Placeholder (pixelated/blur effect) and applies a base64 background to the image tag for a smooth loading experience. // Example: Render a 'landscape' preset defined in module settings echo $page->image->render('landscape', ['class' => 'my-image']); 2. $image->attrs(string $preset, array $options) Perfect for developers who use template engines like Twig or Latte, or prefer full control over their HTML. This returns an array of attributes instead of an HTML string. $data = $page->image->attrs('landscape'); // Returns array like: // [ // 'src' => '...', // 'width' => 1200, // 'height' => 675, // 'srcset' => '...', // 'sources' => [ ... ], // Array for picture tag sources // 'style' => 'background-image: url(data:image...);', // LQIP Base64 // 'class' => 'iv-lazy ...' // ] ⚙️ Configuration Strategy Instead of hardcoding sizes in your templates, you configure your design tokens in the module settings: Breakpoints (e.g., 1200px) Aspect Ratios (e.g., 16:9) Grid Columns (e.g., 1-1, 1-2, 1-3) Factors (e.g., 0.5, 1, 1.5, 2 for Retina support) The module calculates the necessary image dimensions based on these combinations. If you request a specific aspect ratio, it ensures strict adherence to it, preventing 1px rounding errors. 📝 A Note on Documentation I wanted to get this into your hands as soon as possible, but due to a heavy workload, I haven't finished writing the detailed README.md yet. Currently, you can grab the code from GitHub (link below). I will submit this to the official ProcessWire Modules Directory after add some other features and after update readme.md Download / GitHub: GitHub Repo I’d love to hear your feedback and suggestions!

I'm getting the following error, breaking the JSON output of a template (named json.php) i've built to answer a getJSON() JS call and output JSON to feed a popup: Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 83906560 bytes) in /server_path_to_my_root_folder/site/modules/TracyDebugger/includes/TD.php on line 115 As I'm using tracy heavily in templates delivering HTML and JSON as well for a long time now, I'm suspicious this occurs since a recent update to version 5.0.37 and stays throwing errors with version 5.0.38. While looking around, I found this error message in tracy's exceptions tab: Warning: file_get_contents(/server_path_to_my_root_folder/site/modules/TracyDebugger/tracy-2.11.x/src/Tracy/BlueScreen/../assets/reset.css): Failed to open stream: No such file or directory in /server_path_to_my_root_folder/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.11.x/src/Tracy/BlueScreen/BlueScreen.php on line 182 the exhaust error breaks the JSON structure and the popup is waiting for the template's return forever. When I delete all bd() calls from json.php everything works fine and the return of it comes back fast (I don't work locally, but already on a production-identical webspace). As soon as I'm inserting a single minimal bd() call, the template out is broken by tracy with the error message above. When using tracy on "normal" page templates with HTML output i don't see any errors. Any ideas where to turn some screws to get rid of this error?

Export your ProcessWire site structure as comprehensive, AI-optimized documentation for ChatGPT, Claude, Copilot, and other AI coding assistants. What It Does Context automatically generates complete documentation of your ProcessWire site in formats specifically optimized for working with AI: 📊 Site Structure Complete page hierarchy exported as JSON, TOON, and ASCII tree Shows all relationships, templates, URLs, and metadata Smart collapsing for large page lists 📋 Templates & Fields All template definitions with complete field configurations Field types, options, requirements, default values Special handling for Repeater, Matrix, Table fields 📦 Content Samples Real page examples exported for each template Shows actual data formats and field usage Helps AI understand your content patterns 💾 Code Snippets Customized selector patterns for your site type Helper functions and utility code API implementation examples 🤖 AI Prompts Ready-to-use project context file Template creation prompts Debugging assistance prompts Session continuity templates 🖥️ CLI Commands Export from command line for AI agents Query templates, fields, and pages directly Perfect for Claude Code, Cursor, Windsurf integration Dual Format Export (The Game Changer!) Context exports in two formats simultaneously: JSON Format Standard format for development tools, APIs, and compatibility TOON Format (AI-Optimized) ✨ Token-Oriented Object Notation designed specifically for AI prompts: 30-60% fewer tokens than JSON Significantly reduces API costs Same data, more compact representation No external dependencies - pure PHP Real Savings Example For a typical ProcessWire site with 50 templates: structure.json (15,000 tokens) → structure.toon (8,500 tokens) = 43% savings templates.json (8,000 tokens) → templates.toon (4,000 tokens) = 50% savings samples/*.json (12,000 tokens) → samples/*.toon (6,500 tokens) = 46% savings Cost Impact (Claude Sonnet pricing): JSON export: $0.105 per AI interaction TOON export: $0.057 per AI interaction Save ~$5/month if you use AI assistants 100 times/month Installation cd /site/modules/ git clone https://github.com/mxmsmnv/Context.git Then in admin: Modules → Refresh → Install Or download from ProcessWire Modules Directory Quick Start Web Interface Setup → Modules → Context → Configure Choose your site type (Blog, E-commerce, Business, Catalog, Generic) ✅ Enable "Export TOON Format" (recommended for AI work!) Enable optional features: ✅ Export Content Samples ✅ Create Code Snippets ✅ Create AI Prompts ✅ Generate SKILL.md for AI Agents Click "Export Context for AI" Files appear in /site/assets/cache/context/ CLI Interface # Full export php index.php --context-export # Export TOON format only (fastest, smallest) php index.php --context-export --toon-only # Query specific data php index.php --context-query templates php index.php --context-query fields php index.php --context-query pages "template=product, limit=10" # Quick stats php index.php --context-stats # Help php index.php --context-help Perfect for AI coding agents like Claude Code, Cursor, and Windsurf! Generated Files /site/assets/cache/context/ ├── README.md # Complete documentation ├── SKILL.md # AI agent skill definition ├── structure.json / .toon # Page hierarchy ├── structure.txt # ASCII tree ├── templates.json / .toon # All templates & fields ├── templates.csv # Templates in CSV ├── tree.json / .toon # Combined structure ├── config.json / .toon # Site configuration ├── modules.json / .toon # Installed modules ├── classes.json / .toon # Custom Page classes │ ├── samples/ # Real content examples │ ├── product-samples.json │ └── product-samples.toon # 46% smaller! │ ├── snippets/ # Code patterns │ ├── selectors.php # Customized for your site type │ ├── helpers.php # Utility functions │ └── api-examples.php # REST API examples │ └── prompts/ # AI instructions ├── project-context.md # Complete project overview ├── create-template.md # Template creation guide ├── create-api.md # API creation guide ├── debug-issue.md # Debugging helper └── project-summary.md # Session continuity template Using with AI Assistants Web Interface Upload Upload TOON files to save tokens and costs: 📎 structure.toon 📎 templates.toon 📎 prompts/project-context.md Then ask your AI assistant: "Help me create a blog post template with title, body, author, categories, and featured image. Follow the existing patterns from templates.toon" AI Coding Agents (Claude Code, Cursor, Windsurf) 1. Tell your agent to read the docs: Read /site/modules/Context/AGENTS.md 2. Agent can now export context: php index.php --context-export --toon-only 3. Agent queries specific data: php index.php --context-query templates 4. Agent reads exported files: Read SKILL.md, then structure.toon and templates.toon The AI has complete context of your site and can generate code that follows your exact patterns! Site Type Customization Code snippets automatically adapt to your site type: Blog / News / Magazine Post listings, author archives, category filtering Recent posts, popular content, related articles E-commerce / Online Store Product listings, cart logic, order processing Inventory management, payment integration Business / Portfolio / Agency Service pages, team members, case studies Testimonials, project galleries Catalog / Directory / Listings Brand hierarchies, category filters Advanced search, sorting, pagination Generic / Mixed Content General purpose patterns for any site type Features Overview Always Exported (Core) ✅ Complete page tree structure ✅ All templates with field definitions ✅ Site configuration and settings ✅ Installed modules list ✅ Custom Page classes ✅ README with complete documentation ✅ SKILL.md for AI agents Optional (Configurable) ⚙️ Content samples (1-10 per template) ⚙️ API JSON schemas ⚙️ URL routing structure ⚙️ Performance metrics ⚙️ Code snippets library ⚙️ AI prompt templates ⚙️ Field definitions metadata Advanced Settings Auto-update on template/field changes Custom export path (supports absolute paths) Maximum tree depth (3-20 levels) JSON children limit (prevent huge files) Compact mode for large lists Custom AI instructions CSS framework detection (or manual override) Why TOON Format? TOON is specifically designed for AI prompts. Here's the difference: JSON (verbose): { "products": [ {"id": 1, "title": "Dark Chocolate", "price": 12.99}, {"id": 2, "title": "Milk Chocolate", "price": 9.99} ] } TOON (compact): products[2]{id,title,price}: 1,Dark Chocolate,12.99 2,Milk Chocolate,9.99 Same data, 50% fewer tokens! Use Cases 🤖 AI-Assisted Development Upload your site context to Claude/ChatGPT and get code that follows your exact patterns 🤖 AI Coding Agents Claude Code, Cursor, Windsurf can export and query your site via CLI 📚 Developer Onboarding New team members get complete site documentation instantly 🔄 Site Migration Export complete site structure for documentation or migration planning 📖 Code Standards Maintain consistency across your team with AI that knows your patterns 💰 Cost Optimization Reduce AI API costs by 30-60% with TOON format 🔁 Session Continuity Maintain context between AI coding sessions with project-summary.md API Variable In your ProcessWire code: // Get Context module instance $context = wire('context'); // Programmatic export $context->executeExport(); // Get export path $path = $context->getContextPath(); Links GitHub: https://github.com/mxmsmnv/Context TOON Format Spec: https://toonformat.dev Screenshots Example Workflow Export your site Click one button or run php index.php --context-export Upload to AI Upload .toon files to Claude/ChatGPT for maximum efficiency Build features faster AI knows your exact site structure, templates, and patterns Save money Use 30-60% fewer tokens on every AI interaction Perfect for ProcessWire developers who use AI coding assistants! The TOON format support makes it significantly more cost-effective to work with Claude, ChatGPT, and similar tools. Now with CLI support for seamless AI agent integration! Questions? Suggestions? Let me know! 🚀

My print-on-demand webapp is very complex. It has: hundreds of fields tens of thousands of pages (let's focus on orders) listers (again, let's focus on my "Orders" lister) many filters on listers (my Orders lister has about 20 filters) When you load a ListerPro lister page, it technically does 2 requests: first request is to build the interface second request (ajax) loads the results based on the filters, etc. I noticed it became very slow over time, but I didn't look into it deeply until now. Even though I have thousands of order pages, that's actually not the issue. First, part of the issue is what type of page reference fields you are using, which I wrote a tutorial about, so make sure to view that as well. (also keep in mind TracyDebugger slows things down a lot here as well) But even with that, it's still slow on the first request. It would take 8-14 seconds to load a ListerPro page on the first request! The issue? Having too many filters (20 for example) combined with the fact my site has hundreds of fields means that generating that filters list is incredibly intensive. That filters list is powered by the InputfieldSelector field. I worked with DeepSeek and it came up with a simple solution: when rendering the field list (ie, the first dropdown in InputfieldSelector), don't show every single field as an option... instead only grab the fields that I have actually used. This keeps the InputfieldSelector field working correctly, but eliminates a bunch of fields I wouldn't have wanted to use in my filters anyway. So, we're sacrificing a little (unneeded) flexibility for extreme performance gain. Now my ListerPro page loads in less than a second! Use this hook in ready.php: if(wire('page')->process == 'ProcessPageListerPro' && !wire('config')->ajax && wire('input')->urlSegment1 !== 'config') { wire()->addHookBefore('InputfieldSelector::render', function($event) { $is = $event->object; // Don't interfere if limitFields was already explicitly configured $existing = $is->limitFields; if(!empty($existing)) return; // Parse field names from the current selector value $value = (string) $is->attr('value'); if(!strlen($value)) return; $fieldNames = []; try { $selectors = wire(new \ProcessWire\Selectors($value)); foreach($selectors as $s) { foreach($s->fields as $field) { if(strpos($field, '.') !== false) { list($field,) = explode('.', $field, 2); } $fieldNames[$field] = $field; } } } catch(\Exception $e) { return; } // Always include system fields (needed for the template row) foreach(['id','name','title','template','parent','status', 'created','modified','published','path','has_parent', 'created_users_id','modified_users_id','num_children', 'count','include','limit','sort','_custom'] as $f) { $fieldNames[$f] = $f; } if(count($fieldNames)) { $is->set('limitFields', array_values($fieldNames)); } }); }

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.

Hi everyone, Most project management tools are generic. Verk is built specifically around ProcessWire's data model — tasks link directly to PW pages, the calendar reads real page date fields, and content audits run PW selectors. Everything stays inside your install. GitHub: https://github.com/mxmsmnv/Verk Why Verk? Verk means "work" or "task" in Icelandic and Swedish. Short, abstract, and fitting for a tool built around getting things done inside ProcessWire. It follows the same naming approach as other modules in this series — Arbor, Ichiban, Collections — names that mean something without being literal. Screenshots: What it does Dashboard — open tasks, upcoming publications, audit alerts, and active sprint planning Tasks — create/assign tasks linked to specific PW pages; one click opens the page editor directly Calendar — month, week, and quarter views for page publications and task due dates Content Audit — run PW selectors with dot-notation field checks to find missing content Knowledge Base — rich editorial notes organized by category, searchable and exportable Sprints — sprint planning, quarter grouping, task assignment, DOCX export, and progress tracking Key details: Tasks store page_id — page data lives in PW, never duplicated Page Editor Widget injected via hookAfter('ProcessPageEdit::buildForm') — no template files modified Audit to tasks — bulk-create tasks from audit results with page context prefilled Rich text via TinyMCE when InputfieldTinyMCE is installed DOCX exports for task lists, notes, sprints, and knowledge base Return-aware forms — create/edit flows preserve filtered list URLs Requirements: ProcessWire 3.0.200+, PHP 8.0+ MIT License.

This module allows you to automatically rename file (including image) uploads according to a configurable format This module lets you define as many rules as you need to determine how uploaded files will be named and you can have different rules for different pages, templates, fields, and file extensions, or one rule for all uploads. Renaming works for files uploaded via the admin interface and also via the API, including images added from remote URLs. Github: https://github.com/adrianbj/CustomUploadNames Modules Directory: http://modules.processwire.com/modules/process-custom-upload-names/ Renaming Rules The module config allows you to set an unlimited number of Rename Rules. You can define rules to specific fields, templates, pages, and file extensions. If a rule option is left blank, the rule with be applied to all fields/templates/pages/extensions. Leave Filename Format blank to prevent renaming for a specific field/template/page combo, overriding a more general rule. Rules are processed in order, so put more specific rules before more general ones. You can drag to change the order of rules as needed. The following variables can be used in the filename format: $page, $template, $field, and $file. For some of these (eg. $field->description), if they haven't been filled out and saved prior to uploading the image, renaming won't occur on upload, but will happen on page save (could be an issue if image has already been inserted into RTE/HTML field before page save). Some examples: $page->title mysite-{$template->name}-images $field->label $file->description {$page->name}-{$file->filesize}-kb prefix-[Y-m-d_H-i-s]-suffix (anything inside square brackets is is considered to be a PHP date format for the current date/time) randstring[n] (where n is the number of characters you want in the string) ### (custom number mask, eg. 001 if more than one image with same name on a page. This is an enhanced version of the automatic addition of numbers if required) If 'Rename on Save' is checked files will be renamed again each time a page is saved (admin or front-end via API). WARNING: this setting will break any direct links to the old filename, which is particularly relevant for images inserted into RTE/HTML fields. The Filename Format can be defined using plain text and PW $page variable, for example: mysite-{$page->path} You can preserve the uploaded filename for certain rules. This will allow you to set a general renaming rule for your entire site, but then add a rule for a specific page/template/field that does not rename the uploaded file. Just simply build the rule, but leave the Filename Format field empty. You can specify an optional character limit (to nearest whole word) for the length of the filename - useful if you are using $page->path, $path->name etc and have very long page names - eg. news articles, publication titles etc. NOTE - if you are using ProcessWire's webp features, be sure to use the useSrcExt because if you have jpg and png files on the same page and your rename rules result in the same name, you need to maintain the src extension so they are kept as separate files. $config->webpOptions = array( 'useSrcExt' => false, // Use source file extension in webp filename? (file.jpg.webp rather than file.webp) ); Acknowledgments The module config settings make use of code from Pete's EmailToPage module and the renaming function is based on this code from Ryan: http://processwire.com/talk/topic/3299-ability-to-define-convention-for-image-and-file-upload-names/?p=32623 (also see this post for his thoughts on file renaming and why it is the lazy way out - worth a read before deciding to use this module). NOTE: This should not be needed on most sites, but I work with lots of sites that host PDFs and photos/vectors that are available for download and I have always renamed the files on upload because clients will often upload files with horrible meaningless filenames like: Final ReportV6 web version for John Feb 23.PDF

Hi everyone! I am currently developing a new module for a client project and wanted to quickly reach out to see if there is broader interest in the community for a solution like this. The Use Case My client needed an appointment booking system similar to "Calendly". However, they had specific requirements: Zero external dependencies: No third-party SaaS for GDPR/DSGVO compliance and to avoid monthly fees. Full Design Control: It had to fit seamlessly into their custom design. Lightweight: No heavy bloat. The Solution: WireBooking is a native ProcessWire module that handles appointment slots and bookings using standard ProcessWire pages. Current Features: Frontend Wizard: An interactive, step-by-step booking process built with AlpineJS and Tailwind CSS. Native Storage: Bookings are saved as standard ProcessWire pages (booking-entry), allowing you to use the full power of PW selectors and hooks. Backend Management: Simple interface using the native ProcessWire Admin Theme (UIkit) to view bookings. Notifications: Sends confirmation emails to the customer and admin, including generated .ics calendar files for Outlook/Apple/Google Calendar. Availability Management: Manually block specific time slots or entire date ranges via the module settings. AJAX Driven: Dynamically loads available slots via JSON to keep the initial page load light. The "Catch" (Requirements) To keep the module lightweight and modern, it is opinionated regarding the frontend stack. It assumes you are already using (or are willing to include): Tailwind CSS (Utility classes) for the styling. Usage Example: Using it in a template is extremely simple: <?php echo $modules->get('WireBooking')->renderWizard(); ?> I need your feedback! The module is currently functional for this specific use case (Consultants/Service Providers). Before I invest time into generalizing it for a public release on the modules directory, I have two questions for you: Is this something you would use? Is there a need for a native "Calendly" alternative? Is the dependency on Tailwind a dealbreaker? Since the markup relies on Tailwind utility classes, it might be hard to style if you use Bootstrap or custom CSS. Looking forward to your thoughts and suggestions! Cheers, Markus GitHub: https://github.com/markusthomas/WireBooking

Hi all — we're putting this one up as a public beta and looking for feedback before we tag a stable release. How it started. Over the past months we've been moving an old blog into a fresh PW site using our own SiteSync module and a Claude Code agent doing most of the migration grunt work. At some point the blog owner mentioned, in that very offhand way clients do, "hey, an image search would be nice." It was Saturday afternoon, so we let the agent build a prototype, pushed it through SiteSync, tested it on the phone an hour later. Worked great. Search results were… not great. But the search wasn't the problem – the underlying data was. Thousands of imported images, almost no descriptions, no tags, no nothing. So we needed a way to retroactively caption and tag a few thousand images without clicking through hundreds of page edits one by one. Since PW (rightly) attaches images to the pages they belong to, we needed a tool that reaches across the whole install at once and – crucially – can edit metadata in bulk. Why not the existing modules? We looked at the two obvious candidates: Media Manager by @kongondo – great if you're starting fresh and want a central media hub. But it's its own storage layer: you upload INTO Media Manager, editors pick FROM Media Manager. Images already sitting on per-page image fields stay invisible to it. Also commercial. MediaLibrary by @BitPoet – adds a MediaLibrary template with its own MediaImages / MediaFiles fields plus a CKEditor picker. Same pattern: a separate page hierarchy you migrate media into. Both are well-designed for "we want a central media model from day one." Neither helps you when the media is already scattered across lead_image, body_images, gallery, images_in_some_repeater etc. Migrating that into a different storage layer would have broken the original page model the blog depends on. So we built Image Library: a Process module that does nothing to your data – it just surfaces a cross-site table view of everything that's already there, with serious bulk editing on top. The bulk-edit part – the reason this module exists. Selection as a paintbrush. You tick N rows across any pages, templates and image fields. Then you edit a cell on ANY of those rows — the popup gains an Add / Replace mode picker (tags additionally offer Remove) and the value gets broadcast to the entire selection in one server round. Same row applies to description, tags, every custom subfield, AND the filename (with placeholders: (n), (n2)..(n5) padded counters, (N) total, (t) page title, (d) date, (p) page name, (f) field name → e.g. rename 200 selected files to event-2025-(n3).jpg). Same row applies to delete (one trash click, whole selection gone behind one confirm dialog with a where-used preflight – see below). Edits that push a row OUT of the active filter ("missing tags" → tag assigned → row no longer matches) fade out and drop from the table; counters auto-decrement. Other highlights: One sortable, paginated, bookmarkable table across every FieldtypeImage field on every page on every template (with config-side blacklists). Inline edit per cell – multilang-aware: language tabs in the popup, all languages committed in one save. Typed widgets per custom subfield: checkbox, date, integer, options (single + multi), and FieldtypePage rendered through PW's actually configured Inputfield (PageAutocomplete / PageListSelect / ASMSelect / whatever the field uses) — no re-implementation. Replace image in place (drag-drop or upload icon) – basename stays, variations regen. Renaming an image in the library instantly rewrites every CKEditor/TinyMCE embed of that file across the site — original and all variations, in every language — so links never break, and a summary dialog shows which pages were updated. Delete with where-used preflight: dialog scans every Textarea via $pages->findIDs("field%='/pid/stem.', include=all") and lists the pages where the image is still embedded in rich text – CKEditor + TinyMCE both, multilang-aware, with direct edit links so you can fix embeds before deleting. JSON / CSV export + import for offline metadata work – hand a CSV to a copywriter or feed it to your agent, get it back, import it. View prefs (columns, page size, bookmarks) live in $user->meta, cross-device. Status. v0.54.x – public beta. Module + docs (EN + DE concept) at GitHub or the Modules Directory Feedback welcome – especially edge cases we haven't seen yet (weird Fieldtype combos in custom-field templates, ProFields, Repeaters / RepeaterMatrix nesting). And if you've got a use case the current feature set doesn't cover, let us know. Cheers, Mike

Hi @eutervogel! I am extremely surprised and impressed. This shop "module" basically came out of nowhere and solves a huge "black hole" in the ProcessWire community: A functional, up-to date and all-in-one shop solution. I made a shop with Padloper (Version 1) years ago which was one of my first PW projects ever. And in my main job I am working for one of germanys biggest e-commerce shops. Coming that way I now what immense work setting up, developing and not least maintaining an online shop is nowadays. You have tons or regularities that you have to take care of and each year something is added. For example: Last year all bigger online shops had to be be overworked due to the German Accessibility Improvement Act now the latest "addition" was the integration of the "electronic cancellation button". If you offer a shop solution for a client based on an existing system or "custom made" - you have to be in constant awareness of the legal changes and act immediately. Then you have to design the landing page, category pages, product pages, the checkout pages, search pages and the whole customer backend. Not to mention many many e-mail templates. Because of that the last shop that I set up for a client was actually a Shopify solution. That still was a ton of work, especially if you consider the countless hours for reading the developer docs and becoming familiar with the Shopify CLI and the whole template/development system (and so on!). So it's nice to see that there is a PW alternative now. I like the fact that everything is integrated and the documentation seems to be extremely well planned. I can remember that there was another shop module for PW around that looked promising but offered little to no documentation at all. What a bummer.

Hi everyone, I’ve released a new ProcessWire module: Oidc. Oidc adds lightweight OAuth 2.0 and OpenID Connect login to ProcessWire sites. It is meant for projects that need social login or company SSO without a full front-end account-management suite. Repository: https://github.com/mxmsmnv/Oidc What it does Adds OAuth/OIDC login buttons to ProcessWire templates Supports Google, GitHub, LinkedIn, Microsoft, Yandex and Yahoo out of the box Supports custom OIDC providers via discovery URL Works with providers such as Okta, Auth0, Keycloak, authentik, Azure AD and Dex Handles callbacks automatically on frontend pages Supports auto-registration of new ProcessWire users Preserves return URLs through the login flow Includes silent mode for SSO-only sites and intranets Provides hooks for identity resolution, login, registration and provider definitions Verifies OIDC id_token claims with nonce, issuer, audience, expiry and RS256/JWKS checks when available Basic usage After installing and configuring providers, render login buttons in a template: $oidc = $modules->get('Oidc'); echo $oidc->renderButtons(); The page that renders the buttons is also the callback page. Set that URL in the module settings and register the same URL in your OAuth/OIDC provider app. Example use cases Add “Continue with Google” or “Continue with GitHub” to a member area Use Okta/Auth0/Keycloak for company SSO Protect an intranet or private section with silent SSO Auto-create ProcessWire users after successful provider login Add custom rules through hooks, for example restricting registration to a company email domain Documentation The README gives the overview, and the repository includes detailed documentation and agent-readable integration notes: README: https://github.com/mxmsmnv/Oidc Documentation: https://github.com/mxmsmnv/Oidc/blob/main/DOCUMENTATION.md Agent guide: https://github.com/mxmsmnv/Oidc/blob/main/AGENTS.md Requirements ProcessWire 3.0.200+ PHP 8.1+ curl openssl The module is MIT licensed. Feedback, bug reports and suggestions are very welcome.

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

Hey everyone. I have a new Module in the works. It's 99.9% 75% ready for general release, but already running on my own sites for weeks. [Edit: see post about bug re. 3rd party module] If you've ever opened /site/templates/ on a project that's been running for a year, you know the feeling. 20-50 PHP with no structure, no grouping - an alphabetical avalanche. I usually get so far by namespacing all my files, but sometimes I wish for more organisation. Stemplates lets you organise your templates into folders. That's real directories on the filesystem - the way you're used to working. So, instead of leaving everything in a flat directory, you can go from this… site/templates/ ├── account-dashboard.php ├── account-billing.php ├── shipping-methods.php ├── shipping-tracking.php ├── blog-index.php ├── blog-post.php └── blog-category.php to this… site/templates/ ├── account/ │ ├── dashboard.php │ └── billing.php ├── shipping/ │ ├── methods.php │ ├── tracking.php └── blog/ ├── index.php ├── post.php └── category.php I've been running it on my own sites without issues for a while, and it takes just minutes to set up, even on a large site. Setup takes even less time if you're using AI/MCP. Even better, Stemplates is: ✅ completely non-destructive ✅ doesn't touch your database ✅ doesn't modify your templates or fields ✅ doesn't change anything in the admin UI ✅ doesn't alter your workflow ✅ free from manual aliases, no mapping files, no rewrite rules to maintain ✅ doesn't touch system templates (admin, repeaters, etc.) It also works with page classes and supports nested subfolders (50 levels tested). Understandably, I was reluctant to mess around with such a fundamental part of my sites, so a few safeguards exist... Migrate one template at a time at your own pace - no big switchover required Your existing flat templates keep working untouched, alongside any you've already moved If a file can't be found in its subfolder, ProcessWire falls back to its normal flat-folder behaviour automatically - the site doesn't break Uninstall cleanly at any time. Stemplates Free is undergoing a slight rework available now DM me for access. Stemplates Pro (coming soon) takes Stemplates even further. More soon, but honestly, Stemplates (Free) will take care of 99% of your new template -> folders world. Thanks for reading! Peter

Here's a handy FAQ with the types of issues I needed to solve and are built into SEO Neo. FAQ (quick answers) 1. Can meta descriptions be filled automatically from existing page fields? Yes. Smart field mapping and per-template defaults pull from fields like summary or body when the SEO description is left blank. Auto-resolved text is truncated to a configurable length at a word boundary. 2. Can page titles get a consistent suffix (e.g. “About us | My Company”)? Yes. That is built into module config: site name, title format, and separator — no custom code needed for the usual pattern. 3. Can I override or extend resolution logic with hooks? Yes. Individual resolvers (title, description, OG image, etc.) are hookable, so sites with non-standard rules can plug in custom logic without forking the module. 4. Does the admin SERP preview reflect auto-resolved values? Mostly. On load it uses the same resolver chain as the frontend. If SEO fields are empty, the preview shows the computed title and description. If an editor types into the SEO fields, those values take precedence. 5. I am on MarkupSEO or Seo Maestro — can I migrate gradually? Yes. Both legacy fieldsets can stay on the same template while you copy values across. The SeoNeo tab can show a small NEO badge so it stays distinct when both tabs are labelled “SEO”. Migration helper planned. FAQ Longer versions 1. Automatic descriptions from content fields A common requirement is that staff and blog pages should not need a separate meta description when summary or body already exists. SeoNeo handles this in module config, not by asking editors to duplicate content: Smart field mapping defines fallbacks when seoneo_description is empty — for example, try summary, then body. Per-template defaults go further: a [blog-post] or [person] block can set description={summary|body} so only those templates use that chain. Truncation applies to auto-resolved values only. Values typed directly into the SEO description field are left as-is. The max length is set once in module config. There is also an ancestor walk prefix (*fieldname) if a section landing page should supply a default description for child pages. For edge cases — inheriting a homepage description site-wide, template-specific truncation rules, or pulling from a custom settings page — hooks on the description resolver are the extension point. 2. Title suffixes and branded <title> patterns Another frequent ask is a predictable title pattern: Page name | company.com That is a first-class feature via site name, title format, and title separator in module config. Per-template defaults can influence the source part of the title (e.g. {long_title|title} on blog posts) while the suffix still comes from the global format. Homepages that already store a fully branded title in the SEO field can use a hook on the title formatter to skip the automatic suffix on that one page. 3. Hooks for custom SEO logic Sites with existing custom SEO logic often need to tweak titles, descriptions, or OG images based on template, page ID, or external settings. SeoNeo splits resolution into hookable steps — reading and resolving individual values, formatting the final title, resolving OG image, hreflang, and so on — rather than one monolithic hook. Render methods are hookable too if you need to append tags rather than change resolved values. 4. What the SERP preview in the admin actually shows The bundled SERP preview calls the same PHP resolvers the frontend uses on initial render. While editing, typed SEO values take precedence; empty SEO fields fall back to server-resolved values from page load. One limitation: the live preview watches the SEO input fields, not every source field in the fallback chain. Editing summary will not update the preview until save/reload if the description comes from smart-map. A richer fallback-chain visualisation in the editor is on the PRO roadmap. 5. Multilingual sites Multilingual support is a common question for any SEO module, especially when hreflang and locale tags need to stay in sync with ProcessWire’s language tabs. SeoNeo is built around native PW language-aware fields, not a separate storage layer. Each seoneo_* field behaves like any other translatable field — editors fill in SEO values per language tab, and the resolver chain returns the value for the currently active language on the frontend (or whichever language you switch $user->language to in PHP). Configuration for multilingual output: Per-language site name — override the global site name per language (e.g. de=Mein Beispiel). Used in title formatting, template defaults, and og:site_name. Locale map — map PW language names to BCP47 codes (default=en-GB, de=de-AT, etc.). Powers og:locale, og:locale:alternate, and hreflang codes. Hreflang alternates — emitted per language with correct URLs, including x-default pointing at the default-language URL. Segment and pagination handling matches the canonical URL policies. In the page editor: The SERP preview includes a language switcher (on multilingual sites) so editors can preview each language’s title and description without leaving the current PW language tab. Resolved values in the preview use the same per-language fallback chain as the live site, including the localised URL in the breadcrumb. Desktop/mobile toggle and character counters apply per surface regardless of language. Smart-map and template defaults respect language context too — a German summary field resolves when the German language is active, not a mixed default. For sites with unusual language setups (custom domain-per-language, non-standard hreflang codes, or locale rules that differ from PW’s language names), the hreflang and locale resolvers are hookable. 6. Migrating from MarkupSEO or Seo Maestro Both legacy modules can stay installed while you move page by page: Install SeoNeo (InputfieldSeoNeoPreview installs with it). Add seoneo_tab to templates — remaining SEO fields insert automatically on save. Copy legacy values at your own pace. Switch templates from $page->seo to $page->seoneo when ready. Uninstall the legacy module when frontend output is fully on SeoNeo. Watch for doubled <head> output if both modules auto-inject meta tags.

Hi @adrian, I've been trying out the module, in particular the Lister mode. It's a very feature-rich and well-thought-out module. Thanks for creating it! My use case is probably not typical so I expect I'll need to do some custom styling and modifications, but I thought I'd run a few questions by you first in case there are built-in options that I missed. 1. I've set my Default Filter settings, but I get a filter row at the top for "include" that isn't in my settings. Is there a way to avoid that row, or is that compulsory so that users will always see unpublished children? 2. When "template" is included in the filters, is there a way to have the select limited to the "Allowed templates for children" that are defined for the parent page template? 3. I want to use the module for its Lister features rather than for batch editing, so is there a way I can not have the column with the pencil icon that enables inline editing? 4. For my use case the nested fieldset is a bit redundant. No worries to visually hide the nested fieldset using some custom CSS, but one feature idea would be for the module to automatically hide the nested fieldset when the options for "Lister mode title", "Lister mode description", and "Lister mode notes" are all left empty.

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 all, I've made the SeoNeo repo public as planned. SEO Neo is a modern SEO module for ProcessWire that started as a practical fix for real-world canonical, pagination, and hreflang bugs on multilingual sites, and grew into a full replacement path for MarkupSEO and Seo Maestro. GitHub: https://github.com/PeterKnightDigital/SeoNeo Current version: 1.1.3 · Requires: ProcessWire 3.0.200+, PHP 8.1+ What makes it different SeoNeo is a coordinator module, not a custom Fieldtype. It creates ordinary ProcessWire fields (Text, Textarea, URL, Checkbox, etc.), reads them via a configurable mapping, resolves fallbacks, and renders the <head> block. That means: Every SEO value is a real PW field — full multi-language support, selectors, import/export No custom database schema or Fieldtype complexity The SEO tab sits alongside your existing Content / Settings tabs Add seoneo_tab to a template and save — the rest of the SEO fieldset (seoneo_preview, title, description, canonical, robots, etc.) is inserted automatically. What it outputs Full <head> SEO block in one call: echo $page->seoneo; // or echo $page->seoneo->render(); Includes: <title> with configurable format, separator, site name, pagination placeholders Meta description, keywords, author Canonical URL (with configurable URL-segment and pagination policy) Robots meta (noindex/nofollow per page, auto-noindex for unpublished/hidden pages, site-wide defaults) Granular Google robots directives (max-snippet, max-image-preview, etc.) AI/LLM opt-out signals (noai, noimageai) — polite signals, not a substitute for blocking bots at HTTP/robots.txt level Open Graph (title, description, url, type, site name, locale, image + dimensions/secure_url/type) Twitter/X cards (auto summary vs summary_large_image) Hreflang alternates with configurable BCP47 map (default=en-GB, de=de-AT, etc.) Search-engine verification tags (Google, Bing, Yandex, Pinterest, Facebook, Baidu) JSON-LD @graph emitter (Consider BETA IE works, but API/defaults may still change; hooks recommended for production-critical schema) Partial renders and resolved values are available too — flat API ($page->seoneo->renderOg()) or SeoMaestro-style namespaces ($page->seoneo->og->render()). Everything is hookable. Editor / admin features Bundled InputfieldSeoNeoPreview (installs with the module): Live Google SERP preview that updates as you type Desktop / mobile toggle — mobile truncates earlier (separate char budgets) Multilingual language switcher on the preview card Surface-aware character counters (green/amber/red zones, optional hard maxlength) Per-page noindex/nofollow checkboxes Optional NEO badge on the Wire tab — handy when running alongside MarkupSEO's also-named "SEO" tab during migration Configuration highlights Module config covers site name (per-language) title format smart field mapping with ancestor walk (*summary) per-template defaults with placeholders OG image field paths (including dotted paths like banner.image) default OG image locale map Twitter handles auto-inject position canonical policy and more. ProCache: documented and tested on cache-miss and cache-hit paths. Migrating from MarkupSEO or Seo Maestro You can run both modules during migration . You keep legacy fields on the template, copy values into seoneo_* fields at your own pace, then switch templates from $page->seo to $page->seoneo (shape is largely preserved). Migration is being worked on. Watch for doubled <head> output if both modules auto-inject — disable auto-inject on whichever isn't authoritative yet. Quick steps: Install SeoNeo (Modules → Refresh → Install) Add seoneo_tab to templates Copy field values (seo_description → seoneo_description, etc.) Rewrite template API calls Uninstall legacy module when ready Full feature comparison and migration notes are in the README: https://github.com/PeterKnightDigital/SeoNeo#migrating-from-markupseo-or-seo-maestro Deliberately out of scope SeoNeo focuses on <head> SEO coordination, not Swiss-Army-knife extras. For these, dedicated modules are a currently a better fit: Sitemap → MarkupSitemap Redirects → Jumplinks2 or ProcessRedirects robots.txt editor → MarkupRobotsTxt or a template override Analytics/GTM → MarkupGoogleTagManager or similar (A PRO companion bundle with deeper editor tooling is planned separately) Install Copy SeoNeo to site/modules/ Modules → Refresh → Install SeoNeo Add seoneo_tab to any template that needs SEO Feedback very welcome. Especially from anyone migrating off MarkupSEO or Seo Maestro on multilingual or ProCache sites. Issues and PRs on GitHub are the best place for bugs and feature requests. Cheers, Peter

Hi everyone, I've been running this module in production a spirits catalog with 12,000+ products — for several months. Today I'm releasing it publicly. GitHub: https://github.com/mxmsmnv/Collections The problem ProcessWire's page tree is brilliant for site structure. It's painful for data management. When you have thousands of pages as records — products, listings, vacancies, menu items — you hit the same walls on every project: no table view, no inline filters, no bulk actions, no export, no REST API, no role scoping per dataset. Every PW developer has solved some version of this. Collections solves it once. Screenshots What it does Gives any ProcessWire template a configurable admin table — live search, dropdown filters, inline status toggles, bulk actions, CSV/JSON export, and a REST API — all configured through a UI, without writing code. Admin UI: Configurable columns per collection with custom labels Live search with 300ms debounce across multiple fields including Page references Dropdown filters for FieldtypePage and FieldtypeOptions fields Inline publish/unpublish toggle via AJAX Bulk actions: publish, unpublish, delete with CSRF protection CSV and JSON export with active filters preserved Role-based permissions matrix — scope each role per collection "View in Collection" button injected into the page edit form REST API: Bearer token, query param, HTTP Basic, and PW session auth API key management with expiration dates and per-key capability scopes SHA-256 hashed keys, usage tracking, rate limiting (100 req/min) WireCache support for GET responses ProFields support: Table, Textareas, Multiplier, Repeater Matrix, Combo — including dot-notation for subfields (address.city, blocks.hero.title, prices.*.amount) Field types: Text, Textarea, Integer, Float, Checkbox, URL, Email, Date, Image, File, FieldtypeFileB2, FieldtypePage, FieldtypeOptions, MapMarker, Color Requirements: ProcessWire 3.0.244+, PHP 8.2+ There's a thread from 2013 asking for exactly this: Module Idea: Flat Listings — here it is, 12 years later. Known issues are tracked on GitHub — the module is stable for production use, active development continues.

Hey everyone, I've been building a e-commerce project and needed to show personalized content based on visitor location — shipping availability, regional pricing, state-level compliance notices. Nothing like this existed in the PW ecosystem, so I built it. What it does Detects country, region and city from the visitor IP using MaxMind GeoLite2 databases (free). Result is cached in session. Exposes $geoip as a wire variable — available in every template automatically, just like $page or $user. // That's it. No setup, no require, just use it. if ($geoip->inCountry('US')) { echo $page->us_content; } API // Boolean checks — accept single value or array $geoip->inCountry('US') $geoip->inCountry(['US', 'CA', 'GB']) $geoip->inRegion('GA') // ISO 3166-2 subdivision code $geoip->inRegion(['GA', 'NJ', 'NY']) $geoip->inCity('Atlanta') // Inline conditional with optional fallback echo $geoip->showIf('countryCode', 'US', $page->us_block, $page->global_block); echo $geoip->showIf('regionCode', ['GA', 'NJ', 'NY'], $page->northeast_promo); echo $geoip->showIf('continent', 'Europe', $page->eu_gdpr_notice); // Single field $geoip->getField('countryCode') // "US" $geoip->getField('regionCode') // "GA" $geoip->getField('city') // "Atlanta" $geoip->getField('timezone') // "America/New_York" // Full array $geo = $geoip->detect(); // ip, country, countryCode, continent, region, regionCode, // city, zip, lat, lon, timezone, corrected, status Combining conditions // Country + region if ($geoip->inCountry('US') && $geoip->inRegion('CA')) { echo $page->california_prop65_notice; } // Logged-in + location if ($user->isLoggedIn() && $geoip->inCountry('US')) { echo $page->us_member_block; } // Time-of-day in visitor's timezone $tz = $geoip->getField('timezone') ?: 'UTC'; $hour = (int) (new DateTime('now', new DateTimeZone($tz)))->format('H'); if ($geoip->inCountry('US') && $hour >= 9 && $hour < 17) { echo 'Our US office is open right now.'; } // Pre-select shipping dropdown (Vivino-style) $selectedCountry = $geoip->getField('countryCode') ?: 'US'; $selectedState = $geoip->getField('regionCode') ?: ''; User location correction Frontend widget lets visitors fix incorrectly detected location. Stored per-IP in DB, applied on subsequent requests. You can also build your own UI — just POST to /?geoip_action=correct with country_code, region_code, city. Setup Composer package and databases live in site/assets/GeoIP/ — not in the module directory, so they survive updates. cd /path/to/site/assets/GeoIP/ && composer require geoip2/geoip2 Then drop GeoLite2-City.mmdb (or GeoLite2-Country.mmdb) in the same folder. Free download from maxmind.com. The module config page shows the exact path and command for your server. Admin panel Setup → GeoIP — lookup log with country/region/city, corrections manager, manual IP lookup tool. GitHub: https://github.com/mxmsmnv/GeoIP License: MIT Requires: ProcessWire 3.0.200+, PHP 8.2+ Feedback welcome — especially if you're doing anything geo-based with ProcessWire. Maxim

It's a rainy Sunday where I'm at. The monsoon is hitting hard. Perfect time to write a love letter. Addressed to a module, my favorite PW module of all times. And its creator @bernhard, of course. A Love Letter to RockMigrations by a long-time user and contributor Dear RockMigrations, I’ve been using you for years. Built sites with you, shipped modules that lean on you, even chipped in a few pull requests along the way. And honestly, I took you for granted. You just worked. Fields appeared. Templates materialized. Modules shipped their own schema like little self-contained suitcases. I never wrote down why you’re so good. I just kept using you. Recently I found myself comparing you to other approaches, side by side, line by line. And I realized: I should write this down. Not because I learned something new, but because seeing the alternatives made your elegance impossible to ignore. Let me count the ways. The Declaration of Truth Most migration systems hand me a blank file and say “write code.” Fair enough. But you, RM, let me declare what a field or template is: // site/RockMigrations/fields/subtitle.php return [ 'type' => 'text', 'label' => 'Subtitle', 'columnWidth' => 50, ]; That’s it. No $fields->save(), no $field->type = wire('modules')->get(...). Just the truth. The current, desired state. You figure out the rest. This means the file is my source of truth, not a historical log of what someone did at 9:14 AM on a Tuesday. If I want to know what the subtitle field looks like right now, I open one file. Not a trail of timestamped breadcrumbs. Circular References? You Solved Them. Elegantly. Every migration system hits the same wall: Template A needs to know about Template B, and Template B needs to know about Template A. Who goes first? Most systems tell me to manage this manually. Order my timestamps. Cross my fingers. You do something way smarter: two passes. Pass 1: Create everything. All fields, all templates, all roles. They exist as empty vessels. Pass 2: Configure everything. Wire up parent-child relationships, attach fields, set permissions. Everyone knows everyone now. Circular dependencies become non-circular across passes. No timestamp juggling. No depends_on arrays. It just works. And if I need to inject imperative code at the right moment, you give me four lifecycle hooks: beforeAssets, afterAssets, beforeData, afterData. Escape hatches at exactly the right places. Not too early, not too late. I’ve used these to install modules, create reference pages, and detach stale fields, all in the right order, every time. You’re Non-Destructive by Default If I remove a field from a template’s config array, you don’t rip it out. You leave it alone. Because you assume I might still need it, or that removing it accidentally would be catastrophic. If I actually want to detach a field, I tell you explicitly: a removeFieldFromTemplate() call, right there in the same config file or in the relevant hook. Destruction is a conscious choice, not a side effect. This alone has saved me from myself more times than I’d like to admit. Modules Ship Their Own Schema A module can drop a RockMigrations/fields/ folder into its own directory, and you just… discover it. No registration. No global config. No “please add this module to your migration scan path.” site/modules/Foo/ ├── Foo.module.php └── RockMigrations/ ├── fields/bar.php → foo_bar └── templates/baz.php → foo_baz You auto-prefix field names with the module name. You auto-tag them. When I look at a field in the admin, I can see which module owns it. And when the module uninstalls, its ___uninstall() method can call a migration script that cleans everything up, fields, templates, the lot. Optionally guarded behind a checkbox in the module config so the site admin decides whether to keep the data. No manual cleanup. No orphaned fields haunting the database for years. A module is a self-contained package: code and schema. And you respect that boundary. No sprawl into a shared site/migrations/. No “did file 47 or module X create this field?” The answer is in the file path on disk. This design choice makes every module I’ve built feel cleaner and more portable. Free Constants, Free IDE Support By just creating a marker file (RockMigrationsConstants.php), you auto-generate class constants for every field and template: // Auto-generated. Do not edit. class RockMigrationsConstants { const field_subtitle = 'subtitle'; const template_award = 'award'; } Now my IDE autocompletes RockMigrationsConstants::field_... and I never type "subtitle" as a raw string again. No typos. No silent breakage when I rename a field. You generate this from the config files, the same single source of truth. Silly bugs prevented. You’ve Grown Without Bloating You’re not a proof of concept. You’re not a shiny new thing I’m nervously trying in production. You’ve grown organically across versions, picking up MagicPages, deploy helpers, auto-release workflows, and about forty other things. You’re the Swiss Army knife that somehow doesn’t feel bloated. I’ve watched you mature over the years. Every feature felt like it earned its place. Nothing feels bolted on. Things that did at one time got removed. Other solutions are ... not bad Look, I need to say this clearly: the other migration approaches out there are not bad. They’re genuinely good work by talented people, and I’m grateful we have choices. A ProcessWire ecosystem with multiple migration approaches is a healthy ecosystem. Every approach has its place and its audience. But every time I sit down and compare feature to feature, RockMigrations comes out uniquely complete. Declarative config? Check. Two-pass circular dependency resolution? Check. Module self-containment with auto-discovery? Check. Non-destructive by default? Check. Auto-generated constants? Check. Battle-tested over years? Check. Not all in one package anywhere else. So if you’re on the fence, give it a spin. Create a site/RockMigrations/fields/ folder, drop in a config array, refresh modules, and watch it work. You might just stick around for years too. Yours declaratively, a long-time user

Claude is always asking me to test things via Tracy console. This is why I added to the copy MD for agent, including the Copy All button at the bottom. It lets it understand the file/template/data structure and also to run comparisons on the data retrieved when refactoring code or adding new features. I much prefer this to giving Claude direct access to the site DB - this way I can check each query it's about to make and to choose whether I provide it with the complete results or not. Not that it is a real lock, but Tracy does have a setting to prevent all access to superusers with another role so if they don't know about Tracy then you could keep them out. Best bet would be to define this setting via $config>tracy rather than in the module settings so it's harder for them to override.

Took the time and installed SEO Neo to one my larger and most complete side-projects, and so far I am really impressed what can be done with this out of the box. The depth and customisation feels great on the first look. Might need to dig deeper into all the settings and options, but WOW! BUT... I noticed that auto-inject didn't work. Tried that in another instance that's almost clean without any other modules or whatever. I probably missed something at some point. Got it working in both instances nonetheless. I might try it in a clean environment again, but as it is not a show-stopper for me I won't lose another thought about it. Using the $page->seoneo->render() worked everywhere, even in Twig (TemplateEngineFactory) with {{ page.seoneo.render() }}. NICE! One other thing I'm not sure about is adding SEO Neo fields to templates. The module creates quite a few fields, but there is no option to single-click/single-action add them to a template of choice. Sure, in total only a minute or two to add them manually to ONE template but on larger sites with a lot of templates... well. I helped myself, added all fields to a new template and imported that new template into existing templates. More a hack, than a workflow, but at the end fields were in their right spot. In terms of Schema/JSON+LD: what other schemas are planned or how would I add custom ones? Looked into the docs but couldn't spot a reference to custom types like recipe, book, event, real estate / or related schemas. Overall... migrating from a custom solution to SEO Neo is probably doable in a few hours with this very special project. Luckily we have way better AI support now so it might be that all the Claudias out there can assist. First impression was great. Will probably move that project over to SEO Neo this weekend.