All Activity

Cool, thanks.

Thanks for the report @Robin S - I hadn't seen that because it was specific to running the Console panel from the module config settings page, but is fixed in the latest version now.

Yeah, I've mostly weaned my sites off of it, but I have a few busy ones where I don't want to force the logout of all the front-end users. After upgrading the "Running..." notice just keeps going, and when I checked the browser console there was an error message.

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.

Hi @Roych - do you think it would be possible to exclude URLs from the 404 pages section if they end up resolving to another page - for example, the PW core PagePathHistory modules does a great job of automatically redirecting pages with changed names to their new path, but the original failed path is still being listed.

Sorry about that @Robin S - I had checked file downloads with the new version, but not using PW's $files->send. I tested with your example above and it's working again in the latest version. Please let me know if you notice any issues. I think it's really nice having actions run in the background now so that aren't subject to any time limits, but it has complicated things.

Hi @Robin S - really sorry about that I never use SessionHandlerDB but I need to remember to test with it - should be fixed in the latest version.

@Roych dark mode looks amazing. This is turning out to be a stellar addition to PW. Thanks for your grind.

NativeAnalytics v1.0.23 released Finaly! This release brings full theme-adaptive UI support - the dashboard now natively follows the active ProcessWire admin theme, including automatic light/dark mode switching via Konkat's CSS custom properties. What's new: Automatic light/dark mode - panels, tables, charts, filters, tooltips and sub-tabs all adapt to the active color scheme and more ... Grab it from the repo and let me know how it looks on your setups! Thanks to @matjazp for the nudge to make this dark-mode friendly - more and more people are using dark themes these days, so it really had to be done. Took longer than I thought it would ... Cheers R

Hi @adrian, I have an action that was working in v0.9.8 <?php namespace ProcessWire; class DownloadModulesDirectory extends ProcessAdminActions { protected $title = 'Download modules directory'; protected $description = 'Download a ZIP file of /site/modules/'; protected $author = 'Robin'; protected $dbBackup = 'disabled'; protected function defineOptions() { return array(); } protected function executeAction($options) { $files = $this->wire('files'); $config = $this->wire('config'); $zip_pathname = $config->paths->site . 'modules.zip'; $files->zip($zip_pathname, $config->paths->siteModules, ['overwrite' => true]); $files->send($zip_pathname); return true; } } In v1.0.1 the zip is created but a download isn't prompted, and I see this when executing the action:

Hi @adrian, I also got the CSRF issue when using the console. I think it's a compatibility issue with SessionHandlerDB. The console works when that module is uninstalled.

Thanks so much @Roych - I really appreciate the quick turnaround on that.

Hi @adrian, thanks for the kind words! Good news — NativeAnalytics v1.0.22 now supports CSP nonces using exactly the two approaches you describe: Central $config->cspNonce / $config->cspNonce() — if/when Ryan adds it (or you define it yourself in config.php or via a hook), the module picks it up automatically. TracyDebugger-style header parsing — as a fallback, the module reads the already-sent Content-Security-Policy / CSP-Report-Only header and extracts the nonce from script-src / script-src-elem using essentially the same regex you posted. The relevant helper is NativeAnalytics::getCspNonce() / getScriptNonceAttribute(). The module does not create or manage the CSP header itself — it only reuses an existing nonce — so it works with whatever CSP setup you already have (middleware, web server config, custom hook, etc.). If no nonce is found, scripts are emitted normally without the attribute, so nothing breaks for sites that don't use CSP. - See NativeAnalytics.module.php, lines 143–191 if you want to check the implementation. So no core hacks needed on your end — should just work. Let me know if you run into any edge case. Version Updated to: v1.0.22 Cheers 😉 R

Thanks for this @Roych - really excited to make use off all the event and goal tools - I feel like Google Analytics has down really downhill in recent years. Your module's layout is clean and functional. The one thing I am struggling with is PW's lack of a centrally defined nonce which means I can't run this module without hacking the core to add the nonce. I have talked about it here: https://processwire.com/talk/topic/31739-config-cspnonce - but not sure if Ryan is at all interested. I like the idea of a central $config->cspNonce() that could be used by all module developers and also in our template files. The other alternative for module developers is to add a helper function like this: function getNonce() { return preg_match('#^Content-Security-Policy(?:-Report-Only)?:.*\s(?:script-src|script-src-elem)\s+(?:[^;]+\s)?\'nonce-([\w+/]+=*)\'#mi', implode("\n", headers_list()), $m) ? $m[1] : null; } to find the set header's nonce and inject that into its script tags. This is what TracyDebugger does. Anyway, not really sure I have a definitive ask for you - maybe I am just trying to spread the word about my desires for a centrally defined nonce in the PW core.

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

Ok got it! Maybe this is actually a bug? I sort of remember @ryan mentioning that meta weren't really built with search in mind? So maybe just drop the index creation and drop it on updates?

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.

Hi @elabx, Yes, but very small amounts. The kicker here is that it doesn't actually matter what is being stored, it is the frequency of writes that causes the index file to balloon. This caused me a lot of confusion, as I have sites where I store much larger JSON values in pages_meta and they don't appear to have the problem. Ultimately they do, but because writes are much less frequent the index file hasn't grown that much in comparison. Cheers, Chris