All Activity

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

Thanks for the feedback. Yes, easy event tracking is already built into NativeAnalytics. The module can automatically track common engagement actions such as form submits, downloads, mailto/tel clicks and outbound links. For custom CTA buttons or other actions you can add simple data attributes like data-pwna-event, data-pwna-group and data-pwna-label. Based on the feedback, I have also added a new Goals section for the next release (This was already on the list and partialy done, thanks for the kick ... 😉 ). Goals can be created from tracked events or from page/path rules, for example a thank-you page, a form submit, a CTA click or a download. The dashboard then shows conversions, converted sessions, unique visitors and conversion rates. Regarding very large datasets, I do not want to overclaim without real long-term benchmarks at that scale. The module includes retention options, daily aggregate tables and cleanup tools, and the next release improves this further for events and goals. For very high-traffic sites, the recommended approach is to keep raw data only for a limited period and use aggregate data for long-term reporting. Wait for the update refresh 😉 New version is now v1.0.21. Thank you R

Kudos! Thanks for taking the time to share. I can clearly picture myself making the same assumptions about page_meta haha. What was the type of data you were storing? JSON?

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

While trying to find the cause of disk usage increasing by several GB per week, I discovered a file inside /var/lib/mysql that was indeed increasing by several GB per week, sometimes up to a GB a day. This file is used for fulltext indexing: fts_000000000000dbd8_0000000000013612_index_1.ibd By running optimisation on the database tables, I was able to 'reset' the file. I thought it was maybe a bug in the database, so tried setting up a fresh database copy, but the issue persisted. Time to call Claude... Here's the full conversation: https://claude.ai/share/94de4c96-4a04-4fae-b3c5-de95225316bd Long story short, I was using pages_meta to record statistics tied to pages/users, so write operations on the table were pretty frequent. It seems a bit absurd to me that this could cause a index file to balloon to such a ridiculous size (it was 100GB when first discovered) as it isn't a high traffic site and the amount of data in the table is minimal (2MB). However because of the frequent writes, the indexing file was being frequently appended to and for some reason it doesn't prune itself it just keeps expanding. I've re-written the stats so they are stored on the filesystem instead of the database, so far that seems to be working. Claude brought a couple of things up, which would probably be worth reviewing @ryan: Why is there a fulltext index on the data column? No primary key Ultimately, I think the issue here is how I've gone about using pages_meta - It isn't the right solution for frequently updated datasets - but I thought I'd pass this on for consideration, and also for anyone else who might find themselves in the puzzling situation of a ballooning index_1.ibd file. Cheers, Chris