Recently Updated Topics

Hi @Roych - I am seeing a LOT of bot traffic showing up in the stats - it's effectively making the data useless. Claude's analysis and suggestions: Total identifiable non-human traffic in this top-20 alone: ~955 sessions out of your 1,789 (~53%). And the signature is unmistakable: every one of these has ~1.00 hits per session, which is exactly why your single-page rate is 90.7%. Strip these out and your real human single-page rate is probably in the 60–75% range — perfectly normal for a content site. 1. Pull in Matomo's bot regex list (one-time integration, ~thousands of patterns vs. your ~20). Highest ROI. There are a few PHP libraries that wrap it — matomo/device-detector on Packagist. 2. Add datacenter IP filtering with GeoLite2 ASN data — free database, monthly update. Drops the Chrome/142-style residential-proxy-via-datacenter traffic. 3. Consider making JS-tracking the default (set autoTrack: true in injectTracker) and demoting server-side recording to a fallback for visitors who block your JS. This single change would likely cut your bot noise by 60–80%. 4. Skip behavioral fingerprinting unless you find specific high-value bots slipping through — it's a maintenance burden that doesn't justify itself for most sites. https://github.com/matomo-org/device-detector https://github.com/JayBizzle/Crawler-Detect Please let me know if you have any thoughts, but I think it's clear that the isBotUserAgent($ua) regex isn't very useful at all.

Cool, thanks.

Thanks @adrian, working great now. Yes, love this feature here, and in the Tracy Console too. Thanks for adding it!

A simple, flexible asset management system for ProcessWire that makes handling CSS and JavaScript effortless. Organize assets with groups and collections, seamlessly switch between CDNs and local files, inline critical resources, generate integrity hashes, and render optimized HTML tags - all with an intuitive notation system and clean API that feels natural in ProcessWire. Alpha — v0.1.0. This module is in early testing. The API may change before a stable release. Feedback and bug reports are welcome.

A background job queue for ProcessWire. Push tasks onto the queue from any template or hook, and let LazyCron process them automatically in the background — with priority levels, delayed execution, automatic retry with exponential back-off, and your choice of file or database storage. Alpha — v0.1.0. This module is in early testing. The API may change before a stable release. Feedback and bug reports are welcome.

A WireQL-powered query engine for ProcessWire that makes building API endpoints effortless. Execute explicit CRUD operations, apply collection modifiers, sanitize field output, and cross-reference query results — all in a single expressive request. Alpha — v0.1.0. This module is in early testing. The API may change before a stable release. Feedback and bug reports are welcome.

A fluent HTTP response builder for ProcessWire with full HTMX support, redirects, cookies, and content negotiation. Build JSON APIs, send HTML fragments, manage headers, and handle redirects with an elegant chainable interface. Alpha — v0.1.0. This module is in early testing. The API may change before a stable release. Feedback and bug reports are welcome.

A modern HTTP request handler for ProcessWire that provides an expressive, type-safe API for accessing request data. Handle form inputs, headers, files, cookies, JSON payloads, HTMX requests, and client information with an elegant, fluent interface - all while maintaining ProcessWire's philosophy of simplicity. Alpha — v0.1.0. This module is in early testing. The API may change before a stable release. Feedback and bug reports are welcome.

A modern, fluent HTTP client that makes consuming APIs effortless. Send HTTP requests, handle responses, upload files, manage authentication, execute concurrent requests, and download remote files - all with an elegant, chainable interface. Alpha — v0.1.0. This module is in early testing. The API may change before a stable release. Feedback and bug reports are welcome.

That's huge. Obviously not a full solution as manual testing is (even with AI, so far) still required, but a big burden can be mitigated right at the start. 👌 Same for the SEO, but even moreso for the template file security scan. ❤️ Always happy for good documentation that PW is known for.

@elabx - that's what Claude suggests. It looks more like a poor implementation in InnoDB itself to me but I'm sure there's reasons for why it behaves the way it does. Either way, I'd definitely be interested to hear what @ryan thinks.

