All Activity

It looks amazing! So much work has been done and so much more is still to come... And then I'll want to make custom blocks and so on. Keep going, it's so exciting!

Context Module v1.4.0 - Pure UIkit Design System 🎨 Complete dashboard redesign following ProcessWire standards! What's Changed 100% UIkit Compliance Removed ALL custom CSS Removed ALL inline styles Pure UIkit components throughout ProcessWire CSS variables for theming Dashboard Components: Cards: uk-card-default / uk-card-primary Tables: uk-table uk-table-divider uk-table-small Labels: uk-label uk-label-success/danger/warning Alert: uk-alert uk-alert-success Buttons: Clean HTML with uk-button classes Visual Improvements: Templates/Fields/Pages: Light cards Success metrics: Brand color cards (green) Adaptive grid: 2 cols mobile, 3 tablet, 6 desktop Automatic light/dark theme switching UI Cleanup: Removed "NEW!" label Removed version footer Removed "Edit configuration" link Consistent spacing and typography Bugfix: Removed duplicate formatBytes() method Why This Matters: ✅ Matches ProcessWire admin design ✅ Automatic theme support ✅ Zero maintenance CSS ✅ Better accessibility ✅ Mobile-first responsive Install/Update: cd /site/modules/Context/ git pull Then: Modules → Refresh

I am now playing with HTMX for building something like that

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

Thanks for the kind words and the thoughtful question! Just to clarify — Rapid is a ProcessWire fieldtype wrapper around EditorJS, the open-source block editor from the Codex team. The editor itself is their work — my contribution is the PW integration: field storage, server-side PHP renderers, upload handling, and the admin UI. Why I built it: I needed a press release submission system — companies fill in their details, write a press release, pay via Stripe, and it goes to moderation (similar to manufacturingdive.com). The site already used TinyMCE fields across many templates. Giving external users access to those fields was a security risk — one wrong permission and they could edit content site-wide. Creating a dedicated FieldtypeRapid field isolated the editor completely: external users write in their own field, the rest of the site is untouched. So the isolation and the clean JSON output were the primary drivers, not just "try a new editor." On your FieldtypeMulti question — I went with a single JSON column because block order needs to be preserved, EditorJS saves atomically, and I wanted to keep v1 simple. Per-block translation is a real limitation — if that matters to you, FieldtypeMulti might be the better foundation. Would love to see your original implementation if you revisit it.

In Kilo Code there is this: You can set a model for each mode.

Great work! It's exciting to see a solid EditorJS integration for ProcessWire. I actually started working on a similar Fieldtype a few years ago and got it nearly production-ready, but I had to shelf it due to a heavy workload. I’ve recently been re-evaluating whether to pick it back up, especially because I agree that building page builders with PageTable or RepeaterMatrix can become quite complex and difficult to maintain/update over time. While thinking about the architecture, I had a question: Have you considered using FieldtypeMulti instead of a standard Fieldtype? Since EditorJS essentially stores "version" and "time" (which aren't always critical for the PW side), I’ve been wondering if storing each block as an individual entry in a multi-value field would be more efficient. For example, you could store the main block content in a data column and other attributes/settings in a props column. This approach might make it easier to handle multi-language support on a per-block basis within ProcessWire's native logic. I’d love to hear your thoughts on this, though I understand if you’ve taken a completely different architectural path for specific reasons. I’m looking forward to testing your module and providing more feedback soon. Thanks for your hard work on this!

Aider has an interesting “architect mode”, where you can define a “strong” and a “week” models for reasoning and acting. This can keep costs much lower https://aider.chat/2024/09/26/architect.html

