Modul eWiki
Wissen strukturieren, teilen, finden.
eWiki ist das Wissensmanagement-Modul von MeinPortal.cloud. Hilfecenter, Mitarbeiter-Handbuch, Mitglieder-Wissensbasis oder mehrsprachiges Bürger-Service-Wiki — eine Engine, beliebig viele Wikis pro Mandant, sauber gated über ePortal-Gruppen.
- Beliebig viele unabhängige Wikis pro Mandant — öffentlich, intern oder gruppen-gated
- Artikel-Hierarchie mit unbegrenzter Tiefe, automatische Breadcrumbs
- Postgres-Volltextsuche mit deutscher Linguistik, Snippets im Ergebnis
- Vollständige Versionshistorie mit One-Click-Restore — ohne Extra-Plan
Was eWiki kann
Acht Bausteine. Ein Wissens-Modul.
Was eWiki von einem Knowledge-Base-Tool zu einer ausgewachsenen Plattform-Komponente macht.
Beliebig viele Wikis pro Mandant
Ein öffentliches Hilfecenter, ein internes Mitarbeiter-Handbuch, ein gated Vorstands-Wiki — alles im selben Tenant, jedes mit eigener Zugriffskontrolle. Kein Workspace-Wildwuchs, kein Tool-Sprawl.
Artikel-Hierarchie ohne Tiefen-Limit
Artikel verschachteln sich beliebig tief in Parent-Child-Strukturen. Breadcrumbs werden automatisch aus der Hierarchie erzeugt. Aus dem Page-Tree wird die Navigation — ohne separate Menü-Pflege.
Markdown oder HTML
Artikel schreiben Sie in Markdown oder reichem HTML — mit automatischer Konvertierung zwischen beiden Formaten. Inline-Bilder direkt im Artikel (JPG, PNG, WebP, GIF, bis 5 MB).
Vollständige Versionierung
Jede Änderung erzeugt einen Snapshot mit Autor und Zeitstempel. Versionshistorie pro Artikel, Diff zwischen Versionen, One-Click-Restore auf jede frühere Fassung. Auch für Audit-relevante Wikis ein eingebauter Beleg, wer wann was geändert hat.
Postgres-Volltextsuche mit deutscher Linguistik
Nativ über tsvector und ts_headline mit deutscher Stemming-Konfiguration. Suchergebnisse enthalten Kontext-Snippets aus dem Treffer-Artikel und den Breadcrumb-Pfad. Bessere Trefferqualität als generische LIKE-Suchen, ohne externen Such-Index.
Granulares Gating über ePortal-Gruppen
Pro Wiki: öffentlich oder Login-pflichtig, separat steuerbar ob suchbar. Pro Gruppe: "Vorstand", "Premium-Kunden", "Mitglieder" — Zugriffsprüfung auf Wiki- und Artikel-Ebene. Dieselben Gruppen wie im Rest der Plattform, ein einziger Identitäts-Stack.
Mehrsprachigkeit nativ eingebaut
Wiki-Titel und -Beschreibung übersetzbar, Artikel-Titel und -Inhalt übersetzbar. Locale-Resolution über Query-Parameter und Tenant-Host, mit sauberem Fallback auf Deutsch. Kein Plugin, kein Add-on, keine Doppelpflege.
Embed-fähig in eContent und eNews
Wiki-Inhalte erscheinen als nativer Block in eContent-Seiten und als Card in Newsletter-Kampagnen. Dieselbe Quelle, mehrere Auspielwege — ein Artikel wird zur Hilfecenter-Seite, zum Footer-Link und zum Newsletter-Inhalt, ohne dass Sie ihn dreimal pflegen.
Statistik-Dashboard
Admin-Dashboard mit Anzahl Wikis, Drafts, Artikel pro Monat und Top-Wikis. Für größere Wissensbasen wird sichtbar, wo Aktivität passiert — und wo Inhalte stehen, die seit Jahren nicht angefasst wurden.
Tags und Autor-Tracking
Artikel lassen sich über Tags quervernetzen, jeder Artikel zeigt Autor und letzte Änderung. Status „draft“ und „published“ trennen Entwurf von veröffentlichtem Stand — ohne komplexen Approval-Workflow im Weg.
Privacy by Design
Wissensbasis als Plattform-Komponente, nicht als zusätzliches SaaS.
Vier Konsequenzen daraus, dass eWiki kein Stand-alone-Tool ist.
Wissen ist Daten. Sobald eine Wissensbasis Mitarbeiterprozesse, Mitgliederinformationen oder Bürgerdialoge dokumentiert, beginnt die DSGVO-Pflicht — nicht erst im Zwischenfall.
eWiki ist nicht ein zusätzliches SaaS-Tool. Es ist Teil derselben Plattform, in der auch Formulare, Events und Mitgliederdaten leben. Vier Konsequenzen daraus:
- Hosting in Deutschland, ein einziger Tenant. Die Wissensbasis liegt auf denselben Hetzner-Servern wie Ihre Formulare und Mitgliederdaten. Keine Datenexporte zu US-SaaS, kein zusätzlicher Auftragsverarbeitungs-Vertrag, kein TIA-Risiko.
- Identität und Gruppen aus einer Quelle. Wer Zugriff auf das Mitglieder-Wiki hat, ist dieselbe Person, die im ePortal eingeloggt ist. Berechtigungen leben in den ePortal-Gruppen — also genau dort, wo auch Veranstaltungs-Anmeldungen, Newsletter-Bezug und Ticket-Berechtigungen verwaltet werden.
- Versionierung als Audit-Trail. Jeder Schreibvorgang ist nachvollziehbar: Autor, Zeitstempel, Diff. Für Wikis, die Vorschriften, Satzungen oder gesetzliche Hinweise dokumentieren, ist der Audit-Trail bereits eingebaut — kein separates Compliance-Modul nötig.
- Mehrsprachigkeit ohne Datenkopien. Übersetzungen liegen am selben Artikel, nicht in einem parallelen Workspace. Wer die deutsche Fassung ändert, sieht sofort, welche Übersetzungen nachgezogen werden müssen.
Das ist nicht Knowledge-Management als Add-on. Das ist Wissen als integraler Teil derselben Architektur.
Anwendungsfälle
Was Organisationen mit eWiki bauen.
Sechs Cluster, eine Engine — vom öffentlichen Hilfecenter bis zum Vorstands-Wiki.
Öffentliches Produkt-Hilfecenter
Produkt-Hilfe und Wissensdatenbank für Kunden, öffentlich zugänglich und durchsuchbar. Artikel-Hierarchie macht die Navigation zur Struktur, Volltextsuche liefert relevante Treffer mit Kontext-Snippet. Anders als beim klassischen FAQ kein flacher Bullet-Sumpf, sondern ein gepflegter Page-Tree.
Strukturierte FAQ-Sammlung
FAQ-Sammlung mit Kategorien wie Onboarding, Abrechnung, Troubleshooting. Statt einer endlosen Akkordeon-Liste eine echte hierarchische Wissensbasis. Über Tags lassen sich verwandte Artikel quervernetzen — Nutzer landen schneller bei der Antwort, die sie suchen.
Glossar / Fach-Nachschlagewerk
Wikipedia-Style-Nachschlagewerk in der eigenen Domäne: Fachbegriffe, Akronyme, Standardprozesse. Markdown-Formatierung mit Inline-Bildern reicht für die meisten Glossar-Einträge, Versionierung sichert den Stand der Definition ab.
Versionierung
Versionierung als eingebauter Audit-Trail.
Jede Änderung als Snapshot mit Autor, Zeitstempel und One-Click-Restore.
Wer jemals in einer Org gearbeitet hat, in der wichtige Satzungs- oder Prozess-Änderungen in einer Word-Datei mit dem Suffix _final_v3_neu_KORREKTUR.docx liegen, kennt das Problem: Niemand weiß, was die aktuell gültige Fassung ist. Und niemand kann nachweisen, wer wann was geändert hat.
In eWiki ist jede Änderung ein Snapshot. Mit Autor, Zeitstempel, vorherigem Inhalt. Vier Konsequenzen daraus:
- Diff zwischen Versionen. Jede frühere Fassung lässt sich vergleichen, was sich konkret geändert hat — nicht nur „wer hat zuletzt gespeichert“, sondern „was genau ist anders“.
- One-Click-Restore. Eine versehentlich gelöschte oder zerschossene Fassung ist mit einem Klick wieder hergestellt. Ohne Tickets ans IT-Team, ohne Backup-Recovery.
- Audit-Trail ohne Extra-Modul. Für Wikis, die Satzungen, Datenschutz-Richtlinien oder Compliance-Vorgaben dokumentieren, ist der Audit-Trail Pflicht. Hier ist er eingebaut, nicht zugekauft.
- Keine Plan-Begrenzung. Versionshistorie ist ab dem kleinsten Paket dabei. Es gibt nicht den „Enterprise-Tier mit Page-History“ und den „Starter ohne“ — alles oder nichts wäre unehrlich.
Volltextsuche
Suchen, was wirklich gemeint ist.
Native Postgres-Volltextsuche mit Stemming, Snippets und Breadcrumb-Kontext.
Generische LIKE-Suchen finden Einträge nur dann, wenn der Suchbegriff wörtlich vorkommt. Wer nach „Hausordnung“ sucht, findet keinen Artikel mit dem Titel „Haus-Ordnungen“ oder „die Ordnungen unseres Hauses“. Für eine ernst zu nehmende Wissensbasis ist das zu wenig.
eWiki nutzt die native Postgres-Volltextsuche — mit deutscher Sprachkonfiguration. Drei Konsequenzen daraus:
- Stemming und Stoppwörter. Postgres reduziert deutsche Wörter auf ihren Stamm: „Hausordnung“, „Haus-Ordnungen“ und „ordnen“ werden als verwandt erkannt. Stoppwörter wie „und“, „der“, „die“ werden ignoriert — die Suche fokussiert auf das, was Bedeutung trägt.
- Kontext-Snippets im Ergebnis. Pro Treffer zeigt die Suche einen Ausschnitt aus dem Artikel, in dem das Suchwort markiert ist (
ts_headline). Nutzer:innen sehen sofort, ob der Treffer relevant ist — ohne den ganzen Artikel öffnen zu müssen. - Breadcrumb-Pfad als Kontext. Jeder Suchtreffer kommt mit dem vollständigen Breadcrumb — „Handbuch › Onboarding › IT-Zugang › VPN-Einrichtung“. Damit ist klar, in welchem Bereich der Artikel lebt, ohne die Trefferliste raten zu müssen.
Pro Wiki ein Suchindex, öffentlich nur publizierte Artikel — Drafts bleiben aus dem Index draußen. Wer ein Wiki aus der Suche ausnehmen will, schaltet das per is_searchable-Toggle ab. Suchbarkeit und Sichtbarkeit sind separat steuerbar.
Im Vergleich
Wo eWiki aufhört, und wo Confluence-Klone weitermachen.
Was eWiki von Confluence, Notion und Helpjuice unterscheidet — und was nicht.
eWiki tritt nicht gegen die ausgereifte Notion-Editor-Erfahrung oder die Confluence-Plugin-Vielfalt an. Es löst ein anderes Problem: Eine Wissensbasis, die rechtlich und organisatorisch zur Plattform passt, in der die restlichen Daten leben. Drei Unterschiede sind dabei besonders deutlich:
- Mehrsprachigkeit ohne Add-on. Confluence-Mehrsprachigkeit kommt über Plugins (Scroll Translations, Atlas Translation). Notion bietet keine native i18n. eWiki hat Mehrsprachigkeit auf Wiki- und Artikel-Ebene eingebaut, mit sauberem Locale-Fallback. Wer mehrsprachige Inhalte braucht, zahlt das nicht extra.
- DSGVO im eigenen Tenant. Notion und Confluence sind US-SaaS. Für DSGVO-relevante Inhalte (Mitgliederlisten, Mitarbeiterdaten, Bürgerdialoge) braucht es einen TIA, einen AVV und einen guten Anwalt. eWiki läuft auf Hetzner-Servern in Deutschland — im selben Tenant wie die restliche Plattform.
- Gating ohne Zweit-Identität. Wer in Confluence ein internes Wiki neben dem öffentlichen Hilfecenter haben will, jongliert Confluence Cloud-Spaces, Space-Permissions und einen externen Identity-Provider. In eWiki ist das ein Toggle:
is_public,is_searchable, ePortal-Gruppe. Dieselbe Identität, derselbe Mandant.
Was eWiki nicht ist: ein vollständiger Notion-Klon. Es gibt keinen Block-Editor mit Datenbanken-Views, keine Kanban-Boards (das macht eTicket), keine Real-Time-Co-Editing-Cursors. Wenn das zentrale Anforderungen sind, ist eWiki nicht das richtige Tool.
Wenn dagegen Wissensbasis-Funktionalität — strukturierte Hierarchie, Volltextsuche, Versionierung, Gating, Mehrsprachigkeit — in derselben Plattform leben soll wie Formulare, Events und Mitgliederdaten: dann ist eWiki genau der Baustein, der dort hingehört.
FAQ
Was wir oft zu eWiki gefragt werden.
Elf Antworten auf typische Fragen zum eWiki-Modul.
Ist eWiki eine Notion- oder Confluence-Alternative?
Wie viele Wikis kann ich anlegen?
Welches Format haben Artikel?
Wie funktioniert Zugriffskontrolle pro Wiki?
is_public entscheidet über Login-Pflicht, is_searchable separat über Auftauchen in der Suche. Zusätzlich pro Wiki und pro Artikel: Gruppen-Beschränkung über ePortal-Gruppen. Damit lässt sich ein Wiki „unsichtbar für Suchmaschinen, aber zugänglich für Mitglieder“ konfigurieren — ohne externes IAM-System.Gibt es einen Approval-Workflow?
Wie gut ist die Volltextsuche?
tsvector, ts_headline). Stemming und Stoppwörter sind berücksichtigt, Trefferqualität deutlich über dem, was generische LIKE-Suchen liefern. Suche ist pro Wiki, nicht über alle Wikis gleichzeitig — eine bewusste Designentscheidung, damit Suchergebnisse nicht aus Wikis kommen, in denen die Nutzer:in nichts zu suchen hat.Wie funktioniert Mehrsprachigkeit?
Wird die Versionshistorie eingeschränkt?
Wie integriere ich Wiki-Inhalte in andere Stellen?
Wo liegen die Daten?
Kann ich Dateien an Artikel anhängen?
Loslegen
Bereit für Ihre erste Wissensbasis?
eWiki ist in allen Paketen enthalten — von Starter bis Enterprise. Die Anzahl gleichzeitiger Wikis und das Storage-Limit für Inline-Bilder skalieren mit dem Paket, der Funktionsumfang bleibt gleich. Versionierung, Volltextsuche und Mehrsprachigkeit sind ab dem kleinsten Paket dabei.