I use frontend editor in some of my textarea fields. I do it for a long time, without problems. Now, after rebuilding one of my sites, frontend editor works on some pages; on other pages the field I'm trying to edit disappears (not for good, only when I'm trying to edit). On the back office editor, no problem. Did it happened to anyone else? Do you have a clue about possible causes? PW version: 3.0.255 PHP : 8.4 Edit: On a better thought, I begin to suspect that the pages where front-edit doesn't work are those where the textarea field starts with a hannacode (marked with [[...]] ). I use it some times to embed jumplinks. Edit2: I'm using TinyMCE . Edit3: Nop. I tried to render the page without jumplinks, but the problem remains.

@markus-th Good catch! That was a formatting bug — PHP was rendering very small values in scientific notation (9.0E-6 kg) instead of human-readable units. Fixed in v1.7.0: the dashboard and DOCX export now auto-scale to µg / mg / g / kg depending on magnitude, so your total will show as e.g. 9 mg instead. Thanks for spotting it! @Peter Knight Love this idea — just shipped it in v1.7.0! Each bar is now colored by the average CO₂/request for that hour: green = Grade A (<100 mg), yellow = B, orange = C, red = D. So when you optimise a heavy page or compress images, the next day's bars literally turn greener. Tooltip also shows avg mg/request and Grade on hover. A/B/C/D legend sits above the chart. Looking forward to hearing how it goes when you try it!

@ryan - I just did some more testing and I get the same error even if I just instantiate another PW instance in a regular template file. No other code after that, just: $ca = new ProcessWire('/var/www/othesite.com/html', 'https://othersite.com');

Wow!!

Some time ago, I decided to install xdebug on my development server, but I never really needed it or used it. TracyDebugger is enough for what I'm doing. I didn't notice it then because my app was not highly developed at the time, but it really causes speed issues especially if you're working on a sophisticated site with a lot of business logic. For a long time, I thought it was just ProcessWire itself being slow, my app being slow due to some optimizations I hadn't done yet, my database being very large, combined with my low spec dev server, but it turns out disabling xdebug, which I had long forgotten about, made things much faster. Just a heads up if you're having speed issues!

Hi @maximus, Thank you for taking my request into consideration, I have updated Ichiban and I can confirm that in my case {combo.field} and combo.field is working as expected and og:image is showing as intended, the only detail is when I’m using combo fields as source for OG image URL, Ichiban doesn’t show the resolved path and social preview doesn’t show up, but it’s still rendering the correct URL in the source code. In pages that have a unique image field {image} shows the correct resolved path and the social preview image

A router layer over URL segments API that replaces complex if/elseif chains with clean, expressive route definitions. Supports named parameters, type aliases, regex constraints, optional segments, wildcards, and HTTP method matching — all wired directly into ProcessWire's template system via page hooks. https://processwire.com/modules/simple-router/ Alpha — v0.1.0. This module is in early testing. The API may change before a stable release. Feedback and bug reports are welcome.

A tiny ProcessWire admin utility. Hold a modifier key and click any Inputfield toggle to copy the field's machine name to the clipboard — without collapsing the field. Useful when building templates, writing selectors, or debugging: no more hovering to read the name in the title attribute. Github: https://github.com/dlzi/FieldNameCopier

This module provides a ProcessWire Admin UI (“bridge UI”) for the ProcessWire Console ecosystem. It does not re-implement Console features itself; instead it integrates with: trk/processwire-console (required for most features) trk/processwire-boost (optional; status/info only) Module repo

We might have a minor misunderstanding here. Building modules, tools, apps, anything with little to a lot of logic and functions is not the issue here. My problem is not that there are functions or config fields (Admin UI) missing or not working in a way or form I imagined them to work. The problem is that the Agents and LLMs are not ready yet to build module backends (Admin UI) - even when outlined in high detail. Sometimes they are almost there or at least it looks like it, sometimes they invent something totally new and won't even use existing field types, wrappers, and classes. Having an existing module, adding new functionality, new config settings, or even pages works incredibly well. That's because the Agent/LLMs can re-use existing structure of backend code. Besides that I totally support your step-by-step process and workflow. You can't just throw a vague idea towards whatever tool and expect a wonder. That's for sure. Little side note: I asked Kimi and Opus to build a module that's only purpose is to showcase module pages, all sorts of inputs and outputs. So I have a working base for interfaces I can point at later on. The prompt for those interested: The result: https://github.com/webmanufaktur/ProcessShowcase

