Skip to content

Block editing in Directus

[updated on 24-05-17 to address our experiences with directus' built-in relations as well as desirable features exposed by potential solutions]

(1)

As an author who is used to WYSIWYG editors,

I want to see exactly how my article looks as I'm writing

So that I feel confident and don't need to roundtrip/test in a separate window. And I can author esthetic fixes such as hyphenations and river preventions.

(2)

As a maintainer of the site,

I want the authored content to be in a flexible and highly compatible format

So that it can be broadcast as human-readable articles, feeds, and machine-readable keywords, without me needing to write custom parsers.

(3)

As a frontend designer,

I want to give authors the option to reference existing data

In order to promote internal interconnectivity

So that I don't need to write custom parsers to weed out invalid internal links or correct typos.

(3a)

While doing that, I don't want to introduce new error classes, and I don't want to fight against a clunky Ui.

(4)

As an author,

I want to browse and reference existing data such as media files, posts, fellow authors, ecobytes projects, or tech lingo definitions

To prevent typos, duplicate work, and dead links.

(5)

As a frontend designer,

I want to cover the feature set (semantic gamut) of my theme,

namely: Rubrics (keywords/subheadings); Marginals (definitions, further reading, asides); Article series TOCs; Subgrid layout,

as well as the conventional blocks (several heading levels, blockquotes (including warning, info etc.), media, character styles, arbitrary links)

So as to nudge the authors towards semantical markup

(6)

As a reader,

I enjoy a semantically coherent site

because it eases my understanding and involvement with the content.

Derived ideal featureset:

  • Wysiwyg editor (1)
  • Theme synced with frontend (1)
  • Highly compatible format (2)
  • Internal references (3, 4):
    • Page, Post
    • Definition
    • Media File
    • etc. (this list will evolve)
  • Failsafe way to declare relational blocks (3a)
  • Conventional blocks (5)
  • Theme-specific semantics (5):
    • Manual hyphenation (Unicode)
    • Article Series TOC
    • Subgrid layout (cover n horizontal and vertical cells; start on cell m)
    • Aside paragraphs

Standardising on Directus for content editing and content API usage also means to get more familiar with its feature set, and more fluid with using it. In writing some pieces for https://content.ecobytes.net it has come to my attention, that the Directus editor is quite limited, in comparison to what one is known to from WordPress, Ghost, Outline, LogSeq, Notion and other block content editors.

When wanting to roll out Directus as a broader content delivery platform for different communities, it appears useful to consider usage experience first. Therefore options for implementing a block content editor become attractive.

shows an example of how to implement an editor.js extension for Directus.

There is a slight chance for an implementation vector of an eventual Markdown persistence layer via

There are other known approaches for Markdown block editing with Editor.js:

This might even work out within the Editor.js extension.

Whenever there is spare time for such discoveries, would we want to embark on such a journey and support a wider ecosystem with our intervention?

Edited by Flupsi