Leaderboard

Generates a .phpstorm.meta.php file for ProcessWire autocompletion in PhpStorm. Features Autocomplete wire container keys for wire('...') and Wire::wire('...') Autocomplete module names for Modules::get() and Modules::install() Autocomplete field names for Fields::get() Autocomplete template names for Templates::get() Autocomplete unique page names for Pages::get() Autocomplete hookable methods for Wire::addHook*() Autocomplete page status constants/strings for Page::status(), addStatus(), removeStatus(), hasStatus() Autocomplete field flags for Field::addFlag(), removeFlag(), hasFlag() Autocomplete template cache-expire constants for Template::cacheExpire() Autocomplete Inputfield collapsed constants for Inputfield::collapsed() Autocomplete sort flags for WireArray::sort()/sortFlags()/unique() and PageArray::sort()/sortFlags()/unique() Optional: Field type autocompletion per Page class (when enabled in module config) Usage Default path: site/assets/.phpstorm.meta.php (configurable in module settings). The file regenerates automatically when fields, templates, or modules change (debounced). You can manually regenerate from the module settings screen. Optional: enable "Generate page-class field metadata" in module settings for field type hints per Page class. This is intentionally basic. For richer field stubs, use AutoTemplateStubs. Examples Modules $tracy = $modules->get('TracyDebugger'); // Autocomplete + correct class type for navigation and code insight Wire Container $page = wire('page'); $pages = $this->wire('pages'); $cache = wire('cache'); // Autocomplete for keys like page/pages/cache/etc. Fields $body = $fields->get('body'); // Autocomplete field names, fewer typos Templates $tpl = $templates->get('basic-page'); // Autocomplete template names Pages $home = $pages->get('/'); // Maps to the page class when page classes are enabled Page Status $page->status(Page::statusHidden); $page->addStatus('draft'); $page->removeStatus(Page::statusUnpublished); $page->hasStatus('locked'); Field Flags $field->addFlag(Field::flagAutojoin); $field->removeFlag(Field::flagAccess); $field->hasFlag(Field::flagGlobal); Template Cache Expire $template->cacheExpire(Template::cacheExpireParents); Inputfield Collapsed $inputfield->collapsed(Inputfield::collapsedYesAjax); Sort Flags $items->sort('title', SORT_NATURAL | SORT_FLAG_CASE); $items->sortFlags(SORT_NATURAL); $items->unique(SORT_STRING); Page-Class Field Metadata (Optional) $home = $pages->get('/'); // $home is HomePage (page class) // Field types are inferred from the template fieldgroup // e.g. $home->hero_image -> Pageimage or Pageimages depending on field settings Hooks $wire->addHookAfter('Pages::save', function($event) { // Autocomplete hookable methods while typing the hook string }); Notes Hook scanning reads ProcessWire core, modules, and admin templates to build the hook list. If page classes are enabled, page names map to their page class; otherwise they map to Page. Improvement suggestions and PRs are welcome. https://github.com/phlppschrr/ProcessWirePhpStormMeta

https://github.com/phlppschrr/processwire-knowledge-base

@gebeer I have started developing a ‘processwire-knowledge-base’ skill. To do this, I converted all blog articles and tutorials from the website as well as the API docs into Markdown. However, I haven't tested the skill yet. I think it still needs some fine-tuning. It's still a private repo at the moment, but if you're interested in taking a look, I'm happy to make it public.

@bernhard thanks for sharing the video. And exciting journey you had there :-) Eventually this is where things are going, I guess. Would be great to know who in this community is working on similar stuff. I'm currently creating a collection of skills that can be plugged-in to PW projects here: https://github.com/gebeer/processwire-ai-docs Would love to collaborate with others on that and exchange ideas.

Some more work. Not sure why the images are so fuzzy Image detail page You can edit the usual stuff...Title, Alt, Description, and add Tags etc Some utilities in there too such as Download, Copy URl, Duplicate, Delete If an image has Crop versions they are displayed under the main image Crop versions has thumbs and table view A crop version has a detailed view too Image Crop page There are presets, but you can create your own named crops Save as a crop version or save as a new image. The hardest part is in progress which is A custom Inputfield which allows you to add images from the MediaHub. All while maintaining a connection back to the hub source file. IE it's important that there's no duplication and that the images in the Media Hub are a true source / canonical version Displaying images in the page edit field in a nice consistent way with the existing UI. As much as possible, I want the user to feel like this the core and not some bolt-on with its own CSS. Although I am changing some things… Hope you like! P