Work in progress, but in this version, clicking the title takes you to the module config page. You can upgrade dev to the latest commit, which also works for modules. Uninstalled modules are only updated/downloaded, but not installed.

You are right. Ok. You are violating forum rules with this one too. "modules thread" Have you missed an apostrophe perhaps? I am asking this because "module's thread" would make more sense to me. Am I missing something perhaps? Anyway, I deleted my comment above. Cheers.

I’m late to the Konkat theme but having used it recently, I really like it. It seems without any major UI adjustments that it’s just a nicer experience and if I’m not imagining things, a little faster? Nice job @diogo and everyone. If you’re open to feedback, can I add the following. First, the main grey background is a touch too dark for my personal preference, and interestingly a client mentioned the same, describing it as too industrial. They’re marketing. They like their UI to be friendly and approachable. The issue is a practical one: a heavy base grey compresses the tonal range before we placed a single element on the page. To make cards or panels register visually at all, you have to resort to strong contrast because a nice, subtle layering just disappears. Alternatively, with a near-white base you have room to step up gradually, building visual hierarchy through gentle increments. A heavy base leaves nowhere to go without things feeling either too dark or muddy. This isn’t a design lecture… just trying to pinpoint the particular issue. And I agree it only really affects module builders but interestingly, a client recently remarked that they found it a little industrial and unwelcoming compared to the previous theme. Next up, buttons… I find that buttons with 100% border radius never appear as truly aligned as flat side buttons with a subtle border radius. We switched to rounded buttons years ago on an enterprise project, everyone loved the change ( yay, jelly beans!) and now we’re going back to traditional 4px border radius throughout because everything just looks better aligned. It seems the beauty of using the css vars is I can easily tweak these things myself but wondered if at least the grey background was under consideration? Otherwise and honestly, it’s a great theme and I’m looking forward to using it more.

Hey everyone, MediaHub v1.17.0 is now available and introduces Focus Point support, SVG uploads, Input Field UI enhancements, and improved KONKAT compatibility. Existing customers: visit your account downloads area. New to MediaHub?: visit my in-progress landing page Full changelog: https://www.peterknight.digital/docs/mediahub/v1/changelog/ Release blog post https://www.peterknight.digital/blog/posts/mediahub-1-17-release/ Happy to answer questions here, but in the meantime, here are some screenshots. Focus Point support and focus point aware cropping. In the crop editor, you can now set and change the Focus point target.... As you might expect, crop presets and auto-generated crops snap to the focus point... SVG support Also in 1.17, driven by a request from @Stefanowitsch: SVG support for logos, icons, and illustrations that need to scale cleanly. SVG uploads are off by default. Enable them under Modules → Configure → MediaHub in the new SVG Support section. When turned on, uploads require the native ProcessWire FileValidatorSvgSanitizer module. If the sanitiser isn’t installed, uploads are refused rather than letting an unsanitised file through. InputField UI polishes Detail view is meant to show more per card, but the layout felt cluttered. Detail-mode cards now use a cleaner layout with a Crop · Focus · Edit action strip and inline file metadata. More to come on that front. It's somewhat based on the native Input Field view, but with a few tweaks. Konkat Theme If you run the ProcessWire KONKAT light admin theme, 1.17 includes improved compatibility across MediaHub’s admin screens. The asset detail page gets a cleaner card layout, a Modified column in the Crops table, and usage-aware delete confirmations (not shown) IE MediaHub warns you before deleting an asset or crop that’s still referenced elsewhere. Next up, as promised, I am working on improved support for batch operations, such as bulk upload and getRaw() support for massive libraries. Thans for reading. If you like what you see, I hope you can make MediaHub part of your next ProcessWire project 🙂 P