Search the Community

For this, I recommend: https://buildermethods.com/prd-creator Quote: "PRD Creator is just markdown — not Claude Code-specific. If you’re using Codex, Antigravity, Cursor, or another agentic tool, download the bm-prd-creator folder from the bm-skills repo and install it as a custom skill, command, or rule per your tool’s convention. The workflow is identical." These are the actual files: https://github.com/buildermethods/bm-skills/tree/main/plugins/bm-prd-creator/skills/bm-prd-creator You may also want to watch this from the author: https://youtu.be/g6VvvS46uCM

Hello, A small utility I built for my own workflow — export any page directly from the editor as a clean Markdown file. Useful for documentation, content migration, and feeding page content to AI tools. GitHub: https://github.com/mxmsmnv/PageMarkdown What it does: Adds an Export to Markdown button to the page edit form Smart HTML conversion — CKEditor content (tables, lists, headings, links, bold/italic) → standard Markdown Supports ProFields: Table, Combo, Repeater Matrix (with type labels and nested structure) Images and files render as Markdown image/link syntax Page references render as links or titles MapMarker, Email, URL, Color fields all handled Configurable: toggle field labels as headings, ignore lists per field/type, datetime format, empty HTML cleanup Requirements: ProcessWire 3.0+, PHP 8.0+ MIT License.

Video embed for YouTube and Vimeo ProcessWire Textformatter module that enables translation of YouTube or Vimeo URLs to full embed codes, resulting in a viewable video in textarea fields you apply it to. How to install Download or clone from GitHub: https://github.com/r...atterVideoEmbed Copy the TextformatterVideoEmbed.module file to your /site/modules/ directory (or place it in /site/modules/TextformatterVideoEmbed/). Click check for new modules in ProcessWire Admin Modules screen. Click install for the module labeled: "Video embed for YouTube/Vimeo". How to use Edit your body field in Setup > Fields (or whatever field(s) you will be placing videos in). On the details tab, find the Text Formatters field and select "Video embed for YouTube/Vimeo". Save. Edit a page using the field you edited and paste in YouTube and/or Vimeo video URLs each on their own paragraph. Example How it might look in your editor (like TinyMCE): Here are two videos about ProcessWire https://www.youtube.com/watch?v=Wl4XiYadV_k https://www.youtube.com/watch?v=XKnG7sikE-U And here is a great video I watched earlier this week: http://vimeo.com/18280328 How it works This module uses YouTube and Vimeo oEmbed services to generate the embed codes populated in your content. After these services are queried the first time, the embed code is cached so that it doesn't need to be pulled again. The advantage of using the oEmbed services is that you get a video formatted at the proper width, height and proportion. You can also set a max width and max height (in the module config) and expect a proportional video. Configuration/Customization You may want to update the max width and max height settings on the module's configuration screen. You should make these consistent with what is supported by your site design. If you change these max width / max height settings you may also want to check the box to clear cache, so that YouTube/Vimeo oembed services will generate new embed codes for you. Using with Markdown, Textile or other LML I mostly assume you are using this with TinyMCE. But there's no reason why you can't also use this with something like Markdown or Textile. This text formatter is looking for a YouTube or Vimeo video URL surrounded by paragraph tags. As a result, if you are using Markdown or Textile (or something else like it) you want that text formatter to run before this one. That ensures that the expected paragraph tags will be present when TextformatterVideoEmbed runs. You can control the order that text formatters are run in by drag/drop sorting in the field editor. Thanks to Pete for tuning me into these oEmbed services provided by YouTube and Vimeo a long time ago in another thread.

Hi everyone, I’ve released a new module: ProcessLegalDocs GitHub: https://github.com/mxmsmnv/ProcessLegalDocs ProcessLegalDocs generates legal documents directly from the ProcessWire admin, including: Privacy Policy Terms of Use Cookie Policy Data Processing Agreement CCPA Notice Refund Policy Disclaimer It currently supports 93 jurisdictions and 44 languages, with jurisdiction-aware language selection and document requirements. This is also the first module built on top of my new Context module: https://github.com/mxmsmnv/Context Context acts as the AI/site-analysis base layer. ProcessLegalDocs uses it to understand the site structure, installed modules, fields, pages, and configured AI gateway, then uses that context to generate more relevant legal documents. The module can still work without Context, but in that case it falls back to more generic templates. For best results, Context should be installed and configured with AI. Main features: Generates Markdown legal documents with YAML frontmatter Stores files in /site/assets/legal/ Includes dashboard, preview, download, validation, regenerate, delete, and ZIP export actions Supports many privacy/data protection regimes, including GDPR, UK GDPR, CCPA/CPRA, COPPA, PIPEDA, LGPD, APPI, PIPL, DPDP, PDPA variants, and many US state privacy laws Includes settings for owner/company data, DPO, business audience, data categories, processors, analytics, payments, email/marketing tools, cookies, refunds, subscriptions, review status, and optional ProcessWire page publishing Uses ProcessWire admin UI conventions / AdminThemeUikit Requirements: ProcessWire >= 3.0.255 PHP >= 8.3 Context module optional, but recommended for AI generation Let’s take a look at the module interface: Install: Clone into /site/modules/ProcessLegalDocs/ Refresh modules Install ProcessLegalDocs Open Setup → Legal Docs GitHub: https://github.com/mxmsmnv/ProcessLegalDocs Context module: https://github.com/mxmsmnv/Context This is an early release, so feedback, testing, issue reports, and ideas are very welcome.

