Leaderboard

Hi everyone, Every web page has a carbon footprint. Most developers have no idea what it is. This module measures it. GitHub: https://github.com/mxmsmnv/PageCarbon What it does Tracks response size, PHP execution time, and peak memory per front-end request, then estimates CO₂ using the Sustainable Web Design Model v4 (Wholegrain Digital, 2024). Results appear in a dashboard under Setup → PageCarbon. Admin dashboard: Per-page ratings: 🟢 A (< 100 mg) / 🟡 B / 🟠 C / 🔴 D (≥ 700 mg) 24-hour hourly CO₂ bar chart Top 50 pages by average CO₂ with exec time, response size, and hit count Real-world analogies - all-time total translated into 12 everyday equivalents: car km driven, espressos brewed, Netflix hours, Google searches, short-haul flights, trees needed for a year, and more DOCX export - zero-dependency, pure PHP via ZipArchive Screenshot: Performance-first architecture: WireCache buffer - metrics accumulate in memory, batch INSERT once per hour (zero per-request DB writes) Bot sampling - only 1-in-N bot requests recorded, human requests always in full 90-day raw retention with permanent hourly aggregates - historical data never lost Frontend API: $pc = $modules->get('PageCarbon'); echo $pc->renderBadge($page); // full card echo $pc->renderBadge($page, 'compact'); // single-line pill $stats = $pc->getStats($page); // avg_co2_mg, rating, hits... The average web page produces ~500 mg CO₂ per view. Most ProcessWire sites do better - now you can prove it.

Now available in the Modules directory at https://processwire.com/modules/chat-ai/ and on gitHub at https://github.com/clipmagic/ChatAI What is it? ChatAI is a native ProcessWire AI chatbot module designed to answer questions about your site content, with a focus on: ProcessWire-first workflows Site-aware answers using RAG (Retrieval Augmented Generation) Respect for ProcessWire access control rule Admin visibility into usage and performance Keeping content ownership within ProcessWire Features include AI chat widget for frontend use RAG indexing of ProcessWire content Multi-role message support (system / assistant / user) Admin dashboard with metrics and observations Configurable prompts and behaviour Integration with AgentTools for model selection Role-aware retrieval (users only see content they can access) Frontend page restrictions Dictionary / weighting support for retrieval tuning Quick Start Ensure prereqs are installed, ie: PHP>=8.0, ProcessWire>=3.0.255, AgentTools>=0.1.1, TextformatterEntities, TextformatterNewlineBR Configure your chat LLM in AgentTools Configure your textembedder LLM in AgentTools Configure ChatAI module config with both the above Go to Setup->ChatAI and index your site pages (turn off Dry Run when you're ready). Add the CSS, Script and Widget to your template(s). After that, tweak to your heart's content, including adding languages, widget theming and prompts. Current status: Alpha Test thoroughly before using on live sites. Feedback welcome.

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

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

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

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!

Buy land. Plant trees. Don't talk about it. Repeat.

In case it is of interest to someone: https://www.youtube.com/@IBMTechnology I viewed one of the videos presented by Martin Keen the other day and thus discovered this channel. There seems to be a lot of good videos about different aspects of AI and other subjects. I haven't started yet with AI, I'm just slowly trying to understand how things work. As soon as I can I'll try to use it locally. In reality the first (specialized and local) one(s) I'll probably/perhaps try will be while using DaVinci Resolve Studio. For the moment the only one I've started using a few times is Leo on the Brave Browser (On another subject, I just discovered yesterday by accident while using the mouse that it is possible to split the view with (only) 2 visible tabs, unlike with Vivaldi where there are more options. I hadn't even searched if it was possible. And I've just discovered it is now possible with Firefox, but also only with 2 tabs.). I had found about Aider a few weeks or months ago, it seemed really interesting.