Hi guys, I've been working on a full EditorJS integration for ProcessWire and it's reached a point where I'd like to share it and get some testing feedback before calling it stable. GitHub: https://github.com/mxmsmnv/FieldtypeRapid This is a development preview. The core functionality works, but I'm looking for testers on different server configurations and ProcessWire setups before a stable release. Please report issues on GitHub. Why EditorJS instead of CKEditor or TinyMCE? CKEditor and TinyMCE are document editors — they produce a single blob of HTML. That HTML is hard to restructure, style consistently, or repurpose for different output targets (web, mobile, PDF, API). EditorJS is a block-based editor. Every paragraph, heading, image, and quote is a separate JSON object with a type and structured data. This means: Content is stored as clean JSON, not tangled HTML Each block type can be rendered differently per context Easy to add, reorder, or remove blocks without breaking surrounding content Output is fully controlled server-side via PHP renderers — no frontend JS required It's closer in concept to Notion or Gutenberg than to a traditional WYSIWYG. What Rapid does: 17 block types: paragraph, header (h1–h6 with auto anchor IDs), quote, nested lists, table, code, delimiter, warning, checklist, raw HTML, image (WebP convert + resize), file attachments, YouTube/Vimeo embed, alert (8 color variants), toggle/accordion, link preview with OG metadata Inline tools: bold, italic, underline, inline code, marker, link Template API: echo $page->body; // render all blocks echo $page->body->toText(); // plain text for meta/search echo $page->body->renderWith($renderer); // custom renderer 4 CSS frameworks — Vanilla, Tailwind, Bootstrap 5, UIkit 3 Frontend editing — inline editor on frontend for authorized users No build step needed — pre-built js/dist/editor.js included. Requirements: ProcessWire 3.0.200+, PHP 8.2+ Any feedback on installation, rendering edge cases, or block behaviour is welcome!

Thanks Ryan - just starting to play with this now. Remember that for some reason Claude needs to be reminded to add a version check around around curl_close Deprecated: Function curl_close() is deprecated since 8.5, as it has no effect since PHP 8.0 in site/modules/AgentTools/AgentToolsEngineer.php:592

That's what I was thinking about. Like in other tools (Kilo Code Extension in VS Code in the screenshot). With this we come close to OpenClaw and Hermes territory.

I like that idea, maybe a select/drop-down under the engineer prompt box where you can select the model to use? And we should be able to share memory between them too, once it's added.

What about being able to configure multiple models and then selecting the one for each specific task? Planning: Opus 4.x (or GLM 5.1, Kimi K2.5) Workload: MiniMax, Qwen, ... Most plans (I use) support Anthropic-, OpenAI-compatible, and custom endpoints. Right now we have Anthropic and OpenAI available (should cover 90% i guess).