Hi all, I would like to propose a different format for https://processwire.com/api/ref/ The PW docs should be provided as markdown. Reasons: much easier to parse for machines easier to feed as context to AI assistants Most of popular modern frameworks / libraries (laravel, whole node ecosystem, etc.) have their docs in markdown nowadays. And I think it is exactly for the reasons mentioned. Me and also others here like @wbmnfktr are having a hard time providing meaningful context to AI assistants in IDEs like Cursor, Windsurf etc. Once those assistants have good context, they do an excellent job with PW specific code. But currently there is a lot of manual effort required to provide this context. ProcessWire would be more accessible to a wider range of users if development could be assisted by AI in an efficient way. I created markdown docs with python mkdocs at https://gebeer.github.io/mkdocs-processwire/ WARNING: this is in it's early stages and far from complete/perfect. It is merely for demonstration purposes atm and needs a lot of polish regarding structure, index pages for each class etc. I am using a separate local repo for scraping the API docs and parsing them to markdown. The whole process of scraping/parsing/deploying still involves manual steps (though those could be automated). And it needs to be repeated at least for every master release of PW. So I would prefer if @ryan could produce the API docs in markdown in the first place. Your feedback / opinions would be much appreciated. Cheers

Hey everyone, on a recent client project we had to deal with a large number of Markdown files that needed to end up as regular HTML content on ProcessWire pages. Converting them manually or piping them through external tools wasn't an option – too many files, too tedious, and the content had to be stored as actual HTML in rich textfields, not just formatted at runtime. So we built a small module that handles this directly inside ProcessWire. How it works The module creates a file upload field (md_import_files) and a Repeater field (md_import_items) with a standard title field and a richtext body field (md_import_body) inside. The body field automatically uses TinyMCE if installed, otherwise CKEditor. You add both fields (md_import_files,md_import_items) to any template, upload your .md files, hit save – each file gets converted to HTML via PW's core TextformatterMarkdownExtra and stored as a separate Repeater item. The source filename goes into the items title, processed files are removed from the upload automatically. Template output The Repeater items are regular PW pages, so output is straightforward: foreach ($page->md_import_items as $item) { echo "<section>"; echo "<h2>{$item->title}</h2>"; echo "<div>{$item->md_import_body}</div>"; echo "</section>"; } Tag mappings One thing we needed right away: control over how certain Markdown elements end up in HTML. For example, #headings in Markdown become <h1> – but on most websites <h1> is reserved for the page title. The module has a simple config (Modules → Configure → Markdown Importer) where you define tag mappings, one per line: h1:h2 h2:h3 strong:b blockquote:aside hr:br This performs a simple 1:1 tag replacement after conversion, preserving all attributes. Works well for standalone or equivalent elements like headings, inline formatting, blockquotes, or void elements like hr:br. Note that it doesn't handle nested structures – mapping table:ul for example would only replace the outer <table> tag while leaving thead, tr, td etc. untouched. Requirements ProcessWire 3.0.0+ FieldtypeRepeater (core) TextformatterMarkdownExtra (core) GitHub: github.com/frameless-at/MarkdownImporter Modules Directory: https://processwire.com/modules/markdown-importer/ Happy to hear if anyone finds this useful or has suggestions for improvements. Cheers, Mike

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):

ProcessPromptManager is a ProcessWire admin module for generating site-aware prompt exports for external AI agents. It allows an administrator to select a template, define which fields an agent should populate, add instructions, and export a zip containing a markdown prompt and JSON field definitions. The module does not handle authentication or integration. It provides a controlled starting point for accepting structured input from external agents. Never include credentials or sensitive data in prompts. Module info: https://github.com/clipmagic/ProcessPromptManager/

@szabesz TinyMCE support is on the list! CKEditor conversion was the first priority since it's still widely used, but TinyMCE is the logical next step given it's now the default RTE. I'll add it in an upcoming version. @Sergio Great suggestion! A /md/ URL segment or .md extension that returns the Markdown version directly would make the module much more useful for static site generators, AI pipelines, and content migration workflows. Added to the roadmap.

