All Activity

Hi @nbcommunication - I've actually set up my own report endpoint which logs to PW log files (csp-report and csp-report-only). I also ping via slack for any enforced violations. The only thing I still have in report-only mode now is "require-trusted-types-for". I have actually reported to a few open source projects I integrate about the changes to support "require-trusted-types-for" and they've actually been very responsive so I am hoping to be able to enforce this option very soon also. Note that I do exclude violations from browser plugins and the like, so my csp-report log is actually almost completely silent now. I do have separate policies for frontend vs PW admin which helps because PW still has various inline scripts and no nonce (yet). I am using Cloudfront but all my CSP and nonce logic is handled locally in my /site/init.php file - it's very different and much stricter than what I posted earlier above. I have Cloudfront enabled caching for all assets, but I am not using Procache for a variety of reasons, but performance with Cloudfront asset caching is a pretty good middle-ground.

Context v1.5.0 — AI Gateway Hi, just pushed a new release. The main addition is a centralized AI Gateway — a ContextAI class that any ProcessWire module can use to make AI requests through a single shared configuration: $ai = wire('context')->ai(); // Simple $text = $ai->complete('Summarize: ' . $page->title); // Full options $result = $ai->chat([ 'messages' => [['role' => 'user', 'content' => '...']], 'model' => 'openai/gpt-4o-mini', 'caller' => 'MyModule', ]); // Gateway entry point for third-party modules $result = $ai->gateway(['caller' => 'MyModule', 'messages' => [...]]); Supported providers: OpenRouter (200+ models via one key), OpenAI, or any OpenAI-compatible endpoint. New settings fieldset: provider, API key, default model, temperature, max tokens, timeout, global system prompt, and a Test Connection button that fires a live request and shows the response time. The idea is that modules don't need to implement their own HTTP clients or manage API keys — they just call wire('context')->ai() and everything is configured in one place. GitHub: https://github.com/mxmsmnv/Context

