Quartz 4

Blog-Modul

3 min read

Blog-Modul

Anforderung — vom User in Section-Type-Curation 2026-04-28 explizit benannt: “Blog wurde auch gefordert.”

Bedarf

Tenants brauchen ein generisches Blog-Modul fuer:

  • Praxis/Hebammen: Beitraege zu Gesundheits-Themen, News, Saison-Tipps
  • Bands/Kulturbetriebe: Tour-Berichte, Album-Releases, Pressemitteilungen
  • Service-Dienstleister: Case-Studies, Branchen-Insights, Tutorials
  • B2B-SaaS: Marketing-Blog, Customer-Stories, Engineering-Posts

Der heutige Page-Editor unterstuetzt nur statische Pages — ein Blog braucht ein Collection-Modell mit auto-generierten Listings.

Abhaengigkeiten zur Section-Type-Taxonomy

Folgende Section-Types aus der Curation 2026-04-28 (Cat I) funktionieren nur, wenn das Blog-Modul existiert:

  • collection.blog_listing — Auto-generierte Liste der neuesten Blog-Artikel
  • collection.blog_post_header — Header einer Blog-Detail-Page mit Auto-Feldern
  • collection.related_posts — “Auch interessant” am Ende eines Posts
  • collection.search_results — Search-Result-Page (auch nutzbar fuer Page-Search)

Diese Types lassen sich heute schon in der Taxonomy aufnehmen, sind aber noch nicht implementierungsfaehig, bis das Blog-Modul steht.

Modul-Anforderungen (Skizze)

Datenmodell

blog_collection (
  collection_id, tenant_id, slug, name, description, ...
)
 
blog_post (
  post_id, collection_id, author_id, slug, title,
  excerpt, body (richtext_with_blocks), featured_image,
  status (draft|published|archived), publish_at, ...
)
 
blog_post_tag (post_id, tag_id)
blog_tag (tag_id, tenant_id, slug, name)
blog_post_category (post_id, category_id)
blog_category (category_id, tenant_id, slug, name)

Routes / Pages

  • /{collection_slug} — Listing
  • /{collection_slug}/{post_slug} — Detail
  • /{collection_slug}/tag/{tag_slug} — Tag-Filter
  • /{collection_slug}/category/{category_slug} — Category-Filter
  • /search?q=... — Suche

Studio-Views (Editor-Bereich)

  • Posts-Liste (alle Posts eines Tenants)
  • Post-Editor (Body via Page-Editor-Pattern, mit Section-System!)
  • Tag/Category-Verwaltung
  • Author-Profile (greift auf bestehendes Account-System zu)

Permissions (RBAC)

  • blog.manage — Sysadmin-Level
  • blog.edit_own — Author kann eigene Posts editieren
  • blog.publish — Editor-Rolle kann Drafts veroeffentlichen
  • blog.moderate — Editor kann fremde Posts editieren

Aufwand-Schaetzung (grob)

  • Datenmodell + Migrations + Repositories: M (1-2 Tage)
  • Studio-Editor-Views (Liste + Editor + Tag/Category): L (3-4 Tage)
  • Routes + Public-Rendering: M (2-3 Tage)
  • Section-Type-Implementierung (collection.blog_*): M (parallel zur Theme-Migration)
  • Gesamt: ~10 Tage, eigener Sprint

Zusammenhaenge

Aehnliche Modul-Anforderungen (parallel diskutieren)

  • Event-Modul — Veranstaltungs-Darstellung auf CMS-Seiten (Beispiel: Baume “Unsere Auftritte”). NICHT der Workflow-Anlass (das ist ein anderer Workflow im FlowController). Section-Templates: collection.event_listing, collection.event_detail. Section-Templates eigener Sprint nach Modul-Implementierung.
  • Product/Catalog-Modul — fuer E-Commerce-Branchen
  • Case-Study-Modul — fuer B2B-Marketing-Sites

Alle drei haben aehnliche Architektur-Anforderungen wie Blog (Collection + Detail + Listing + Tags). Ueberlegung: ein generisches “Collection-Modul” als Plattform, das fuer Blog/Events/Products spezialisiert wird. Spart Code, einheitliche UX.

Modul-Konzept als License-Unit

Bestaetigt aus Brainstorm 2026-04-28: Modul ist eine eigene License-Unit-Type (neben Standard/Theme/Premium-Section). Ein Modul liefert:

  • Backend-Datenmodell (Collections wie Posts/Events/Products)
  • Studio-Admin-Views fuer Datenpflege
  • Section-Type-Definitionen mit Schema + Default-Component, die nur fuer Modul-Abonnenten verfuegbar sind

Theme-Designer koennen Variants dieser Modul-Section-Types in ihren Themes anbieten — das CSS-Pattern bleibt das gleiche wie bei normalen Sections, die Schema-Definition kommt vom Modul.

Siehe Theme-Marketplace fuer License-Unit-Architektur.

Graph View

Backlinks