Leaderboard

This week I've been doing a major overhaul of the /wire/core/ directory structure aimed at improving and adding documentation. Now all core classes that will receive their own API.md documentation also have their own directory. The /wire/core/ directory kind of resembles the /wire/modules/ structure now. In addition, new API.md files have been created for the Pages, Page, PageArray, Modules and Module, all of which also improve the online API reference documentation too, which is what those links are linking to. We'll continue adding more API.md documents every week. Every time a new API.md file is completed, it gets sent over to the WireTests module to verify that everything documented in the API.md works exactly as stated. So new tests have been committed to that module as well, and more will be getting added every week. In addition, ProcessWire now has a CLI (command line interface) installer. Installing ProcessWire is as simple as typing this from the command line: php install.php When you do that, it'll present you with the installation options (see below). For human users, the "Standard usage" option is likely to be best, while AI agents will likely prefer the "Alternate usage" option: Standard usage: php install.php --generate Generate ./install-config.php for you to edit php install.php --config install-config.php Install from settings in ./install-config.php Alternate usage: echo '{"dbName":"mydb",...}' | php install.php Install from settings in JSON string php install.php --json '{"dbName":"mydb",...}' Install using an inline JSON string Other: php install.php --help Display all options That last option "--help" displays a giant screen of options, so I won't repeat it here, but take a look if you are interested. New versions of FieldtypeTable, FieldtypeCustom, FieldtypeCombo and FieldtypeRepeaterMatrix next week. Lots more in progress here too so stay tuned! Thanks for reading and have a great weekend!

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.

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.

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

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.

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

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 ?

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.

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.

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.

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.

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

Hi @ryan there are a lot of modules I was working on. I began creating them even before the company project itself got underway (these are apps intended for internal use), anticipating what I would need based on the initial requirements and my prior experience with ProcessWire projects. I wanted to avoid conflating module development with the development of the core application itself. That said, this meant I was able to test some of the modules incrementally, as the need arose; however, a significant portion of the project remains to be completed, and there are other modules—on which I performed only limited initial testing—that I haven't actually put into use yet. In fact, they could be considered by the community as proofs of concept, given that I am not strictly a "professional" developer; I'm a graphic designer, and my role within the company is as Webmaster. Nevertheless—thanks to ProcessWire's ease of use—I have spent years implementing tools that assist the various departments in their daily operations. All these modules were built around a philosophy of "Simple": they get straight to the point regarding my specific needs, though I am not sure whether they would prove useful to others. I have never worked with Git or a version control system, nor have I ever published modules before, so I have no idea what the best way to proceed would be; if you could offer me any guidance, I would be very grateful.

@AndZyk I was able to duplicate the issue when using openrouter. It turned out that because the openrouter string starts with "anthropic", it was getting interpreted as a line having a "provider" property, which is something that we deprecated, but still supported for backwards compatibility, and so it was causing the properties to get mixed up. I've updated the detection logic so that it shouldn't happen anymore. Thanks .

