maximus

I not owned module. I think not good idea storage 3 files 🙂

This resonates. 20 years in development, still figuring it out honestly. Current reality: Day job 6 days/week, building PW modules in spare time. Not balanced, but intentional - grinding now to create options later. What actually helps: - Seasons, not balance - some months are 80% work, others need to be 80% recovery - Combine categories - coding for fun = leisure + professional growth - One rule: protect sleep and one full day off. Everything else is negotiable - Physical maintenance - injuries taught me this the hard way The AI/tech pressure to "stay relevant" is real, but burnout is worse. Better to have 3 solid productive hours than 8 exhausted ones. What's working for you so far?

Hey, built an OpenRouter engine for Fluency — lets you pick any model from their catalog (400+), including free ones. Install: drop the OpenRouter folder into site/modules/Fluency/app/Engines/, refresh modules, done. Fast models that work well for translation: google/gemini-2.5-flash-lite, google/gemini-2.0-flash-001, ibm-granite/granite-4.1-8b. Free options: google/gemma-4-31b-it:free, meta-llama/llama-3.3-70b-instruct:free. Avoid big models like GPT-4o or Claude Opus — too slow for this. Zip attached. OpenRouter.zip

Thank you very much for your feedback and for your contribution to helping us refine the module! I'll try to make some adjustments in the coming days. The module has been in development since February 2026, so stable operation was paramount. If you have any issues or suggestions for improvement, I'm always happy to help!

Hi everyone, Built this for a financial news site that needed live stock quotes embedded inline in editorial content. Drop a ticker into any text field and it renders as a live badge with price, change, and direction - clicking opens a full detail popup. GitHub: https://github.com/mxmsmnv/Stocks What it does: Live price badges - ticker, price, change amount/%, direction arrow; click opens a popup with open/high/low, 52-week range, P/E, volume, market state Three data providers - Yahoo Finance (free, no key needed), Finnhub, Alpha Vantage TextFormatter with three parse modes: Explicit [stock:AAPL] tags Cashtag/hashtag - $AAPL, #TSLA Auto-detection by company name and aliases in text Company Manager - tracked companies with names, aliases, enable/disable toggles, bulk CSV import Four CSS frameworks - Vanilla CSS (built-in), Tailwind, Bootstrap 5, UIkit 3; auto-detected or manually set File-based cache with configurable TTL and per-ticker clear from admin Circuit breaker - pauses API calls after repeated failures, serves stale cache with ~ marker Custom provider API - add any data source by extending StocksProviderBase $stocks = $modules->get('Stocks'); echo $stocks->renderBadge('AAPL'); echo $stocks->renderBadgeAs('TSLA', 'bootstrap'); Requirements: ProcessWire 3.0+, PHP 8.2+ MIT License.

Hi @jacmaes, thanks for the kind words and for taking the time to test! Both issues you reported are fixed in v1.9.2 (released today). Quick summary: Unix timestamps for start_date / end_date — datetime fields are now auto-detected by field type and formatted automatically, no manual column type override needed. Filter dropdown doing nothing — two bugs were at play: the Apply button wasn't showing up on select change (DOM queried before ready), and the query string was encoding [ / ] as %5B%5D which PHP couldn't parse as an array. Both fixed. Full details in the changelog. Let me know if anything else comes up!

Context v1.5.0 — AI Gateway Hi, just pushed a new release. The main addition is a centralized AI Gateway — a ContextAI class that any ProcessWire module can use to make AI requests through a single shared configuration: $ai = wire('context')->ai(); // Simple $text = $ai->complete('Summarize: ' . $page->title); // Full options $result = $ai->chat([ 'messages' => [['role' => 'user', 'content' => '...']], 'model' => 'openai/gpt-4o-mini', 'caller' => 'MyModule', ]); // Gateway entry point for third-party modules $result = $ai->gateway(['caller' => 'MyModule', 'messages' => [...]]); Supported providers: OpenRouter (200+ models via one key), OpenAI, or any OpenAI-compatible endpoint. New settings fieldset: provider, API key, default model, temperature, max tokens, timeout, global system prompt, and a Test Connection button that fires a live request and shows the response time. The idea is that modules don't need to implement their own HTTP clients or manage API keys — they just call wire('context')->ai() and everything is configured in one place. GitHub: https://github.com/mxmsmnv/Context

Not yet — currently it renders as a single top-level link. A dropdown listing all collections on hover is a reasonable UX improvement and I'll add it to the roadmap. The main challenge is that collections lists can get long, so it'll need some thought around grouping or truncation.

The module may not have received any updates in the last five years, but it works reliably. I use it as a must-have for updates. Thanks for sharing the link - I hadn't heard of it before.

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.

