Das Modul simplebis-posts verwaltet Beiträge, News und Blog-Inhalte einer simplebis-Umgebung. Beiträge werden zentral im Manager gepflegt und können anschließend in Webseiten, Apps und im simplebis-tool verwendet werden.
Die neue Implementierung nutzt den Manager-Bereich Beiträge, speichert Beiträge in der Collection posts und arbeitet mit der v2-Funktions-API posts.details und posts.save. Legacy-Web-Embeds und alte Editorfunktionen sind für diese Beschreibung nicht relevant. Wichtig ist: Ein Beitrag ist kein isolierter Website-Inhalt, sondern ein wiederverwendbarer Datensatz, der von mehreren Ausgabekanälen gelesen werden kann.
Der Menüpunkt Beiträge erscheint im Manager, wenn das Modul posts in der Umgebung aktiv ist. Für den Zugriff wird die Berechtigung posts.use verwendet. Das Modul definiert außerdem Rechte für Erstellen, Bearbeiten und Löschen von Beiträgen: create, edit und delete, jeweils auf Basis der Modulnutzung.
Wie bei anderen Modulen werden diese Berechtigungen über Benutzergruppen gepflegt. Benutzer ohne Modulberechtigung sehen den Bereich nicht oder können ihn nicht nutzen. Für Integrationen über Website-Kontexte und API-Funktionen ist zusätzlich relevant, dass der ausführende Kontext die Posts-Lese-Freigabe besitzt, zum Beispiel mcp.posts.read bei den neuen API-Scopes.
Beiträge werden im Manager über Beiträge geöffnet. Die Übersicht nutzt in der neuen Implementierung die Datatable posts. Sie zeigt vorhandene Beiträge und öffnet einen Eintrag über /posts/<id>/edit. Über Beitrag anlegen wird ein neuer Beitrag erstellt.
Ein Beitrag besitzt mindestens einen Titel. Zusätzlich können Content-Builder-Inhalte, ein Beitragsbild, Veröffentlichungsstatus, Veröffentlichungszeitpunkt und die Sichtbarkeit im simplebis-tool gepflegt werden. Beim Speichern wird der Beitrag der aktuellen Umgebung zugeordnet und mit created_at, created_by, updated_at und updated_by protokolliert.
Der neue Beitragseditor besteht aus dem Content-Bereich und einer rechten Seitenleiste. Im Content-Bereich wird der Titel gepflegt und darunter werden Inhaltselemente über den Content Builder ergänzt. Rechts wird das Beitragsbild ausgewählt und die Veröffentlichung gesteuert.
Das Beitragsbild wird als Datei aus dem Dateimanager gesetzt und in _featured_image gespeichert. Ausgabekanäle können daraus direkte Bild-URLs und Thumbnails erzeugen. Der eigentliche Beitragstext wird als strukturierte Liste in content gespeichert. Dadurch können Websites, Apps und Renderer die Inhalte kanalspezifisch darstellen, ohne den Beitrag mehrfach zu pflegen.
Die neue Manager-Implementierung stellt im Content Builder aktuell zwei Inhaltstypen bereit:
Text beziehungsweise wysiwyg: ein WYSIWYG-Inhalt über SimplebisWYSIWYG im Modus posts. Dieser Typ eignet sich für formatierte Fließtexte, Überschriften, Links und HTML-basierte Inhalte.String beziehungsweise string: ein einfaches Textelement mit optionalem Text-Styling. Dieser Typ eignet sich für kurze Textblöcke, Teaser, Hervorhebungen oder strukturierte Zwischenzeilen.Die Website-Detailseite des neuen Website-Presets kann außerdem kompatible Einträge der Typen html und text rendern. Für neue Beiträge sollten im Manager aber primär die sichtbaren Builder-Typen wysiwyg und string verwendet werden.
Die Veröffentlichung wird in der rechten Seitenleiste gesteuert. Der Schalter Beitrag veröffentlicht entscheidet, ob der Beitrag grundsätzlich veröffentlicht werden soll. Ist der Schalter aktiv, kann ein Zeitpunkt der Veröffentlichung gesetzt werden.
Wenn ein Beitrag als veröffentlicht gespeichert wird und kein Veröffentlichungszeitpunkt gesetzt ist, setzt simplebis publish_at automatisch auf den aktuellen Zeitpunkt. Wird ein zukünftiger Zeitpunkt eingetragen, ist der Beitrag geplant. Er wird automatisch sichtbar, sobald publish_at erreicht ist. Dafür ist kein separater Veröffentlichungsjob nötig; Listen und Kontexte filtern live nach is_published und publish_at <= jetzt.
Wird Beitrag veröffentlicht deaktiviert, setzt simplebis is_published auf false und entfernt publish_at. Der Beitrag bleibt im Manager bearbeitbar, erscheint aber nicht in veröffentlichten Listen.
Beitragskategorien werden in posts_categories gespeichert und gehören zur jeweiligen Umgebung. Eine Kategorie besitzt einen Titel; pro Umgebung darf derselbe Titel nicht doppelt angelegt werden. Die Manager-API stellt dafür Funktionen zum Auflisten, Speichern, Laden und Entfernen bereit: /api/manager/posts/categories/list, save, details und remove.
Die Zuordnung eines Beitrags zu Kategorien wird als Kategorie-ID-Liste in attributes.categories gespeichert. Die neue Posts-API berücksichtigt sowohl attributes.categories als auch ältere categories-Felder, damit bestehende Inhalte sauber gefunden werden können. Beim Löschen einer Kategorie entfernt simplebis die Kategorie aus betroffenen Beiträgen, sofern sie in der älteren Kategoriezuordnung verwendet wurde.
Kategorien sind besonders wichtig für Websites und Apps, weil Listen damit gefiltert werden können. Die neuen Kontexte akzeptieren Kategorie-IDs oder eindeutige Kategorie-Titel. Dadurch kann eine Website-Seite zum Beispiel nur Beiträge aus News, Ankündigungen oder Team anzeigen.
Das Modul stellt neue API-Funktionen im Scope simplebis-posts bereit:
posts.list: listet Beiträge mit Filtern für ID, URL-Slug, Suche, Titel, Kategorien, Sichtbarkeit, Sortierung, Limit und Offset.posts.categories.list: listet Beitragskategorien mit Filtern für ID, Suche, Titel, Sortierung, Limit und Offset.posts.list liefert neben ID und Titel auch title_short, url_slug, content, attributes, publish_at, Veröffentlichungsstatus, Zeitstempel, Kategorien sowie Bilddaten inklusive URL und Thumbnails. Die Standardsichtbarkeit ist published; damit erscheinen nur Beiträge, die veröffentlicht sind und deren Veröffentlichungszeitpunkt erreicht ist.
Als Sortierungen stehen unter anderem publish_at_desc, publish_at_asc, title_asc, title_desc, created_at_desc und updated_at_desc zur Verfügung. Für Kategorien gibt es title_asc, title_desc, created_at_desc und updated_at_desc.
Für Webseiten gibt es das Preset Website Posts Basic mit dem Preset-Key website_posts_basic. Es legt zwei Seiten und zwei Kontexte an:
/posts: Beitragsliste mit dem Kontext posts./post/:urlslug: Beitragsdetail mit dem Kontext posts im Modus single_entry.posts: ruft posts.list auf.post_categories: ruft posts.categories.list auf.Die Listenseite liest data.posts.entries und verlinkt Beiträge über /post/<url_slug oder id>. Die Detailseite liest data.post, zeigt Datum, Kategorien, Beitragsbild, Kurztext und Content-Builder-Inhalte. Meta-Titel und Meta-Beschreibung können über Template-Ausdrücke wie {{ data.post.title }} und {{ data.post.title_short }} gesetzt werden.
Anpassungen erfolgen wie bei anderen Website-Presets über Seiten, Code-Komponenten, Plugin-Kontexte und Styling. Man kann Listenlayouts ändern, Kategorie-Filter setzen, Pagination bauen, Detailseiten anders rendern, Beitragsbilder anders verwenden oder weitere Kontexte kombinieren.
Eine Beitragsliste kann in einer Website-Seite über den Kontext posts geladen werden. Der Kontext wird auf der Seite aktiviert und unter einem Ziel-Key bereitgestellt, zum Beispiel posts.
Beispiel für den Zugriff in einer Code-Seite:
export default async function PostsPage({ data, api }: any) {
const entries = Array.isArray(data?.posts?.entries) ? data.posts.entries : [];
return (
<main>
<h1>Beiträge</h1>
{entries.map((post: any) => (
<a key={post._id} href={api.buildUrl('/post/' + encodeURIComponent(post.url_slug || post._id))}>
{post.image_url ? <img src={post.image_url} alt={post.title || ''} /> : null}
<strong>{post.title}</strong>
{post.title_short ? <p>{post.title_short}</p> : null}
</a>
))}
</main>
);
}
Für eine Detailseite wird derselbe Kontext mit single_entry: true und urlslug: "$route.urlslug" verwendet. Dann liegt der einzelne Beitrag direkt unter dem gewählten Target-Key, zum Beispiel data.post.
Beiträge integrieren sich in Apps über die App-Konfiguration und die Posts-APIs. In vorkonfigurierten App-Screens kann der Dashboard-Modus News- / Beitrags-Slider gewählt werden. Dazu können Slider Textfarbe und Slider Schatten-Farbe angepasst werden. So lässt sich eine Startseite bauen, die veröffentlichte Beiträge als News- oder Blog-Slider nutzt.
Für eigene App-Screens können Beiträge über die vorhandenen Posts-Listenfunktionen geladen und gerendert werden. Die neue API liefert Content, Bilddaten, Kategorien und Veröffentlichungsdaten, sodass ein Custom Screen eigene Karten, Slider, Detailseiten oder Kategorieansichten bauen kann. Übliche Anpassungen sind Anzahl der Beiträge, Sortierung, Kategorie-Filter, Darstellung des Beitragsbilds, Teasertext, Detailnavigation und App-spezifische Styles.
Für ältere App-spezifische Sliderdaten existieren Felder wie attributes.app_slider_<appId> und attributes.app_slider_image_<appId>. Neue Implementierungen sollten Beiträge jedoch bevorzugt über die Posts-API beziehungsweise App-/Builder-Screens lesen und dort explizit filtern und darstellen.
Das simplebis-tool erhält Beiträge über die Mitarbeiter-Hauptdaten. Dafür muss ein Beitrag veröffentlicht sein, publish_at erreicht haben und In Mitarbeiter-App (simplebis-tool) veröffentlichen muss aktiv sein. Intern wird das als publish_employees: true gespeichert.
Für Mitarbeiter werden nur Beiträge geladen, die zur aktuellen Umgebung gehören und die Bedingungen publish_employees: true, is_published: true und publish_at <= jetzt erfüllen. Die Beiträge werden nach Veröffentlichungszeitpunkt absteigend sortiert.
Damit eignet sich das Posts-Modul auch für interne News, Schichtinformationen, Team-Ankündigungen, Prozesshinweise oder kurzfristige Mitteilungen. Ein Beitrag kann gleichzeitig öffentlich auf der Website erscheinen, in einer App genutzt werden und zusätzlich im simplebis-tool für Mitarbeiter freigegeben werden.
Die Ausgabe ist bewusst kanalabhängig anpassbar:
publish_employees, welche Beiträge intern sichtbar werden.Die wichtigste Regel ist: Der Beitrag bleibt der zentrale Datensatz. Kanal-spezifische Anpassungen sollten möglichst in der jeweiligen Website-, App- oder Tool-Ausgabe passieren, damit Inhalte nicht mehrfach gepflegt werden müssen.
Für ein neues Beiträge-/Blog-Setup empfiehlt sich diese Reihenfolge:
posts aktivieren und Benutzergruppen mit passenden Beitragsrechten ausstatten.Website Posts Basic aktivieren oder eigene Website-Seiten mit den Kontexten posts und post_categories bauen.In Mitarbeiter-App (simplebis-tool) veröffentlichen aktivieren und im simplebis-tool prüfen.Bei späteren Änderungen sollte immer geprüft werden, ob die gewünschte Zielgruppe den Beitrag sehen darf: öffentlich auf Webseiten, in Apps, intern im simplebis-tool oder in mehreren Kanälen gleichzeitig.