Rapid — EditorJS block editor fieldtype for ProcessWire

[maximus]

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!

[ukyo]

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!

[maximus]

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.

[ukyo]

I am now playing with HTMX for building something like that

[maximus]

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!