Yes, I know it well — great Dashboard module! I've used it on almost every project to keep the admin from feeling bare. But as projects grew, I kept hitting the same wall: customizing Dashboard meant writing PHP for each install, and the widget lists got unwieldy. Start (and its companion module Collections) came out of that frustration — the goal was a fully visual, no-code editor where you just drag, drop, and pick icons without touching any config files.

Six months ago when Ryan was posting once a week, I thought the project was slowing down. Really glad to see the pace pick up! ProcessWire's architecture was always ahead of its time — there's legacy code built up in layers, sure, but the direction now is exciting and hard to keep up with 😄

@ryan, can you add cli command for quick updates without pushing for each button ?

Thanks Adrian! Since you're in Canada — if you ever deal with cross-border shipments to the US or Europe, the unit conversion comes in handy. Canadians get the best of both worlds — metric by default but imperial just across the border. 😄

Hi @adrian, great question — happy to clarify. Both modules store L×W×H, but the focus is different: FieldtypeObjectDimensions (juergen) — geometry-oriented: auto-calculates and stores area and volume, useful when you need spatial calculations. FieldtypeDimensions (mine) — shipping/e-commerce-oriented. The reason it exists: I've been building a package forwarding platform (think Qwintry-style — customers ship packages to a US warehouse, we consolidate and forward internationally). That platform, AltaPost, never launched at scale, but the logistics logic stuck with me. When I needed a dimensions field for product catalogs in ProcessWire, the obvious missing piece was weight — you can't quote a shipping rate without it. A lot of our shipments went to Europe, so we constantly needed to show the same package in both metric and imperial at once — 120 × 80 × 50 mm / 4.7 × 3.1 × 1.9 in, 1.5 kg / 3.3 lb. That's why the conversion API exists: no manual math in templates. Main differences: Weight field — fourth subfield alongside L×W×H, optional per-field Unit conversion API — $dim->lengthIn('in'), $dim->weightIn('lb') for passing values directly to shipping APIs (GoShippo, EasyPost, FedEx rates) or displaying both metric and imperial simultaneously Normalized storage — always saves in mm/grams internally; changing display unit never requires data migration 28 admin languages — useful when ProcessWire itself is configured with multiple languages and you want field labels to appear natively for each editor If you need area/volume stored and searchable — @Juergen module is the better fit. If you need weight + unit conversion for shipping integrations — this one covers that case.

Hi everyone, I made a small fieldtype module for storing product dimensions: https://github.com/mxmsmnv/FieldtypeDimensions FieldtypeDimensions lets you store length, width, height and optionally weight in a single field. It’s mainly useful for product/catalog/e-commerce pages where dimensions are needed for display, shipping or filtering. Supports different units (mm, cm, m, in, etc. for length and g, kg, lb, etc. for weight) and stores values internally in mm/grams. The module also supports multilingual setups — admin field labels are available in 20+ languages and can be configured globally. Basic usage example: $dim = $page->dimensions; echo $dim; // 120 × 80 × 50 mm, 1.5 kg echo $dim->lengthIn('cm'); echo $dim->weightIn('kg'); Selectors: $pages->find("template=product, dimensions.length>100"); $pages->find("template=product, dimensions.weight>500"); More details in the README. Feedback and suggestions are very welcome.

I'm not getting it done as quickly as I'd like. Most of the modules were written in February and March, when I had free time. Regarding the topic, yes and no. I want to standardize everything so that it looks native. Everywhere and always. And also the UI and UX should be convenient. So that when you open the Tracy dashboard at 3 AM, it doesn't look like a bright light, nothing more. @Ivan Gretsky

Hey everyone! Pushed a big update to WireWall today. The main addition is a dashboard module — install ProcessWireWall alongside the main module and you get a live stats page at Admin → Setup → WireWall. It shows blocked/allowed counts, a 24-hour chart, top block reasons, top countries, top IPs, active bans with countdown timers, and a recent events table. Works in both light and dark admin themes since it reads PW CSS variables. Also rewrote the settings page from scratch — went from 15+ scattered fieldsets down to 10 logical sections. City and subdivision blocking options now only show up if you actually have GeoLite2-City.mmdb installed, which cleans things up a lot. A few security fixes in this release too: proxy headers like CF-Connecting-IP are now validated against Cloudflare's published IP ranges before being trusted (previously any client could spoof them), unserialize() in the cache layer got hardened, and some overly broad AJAX bypass patterns were tightened up. Silent 404 mode now throws ProcessWire's native 404 page instead of plain text. GitHub: https://github.com/mxmsmnv/WireWall

❤️❤️❤️