Hey everyone, I've noticed that AI-related discussions are popping up more and more across the forum, but they're scattered across different threads and often go off-topic (guilty as charged). So I thought it's time we create a dedicated place to collect our experiences, tools, and workflows around using AI with ProcessWire. Why this thread? There are several existing discussions that touch on the topic: My recent post about Cursor turned into a broader AI conversation that drifted off-topic (link) There's a thread about MCP (Model Context Protocol) and ProcessWire (link) @gebeer started a thread about creating better Markdown documentation for ProcessWire - IMHO it was more of a request rather than a howto (link) All of these are related, but none of them serve as a central hub for the bigger question: How do we best leverage AI in our day-to-day ProcessWire development? What I'd love to collect here: What's your current setup? Which AI tools are you using (Cursor, GitHub Copilot, Claude, ChatGPT, something else)? How did you integrate them into your workflow? What works well? Where does AI genuinely save you time with ProcessWire? Module development, migrations, frontend templating, debugging, writing selectors, documentation...? What doesn't work (yet)? Where do the current AI tools fall short when it comes to PW specifically? Is it the lack of training data, the API structure, something else? Context & documentation: How do you feed ProcessWire knowledge to your AI? Custom rules, project documentation, Markdown exports of the PW docs, MCP servers? Tips & tricks: Any prompts, configurations, or workflows that made a real difference for you? Looking forward to your input!

Very useful, indeed! May I suggest an example in its docs for the developer to implement: - A URL segment `/md/` or, even better, adding `.md` to the URL to trigger the display of the markdown version of the page?

😲 I have no idea how context7's “related skills” are created. The complete setup, including the markdown conversion, is in the other repo https://github.com/phlppschrr/processwire-knowledge-base. The Python code for this is mostly vibe-coded with codex 5.2, and partly with gemini 3 pro. I have to admit that I haven't looked at the resulting Python code, but at least on my computer it works reliably. The repo indexed by context7 currently only contains the Markdown version of the ProcessWire API documentation as Markdown. As long as Ryan hasn't built prompt injecting into his phpdocs, it should be safe. I don't know yet how to best use the repository. I would appreciate input on how to write the skill to make the content usable for an LLM without bloating the context window. Probably the way via context7 is more promising than searching the local md files with grep. By the way, I've also started using gemini to break down the blog articles into individual, uniformly structured snippets with frontmatter metadata. I can imagine that this would be quite good for context7. However, it hasn't been committed yet. Unfortunately, I have to get back to customer work now... Example of a generated snippet:

Hi ProcessWire community! 👋 I'm excited to share a new module I've been working on: TeleWire - a Telegram notifications module that brings instant messaging capabilities to your ProcessWire sites. The Problem with Current Notification Solutions After running several e-commerce sites and experimenting with different notification systems, I've encountered these recurring issues: 📧 Email (SMTP/WireMail): Requires SMTP server configuration (WireMailSMTP) Google App Passwords setup complexity Emails constantly landing in spam folders Delayed delivery (sometimes 5-10 minutes) No guarantee the recipient will see it quickly 📱 SMS (Twilio, etc): Monthly fees just to keep a phone number active (~$1-15/month) Per-message charges (can add up quickly) US compliance requirements (verification, regulations) Not everyone wants to share their phone number 💬 WhatsApp Business API: Requires business verification Complex setup process API fees and restrictions Limited to business accounts 🔔 Push services (Pushover, etc): Requires purchasing apps ($5-10 per platform) Recipient needs to install and configure the app Additional barrier to entry Why Telegram? 🆓 Completely free - No monthly fees, no per-message charges, no app purchases 🌍 Widely available - Free to download on any platform, 900+ million users worldwide ⚡ Instant delivery - Messages arrive in 1-2 seconds, not minutes 🎯 Low barrier to entry - Just "install the free app and start a chat with the bot" vs "pay $5" or "give me your phone number" 🔒 Reliable - No spam filters, no deliverability issues, no carrier restrictions 📱 Multi-platform - iOS, Android, Web, Desktop - works everywhere 🎨 Rich features - HTML formatting, emojis, photos, documents, links Key Features 🚀 Send text notifications with HTML/Markdown formatting 📸 Send photos and documents 👥 Support for multiple recipients (users and groups) 🔧 Simple admin interface with test button 📊 Optional logging and debug mode ⚡ Optimized performance with configurable timeouts 🎯 Easy to integrate with hooks Real-World Use Cases E-commerce order notifications: $wire->addHookAfter('FormBuilderProcessor::processInputDone', function($event) { $form = $event->object; if($form->name === 'order-form') { $telewire = $this->modules->get('TeleWire'); $message = '🛒 <b>New Order</b>' . "\n\n"; $message .= '👤 Customer: ' . $form->get('customer_name')->value . "\n"; $message .= '💰 Total: $' . $form->get('total')->value; $telewire->send($message); } }); Failed login attempts monitoring: $wire->addHookAfter('Session::loginFailed', function($event) { $telewire = $this->modules->get('TeleWire'); $name = $event->arguments(0); $message = '⚠️ <b>Failed Login Attempt</b>' . "\n\n"; $message .= 'Username: ' . $name . "\n"; $message .= 'IP: ' . $this->session->getIP(); $telewire->send($message); }); Content updates: $wire->addHookAfter('Pages::saved', function($event) { $page = $event->arguments(0); if($page->template == 'article' && !$page->isNew()) { $telewire = $this->modules->get('TeleWire'); $message = '📝 <b>Article Updated</b>' . "\n"; $message .= 'Title: ' . $page->title . "\n"; $message .= 'By: ' . $this->user->name; $telewire->send($message); } }); Send photos with captions: $telewire = $modules->get('TeleWire'); // Product photo when new product added $telewire->sendPhoto( $page->images->first()->httpUrl, "New product: {$page->title} - \${$page->price}" ); Send documents (invoices, reports): $telewire = $modules->get('TeleWire'); // Send generated PDF invoice $telewire->sendDocument( '/site/assets/invoices/invoice-123.pdf', 'Invoice #123 for Order #456' ); Installation Get a bot token from @BotFather on Telegram (takes 30 seconds) Install the module from GitHub Configure your bot token and chat IDs Click "Send Test Message" to verify everything works Requirements: PHP 8.2+ and ProcessWire 3.0.210+ Admin Interface Features The configuration page includes: ✅ Real-time connection status indicator 🧪 One-click test message button (AJAX, no page reload) ⚙️ Configurable parse mode (HTML/Markdown/MarkdownV2) 📝 Optional logging with debug mode for troubleshooting ⏱️ Adjustable API timeouts 🔇 Silent mode option (no notification sound) 📊 Message length handling (auto-split long messages) Production Ready This module is currently running on several production sites: 🍫 E-commerce shop - order notifications, stock alerts 🍷 Wine/liquor business - order confirmations, delivery updates 📰 News portal - content publishing notifications Average response time: ~150-300ms per notification Getting Your Chat ID Find @userinfobot in Telegram Send any message - it will reply with your Chat ID Important: Start conversation with your bot by sending /start Enter the Chat ID in module configuration For groups: Add the bot to your group, make it admin, and use the negative Chat ID API Documentation // Get module instance $telewire = $modules->get('TeleWire'); // Simple text message $telewire->send('Hello from ProcessWire!'); // HTML formatted message $message = '<b>Bold</b> <i>italic</i> <code>code</code>'; $telewire->send($message); // Send with custom options $telewire->send('Silent notification', [ 'disable_notification' => true, 'parse_mode' => 'Markdown' ]); // Send photo $telewire->sendPhoto('/path/to/photo.jpg', 'Optional caption'); // Send document $telewire->sendDocument('/path/to/file.pdf', 'Document caption'); Feedback Welcome! I'd love to hear your thoughts, use cases, and suggestions. If you've been frustrated with email deliverability or SMS costs for notifications, give this a try! GitHub: https://github.com/mxmsmnv/TeleWire Thanks to the ProcessWire community for the inspiration and all the great modules that helped me learn the PW module system!

While my plan is to switch to Linux one day (probably Omarchy), I'm still putting that (and tiling window managers) off for a bit. Let it cook a little more. In Windows 11, I like my taskbar, but one nagging thing is that it's hard to differentiate the icons of many Code/Codium instances given that I don't group them. I use both programs actually: Code for actual coding and Codium as my Markdown note taking tool (I prefer to not use Obsidian and the million other markdown editors; Code/Codium for Markdown is fantastic since you get all the developer ergonomics) With the help of AI, I developed a program with dotnet that makes it easy to add custom icon overlays effectively differentiating the program instances. This saves a lot of headache of knowing which icon corresponds to which project with a quick glance. Feel free to use it! https://github.com/jlahijani/TaskbarIconOverlay