I have never been loyal to tools for the sake of it. If something stops earning its keep, I move on. The reason I have stayed with ProcessWire for close to ten years is simple: it continues to make sense for how I work. I still look after sites I built many years ago, and most of them just run. No rewrites, no upgrade stress, no feeling that past work is a liability. The API has stayed stable, and when it has changed, it has been deliberate and predictable. That matters when you are responsible for client sites long-term. What really locked me in early on was the front-end freedom. PW never told me how a site should look or behave. It gave me solid building blocks and allowed me to choose. I can build very different sites without switching platforms or fighting opinionated defaults, and that freedom is something I value. The forum is another reason I am still here. You, the people in this community, take the time to understand a problem before jumping to solutions. That is very rare. The discussions are thoughtful, practical, and grounded in real experience, and I have learned a lot simply by reading how others approach things. And finally, trust. I trust ProcessWire not to chase trends simply for attention, and not to trade clarity or performance for fashion. Ten years on, it still feels like a system built by people who actually build websites. For me, that combination has been hard to beat.

This is great!. I see you have a much more sophisticated setup for API/docs extraction setup than me. I was having a go at producing markdown docs for processwire a while ago and took a different approach (Scrape API docs instead of parsing source). Partial results are here: https://gebeer.github.io/mkdocs-processwire/ I really wish @ryan would adapt the md format for the official API docs so that AI assistants can easily parse them and als cotent7 can index them. And the collection of blog posts you have is impressive. As for the Skill itself, it doesn't currently follow the recommended format. There should be no README, docs dir could be renamed to references etc. Other than that it looks amazing. Love the scripts section. Def will give this a go and let you know how it goes.

It's a bit over a year since I started this post and it's crazy how far AI and cursor got! Huge shoutout to @gebeer who is my main source of wisdom when it comes to AI related stuff 🙂 I wanted to share a video that I watched recently. It is quite lengthy, but I was looking for exactly that to make sure I don't miss any basics. For me it was eye opening, so I wanted to share it: My personal takeaways/learnings: I have thought for a long time that AI is great to read/understand/explain or help me find something in my codebase but for actual coding it's not very helpful most of the time (other than cursor tab, which is awesome!) You can run multiple agents in cursor at once, and you can run multiple models at once, which is crazy The better you setup your environment, the better the results (obviously...) AI can write all your RockPageBuilder blocks with RockMigrations code easily You can actually TALK to cursor in the chat, which is a lot quicker than typing. You can even TALK to it in german and it will translate it to english on the fly, which is crazy. This is just the beginning So the question for me was is it really worth the effort of setting up your environment so that AI does the work for you and then in the end you spend more time debugging than if you just went ahead and coded it from scratch? I'm not sure yet, and I asked that question today @gebeer. He said clearly yes, and my gut said I can imagine he is right, but I did not really experience it myself. Today that changed. I took some time to try a new workflow for a client request. Usually I would have added code by hand, as that's a lot quicker. Why? Because you either start prompting and get bad results or you have to invest a lot of time upfront. But I know how it feels to invest some time upfront and then have superpowers forever 🙂 So I gave it a try and after a quick emergency rescue session with @gebeer I got very good results in actually very little time. And once I started to adopt that workflow it started to make sense more and more and I started to answer the question to myself: Is the effort worth it? Clear answer: YES So I want to encourage everyone to watch the video, try it out, ask for help if you hit any roadblocks. So why do I think it's worth it? Simple example: I asked AI to implement a new RockPageBuilder block. It did the backend for me quickly and easily. Then it did the frontend for me. The frontend needed more time and debugging, but I then added the uikit docs to my project and told cursor to add the docs to my cursor rules/skills/whatever (still confused, but cursor knows what to do). Then results seemed to get even better and it even fixed an issue in a way that I would have never thought of (because I didn't know this option was there). So I even learned something new. Finally I saw an issue in my .latte file, which is quite a common mistake: AI forgot to add |noescape to the {$page->headline} output, which made the headline "Foo & Bar" show up as "Foo & Bar". I guess every latte user knows that problem 🙂 The solution: Tell AI to fix the issue and to also add that info to the frontend-dev skill/rules. That means it will likely never make this mistake again! This is a really powerful approach. I'm quite impressed. And I think I'll need a more expensive subscription soon ^^ Which is one of the downsides. You have been warned! 😄😉 PS: The initial setup is also quite easy. All I did is to talk to cursor: A bit messy instructions and lots of mistakes, but it doesn't matter as long as cursor understands you. I'm quite sure the results are not perfect, but from what I read in the instructions for the AI it's a quite good overview of the project! And it's something to build upon and grow 🙂

@ai_slop Look here: The many pinned threads make the forum a bit confusing. Perhaps a moderator or @kongondo could “optimize” this a little. 😁