this message from repo https://github.com/BernhardBaumrock/TemplatePreviewImages

Hey everyone! I'd like to share Start - a module that replaces the default ProcessWire admin home screen with a configurable personal dashboard. The problem it solves As your ProcessWire install grows, the Setup menu gets long - on smaller screens it overflows and you end up scrolling just to reach the tools you use every day. Start is the fix: think of it as the Windows Start button for your PW admin. Pin exactly what you need - modules, pages, whatever - and get to it in one click from the home screen. The result Features Two view modes - list and icon grid, preference saved per-browser Visual drag-and-drop editor at /setup/start/edit/ - reorder groups and links without page reloads Font Awesome 6 icons - 1887 icons with a searchable popup picker PagePicker - browse the full page tree directly from the URL field Example button - auto-populates with your installed Process modules and their FA icons Widget on the default admin home page Access control via start-dashboard permission Fully translated editor UI — 20 languages including RTL support for Hebrew and Arabic Supported languages English, Russian, German, French, Spanish, Polish, Ukrainian, Italian, Dutch, Portuguese, Chinese, Japanese, Turkish, Czech, Finnish, Korean, Hindi, Hebrew, Arabic, Hungarian. Installation Install like any other module — upload or place in /site/modules/, then install via Modules → Refresh. A Start item will appear under Setup in the admin menu. Make Start your admin home screen (optional) By default Start lives under Setup. To make it open whenever you click the admin logo or navigate to /admin/: Go to Pages in the admin menu Find the Admin page and click Edit In the Process field, select Start from the dropdown Save Links GitHub: https://github.com/mxmsmnv/Start

I tried integrating Columns, but it had issues with drag-and-drop blocks. So I released the beta version without it. The most important thing now is the stability of the beta version so we can move on to adding other features. Roadmap: Dark theme - there is a bug now, you need to change the reverse colors Localizing text in the editor so that it looks native on websites with a different language set in the admin panel Multilingual support - for example, for websites from Switzerland and Belgium, this is more relevant. Gallery (Slider) - the ability to upload multiple photos at once Textformatter support to allow connection to other text processors Columns plugin for adding column view If you know what works poorly or doesn't work at all, and would like to add something, I'd be happy to hear your suggestions!

Thank you Adrian for update. Are you planning to release a black version?

Late to the thread, but wanted to add a real-world data point. I run a spirits/wine catalog (~12,000 products) and a chocolate e-commerce store on ProcessWire. Both are in production and both have maintenance contracts attached. What I've found: the "update treadmill" problem simply doesn't exist with PW. Core updates are rare and painless. Module updates — same. That frees up retainer hours for things clients actually care about: new filters, catalog improvements, performance work. My maintenance plans now look like this: Backups + uptime monitoring (minimal time, easy to automate) A fixed block of hours for small improvements, content ops, or feature requests Reduced hourly rate for anything beyond that block The key insight for recurring revenue: clients with active e-commerce always have a backlog of small improvements. The retainer becomes a comfortable way for them to drain that backlog without opening a new project each time. For simpler marketing sites, the retainer is lighter but still justified by the "someone is watching this" peace of mind. SEO and analytics reporting also fit naturally into retainers — especially if you're running something like Plausible and can send a monthly digest.

The structure you want is actually slightly different from what Option #1 describes, but it's achievable. Option #1 assumes all sites share the same web root — the multi-site switching happens via index.config.php in that single root. Your setup (separate vhost docroots) requires a different approach. The cleanest way to do this with separate docroots: In each domain's docroot (/domaintwo/, /domainthree/, etc.) you only need: A symlink (or include-based) index.php that bootstraps from domainone's /wire A site/ directory with its own config.php, templates, modules The trick is the index.php in each secondary domain. Replace it with something like: <?php // /domaintwo/index.php $rootPath = '/var/www/html/domainone'; chdir($rootPath); require($rootPath . '/index.php'); And in each domain's site/config.php make sure $config->paths->root isn't hardcoded — ProcessWire resolves this dynamically, so it usually just works. You also need to copy (not symlink) .htaccess from domainone to each secondary docroot, since Apache serves it per-vhost. No index.config.php needed since routing is handled by vhosts at the server level — each domain already hits its own docroot. So the final structure: /domainone/wire/ ← shared core /domainone/site/ ← site 1 /domainone/index.php ← original /domainone/.htaccess /domaintwo/site/ ← site 2 (own db, templates, modules) /domaintwo/index.php ← bootstraps from domainone /domaintwo/.htaccess ← copy from domainone Each site/config.php points to its own database. Works cleanly without symlinks to /wire (which can cause issues with __DIR__ resolution in some PW internals).