Hi Ryan, I'll do my best to explain this, but keep in mind my experience with queues / background jobs is only 2 years old. But in short, inspiration would be best taken from the classic, "batteries included" big web application frameworks like Laravel (as Teppo pointed out) and Rails. I like the Laravel page I linked because it gets very in-depth (I've read that page at least 10 times). Let's use a classic example like this: Let's say someone wants to upload a video to a field and we want it to be converted to a different file format (let's say that's being handled by ffmpeg). That's a time intensive task that wouldn't be able to be done within a standard max limit 30 second web request, or even with the memory available to php via php-fpm. It might take minutes or even hours, and even then, things can go wrong and it might fail. So, instead we'd want this to happen independent of the web request, therefore a background job dedicated to that task would have to be made and scheduled to be processed. It could happen immediately, or maybe it can be scheduled for 30 minutes later. This is not related to cron jobs which are a different concept. (Another example is for example in an ecommerce checkout; it's generally better practice to send the order notification email as a background job instead of inline with the code that processes the order after it's submitted). With that, queue systems are typically powered by a different dedicated database or system, with Redis being a popular choice. The reason for this is to limit load on the primary database; many large systems may have millions of jobs per day so offloading that to a separate database saves resources. However the big web application frameworks I mentioned also allow the option for the main database itself to store the jobs (Rails enabled this in Nov 2024), which is typically fast enough and probably good enough for a ProcessWire-based solution. You then have workers which act on the jobs. You can define there to be one or multiple workers. Let's say you have a powerful server and want to transcode multiple videos at a time, then having multiple workers would allow more jobs to be done in parallel and take advantage of your system resources. Obviously you don't want a worker to act on a job more than once, or two different workers to act on the same job. So this gets into jobs have statuses, being locked, and avoiding race conditions. The Laravel documentation gets into all of that, but I think reading up on queues/background jobs/workers and experimenting with it would be tremendously helpful. In regards to my print-on-demand system, I'm not using a queue system as I described above and I did experiment with WireQueue and IftRunner a while ago, but it didn't really... fit? It was a while ago and I was still wrapping my head around queues; also I came to realize that what I needed was even deeper than that (ie, durable workflows, but that's unrelated to what we're talking about here). I eventually put something together that relies on "fake" jobs using cron jobs and progressing through a durable workflow; it's not the most efficient way to do it, but I got it working. I've been meaning to rewrite that part of the system one day and having a native / first-party queue system (which dovetails with the CLI commands), would be the best approach.

There has been a lot of ProcessWire work covered this week! Here's a summary: 1. AgentTools module has been upgraded with "Site Engineer", an AI agent now built into your admin, and you can ask it questions, create migrations, or have it make other web development updates to your site by going to Setup > Agent Tools > Engineer. To enable the Engineer, you need an Anthropic API key, an OpenAI API key, or an OpenAI compatible API key (apparently several others use the OpenAI key standard). You can optionally put Engineer in "read-only" mode, which is what I do for production sites. In read-only mode, it answers questions and provides you with code for making updates yourself. But if read-only mode is not enabled, then it can act as your web developer and make changes directly, which is what I use with development sites. AgentTools provides full context to Engineer on your site's pages, fields and templates. If using ProcessWire 3.0.258 (or newer) it also provides the new API.md files to help AI know how to best work with all of ProcessWire's Fieldtypes. If you are having Engineer create or manipulate Fields on your site, it's a good idea to have 3.0.258 for the API.md support. Engineer also supports prompt caching for up to 1 hour in order to limit token usage. 2. The AgentTools now has JSON site-map generation features for AI agents. This enables an AI agent to see the full scope of your site. A second site-map feature focuses on all your site's templates and fields, essentially providing the full site schema to the AI agent. 3. In the core, we've added API.md files for all 18 of ProcessWire's core Fieldtypes, except for the comments and cache Fieldtypes, so far. In order to facilitiate this, and to facilitiate AI agent accessibility, all of ProcessWire's Fieldtypes now have their own directories as well. 4. After looking at all the API.md files, it became clear that there was plenty of room for improvement in the APIs of several Fieldtypes, so there have been major core updates to several Fieldtypes, as well as the Fields, Templates and Fieldgroups classes. 5. A Fieldtype testing framework has been built, which tests the full scope of 20 ProcessWire Fieldtypes (all the core ones, plus FieldtypeRepeaterMatrix and FieldtypeTable). It tests field creation, manipulation, traversal (where applicable), sorting (where applicable), searching with selectors, and more. I'll be uploading the testing framework to GitHub soon as well. 6. The new testing framework identified some bugs, which have been fixed. Most notable were selector matching bugs in FieldtypeFloat and FieldtypeDatetime. 7. There has been some refactoring in ProFields FieldtypeRepeaterMatrix and FieldtypeTable, plus API.md files have been generated for both. New versions should be ready soon. In fact, that applies to all of the ProFields, and I hope to cover FieldtypeCombo and FieldtypeCustom next week. 8. ProcessWire 3.0.258 has a whole lot of improvements, changes and fixes in it. Here's the commit log: https://github.com/processwire/processwire/commits/dev/ 9. Back to working on PagesVersionsPro (and have been for a few weeks) but more on that later. 10. There's probably more, but that's all I can remember at the moment. 🙂 Thanks for reading and have a great weekend! Basic examples of using Engineer for migrations:

YES!