Done. https://context7.com/phlppschrr/processwire-api-docs

You can surely do that. context7 will accept it no problem. could add a note: unofficial but AI-friendly docs for the great ProcessWire CMS/CMF lol

Some updates to the Cursor MCP to Processwire Module. There's a new front-end called MCP Sync. So if the MCP server acted as a bridge between Processwire and Cursor, why do I then need a front-end UI? Surely the point of an MCP server was 50% to bypass the Admin? Well, apart from building it for fun, I thought it was nice to have a more visual front-end for the import and export of pages. From the screenshot you might notice a traditional tree view with some useful columns... Change Status Never exported - probably doesnt need a badge but just means it's the original state Local Changes - I've downloaded the page to a file and edited it In Sync - changes have been imported Conflict - both the remote (PW) and the local file) have changes In the Actions column the three icons are WTF (Wire to file) 🙂 - exporting FTW (File to wire) - importing This was a little tricky because import and export mean different things wether you're operating from Curors MCP or import/export via the Cursor UI. So I settled on WTF and FTW because they are less relative to your environment. Big change Previously, when a page was in WTF mod,e I was storing a YAML file. Apart from Matrix items which were separate YAML files. But as we know, YAML can be prone to misformatting so the Module now understands if a field is a Rich Text field and will export that as a stand-alone HTML file with a match name. It means a few more files on the file system than the previous method, but I like that I get a separate HTML entity. The screenshot of my local file system you can see I have WTF my Diagram and Illustrations page. And not just because the content was out of date and mentioned Macromedia Flash! Back to the GUI, you can see a screenshot of that row now picks up the change requiring a FTW. There's a few other helpful functions such as a changes preview as a safety step prior to committing a FTW. There's also a View YAML icon on each row which is a preview too. Here's the raw details of my WTF of Diagram and Illustrations page site/assets/pw-mcp/services/diagrams-illustration/page.meta.json This is a high-level overview of the exported page and is not meant to be edited. { "_readme": "DO NOT EDIT - This file is auto-generated. Edit page.yaml and field HTML files instead.", "pageId": 1051, "canonicalPath": "/services/diagrams-illustration/", "template": "services-detail", "title": "Professional Diagram Design & Illustration Services", "pulledAt": "2026-02-11T11:27:58+00:00", "lastPushedAt": null, "revisionHash": "sha256:2c264809d740ff009e27a5c664b3dced0e529493e54f39c3b458a718d47defb4", "contentHash": "0fc046d624ae2a6add4f6ffbcd6b80dd", "status": "clean" } /site/assets/pw-mcp/services/diagrams-illustration/page.yaml Note how the body field around line 4 or 5 is an RTE, so it's not included in the raw YAML but saved as a standalone file. fields: title: "Professional Diagram Design & Illustration Services" body_summary: "Need to clarify a product, process or service? Clarify your offering with our diagram design services." body: _file: fields/body.html image: [] service_thumbnail: - filename: icon-service-diagrams.png description: null width: 173 height: 113 seo_tab: null seo_title: "Professional Diagram Design & Illustration Services" seo_keywords: null seo_description: Transform complex ideas into clear, compelling diagrams. We create technical illustrations, infographics, and process diagrams that simplify your message and engage your audience. seo_image: null seo_custom: null seo_canonical: null seo_tab_END: null First_Child_Redirect: 0 sitemap_ignore: 0 site/assets/pw-mcp/services/diagrams-illustration/fields/body.html Just a html page and not worth including That's it for the mo.

Do you know if we can create our own repo that only contains the Markdown APIDocs and use it for content7, or does it have to be the official repo?

Good idea, thank you! You might want to create a separate thread for this for further discussion. Sure people are interested in working together on this.

Slightly off-topic, but looking how others do similar things could be helpful: Drupal 10’s "Recipes" - modular YAML configuration packages for specific use cases like blogs or e-commerce - could inspire a similar approach in ProcessWire to streamline project setups. While PW already excels in flexibility, a "Recipe Manager" module could allow users to define, share, and install pre-configured templates, fields, and modules via JSON/YAML files, making it easier to replicate common setups (e.g., portfolios, multilingual sites) without manual repetition. Existing tools like RockMigrations or Site Profiles already cover parts of this, but a dedicated system could automate dependencies, roles, and content structures while keeping PW’s core simplicity intact. Community-driven recipes (e.g., for SEO, galleries, or contact forms) could further accelerate development - especially for agencies handling repetitive project types. Would such a system add value, or does PW’s current flexibility already cover these needs?