Last week we released the new ProcessWire 3.0.184 master/main/stable version. This is our biggest version release in a year. It's been a very smooth stable version launch with no major issues so we're keeping the version number where it is this week. If you haven't upgraded yet, it's an easy and worthwhile upgrade. For full details see the blog post that covers it all. This week I have 3 new Textformatter modules released in the modules directory. These are modules that I developed earlier for recurring needs that I had, but this week decided to finish them up and release them. I hope that you might find one or more of them useful sometime. TextformatterFindReplace This module applies find/replace patterns to formatted text or markup at runtime. The patterns may be simple text or more complex regular expressions. This module can be handy if you perform a text replacement on all output from a particular field, without having to manually make the change on all instances where it might appear. For instance, maybe you need to insert a trademark symbol ™ after every appearance of a brand name, or maybe your website hostname has changed and you need to replace all references to it, or perhaps you need to replace all <h1> headlines with <h2> headlines. These are just a few examples of any number of possibilities. Read more / Usage / Examples TextformatterMarkdownInMarkup Enables you to use Markdown formatting codes in CKEditor (or HTML). A significant amount of content that is populated into the “bodycopy” field of websites is not actually written in the admin and instead originates from text editors, word processors, and other tools outside of the CMS. It then gets pasted into CKEditor, and then manually formatted into HTML using tools in CKEditor. This process of manually converting links, lists, headlines, bold, and italic text and more can be sometimes very time consuming. This module provides a time saving alternative, enabling use of markdown formatted text in CKEditor (or any HTML/richtext editor). It remains as markdown formatted text in the editor, but as soon as it is rendered on the front-end it is automatically formatted as HTML. This means that text like **this** gets converted to this, links like [this](https://processwire.com) get converted to this, and so on for most types of markdown formatting. This enables markdown formatted text to be written anywhere and the formatting to be rendered properly in your bodycopy when viewed on your website. Using this module means that you can mix richtext and markdown in the same copy. No longer do you have to manually convert all of the links, lists, bold/italic, and so on in pasted in text. This module saves me quite a bit of time when writing blog posts like the one last week. Much of the formatting in that post was markdown based, since I wrote the post in my text editor over a period of a couple weeks. Once I got it into CKEditor, I did some formatting with that too, but when it came to other formatting (especially links and inline `code`) it was a big help to have them just work, and not to have to re-do all of them manually with CKEditor tools. So why not just work exclusively in Markdown? Well I don't like working with just markdown most of the time, I much prefer CKEditor. But I also can't deny the convenience of markdown for a lot of cases too. So being able to use Markdown within CKEditor is the best of both worlds, to me at least. Read more / Supported markdown / Configuration options TextformatterEmoji This module converts more than 800 named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. ? This can be especially useful if your ProcessWire database uses the utf8 character set rather than utf8mb4, as it enables you to use emojis on an installation that typically would not be able to save them. This is because emojis usually require utf8mb4 (4 bytes characters) to be used by the database in order to store them. Though when you want to specify an emoji by name, this module will be useful regardless of your database charset. Read more / Supported emojis reference

Yes, that's true. I have nothing against Markdown. I just don't like writing Markdown. It is not a pleasant editing experience. I don't mind using Markdown for short content such as READMEs. Been there, done that. The existing Padloper docs are running on VitePress 😀. The editing experience sucks, especially working with tables and images (editing). https://docs.kongondo.com/ Not to digress much, but I have done the whole NodeJS/npm dance. I have (private) repos with various variants of Padloper written in Vue, Vuetify, Nuxt, Primefaces. I ended up back at using ProcessWire with a sprinkling of htmx and Alpine JS (thanks to two buddies here in the forums). I still use Node JS, now and then. Long story short, all I want is a Markdown generator. if I can edit docs using ProcessWire or a WYSIWYG then export that to Markdown and have that trigger a CICD pointing at GitHub pages, that's the ticket for me. This scenario doesn't stop anyone who doesn't mind editing Markdown to do so. We'll meet at Markdown, so to speak 😀. The main (only?) reason to use Markdown is to make contributing easier. An additional advantage for a generating from ProcessWire pages is I would have the documentation saved in a DB as well.

Hello! I have a textarea field already full of Markdown content. My clients need it to have CKEditor on it. That may be a silly question, but I can’t figure out how to use CKEditor with Markdown. Is it possible to either: interpret Markdown in HTML on the fly, in the CKEditor field convert all Markdown in HTML so CKEditor fields show HTML as they are supposed to do (I guess) Thank you for your answers.

Not that long ago I started with a completely new approach in regards to ProcessWire an AI. I had some rules, commands, and settings for Windsurf and Cursor months back but nothing really worked as good as I hoped it would and lost interest. Even switched to Astro, NextJS, BHVR, and other JS solutions. 🙈 ProcessWire-based development went back to 80% hand-coded with some assistance on the sidelines, mostly debugging, security, and tasks that were more PHP-focussed than ProcessWire-related. Then AGENTS.md and SKILLS came up. Custom instructions, guardrails, links to docs and example code. Almost similar to a README.md but for AI coding tools. The main problem still was the knowledge gap in models. They just didn't know enough about ProcessWire works and how to do more complex stuff. With SKILLS this changed. I pulled the entire docs, some blog posts, took some of the old recipes and let the AI do its magic. The AI repackaged the entire docs, custom instructions, module docs, PHP best practices, and everything else into skills. I installed new and clean instances of ProcessWire and just asked the AI to build things. Yeah... didn't work as expected. I gave the AI more tools to work with and fixed the AGENTS.md: RockMigrations - for creating and updating templates, fields, and pages 🥰 AutoTemplateStubs - for details about existing templates and fields 🤯 ProcessDatabaseBackups - can be a good idea to give your tools a database file it can look into without the need to bootstrap ProcessWire into a custom script or similar. Inline comments in config.php to mark things as important or noteworthy otherwise that file would be ignored /init - a custom action OpenCode, Claude Code, and some other tools have to initialize the whole project 💯 Now my tools have all the skills and know how to use RockMigrations to create templates, fields, and pages, can trigger database backups and look into the made changes, know how to build a custom module. Even custom page classes or URL hooks aren't a problem anymore. The AGENTS.md contains now critical changes in the config.php, has links to all the skills, and whatever necessary. The /init command is very capable of creating it nowadays. I just started to test it more and more. With fresh installations, older projects and even recent projects that have tons of everything. Whenever problems occure I let the AI update the skills or create new ones that take care of the problems it faced. Learning by mistakes. The overall workflow A README.md with a scope of the project, necessary templates and their fields, overall main features besides handling page rendering, like a bookmarking function for recipes or read articles, newsletter signups, automation tasks to clean up older data, and whatever the project needs. The amount of typing is still the same but now mainly in markdown files that explain what to build (/specs), what to fix (/issues), and what we have done already (/docs). I always start in PLAN mode. Starting simple with the overall idea, goals, and outcome. Then the combination of tool and model is important. OpenCode and Claude Code are great at thinking and planning but they need a capable model like Opus, Kimi K2.5 Thinking or even GLM-5. They start to ask questions, give options, recommend workflows. When that's done i ask to save everything to a file in the /specs folder. From here I can either switch to BUILD mode, manually tweaks the plan file, or let other models (Gemini 3 Pro or Codex) review it and ask for suggestions, changes, fixes. Github: https://github.com/webmanufaktur/pwaiworkflow/ Installation: Download and extract files Move entire .agents folder into the project root next to the wire/ folder Look into create-symlinks.sh, run if necessary --- Plans Windsurf $10/month (Legacy) with access to all Anthropic, OpenAI, Google models, and many more Z.AI Coding Plan Pro $120/year (BlackFriday Deal) with all GLM models, including GLM-5 and future releases Kimi Moderato $19/month with Kimi K2.5 (just expired) Minimax Coding Plan $20/month with M2.5 (started using it as successor to Kimi) Tools OpenCode - https://opencode.ai/ Similar to Claude Code, easy to configure, and even easier to extend with custom modes, agents, skills, and whatever you might need or want. Has a great planning mode and doesn't ask unnecessary questions in the middle of tasks like Claude Code did for a while just to burn more tokens. Kimi Code CLI (with Kimi K2.5) - https://www.kimi.com/code/en Tested it last month and while it's a CLI like OpenCode/Claude Code it feels and works totally different. It doesn't have any modes but supports AGENTS.md and SKILLS. Super fast and it is super capable for quick fixes, smaller features, or heavy automations. Windsurf IDE - https://windsurf.com/editor Like Cursor with almost identical features, a custom terminal integration, includes a browser that has full access and control which is great for debugging, UI/UX (especially with Opus 4x.) - I guess most of you have seen in the past or even tried it. Was called Codium before and I know some of you used that Codium Extension which was awesome.

Hello There fellow PW users. I am writing to get your advice on how to figure this problem out. I have never used the Front-end Editing functions of PW before so i tought i try it out. Using Ryans Front-end Page Editor module version 0.0.6. And i am using option A (automatic editing) method described in the documentation together with: <?PHP /* In my setup 'main_markdown_content' is a textarea field with a 'Markdown/Parsedown' textformatter. and inputfieldtype 'Textarea' selected on details tab for the field. Also content type is 'Unknown/Text' is selected. I get a warning when editing this field: -"This field currently allows Markup/HTML in formatted output. If you do not intend to allow Markup/HTML, please select the “HTML Entity Encoder” for “Text formatters”. But the field is storing Markdown and not HTML, as i understand it, the markdown gets rendered into HTML by the textformatter at runtime when outputting the field in my template ? */ /* using Option A (automatic editing) */ echo($page->main_markdown_content); ?> So far so good, it works, the trouble comes when the field is saved when clicking "Save" button on the frontend. For some reason new line endings are added to every line in my Markdown. Lets say this is the markdown (sorry for the swedish): # Sommar 2024 Sommar och sol, värme och regn om vart annat, för att inte tala om pollen. /EyeDentify. ## Uppdateringar - **2024-07-13:** Har uppdaterat Bulma.JS och önskar glad sommar. - **2024-04-10:** Önskar en trevlig vår. - **2023-12-24:** Önskar God Jul och Gott nytt år. - **2023-01-11:** Det är ett nytt år och jag fortsätter jobba på siten. Har planer för att utveckla den. Mer om det senare. And that after saving the frontend field ends up looking like this when i check it in the Admin editor: # Sommar 2024 Sommar och sol, värme och regn om vart annat, för att inte tala om pollen. /EyeDentify ## Uppdateringar - **2024-07-13:** Har uppdaterat Bulma.JS och önskar glad sommar. - **2024-04-10:** Önskar en trevlig vår. - **2023-12-24:** Önskar God Jul och Gott nytt år. - **2023-01-11:** Det är ett nytt år och jag fortsätter jobba på siten. Har planer för att utveckla den. Mer om det senare. (data above is copied exactly from the field after a save and it adds extra spaces.) Which is not what i want, the textformatter outputs the HTML as expected but it has more line endings and spaces between rows. I have to edit out the extra spaces in the Admin backend editor to make it go back to my original Markdown. I can´t figure out what is happening so i turned the editing of for now. Would realy like to be able to use it. You PW gurus have any ideas to what is going on ? If you want any other info to help me, just say so and i will try to supply it. Thanks again! /EyeDentify

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?

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.

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

+1 Docs in markdown have been working great for me. All my module docs are markdown, so they are part of the repo (could be another repo as well, as images for example bloat the module code, which is not ideal). I'm using RockFrontend's dom tools to enhance the markdown docs with some special features. That makes it possible to have working forms on my docs for RockForms, for example: https://www.baumrock.com/en/processwire/modules/rockforms/docs/ ## Working Example In this example we will build the following form. [rockforms=Quickstart] Or another example is rendering code blocks and showing copy buttons. In markdown it's just a plain code example, on the HTML page it's an interactive element with nice labels etc: ## Example This example shows how you can make every required field's label bold and add the note `optional` to every field that is not required. Note that NetteForms uses the terms `label` and `caption` for field labels. [rockforms=Optional] `label: /site/ready.php` ```php $wire->addHookBefore( "RockForms::renderField", function (HookEvent $event) { // get the field that is rendered // in netteforms its called "control" $control = $event->arguments(1); // make required fields bold if ($control->isRequired()) { $control->getLabelPrototype()->addClass('uk-text-bold'); } // add optional note if not required else { $renderer = $event->arguments(0); $label = $control->label->getText() . " <small>(optional)</small>"; $control->setCaption($renderer->html($label)); } } ); ```

Yes! This would be great! I like the idea....but... I've got Node fatigue 😁 and I really don't like writing Markdown... So what now? If only there was a way I could work comfortably in ProcessWire and export to Markdown, or better to GitHub... Yes! This is it. OK, I really don't want to use Laravel blade or Twig. Just give me plain PHP. Wait, https://www.atasasmaz.com/p/atas-php-ssg https://github.com/atas/ssg Yes! Now I can have my cake and eat it too! 😄. I'll have a play and see if I can use this in ProcessWire, maybe as a library or a module. This, I think, offers the best of several words! Living the dream! Everyone can generate their Markdown as they please! 😄 Thanks for the idea. I'll have a play. We'll also need to come up with a templating structure of some sort for the docs, to guide contributors. Thanks!

Went down a rabbit hole on this one... Really curious why they chose a structureless document format like markdown when there are rich and mature data standards like Schema.org. The foundational work would have already been completed, the syntax well established/adopted, and there could be a lot of areas where the wheel may not need to be reinvented. Already exists on millions of websites and generators/parsers already exist for it- adoption by devs and orgs could adopt it so much more quickly with updates to existing packages/libraries. Almost all of the examples they give on the llmstxt website could be satisfied out of the box and if not, remedied by extending the specification. Maybe I'm missing the boat on this one, but is their rejection of an existing data structure due to the fact that they want LLMs to read the content "naturally"? Are LLMs incapable? If that's the case, should LLMs be giving anyone programming tips... I know I've veered off the topic of this post, but this proposal is 3 months old and curious if it has any legs. ANYWAY. Considerations for a module... How would it handle different information at different URL paths? Would it just dump all content into a single file? May create a massive file that starts to introduce performance issues on larger sites with things like blogs. This issue filed on the proposal Github repo brings up multiple URLs but the proposal itself doesn't seem to have anything concrete that takes this into consideration. Thinking about this out loud because creating a module to satisfy this need may end up being a more generalized module. I think this would end up turning into a Markdown generator, if not a library outright. I did a good amount of searching and there are tons of PHP packages that parse MD but I couldn't find any that generate MD from values. If that library existed, the module would be a lot easier to build. In the case of this module we'd essentially be building two versions of the same site because Markdown is as concerned about presentation as it is about content rather than just logic. Each field would have to be configured for rendering in MD. The llmstxt example of Franklin's BBQ is a good illustration. They have an unordered list of weekly hours, but their menu is formatted as a table. In that example, either one could be rendered as a list or table. Assuming we are using a repeater for hours and a repeater for menu items, each field would need to have settings for how it should be rendered (list or table). In the case of a table, fields for table headers need to be mapped and the subfields in the repeater mapped to column values. I don't even know what the settings would look like to render the business hours as a list according to the example. I'm thinking that putting all of the configuration into a module would be a significant challenge. I'm not sure that this proposed standard lends itself well to creating content for the markdown file via a user-friendly UI. It may need a developer to handle it all separately. This is one of the reasons I mentioned Schema data. It would be trivial to implement a Schema object, we already to for Google's structured data. The biggest lift would be to write a library that the developer uses to render the MD data and minimizing per-field configuration, and probably making the module just a formatter that outputs Markdown using defined methods. Here's a hypothetical implementation that uses page classes and an imaginary MarkdownGenerator module. This would render something like the Franklin's BBQ example in the link above <?php namespace ProcessWire; // site/classes/HomePage class HomePage extends DefaulePage { public function renderLlmsMarkdown(): string { $md = wire('modules')->get('MarkdownGenerator'); return $md->render([ $md->h1($this->title), $md->quote($this->summary), $md->text('Here are our weekly hours'), $md->ul( array_map( fn ($row) => "{$row->days}: {$row->hours}", $this->pages->get(1012)->operating_hours->getArray(), ), ), $md->h2('Menus'), $md->ul( array_map( fn ($menuPage) => $md->link($menuPage->title, "{$menuPage->httpUrl}/llms.txt"), $this->get('template=menu')->menus->getArray(), ), ), ]); } } // site/classes/MenuPage.php class MenuPage extends DefaulePage { public function renderLlmsMarkdown(): string { $md = wire('modules')->get('MarkdownGenerator'); $markdownItems = array_map(function($menuSection) use ($md) { return $md->render([ $md->h2($menuSection->title), $md->table( ['Item', 'Price'], array_map( fn ($item) => [$item->title, $item->price], $section->menu_items->getArray(), ), ), ]); }, $this->menu->getArray()); return $md->renderBlocks($markdownItems); } } // site/init.php foreach ($pages->find('template=home|menu') as $llmPage) { $wire->addHook( "{$llmPage->url}llms.txt", fn (HookEvent $e) => $e->pages->get($llmPage)->renderLlmsMarkdown() ); } That should really leverage caching in the real world. This approach will render an llms file at each individual URL for pages that are configured. This standard proposal seems to be taking a non-web approach and, as mentioned in that Github issue above, haven't considered leveraging web URLs but instead creating a stack of separate linked MD documents that an LLM reads like a book at the root URL. Since the standard doesn't say "look for llms.txt at every available url', then any pages with llms data will have to be specifically referenced/rendered on either the root llms.txt document or another llms.txt document that is or has an ancestor that is referenced in the root document. This follows the BBQ example, but just uses actual URLs rather than generating a stack of separate MD documents at the root. I assume you could just hook file names that contain Page IDs or something, but this makes more sense to me. Seems like an incredibly efficient way to build a whole new internet just for robots without any value provided to the people doing the work 🤔 At the very least I want a promise from someone that my life and the lives of my family will be spared when Skynet takes over. tl;dr Creating a module specifically to render llms data may not be the most efficient way to go about this A module that puts configurations into the UI would have to be extremely complex and account for the many types of fields available in ProcessWire Accounting for fields requires that each type of field is limited to the type of MD is can generate if the module attempted to make everything configurable The best way would probably be to create fields that will contain the content and then have your code do the rendering This is basically just creating two websites. One for people and one for LLMs Because this proposed standard has chosen markup over a logical data structure, it's probably always going to be on the shoulders of the developer unless they change something Another challenge is their expectation of additional content management: If this is important enough then there may be a need to manage LLM consumable information separately in fields that contain content sufficiently dumbed down for LLMs. Maybe the real module here is one that connects to an LLM API which auto-summarizes the content to then be used when creating MD files that describe the content to other LLMs. Solution: a library or Module that takes inputs and renders Markdown. Wouldn't be anything specific to AI. Or this standard could be tossed and we can just render structured data on the web page so LLMs can use the internet as a natively hyperlinked set of documents located at stable and discoverable URLs... Having thought this out I think even less of this standard than when I first read the proposal 🤣