Leaderboard

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.

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!

The Tracy core now supports some new AI agent tools: https://github.com/nette/tracy/releases/tag/v2.12.0 I have included this new version, but also extended it so there is now a new bluescreen panel with the Agent Markdown version for easy copying into your AI deity of choice. I also added a copy MD to clipboard button for those exception files generated by guest users (in production mode):

Hello @Peter Knight To be clear, FrontendForms doesn't send any form data by default – it just checks whether a form is valid or not. Inside the isValid() method, you can send form data — or do whatever you want (e.g., store the values on a page). So it's not a "Email Form" module by default. Informing about what went wrong So in this case, it's a bit more complicated. The validator can only set the form validation to true or false (without sending information to an administrator). Of course, it could happen that a real person uses some characteristics of a SPAM text and the text is therefore declared as SPAM. This risk always exists, but it is very low. For this reason, it is necessary to inform the user about which mechanisms were responsible for the failure of validation. But I agree with you: too much detailed information (e.g., word 1 and word 2 are SPAM words) could give a human spammer too much information. My Opinion: In this case you have to make a compromise. You can't stop SPAMMERS completely. If it's a bot, it should post a fixed text in a text box – it will fail and can't react the way it changes the SPAM text it's going to pass. When you have real human SPAMMERS, it becomes much harder to stop them, because they can react much different than a bot. At the moment, the information in the error message is very general and doesn't contain too much detailed information. Yes the danger is always there, especially with AI - so I guess I leave it general. You can also change the error message to your own by asking the user to call you by phone if the message fails validation. Another option would be to set the threshold lower (e.g. from 50 to 30) so that more SPAM properties are accepted and the entered text is more likely to pass validation. I don't know what the "best practice" scenario is in this case. Maybe someone has an idea how best to deal with messages that have been falsely declared as SPAM, even though they are not.

Hi @jacmaes, thanks for the kind words and for taking the time to test! Both issues you reported are fixed in v1.9.2 (released today). Quick summary: Unix timestamps for start_date / end_date — datetime fields are now auto-detected by field type and formatted automatically, no manual column type override needed. Filter dropdown doing nothing — two bugs were at play: the Apply button wasn't showing up on select change (DOM queried before ready), and the query string was encoding [ / ] as %5B%5D which PHP couldn't parse as an array. Both fixed. Full details in the changelog. Let me know if anything else comes up!

Thanks Juergen I guess what I was imagining would be the apparent successful submission of a form. The ProcessWire admin might get the spam notification (or not) to catch any false positives. Is there a danger that by telling spammers or bots what content triggers the spam gate, that we are educating them on how to avoid the system you have in place? Im only coming at this from my own PoV. Looks like a great Module.

@maximus Thanks for all your modules, you're on a roll! I've tested this module and opened an issue. It's probably a misunderstanding on my part, but when you get a chance, could you take a look at it? Thanks!

Sounds great. What happens when an email is identified as spam. Does it get logged, recorded and not forwarded? Or are there options in case of false positives.

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 😄

Check out what @Jonathan Lahijani sent me in the mail. This is so cool!

Further to above, there was an issue with the sitemap handling urlsegments with the canonical link. Another hook solved it for me:

Still using Seomaestro. Discovered a scenario where it missed pages in the sitemap that used urlsegments. In my case, it was the blog module authors page. It should also handle paginated pages but untested. Hope this helps.