Used Droid (https://factory.ai/) and OpenCode (https://opencode.ai/) in this project for now and they both had no issues at all (besides learning that the project is running in a DDEV environment). Also Z.AI GLM 5.1 and MiniMax M2.7 did a really great job. Not as fast (and by far not as expensive) as Opus 4.6 but planning everything in GLM 5.1, spawning subagents (only really works in OpenCode) with MiniMax that does the heavy lifting and then using GLM 5.1 again to confirm and double-check everything. 🤯

Btw, one feature that wasn't quite ready this week for AgentTools was Engineer memory. Currently every prompt is like a new thread. But next week we'll enable memory, so that it has context of all your previous prompts.

It also works without issues using MiniMax M2.7 - which is actually even faster. 🥰

Thanks Jonathan! I appreciate the kind words. I also feel like this is the beginning of the next era of ProcessWire, so much fun stuff lately on the way! Really cool project you are working on there! Also, I'm thrilled to see the AgentTools module working with another AI Agent. I've only been able to test with an Anthropic API key so far, so nice to see it's working well with Z.ai.

YES!

Holy... this feels like a bit of Christmas and Easter on the same day during summer holidays. Just plugged Z.AI GLM-5.1 into this and ... From the side notes:

I can't wait to play with all this stuff. I love that ProcessWire was envisioned over 2 decades ago, yet is adaptable with the cutting edge in web development. This just speaks to how well it was architected when it was publicly released. This feels like the next era of ProcessWire!

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:

@LexSanchez Thanks for sharing, but please follow the "The forum language is English. We really appreciate the effort everyone makes from countries around the world to post in English. After careful consideration and experience on other forums, it makes sense to have one common language for discussion here so that ideas can be shared and not missed in language-specific forums - the same applies for debates that might get out of hand as we do not want to miss those either."

I've ran into the exact same issue, and couldn't find a satisfying solution. I would be interested also to learn if anyone has found a way around this limitation.

Multilingual Site (EN / ES) Normally, it's not possible (!?) to set a link from an EN to a ES page (to a different language page) in CKEditor. Entering the link manually via the URL doesn't work either, evenver the entry in the editor is correct, you remain in the current language version. Is there a solution?

TextformatterFontAwesome A Textformatter module for ProcessWire that converts text shortcuts into Font Awesome icons. Features ✅ Converts shortcuts like :fa-star: into Font Awesome icons ✅ Flexible icon mapping configuration ✅ Support for Font Awesome 6+ (solid, regular, brands) ✅ Automatic asset loading from CDN ✅ HTML or SVG output ✅ Cache for improved performance ✅ Easy configuration from the ProcessWire admin Installation Download or clone this module into /site/modules/TextformatterFontAwesome/ Go to Modules > Refresh in the ProcessWire admin Install the TextformatterFontAwesome module Configure icon mappings as needed Configuration Icon Mappings Define your text shortcuts and their corresponding Font Awesome classes: :fa-star: = fa-solid fa-star :fa-heart: = fa-solid fa-heart :fa-home: = fa-solid fa-house :fa-user: = fa-solid fa-user :fa-email: = fa-solid fa-envelope :fa-facebook: = fa-brands fa-facebook :fa-twitter: = fa-brands fa-twitter Configuration Options Output Format: HTML (CSS) or SVG Load Assets: Automatically include Font Awesome from CDN CDN Version: Font Awesome version to load (default 6.5.1) Custom CSS: Optional URL for custom CSS Enable Cache: Cache mappings for improved performance Usage 1. Apply to Fields Go to Setup > Fields > select your text field and in the Details tab: Under Applied Textformatters, select Font Awesome Icons Save the field 2. Use in Templates // The textformatter is automatically applied when rendering the field echo $page->body; // Shortcuts like :fa-star: are converted automatically // Or apply manually $textformatter = $modules->get('TextformatterFontAwesome'); $text = "I like this page :fa-heart: It's great! :fa-star:"; $textformatter->format($text); echo $text; // Output: I like this page <i class="fa-solid fa-heart"></i> It's great! <i class="fa-solid fa-star"></i> 3. Shortcut Examples Shortcut Result Description :fa-star: <i class="fa-solid fa-star"></i> Solid star :fa-heart: <i class="fa-solid fa-heart"></i> Solid heart :fa-home: <i class="fa-solid fa-house"></i> Solid house :fa-facebook: <i class="fa-brands fa-facebook"></i> Facebook logo :fa-email: <i class="fa-solid fa-envelope"></i> Email envelope Content Usage Examples In a Text Editor Welcome to our site! :fa-star: Contact us: - Email: info@example.com :fa-email: - Phone: +1234567890 :fa-phone: Follow us on social media: - Facebook :fa-facebook: - Twitter :fa-twitter: - Instagram :fa-instagram: Thanks for visiting! :fa-heart: HTML Output Welcome to our site! <i class="fa-solid fa-star"></i> Contact us: - Email: info@example.com <i class="fa-solid fa-envelope"></i> - Phone: +1234567890 <i class="fa-solid fa-phone"></i> Follow us on social media: - Facebook <i class="fa-brands fa-facebook"></i> - Twitter <i class="fa-brands fa-twitter"></i> - Instagram <i class="fa-brands fa-instagram"></i> Thanks for visiting! <i class="fa-solid fa-heart"></i> Advanced Customization Custom Mappings You can create your own shortcuts: :my-icon: = fa-solid fa-custom-icon :company: = fa-solid fa-building :product: = fa-solid fa-box Custom CSS If you use Font Awesome Pro or have custom icons: .fa-custom-icon::before { content: "\f123"; } Programmatic Usage // Get the module $fa = $modules->get('TextformatterFontAwesome'); // Format text $content = "Text with icons :fa-star: and :fa-heart:"; $fa->format($content); echo $content; // Configure dynamically $fa->set('outputFormat', 'svg'); $fa->set('loadAssets', false); Performance The module includes cache for parsed mappings Assets are loaded only when needed Smart detection of content with icons Compatibility ProcessWire 3.0+ Font Awesome 6.0+ PHP 7.4+ Support To report bugs or request features, visit: GitHub Issues License Mozilla Public License v2.0 Credits Based on TextformatterEmoji by Ryan Cramer.