All Activity

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

Wow, this is really thoughtful and timely @maximus. On your column chart, it would be amazing to see how optimising inefficient code and graphics etc can help flatten those bars. Going to try it soon. 🌳

@Roych It looks promising so far. Thanks for the module. Custom event tracking and goal tracking are features I personally would still like to see. Plus conversion rates based on that data. Have you already run a performance test using long-term data and a large number of visitors? How does this scale over the long term? For example: I have sites with 6 million unique visitors per year and a tracking history spanning 15 years. Does the module still run stably with such large data volumes?

Nice module 😉 Look at CO₂ total. Is it too less to calculate actually?

I am just reading about this but just in case: Can you make event tracking easy? Google Analytics makes it so hard to see when a button or other action is taken. Having this built into PW and super easy to implement would be a godsend.

Whoa! This seems like a monumentally great module. Just blown away. Thank you!

@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');

They are both running the same version - latest dev. I am seeing the issue when pulling in data from another instance via a RuntimeOnly field on the User template. It worked without error until recently so there is definitely something the way things are now loaded. More details here: https://github.com/processwire/processwire-issues/issues/2247

Wow!!

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.

The hardest bit...

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

Sure thing. If it were possible to code a module like that, I would be the first to do it. Jokes aside, anything that helps even a little is welcome, of course. Thanks for sharing!

Agreed — and while we're waiting for the forests to grow back, at least we can measure how much damage our websites are doing. 🌱 Awareness is the first step. Knowing your numbers is what makes the conversation about natural restoration possible in the first place. The module doesn't claim to solve anything, just to measure.

Which should be addressed by planting forests and most importantly, letting nature heal. https://en.wikipedia.org/wiki/Biological_carbon_fixation "The process of biological carbon fixation plays a crucial role in the global carbon cycle, as it serves as the primary mechanism for removing CO2 from the atmosphere and incorporating it into living biomass. The primary production of organic compounds allows carbon to enter the biosphere. Carbon is considered essential for life as a base element for building organic compounds. The flow of carbon from the Earth's atmosphere, oceans and lithosphere into lifeforms and then back into the air, water and soil is one of the key biogeochemical cycles (or nutrient cycles). Understanding biological carbon fixation is essential for comprehending ecosystem dynamics, climate regulation, and the sustainability of life on Earth." Destroying natural habitats is something we should have stopped doing a long time ago. But it's not too late. I think we should concentrate on letting nature heal on its own by restoring (letting it restore) as much habitat as possible. We should just let Mother Nature do what she does best, without trying to play God by always trying to fix what we have screwed up by some sort of yet another artificial method we (most of the time) come up with.

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.

@wbmnfktr The current version of AgentTools lets you configure the max iterations on the module screen. Previously the number was like 5, but the new default I believe is now 20. They are good at fixing bugs. It's just that some of the bugs were previously silent or not commonly noticed. I use multi-instance quite a bit, and even on this site (the whole modules directory is a separate install booted from this one). But I've not run into this issue. Is it possible the two instances are running different versions of PW?