Hi @adrian, My experience is that it has to be implemented as middleware - as an example I've only experimented a little with Cloudflare Workers to implement a CSP nonce, but were it not for the Apache module this is likely the route I'd be going (for sites proxied through CF). A good goal, but I'm not sure it'll be achievable for sites using ProCache, there needs to be something modifying the cached HTML to add the nonce before serving it. Yep, agreed! We use a service (Report URI) to collate violation reports, and though it is a bit of a chore to review given the amount of violations that are recorded, that in itself is the reason to have it in place. I feel it also gives us a bit of a perspective on what clients are doing with their sites that we might not have otherwise, and for retained clients gives us information that allows us to be proactive (e.g. you've added a invalid media url on this page, it should be ...). Cheers, Chris

@teppo If I understand correctly, it sounds like you are primarily looking for a way to disable LazyCron from running during regular web requests? And to be triggered from a real CRON job (via CLI command) or from some other condition, like the presence of a GET variable or something? We already have conditions in the module that prevent it from during during ajax requests, file requests, redirect requests, path hook requests, etc., so it'd be a simple matter to have an option to prevent it from running during web requests and instead delegate to CLI or similar. I'll go ahead and add this. Though let me know if I've misunderstood any part.

Version 2.3.16 comes with a very powerful new validator called "checkContentForSpam" for checking a text for SPAM content. This was the first time I've used AI to develop a new functionality, and it was a pleasure. 😀 In a nutshell: By default the validator can check a text entered inside a form field for the following characteristics: Presence of STOP/SPAM words (compares it to a list of over 60 000 SPAM words) Capital letters of over 50% inside the text More than 2 Links inside the text Repeated usage of special characters ($,!,# and ?) Excessive usage of exclamation signs in a row (> 5) Short text with less then 50 characters and with various suspicious keywords in it Every characteristic found adds a specific amount of points to the SPAM score. If the max SPAM score is reached, then the validator returns false. Please read the full description in the docs for more detailed information.

Hey @ryan! In my case the main benefit of wp-cron is that the system keeps track of registered/queued jobs and lets me disable the request based execution and run them via real cron. This is a common practice, and I would even go as far as say that the request-based way of running queued tasks is mostly intended for shared hosting etc. where real cron may not be available. For this purpose wp-cron keeps track of scheduled jobs in the database, and has a config setting for disabling the "lazy" (request based) execution: define('DISABLE_WP_CRON', true) Once you've done this, you can set up a cron job, systemd task, or something similar that runs queued jobs, typically on a short interval (e.g. once a minute), so that you have almost-exact executions: * * * * * wp cron event run --due-now Basically wp-cron is a standard, system-wide way to register jobs to a queue, and keep track of which jobs have been registered and when, how often they should run, and when the next run time is. Those with no access to real cron (or some reason not to use it) can keep using the lazy approach, while those that don't want the jobs tied to web requests can set up a single cron job instead of e.g. many task-specific jobs. (And this also makes it a bit easier to e.g. set up a separate worker machine that just runs cron jobs.) I have a feeling that you may have looked at their default way to run jobs; you are right that at the surface level that looks very similar to LazyCron. But in my opinion this is actually the least important part of wp-cron 🙂 We have modules for setting something like this up. And it can be done by e.g. short-circuiting hooks unless some param is present, and so on. But a core way to do this would be most impactful. What we are missing is essentially a) a way for sites to disable request based job triggering globally (and I mean in a way that each module etc. adding these hooks doesn't have to know, e.g. $config->disableLazyCron), b) likely an option to store registered tasks in database so that they can be easily triggered and upcoming executions are made visible, and c) a way to execute scheduled tasks (something like WP-CLI cron command). Does this explain better what I meant? 🙂

Not yet — currently it renders as a single top-level link. A dropdown listing all collections on hover is a reasonable UX improvement and I'll add it to the roadmap. The main challenge is that collections lists can get long, so it'll need some thought around grouping or truncation.

Thanks for sharing this! It looks really helpful. Does the Collections link in the top nav behave like a dropdown menu with all the collections listed when hovered?

Since it partially solves what Lister Pro is about, we cannot expect something like this in the core. Anyway, thank you @maximus for sharing this module, I will surely try it out.

Hey NEO in this instance is more aligned to “new” than any acronym or AI /LLM technology. I guess the upper case letters suggests an acronym but, honestly, I just liked the visual rhythms of both words. Not sure if this answers your question or if I misunderstood?

Thanks for all the feedback, this is great. I just wanted to say ProcessWire has always been "back", never left. It's always been a long term project and never a fad project, so periods of rapid development and periods of slow development are normal, and I'm sure that cycle will always be the case. I've always been careful about making sure the project doesn't get bloated with short term things. So to make sure the quality is high over the long term, it's good to know when to go into rapid development, and when to let things simmer slowly. There's room for both. The other factor is that sometimes I have client work deadlines that I've got to give priority to because that's what keeps me in business, and able to keep investing in ProcessWire. I mention all this just because I don't want folks to be disappointed when there are weeks without any commits, etc., because that's unavoidable. For me this has always been a lifetime project, so ProcessWire isn't leaving or coming back, it's here to stay, as has always been the case.

Brilliant implementation as usual. Ditto - I find when creating modules that tables are almost always the most important working view and the data model I have to fight and customise the most. I’d love to see this incorporated into the core and more modules too.

A quick note about the new documentation: the table layouts in the accordion sections don't work on mobile devices. They aren't scrollable. 😊

The module may not have received any updates in the last five years, but it works reliably. I use it as a must-have for updates. Thanks for sharing the link - I hadn't heard of it before.

@maximus - it hasn't been maintained in quite some time (and probably does need some work on some features), but https://github.com/adrianbj/ProcessModuleToolkit provides a way to upgrade all with one button click. Not suggesting your idea wouldn't be nice as well though.

I’m using the core FieldtypeComments in ProcessWire and everything works correctly on the frontend and in the database. Comments are saved properly and displayed without issues. However, in the admin I get a one-time SQL error after a new comment is submitted: SQLSTATE[HY000]: General error: 1525 Incorrect TIMESTAMP value: '1777649215' Observations: Difference between “error value” and stored value is consistently +3600 seconds No data corruption or functional issues occur Environment: PHP timezone and $config->timezone both set to Europe/Brussels The warning only appears once per comment submission and does not affect saving or rendering. Has anyone seen this behavior before with FieldtypeComments?

Hi everyone, I've been running this module in production a spirits catalog with 12,000+ products — for several months. Today I'm releasing it publicly. GitHub: https://github.com/mxmsmnv/Collections The problem ProcessWire's page tree is brilliant for site structure. It's painful for data management. When you have thousands of pages as records — products, listings, vacancies, menu items — you hit the same walls on every project: no table view, no inline filters, no bulk actions, no export, no REST API, no role scoping per dataset. Every PW developer has solved some version of this. Collections solves it once. Screenshots What it does Gives any ProcessWire template a configurable admin table — live search, dropdown filters, inline status toggles, bulk actions, CSV/JSON export, and a REST API — all configured through a UI, without writing code. Admin UI: Configurable columns per collection with custom labels Live search with 300ms debounce across multiple fields including Page references Dropdown filters for FieldtypePage and FieldtypeOptions fields Inline publish/unpublish toggle via AJAX Bulk actions: publish, unpublish, delete with CSRF protection CSV and JSON export with active filters preserved Role-based permissions matrix — scope each role per collection "View in Collection" button injected into the page edit form REST API: Bearer token, query param, HTTP Basic, and PW session auth API key management with expiration dates and per-key capability scopes SHA-256 hashed keys, usage tracking, rate limiting (100 req/min) WireCache support for GET responses ProFields support: Table, Textareas, Multiplier, Repeater Matrix, Combo — including dot-notation for subfields (address.city, blocks.hero.title, prices.*.amount) Field types: Text, Textarea, Integer, Float, Checkbox, URL, Email, Date, Image, File, FieldtypeFileB2, FieldtypePage, FieldtypeOptions, MapMarker, Color Requirements: ProcessWire 3.0.244+, PHP 8.2+ There's a thread from 2013 asking for exactly this: Module Idea: Flat Listings — here it is, 12 years later. Known issues are tracked on GitHub — the module is stable for production use, active development continues.

Yes, I know it well — great Dashboard module! I've used it on almost every project to keep the admin from feeling bare. But as projects grew, I kept hitting the same wall: customizing Dashboard meant writing PHP for each install, and the widget lists got unwieldy. Start (and its companion module Collections) came out of that frustration — the goal was a fully visual, no-code editor where you just drag, drop, and pick icons without touching any config files.

Six months ago when Ryan was posting once a week, I thought the project was slowing down. Really glad to see the pace pick up! ProcessWire's architecture was always ahead of its time — there's legacy code built up in layers, sure, but the direction now is exciting and hard to keep up with 😄

@ryan, can you add cli command for quick updates without pushing for each button ?

Super happy with the energy revival of Processwire and the speed at which everything is moving. I feel like moving from a hobbyist to a PRO! This week did my first Claude Design, which I then passed onto Claude Code, with an amazingly simple and smooth workflow. For people into Claude who haven't tried this workflow, please check it out.

You won't believe how these changes make my day(s) now! Moving away from ProcessWire to NextJS/AstroJS/HonoJs/WhateverJS just to be able to prove a concept and go live within a super short time using AI/LLMs/Agents was hard but I got things done. I was able to test things, to experiment, to explore, to fail, to succeed. Well... now ProcessWire is back. Back in my preferred stack of tools. Back on #1. I've already moved 2 big projects back from HonoJS and NextJS to ProcessWire. The RSS Monitoring Tool and another one. Cloudflare Workers and Vercel were great hosts with pretty awesome free tiers, yet... at some point I scratched limits big time. Now everything is hosted on H*stinger for a few dollars a month with full CI/CD pipeline, no limits on reads/writes to the database, just a 5GB size limit per database and some other weird limits those projects will never reach. It's unbelievable how fast things turned around and back to a language (PHP) I actually can read and understand and a framework I kind of know how to work with.

@wbmnfktr Thanks! This is great to hear, this kind of feedback makes my day. 🙂

Can you define this a bit more detailed? I mean we have a lot of new AEO, GEO, LLMO, AIO, VEO, NEO, AISO acronyms out there. The name would suggest that NEO (Neural Engine Optimization) would be the focus... is this the case?

This will retire my whole set of ProcessWire skills... and I love it! I really enjoy the pace and direction you, @ryan, and ProcessWire are going now. Let alone AgentTools in a fresh installation of ProcessWire does some magic with LLMs (from super cheap Mistral, Deepseek, to great models like Kimi 2.6, MiniMax 2.6, and to Opus 4.6/7 and Codex 5.4/5) which was NOT possible in that way 6 weeks ago. 🥰