That's not the case. If you release it as open source you are still the owner of the repo. Others can then "fork" the repo (which creates a copy of your repo in their own github account) and can then work on it, make changes and commit them (to their repo). Once they have new commits they can create a pull request (it's easy, the github website will suggest it and it's really just a click of a button). That pull request will then be added to YOUR repo and you can then merge it (or anyone having rights for it). @gebeer how is that approach different to what we have been talking today? is one approach better than the other? seems like it's doing the same thing?

As some of you might know from my monthly newsletter I have been struggling with how to proceed with my commercial modules. It's a long story, but last year I reached a point were something had to change. The main problem is that building and selling modules for ProcessWire has never been sustainable for me. Not even close. It has been a lot of work to build the shop. It has been a lot of work to provide proper docs. It has been a lot of work to create videos about the modules so that interested people can get an idea of my modules. That's fine. I knew it would probably not be easy. But I wanted to try 🙂 You never know if you don't try. And I've had hope that it is possible. Unfortunately I don't have this hope any more and that's why I have to draw a line under it. That's also fine. I've learned a lot and I'm really thankful for anybody that has sent some Euros to a stranger that they have never met in person and that excludes any refund 😄 So for me the decision was taken. It took me quite some time to get there, but here we are. There was just one problem left: My clients. They have put trust in me and I didn't want to disappoint them. Just drawing a line might be a good solution for myself but might be a terrible solution for them (and their clients as well). Just not providing updates and keeping selling them is also not my style. With open sourcing my modules I try to find the best solution for everybody involved and I want to especially thank @FireWire for helping me get there 🙂 What does that mean? I'm using my modules in many of my own projects, which means that I will likely keep them alive for some time. On the other hand I don't plan to develop a lot of websites any more and many modules are somewhat feature complete as @FireWire helped me to realise, so there are no bigger updates planned for any of my modules at this time. Also, none of my modules is tested with the new admin theme. If you want to help out on that front, I'll be happily merging PRs, but as I'm not using it myself I'm not going to fix any issues or adding support for it in my spare time. So if you want to keep using my modules: Go ahead and have fun! 🙂 If you find the modules helpful it's always nice to let me know. Hope this is a good solution for everyone! Thx for reading and all the best.

Agree that the site is too developer-centric at the moment. And while people might correctly say this is the target audience, none of my clients using ProcessWire are technical. They are marketing managers, business owners, copywriters, CEOs, eLearning folks etc. They don't care about the API, what a CMF means, what hooks are, or what Modules are. They want a nice, stable UI and editing experience, and to know that if they need custom stuff, it can be done. So my point is, the current Processwire homepage does an OK job of mentioning some of the features these personas might like (the tree, the simple editing etc). However, the site is largely developer-centric, and I believe the appeal can be broadened with: 1: A comprehensive ProcessWire for... section This would be a top-level nav item with dedicated pages for Marketing executives and assistants Content writers/copywriters SEO specialists social media/comms etc etc and thats just the tip of the iceberg, but we should approach it with three key non-developer personas in mind: Publishers (write/edit content) Maintainers (keep info accurate) Promoters (campaigns, SEO, sales, social) And I realise there will be a lot of overlap between the sections, but that's fine. 2: Video walkthrough The website badly needs a UI walkthrough. ProcessWire in 60 seconds... type thing. Made for non-technical people...a quick look around the UI and I honestly think that's 90% of the work done. I realise video work can be a time sponge so I'd focus on item 1 first. I'm happy to help out on item 1 if @ryan needs help there.

Hey ProcessWire community! I'm excited to introduce RockCalendar, a new calendar module that brings powerful event management capabilities to your ProcessWire sites. Key features include: Full calendar view in the ProcessWire admin Easy event creation and management Drag-and-drop event scheduling Recurring events (SSE powered, needs RockGrid) Seamless integration with ProcessWire pages and fields I've created a detailed video walkthrough showcasing RockCalendar's features and installation process: Check it out and let me know what you think! I'm here to answer any questions you might have about RockCalendar. Download & Docs: https://www.baumrock.com/en/processwire/modules/rockcalendar/ Happy coding!

In addition to the great suggestion from @Nicolas, you can also do it by prepending a Markup textfield to the edit form for just that particular template. Here's more code - I'd put this in site/templates/admin.php as this is only an admin feature. $pages->addHookAfter("ProcessPageEdit::buildForm", function($event) { $form = $event->return; $id = (int) wire("input")->get("id"); if (!$id) { return; } $editedPage = wire("pages")->get($id); if ($editedPage->template->name === "home") { // CHANGE TEMPLATE NAME HERE $f = wire()->modules->get('InputfieldMarkup'); $f->label = "Notes"; $f->value = "<p>Your HTML Notes in here.</p>"; $form->prepend($f); } });