Leaderboard

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.

From a database perspective page reference fields should scale quite well and there's always the option to build a custom table managed with hooks if you need something ultra fast so you have control of the indexes. But, in the admin, is there any field type that scales well? I've tried them all out and from what I can see, all page reference field types and input types, do not have the option to show your page references in a searchable, paginated lit loaded by AJAX; they all go in a single list. I can imagine this getting problematic once the number of page references gets moderately big. Is there such a thing? What do you do if you have 100s of references, 1000s of references or more? At what point are the standard page reference fields no longer an option?

Hi, if your page reference field is used for a single page selection, you may choose "page auto complete" in the input->input field type select, it is ajax powered and works very well 🙂 the only big difference is that you have o know at least 2 or three letters of the page title you're looking for it works great too with a hook (custom php code) allowing you to select several parents, templates and so on if needed have a nice day

Hi @eutervogel! I just wanted to tell you that I spent quite some time in the demo shop, testing everything out, and I am pretty impressed with the work you've done! Of course I lack the experience of Stefanowitsch in this matter, but I ckecked out all the other shop solutions for PW and all of them are not suited for EU use. This is something I could work with and/or suggest to a client. In the past I had to refuse all requests for a shop... If you are short of testers? I am more than willing to help! Bernd

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.

Demo storefront screenshots:

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 all 👋 AiWire is now Squad. Same module, same author, cleaner name — and a lot more under the hood since the last release. If you were using AiWire, this is your upgrade-and-rename notice; if you're new, here's the short version. What Squad is A provider-independent AI gateway for ProcessWire. You write your code once against a simple API ($squad->ask(...)) and switch model/provider with a single option — no provider-specific glue in your templates. What's new since AiWire 14 providers through one API — Anthropic, OpenAI, Google, xAI, OpenRouter, plus direct Chinese providers: DeepSeek, Qwen (Alibaba), Moonshot/Kimi, Zhipu/GLM, MiniMax, 01.AI/Yi, Doubao, Ernie (Baidu), Hunyuan (Tencent). Embeddings — embed() for vectors (OpenAI / Google / Qwen / Zhipu), single or batched. Images — image() (xAI Grok Imagine, OpenAI gpt-image-1). Agentic tool-use — run() runs the full tool-calling loop for you (OpenAI/Anthropic differences normalized). Encrypted key storage — keys live encrypted at rest (libsodium); a DB dump shows only ciphertext. You can also reference an env var with env:MY_KEY so nothing secret hits the database. Prompt caching, adaptive-aware model handling, and a refreshed model catalog (Opus 4.8 default, Fable 5, current GPT/Gemini/Grok). Familiar helpers kept: chat(), ask(), fallback chains, multi-key rotation, per-page file caching, save-to-field. Migrating from AiWire (order matters) Install Squad first — it auto-migrates your key table and settings (your encrypted keys are preserved). Then uninstall AiWire. ⚠️ Do it in that order. Uninstalling AiWire first drops the old key table, so you'd have to re-enter keys. Links & requirements GitHub: https://github.com/mxmsmnv/Squad (old AiWire links redirect) Requires ProcessWire 3.0.210+ and PHP 8.1+ MIT, by me — smnv.org Feedback and issues welcome. Thanks to everyone who tried AiWire — Squad is where it grows from here. 🚀

There are still a few modules left to do...