Zum Inhalt springen

Gespräch:Rechtevergabe Semantic MediaWiki

aus AufEinWort, der freien Forschung

Über diese Seite Gespräch

Namespace Konfiguration MediaWIki
ChatGPT Sophos GPT-4, ChatGPT Sophos GPT-5 Thinking
5. September 2025 n. Chr. erst.  
Ausgabe 01
Ausgabe 01
unüberarbeitet ungeprüft
2025090501 Rechtevergabe Semantic MediaWiki.webarchive

Aufgabenstellung

Nikolaos:

Schutz Semantic MediaWiki

Hallo Sophos,

Bevor ich mein SMW online stelle muß ich folgenden Schutz einrichten:

1. Systemseiten wie Vorlagen, Kategorien, Module, MediaWIki, Hilfe  oder ähnlich, sollen nur von Administratoren angelegt, verändert, verschoben und bearbeitet werden können.

1. Wikiseiten sollen erst und gemäß Freigebe für Gruppen lesbar sein, nicht nur einfach mit einem Trick die Ansicht der Inhalte verbergen, sondern nicht freigegebene Seiten gar nicht sehen können.

Recherchiere bitte, wie diese beiden Bedingungen in MW 1.43 SMW 5.1 erfüllt werden können.

Lösungsansatz verwendbare SMW Erweiterungen und Einstellungen

Sophos:

Nachgedacht

Ich muss Lösungen für MediaWiki 1.43 und SMW 5.1 finden, um Systemseiten wie Vorlagen, Kategorien und Medienwiki-Namensräume zu schützen. Die Festlegung von wgNamespaceProtection und Gruppenberechtigungen wie edit-template scheint üblich. Alternativen wären Erweiterungen wie Lockdown oder ProtectSite, die auch mehr Kontrolle erlauben.

Es gibt verschiedene Erweiterungen wie Lockdown für Lesezugriffsberechtigungen und NamespaceProtection im Kern von MW, um Systemseiten zu schützen. Für Seiten, die wirklich versteckt werden sollen, sind Erweiterungen wie Lockdown oder AccessControl hilfreich. Bei SMW könnte die Erweiterung SemanticACL nützlich sein, aber es bleibt zu beachten, dass SMW-Abfragen möglicherweise immer noch Daten anzeigen.

Es gibt Erweiterungen wie "SMW Security" und "SemanticACL", die Zugriffskontrollen für semantische Daten ermöglichen. Ich muss die neuesten Informationen für MW 1.43 und SMW 5.1 checken, insbesondere im Hinblick auf die unsichtbare Anzeige von Seiten. Die "Lockdown"-Erweiterung könnte Leseaktionen verhindern und Inhalte in Suchergebnissen unsichtbar machen, aber Titel bleiben möglicherweise sichtbar. Schutz von Systemseiten über $wgNamespaceProtection ist auch eine Option.

Die Benutzer möchten, dass nur Administratoren Vorlagen und ähnliche Seiten erstellen/bearbeiten können. Um dies umzusetzen, kann $wgGroupPermissions['*']['createpage'] angepasst werden. Möchte man speziell nur Admins das Erstellen und Bearbeiten von Seiten innerhalb bestimmter Namensräume erlauben, könnte $wgNamespaceProtection mit der Berechtigung 'create-template' helfen.

Es scheint, dass "Lockdown" eine read-Schutzebene hinzufügt, aber ich bin mir nicht sicher. Die Erweiterung "SimpleSecurity" könnte per-Seiten-Schutz bieten, ist aber veraltet. "Approved Revs" könnte helfen, unbestätigte Revisionen unsichtbar zu machen, aber der Benutzer will vollständige Zugriffskontrolle. Eventuell könnte eine Kombination von "Lockdown" mit einer benutzerdefinierten Namespace-Methode der Lösung näherkommen.

Durchsuchen von Lösungen für MediaWiki 1.43 und SMW 5.1

Für Namensräume wie NS_TEMPLATE erfordert die Erstellung von Seiten die Berechtigung 'create-template', zusätzlich zur 'edit'-Berechtigung. Namespace-Schutz und Benutzergruppenberechtigungen müssen entsprechend gesetzt werden, um die Bearbeitung auf Administratoren zu beschränken. Per-Page-Leseeinschränkungen können durch Erweiterungen wie 'Lockdown' oder 'PageAccess' erreicht werden.

Ich werde die relevanten Seiten zu $wgNamespaceProtection, der Erweiterung "Lockdown" und Semantic ACL überprüfen. Dabei möchte ich sicherstellen, dass diese mit MW 1.43 und SMW 5.1 kompatibel sind. Besonders wichtig ist, ob "Semantic ACL" noch gewartet wird und ob es gut mit SMW funktioniert.

Überprüfen der Kompatibilität von MediaWiki-Erweiterungen

Es wird ausdrücklich gesagt, dass Lesebeschränkungen nicht mit $wgNamespaceProtection erreichbar sind, sondern dass dafür die Erweiterung "Lockdown" verwendet werden muss. Die Beispiele dort scheinen genau die Lösung zu bieten. Ich werde nun die Seite zur Lockdown-Erweiterung öffnen, um weitere Details zu überprüfen.

Öffnen der Lockdown-Seite

Die Lockdown-Seite zeigt, dass die Erweiterung stabil ist und mit MW 1.31+ kompatibel ist, also auch mit 1.43 funktioniert. Jetzt schaue ich mir die Semantic ACL Erweiterung an, um ihre Kompatibilität und Wartungsstatus zu prüfen und herauszufinden, ob sie mit den neuesten Versionen von MW und SMW funktioniert.

Überprüfung der Lockdown-Seite und Semantic ACL Erweiterung

Die Semantic ACL Erweiterung ist laut der Seite nicht mehr gepflegt, aber kompatibel mit SMW 5.1. Es gibt eine Risikoabschätzung, da sie nicht mehr gewartet wird. Es gibt auch andere Optionen wie "PageOwnership" oder "PagePermissions". Für den Benutzer müssen wir eine empfohlene, wartungsfähige Lösung finden, die auf die Gruppenberechtigungen abzielt, um Seiten sicher zu halten und Transklusionen zu verhindern.

Eine Möglichkeit wäre, den "Review"-Namespace zu verwenden, um Entwürfe nur für bestimmte Gruppen sichtbar zu machen und freigegebene Seiten in den öffentlichen "Werk"-Namespace zu verschieben. Eine andere Option ist die "Approved Revs"-Erweiterung, um nur genehmigte Versionen anzuzeigen. Wir sollten die Erweiterung überprüfen und sicherstellen, dass sie mit den Steuerungen kompatibel ist.

Empfehlen von Zugriffssteuerung für MediaWiki-Erweiterungen

Die "Approved Revs"-Erweiterung zeigt nur genehmigte Versionen an, aber macht Seiten weiterhin sichtbar. "PageOwnership" könnte für Transklusion und SMW geeignet sein, aber wir müssen sicherstellen, dass es mit MW 1.43 kompatibel und noch gepflegt wird. Ich werde diese Erweiterung weiter prüfen.

Überprüfen der Kompatibilität von PageOwnership mit Version 1.43

Diese Erweiterung scheint interaktiv zu sein und unterstützt SMW und Transklusion sowie Seitenzugriffsberechtigungen. Wir müssen jedoch ihre Kompatibilität mit MW 1.43 überprüfen. Es gibt Bedenken wegen möglicher Leaks bei Seitenbeschränkungen. Ich würde „Lockdown“ für Namespace-Level und „PageOwnership“ oder „AccessControl“ für Seitenbeschränkungen vorschlagen. Auch die Konfiguration von Systemseiten sollte nicht übersehen werden.

Es ist besser, eine Berechtigung pro Namespace zu definieren, wie z.B. $wgNamespaceProtection[NS_TEMPLATE] = ['templatemodify']. Für die Verwaltung von Berechtigungen wie Verschieben und Löschen sollten wir Lockdown verwenden, da dies pro Namespace eingrenzbar ist. Bei MediaWiki sollte die „interface-admin“-Gruppe für siteweite Bearbeitungen genutzt werden.

Um die Seitencreation durch Nicht-Sysops in bestimmten Namespaces zu blockieren, verwenden wir $wgNamespaceProtection. Dies verhindert deren Erstellung von Seiten, solange sie keine Bearbeitungsrechte haben. Für Categories: Nicht-Sysops können Kategorie-Links setzen, aber keine Kategoriebeschreibungen ändern oder neue Seiten erstellen, was in diesem Fall gewünscht sein könnte.

Überprüfen von SMW-Lesebeschränkungen und Lockdown-Kompatibilität

SMW kann Leseeinschränkungen ignorieren, was zu Datenlecks führen könnte. Semantic ACL adressiert dieses Problem jedoch, da Abfragen nur sichtbare Seiten einbeziehen. Wir können eine schrittweise Konfiguration anbieten: Zum Beispiel $wgNamespaceProtection für System-Namespaces wie NS_TEMPLATE, NS_CATEGORY und benutzerdefinierte als ‚edit-template‘, um nur Sysops Zugriff zu gewähren.

Das Gruppenrecht „interface-admin“ ist erforderlich, um CSS/JS/JSON zu bearbeiten. Optional können Sie sich selbst dieser Gruppe hinzufügen. Um Umzüge und Löschen in bestimmten Namespaces nur für Sysops zu beschränken, sollte Lockdown verwendet werden. Für die Seitenerstellung in solchen Namespaces verhindert $wgNamespaceProtection die Erstellung ohne erforderliche Bearbeitungsrechte.

Für „Kategorie“-Namespaces könnte man das Verschieben von Kategorien auf Sysops beschränken. Bei „Scribunto“-Modulen könnte „editcontentmodel“ nötig sein, wenn man das Inhaltsmodell ändert. Eine gute Strategie für „Entwurf“-Namespaces ist es, den Zugriff auf bestimmte Gruppen zu beschränken und dann genehmigte Seiten öffentlich zu machen.

Exploring MediaWiki configuration for namespace protection and access

Die "CategoryLockdown"-Erweiterung könnte helfen, Kategorien nach Gruppen zu beschränken und so deren Leserechte zu kontrollieren. Allerdings sollte die Stabilität der Erweiterung beachtet werden, besonders bei der Version 4.0. Eine allgemeinere Lösung wäre es, "Lockdown" und "PageOwnership" zu verwenden. Auch die Einschränkung von Spezialseiten ist wichtig.

Zur Umsetzung von Gruppen-basierten Leseberechtigungen könnte man $wgGroupPermissions für 'read' anpassen. Eine private Wiki-Konfiguration mit Lockdown beschränkt den Zugriff auf Genehmigte Gruppen und lässt Seiten wie 'Public' frei zugänglich. Alle nicht freigegebenen Seiten bleiben geschützt und nur zugängliche Seiten werden nach Freigabe verschoben.

Wenn einige Seiten öffentlich zugänglich sind, kann man $wgGroupPermissions für 'read' nicht auf false setzen. Aber Lockdown lässt sich weiterhin nutzen, um 'Draft' auf bestimmte Gruppen zu beschränken. Auch bei eingeschränkten Seiten können 'File'-Dateien über direkte URLs zugänglich bleiben. Achtung vor dieser Lücke und eine Linkempfehlung zu "Manual:Image Authorization".

Erstellen von Zugriffskontrollen für Wikiseiten und Dateien

Es ist wichtig, Dateien zu schützten, z. B. durch Lockdown bei "Recentchanges" und "Search" für eingeloggt Nutzer. Verwende $wgSpecialPageLockdown['Recentchanges'] = ['user']; Sicherstellen, dass Systemseiten und "moving"-Rechte durch Lockdown auf 'user' oder 'editor' eingeschränkt sind. Auf "Interface admin" für JS/CSS zugreifen. Eventuell doppelte Sperrung mittels Dateieigentümerschaft erwägen. Best-Practice: übersichtlich, Schritt-für-Schritt im klaren Code.

Da dies ein komplexes Thema ist, werde ich mit einer knappen Zusammenfassung beginnen. Danach präsentiere ich Option A (beste Praxis) und Option B (pro Seite). Wichtige Aussagen müssen mit den entsprechenden Quellen belegt werden. So bleibt die Antwort klar und gut nachvollziehbar.

Ich sollte die folgenden Punkte einbeziehen:

  • Verwendung und Einschränkungen von $wgNamespaceProtection (kein Lesezugriff): Manual:$wgNamespaceProtection (link).
  • Lockdown-Erweiterung für Namensraum-/Spezialseiteneinschränkungen – siehe Lockdown-Seite (link).
  • Hinweise zu Semantic ACL – unrealistisch gepflegt, aber verfiltern möglich; siehe Semantic ACL-Seite (link).
  • MedienWiki für Seitenbeschränkungen nicht optimiert – siehe Manual:Preventing access (link).
  • Bild-/Datei-Autorisierung schützen: Manual:Image authorization (link).
  • Release Notes 1.43 zu $wgNamespaceProtection (link).

Ich muss die folgenden Punkte ansprechen:

  • Einschränkungen von $wgNamespaceProtection, das Lesezugriff nicht beschränkt: Manual:$wgNamespaceProtection.
  • Lockdown Erweiterung für Namensraum-/Spezialseiteneinschränkungen: Lockdown-Seite.
  • Semantic ACL funktioniert bis SMW 4+, aber nicht gepflegt: Semantic ACL-Seite.
  • MediaWiki ist nicht für Seitenrestriktionen gedacht: Manual:Preventing access.
  • Bild-/Dateiautorisierung via img_auth.php: Manual:Image authorization.
  • Release Notes 1.43 zu $wgNamespaceProtection: (link).

Beginnen wir mit einer kurzen Zusammenfassung der empfohlenen Architektur:

A) Systemseiten sperren: Verwenden Sie $wgNamespaceProtection für Templates, Kategorien, Module, Hilfe etc. Mit MedienWiki 'interface-admin' Gruppe und Lockdown zur Einschränkung von Verschiebungen/Löschungen je nach Namensraum.

B) Sichtbarkeit/Lese-Rechte per Freigabe:

  1. Entwurf-/Freigabe-Namensräume: $wgNamespacePermissionLockdown und Lockdown verwenden, um Leserechte zu beschränken. Codebeispiel enthalten.
  2. Alternative

Fertig

Hallo Nikolaos — hier ist die kürzeste robuste Route für deine zwei Ziele (MW 1.43, SMW 5.1), jeweils mit konkreten LocalSettings.php-Snippets und Hinweisen zu Fallstricken.

1) „Systemseiten“ nur für Admins (anlegen/ändern/verschieben)

Kernprinzip: Schreibrechte pro Namensraum einschränken; Verschieben/Schützen/Löschen in diesen Namensräumen ebenfalls nur für sysop.

  • Das macht man mit $wgNamespaceProtection (Schreiben) und der Extension:Lockdown (Move/Protect/Delete je Namensraum). Beachte: $wgNamespaceProtection steuert nur Schreibaktionen, nicht Lesen. MediaWiki+1

Beispiel (LocalSettings.php)

# --- 1a) Schreibschutz für System-Namensräume ------------------------------
# MediaWiki:-Namensraum: bleibt per Core auf editinterface gesperrt.
# => Admins, die Interface (CSS/JS/JSON) ändern sollen, in die Gruppe 'interface-admin' aufnehmen.
# (Alternativ: sysop das Recht geben – eher nicht empfohlen.)
# $wgGroupPermissions['sysop']['editinterface'] = true;

# Templates
$wgNamespaceProtection[NS_TEMPLATE] = [ 'edit-template' ];
$wgGroupPermissions['sysop']['edit-template'] = true;

# Kategorien
$wgNamespaceProtection[NS_CATEGORY] = [ 'edit-category' ];
$wgGroupPermissions['sysop']['edit-category'] = true;

# Module (Scribunto)
$wgNamespaceProtection[NS_MODULE] = [ 'edit-module' ];
$wgGroupPermissions['sysop']['edit-module'] = true;

# Hilfe
$wgNamespaceProtection[NS_HELP] = [ 'edit-help' ];
$wgGroupPermissions['sysop']['edit-help'] = true;

# Hinweis: Wer diese Rechte nicht hat, kann in den genannten Namensräumen
# weder bearbeiten noch neue Seiten anlegen (Neuanlage setzt dieselben Rechte voraus).

Ergänzung für Move/Protect/Delete pro Namensraum: (Lockdown installieren)

wfLoadExtension( 'Lockdown' );

foreach ( [ NS_TEMPLATE, NS_CATEGORY, NS_MODULE, NS_HELP ] as $ns ) {
  $wgNamespacePermissionLockdown[$ns]['move']    = [ 'sysop' ];
  $wgNamespacePermissionLockdown[$ns]['delete']  = [ 'sysop' ];
  $wgNamespacePermissionLockdown[$ns]['protect'] = [ 'sysop' ];
}

# Optional: auch die zugehörigen Diskussionen nur Admin-editierbar
foreach ( [ NS_TEMPLATE_TALK, NS_CATEGORY_TALK, NS_MODULE_TALK, NS_HELP_TALK ] as $nsTalk ) {
  $wgNamespacePermissionLockdown[$nsTalk]['edit'] = [ 'sysop' ];
}
  • Doku: $wgNamespaceProtection (Schreibschutz je Namensraum) und Lockdown (Rechte je Namensraum + SpecialPages/Actions). MediaWiki+1
  • Für MediaWiki: Der Core erzwingt editinterface; seit 1.32 ist interface-admin der saubere Weg für CSS/JS/JSON. MediaWiki

2) Seiten erst nach „Freigabe“ für bestimmte Gruppen sichtbar – sonst gar nicht sichtbar

Wichtig: MediaWiki ist nicht für echte Per-Page-Leserechte gebaut; Core-Mittel verstecken Inhalte nicht wasserdicht. Sauber wird es mit Namensraum-Trennung + Lockdown oder mit einer (gut gewählten) ACL-Erweiterung. MediaWiki

Option A – Praxisfest: Entwurfs-/Privat-Namensraum + Lockdown (empfohlen)
  • Idee: Unfreigegebene Seiten liegen in einem privaten Namensraum, der nur von bestimmten Gruppen gelesen/editiert werden darf. Nach Freigabe: Seite in öffentlichen Namensraum verschieben (oder kopieren).
  • Transklusions-Lecks verhindern mit $wgNonincludableNamespaces. (Sonst könnten geschützte Seiten via {{:…}}sichtbar werden.) MediaWiki
Beispiel
# --- 2a) Entwurfs-Namensräume definieren -----------------------------------
define( 'NS_ENTWURF',       3000 );
define( 'NS_ENTWURF_TALK',  3001 );
$wgExtraNamespaces[NS_ENTWURF]      = 'Entwurf';
$wgExtraNamespaces[NS_ENTWURF_TALK] = 'Entwurf_Diskussion';

wfLoadExtension( 'Lockdown' );

# Nur Gruppe 'reviewer' darf lesen & editieren
$wgNamespacePermissionLockdown[NS_ENTWURF]['read'] = [ 'reviewer' ];
$wgNamespacePermissionLockdown[NS_ENTWURF]['edit'] = [ 'reviewer' ];
$wgNamespacePermissionLockdown[NS_ENTWURF_TALK]['read'] = [ 'reviewer' ];
$wgNamespacePermissionLockdown[NS_ENTWURF_TALK]['edit'] = [ 'reviewer' ];

# Transklusion verhindern (sonst Datenleck)
$wgNonincludableNamespaces[] = NS_ENTWURF;
$wgNonincludableNamespaces[] = NS_ENTWURF_TALK;

# Optional: Such-/Änderungslisten stärker einschränken (Titel-Leaks minimieren)
$wgSpecialPageLockdown['Search']         = [ 'user' ];     # oder 'reviewer'
$wgSpecialPageLockdown['Recentchanges']  = [ 'user' ];     # oder 'reviewer'
  • Lockdown-Doku inkl. read pro Namensraum, SpecialPageLockdown und NonincludableNamespaces. MediaWiki

Dateien schützen: Dateipfade sind sonst direkt abrufbar. Für echte Dateischutz-Prüfung die Image-Authorization (img_auth.php) aktivieren und Upload-Verzeichnis vor direktem Webzugriff schützen. MediaWiki

Option B – Feingranular pro Seite (wenn du nicht verschieben willst)

1) PageOwnership (GUI-basiert, per-Seite/-Namensraum, SMW-kompatibel)

  • Rechte pro Seite/Subseiten/Namespace an Benutzer/Gruppen vergeben; unterstützt Transklusion und SMW-Abfragen. Praktisch für „Freigabe auf der Seite setzen“. Unbedingt auf Staging testen. MediaWiki

2) Semantic ACL (per SMW-Eigenschaften)

  • Les-/Edit-Rechte mit Properties wie [[Visible to::whitelist]], [[Visible to group::…]] direkt auf der Seite steuern; blendet Inhalte in Suchen/SMW-Queries für Nichtberechtigte aus. Aber: aktuell als unmaintained markiert – Einsatz mit Vorsicht, vorab prüfen. MediaWiki

Hinweis zu SMW insgesamt: Ohne spezielle ACL-Erweiterung können semantische Abfragen Inhalte aus geschützten Seiten verraten. Semantic ACL adressiert das; der allgemeine Warnhinweis bleibt gültig. workingwithmediawiki.comMediaWiki

Zusatz: Ganzes Wiki „privat“, dann gezielt öffnen (Variante)

Wenn du grundsätzlich Login erzwingen willst:

# Anonyme dürfen nichts lesen:
$wgGroupPermissions['*']['read'] = false;

# Öffentlich sichtbare Bereiche gezielt öffnen (Lockdown):
wfLoadExtension( 'Lockdown' );
$wgNamespacePermissionLockdown[NS_MAIN]['read'] = [ '*' ];  # Beispiel
  • So vermeidest du, dass Unangemeldete überhaupt irgendetwas sehen; Sichtbarkeit gibst du pro Namensraum/Seite zurück. MediaWiki

Checkliste (kurz)

  1. Schreibschutz System-NS einrichten ($wgNamespaceProtection), MediaWiki: via interface-admin. MediaWiki
  2. Lockdown installieren; Move/Delete/Protect in System-NS auf sysop begrenzen; NonincludableNamespaces für private NS setzen; sensible SpecialPages einschränken. MediaWiki
  3. Strategie wählen:
    • A: Entwurf-NS (privat) → nach Freigabe in öffentlichen NS verschieben.
    • B: Per-Seite-ACL (PageOwnership oder Semantic ACL – mit Tests/Vorsicht). MediaWiki+1
  4. Uploads absichern (img_auth.php), sonst Dateileak trotz Seiten-Schutz. MediaWiki

Wenn du magst, passe ich dir die Snippets direkt auf deine benannten NS („AufEinWort“, „Werk“, „Erörterung“ etc.) und Gruppen („Autor“, „Leserschaft“, „Freigeber“) an – inkl. kurzer Migrationsanleitung (Entwurf → Freigabe).

Angaben zum Lösungsansatz

Nikolaos:

Ich habe infolge nun auch recherchiert.

zu 1. Ich brauche keinen Schutz für Speziel… insondern einrichten, da dies nativ bereits auf sysop begrenzt ist.

"This configuration parameter allows a wiki to require special permissions to edit some namespaces. By default, the only restriction is that the MediaWiki namespace can only be edited by users with the editinterface permission (by default: sysops)." Quelle: https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection/de

zu 2. Danke für diese Hinweise.

2.1 Ich bin derzeit der eizige user uns sysop meines SMW.

2.2 Mein MediaWiki ist bereits für nicht angemeldete User gesperrt und nur über VPN erreichbar.

Über bereits eingerichtete namespaces und permissions

Zusätzlich eingerichtete namespaces und permissions
1.  // Definition des neuen Namensraums "Werke" und seiner Talk-Seite

define('NS_WERK', 3000);

define('NS_WERK_TALK', 3001);

// Registrierung des Namensraums in MediaWiki

$wgExtraNamespaces[NS_WERK] = "Werk";

$wgExtraNamespaces[NS_WERK_TALK] = "Werk_Erörterung";

// Integration in SemanticMediaWiki: semantische Funktionen in diesem Namensraum aktivieren

$smwgNamespacesWithSemanticLinks[NS_WERK] = true;

// Optional: Suchindex aktivieren, wenn dieser Raum durchsuchbar sein soll

$wgNamespacesToBeSearchedDefault[NS_WERK] = true;

2. // Definition des neuen Namensraums "Gespräche" und seiner Talk-Seite

define("NS_GESPRAECH", 3002);

define("NS_GESPRAECH_TALK", 3003);

$wgExtraNamespaces[NS_GESPRAECH] = "Gespräch";

$wgGroupPermissions['user']['NS_GESPRAECH'] = true;

$wgExtraNamespaces[NS_GESPRAECH_TALK] = "Gespräch_Erörterung";

$wgGroupPermissions['user']['NS_GESPRAECH_TALK'] = true;

// Optional: Content Namespace (wichtig für Artikel-ähnliches Verhalten)

$wgContentNamespaces = [ NS_MAIN, NS_HELP, NS_PROJECT, NS_WERK, NS_GESPRAECH ];

// Optional: Suchindex aktivieren, wenn dieser Raum durchsuchbar sein soll

$wgNamespacesToBeSearchedDefault[NS_GESPRAECH] = true;

3.  // Optional: Semantic MediaWiki aktivieren für diesen Namespace

$smwgNamespacesWithSemanticLinks[NS_GESPRAECH] = true;

define("NS_ANMERKUNG", 3004);

define("NS_ANMERKUNG_TALK", 3005);

$wgExtraNamespaces[NS_ANMERKUNG] = "Anmerkung";

$wgGroupPermissions['user']['NS_ANMERKUNG'] = true;

$wgExtraNamespaces[NS_ANMERKUNG_TALK] = "Anmerkung_Erörterung";

$wgGroupPermissions['user']['NS_ANMERKUNG_TALK'] = true;

$smwgNamespacesWithSemanticLinks[NS_ANMERKUNG] = true;

SMW Besonderheit Kurator

$smwgEditProtectionRight = "smw-pageedit";

$wgGroupPermissions['smwcurator']['smw-pageedit'] = true;

Meine Absichten und Anforderungen

1. SMW wird für nicht angemeldete user nur stark eingeschränkt zur Nutzung freigegeben

2. Nicht angemeldete User

2.1 die üblichen Systemseiten sollen wenn für nicht angemeldete User nur lesbear sein

2.3 nicht angemeldete user sollen nur freigegebene Seiten in NS_GESPRAECH sehen, aufrufen und lesen, jedoch nicht bearbeiten können – sonst nichts machen können.

2.3 Von anderen namespaces transcludierte Inhalte sollen auch für nicht angemeldete user für freigegebene Seiten  lesbar sein

3. angemeldete User die der Gruppe smwcurator zugewiesen wurden, können bis auf sysop begrenzte Tätigkeiten alle Seiten lesen und bearbeiten

3. alle anderen angeledeten User können in allen Namespaces alle freigegebenen Seiten lesen

Ende zu "Absichten und Anforderungen"

Extension:Lockdown

ist in menem SMW installiert und aktiviert, jedoch keine weiteren Parameter eingerichtet.

Eine echte Seitenfreigabe-Funktion scheint Extension:Lockdown nicht zu haben.

Deine Aufgabenstellung

Recherchiere bitte erneut ob und wie meine Absichten und Anforderungen verwirklicherbar sind.

Umsetzbarkeit der Rechtestruktur Einrichtung vom SMW

Sophos:

Nachgedacht

Nikolaos fragt, wie seine Anforderungen in MediaWiki 1.43 und SMW 5.1 mit bestimmten Namensräumen und Gruppenberechtigungen umgesetzt werden können. Das "Lockdown"-Plugin ist installiert, aber nicht richtig konfiguriert. Lockdown wirkt auf Namensräume und Aktionen, nicht auf einzelne Seiten. Mögliche Lösungen sind Plugins wie "PageOwnership" und "AccessControl" für spezifische Seitensperren. Ich werde diese zusätzlich überprüfen.

Der Benutzer möchte bestimmte Wiki-Seiten öffentlich zugänglich machen, selbst wenn sonst Lesezugriff verweigert wird. Lockdown kann mit Namensräumen und spezifischen Benutzerrechten arbeiten, um dies zu ermöglichen. Ich muss die genaue Funktionsweise von Lockdown und SMW $smwgEditProtectionRight überprüfen, insbesondere durch die Dokumentation und spezifische Erweiterungen wie PageOwnership.

Der Benutzer möchte, dass nicht angemeldete Nutzer nur bestimmte Seiten in einem Namespace lesen können, aber transkludierte Inhalte aus anderen Namensräumen auch sichtbar sind. Dies könnte problematisch sein, da die Leseprüfungen auf die Quellseiten angewendet werden. Ich muss bestätigen, ob Lockdown eine Möglichkeit bietet, dieses Szenario zu umgehen.

Die Idee, öffentliche Inhalte in einem Namespace bereitzustellen und diese in öffentliche Seiten zu transkludieren, ist eine Möglichkeit. Doch Transklusionen respektieren standardmäßig Lesezugriffsrechte. Das gewünschte Szenario, private Inhalte für nicht angemeldete Benutzer zugänglich zu machen, würde wahrscheinlich gegen die Zugriffseinschränkungen der anderen Namensräume verstoßen.

Um das gewünschte Szenario zu ermöglichen, müssten transkludierte Seiten in einem für anonyme Benutzer lesbaren Namespace platziert werden. Alternativ könnte man mit unsicheren Hacks wie der Vorab-Renderung durch ParserCache arbeiten. Es gibt jedoch sicherere Alternativen wie "PageOwnership" oder "Cargo" für eine bessere Lösung.

Durchsuchen von MediaWiki-Dokumenten zu Lockdown und Berechtigungen

Das Ziel, bestimmte Seiten für nicht angemeldete Benutzer zugänglich zu machen, erfordert, dass die allgemeinen Lese-Rechte für alle gesperrt bleiben. Lockdown kann die Lese-Rechte für spezifische Namespaces wie "NS_GESPRAECH" aktivieren, während andere eingeschränkt bleiben. Das würde eine passende Konfiguration ermöglichen, die die Ziele erfüllt.

Überprüfen der Lockdown-Dokumentation für Namensräume

Die Dokumentation bestätigt, dass Lockdown nur Lese-Einschränkungen unterstützt und nicht gewährt. Es zeigt jedoch an, dass Lockdown Lese-Rechte für „“ innerhalb eines Namespaces gewähren kann, wenn $wgGroupPermissions['']['read'] dies ermöglicht. Allerdings muss $wgGroupPermissions['*']['read'] auf „true“ gesetzt sein, damit Lockdown Lese-Rechte gewähren kann.

Ich möchte genauer suchen, wie man mit Lockdown einige Seiten sichtbar machen kann, während das Wiki privat bleibt. Ich werde nach „Lockdown private wiki whitelist namespace“ suchen, um gezielt die nötigen Informationen zu finden. So kann ich sicherstellen, dass ich die richtige Einstellung aufgreife.

Durchsuchen der Web nach Lockdown-Whitelist für Namensräume

Ich erinnere mich, dass eine Vorlage für ein privates Wiki mit einigen öffentlichen Namespaces darin besteht, global read auf false zu setzen und über Lockdown bestimmte Seiten freizugeben. Aber die Dokumentation sagt, dass Lockdown nicht gewähren kann, wenn durch die Standard-Einstellungen ausgeschlossen. Ich brauche eine endgültige Quelle, um zu bestätigen, wie das genau funktioniert.

Es gibt einige Fehler bei den Einstellungen für benutzerdefinierte Namespaces und Berechtigungen. Zum Beispiel wird $wgGroupPermissions['user']['NS_GESPRAECH'] = true nicht das gewünschte Ergebnis erzielen, da $wgGroupPermissions mit Rechten und nicht mit Namespace-Namen arbeitet. Wir müssen also die richtigen Methoden wie $wgNamespaceProtection oder Lockdown verwenden.

Da der Wiki momentan privat ist und nur nicht-angemeldete Nutzer bestimmte Seiten lesen können, schlägt es vor, ausschließlich NS_GESPRAECH für alle lesbar zu machen, während andere NS weiterhin verbogen sind. Tatsächlich können auch Systemseiten wie „MediaWiki:“ sichtbar sein, aber das ist nicht ideal. Alles andere bleibt unsichtbar.

Die Anfrage ist etwas unklar, da „sollen wenn … nur lesbar sein“ sowohl Bezug auf Systemseiten als auch „ansonsten nichts“ besitzt. Mein Vorschlag ist, die Systemseiten generell zu verbergen und einfach den Lesebereich für NS_GESPRAECH via Lockdown zu öffnen. Gerade bei einem privaten Wiki bleibt Standard, globale Leseberechtigung zu deaktivieren.

Überprüfung von Namensräumen und Zugriffskonfigurationen

Die Verwendung von $wgWhitelistRead und $wgWhitelistReadRegexp ermöglicht es uns, spezifische Seiten oder Muster für anonyme Nutzer auf einem privaten Wiki freizugeben. Bei der Verwendung eines Regex, um das gesamte Namespace „Gespräch:“ freizugeben, sollten wir sicherstellen, dass wir die richtigen Format- und Codierungserwartungen erfüllen.

Untersuchen der Whitelist-Regex-Konfiguration in MediaWiki

$wgWhitelistReadRegexp funktioniert nur, wenn die globale Leseberechtigung auf „false“ gesetzt ist und erlaubt es, ganze Namensräume per Regex freizugeben. Allerdings blockiert die Whitelist Transklusionen von nicht freigegebenen Seiten. Ohne zusätzliche Einstellung wird ein Seiten-Transklusionsversuch abgelehnt, wenn der Namensraum nicht freigegeben ist.

Searching MediaWiki transclusion and read permissions

Um nur Seiten im Namensraum "NS_GESPRAECH" für Nicht-angemeldete Nutzer sichtbar zu machen, sollten wir die private Wiki-Einstellung beibehalten und $wgWhitelistReadRegexp verwenden, um Seiten mit "Gespräch:" freizugeben. Achten wir auf diakritische Zeichen, z.B. 'Gespräch' mit 'ä'. Wichtig ist auch, essentielle Dateien wie CSS/JS freizugeben.

Die ResourceLoader lädt CSS/JS für anonyme Nutzer in einer privaten Wiki, wenn die Seiten auf der Whitelist stehen. Zusätzlich werden die speziellen Seiten wie Special:UserLogin und Special:UserCreate für den Login freigegeben. Für smwcurator haben wir Lese- und Bearbeitungsrechte eingestellt. Andere angemeldete Nutzer können alle freigegebenen Seiten sehen, es sei denn, Lockdown oder Whitelist schränken den Zugriff ein.

Die Anforderung, dass nur "freigegebene Seiten" in allen Namespaces für andere angemeldete Benutzer zugänglich sind, deutet auf eine Seitenmodellierung hin. Wenn einiges per "Freigabe" zugänglich gemacht wird, könnte Lockdown auf Namespace-Ebene ausreichen. Um Seiten pro Seite zu kontrollieren, braucht es jedoch erweiterte ACLs.

Ich denke an zwei Erweiterungen für die pro-Seiten-ACL:

  • PageOwnership (mit SMW-Unterstützung) ermöglicht es, Lesezugriffsrechte auf Seite für spezifische Gruppen festzulegen und unterstützt Transklusion sowie das Caching.
  • PagePermissions scheint ebenfalls geeignet, aber ich möchte sicherstellen, dass es mit MW 1.43 kompatibel ist und regelmäßig gewartet wird.

Empfehlen von Konfigurationen und Erweiterungen für Wiki-Sicherheit

PagePermissions scheint gut gepflegt zu sein und bietet benutzerbezogene Zugriffssteuerung pro Seite, jedoch keine Unterstützung für Gruppen. Es listet eher einzelne Benutzer auf. Andererseits unterstützt PageOwnership sowohl Benutzer als auch Gruppen und bietet eine bessere Anpassung an Gruppen. Ich werde die Anforderungen zu SMW noch genauer betrachten.

Überprüfen von Gruppenunterstützung in PagePermissions

PageOwnership scheint gut gewartet zu werden, unterstützt SMW und Gruppen sowie die Transklusion von geschützten Inhalten. Für die Anforderung, dass anonyme Benutzer transkludierten Inhalt von anderen Namensräumen lesen können, muss auf Seitenebene explizit das 'Lesen' für alle ('*') gesetzt werden. Sonst bleibt der Inhalt unsichtbar.

Um die Anforderung zu erfüllen, könnten wir PageOwnership nutzen, um spezifische Quellseiten lesbar für alle ('*') zu markieren und sie zu transkludieren. Der Rest der NS_WERK bleibt privat. Alternativ könnte man den Inhalt in NS_GESPRAECH platzieren, um Problemen mit Namensräumen zu entgehen. Wichtig ist auch, dass SMW-Abfragen den Leseberechtigungen folgen.

Zuerst entferne ich ungültige Zeilen wie $wgGroupPermissions['user']['NS_GESPRAECH'] = true, da sie nicht korrekt sind. Dann schlage ich vor: Lockdown und $wgNamespaceProtection. Was die Bearbeitungsbeschränkungen betrifft, wird $wgNamespaceProtection verwendet, um Template, Kategorie und Modul zu schützen. Für die anonymen Lese-Beschränkungen schlagen wir eine Konfiguration vor, bei der anonyme Benutzer nur für bestimmte Bereiche Lesezugriff haben.

Wir werden weiterhin Lockdown verwenden, um das Lesen für alle anderen Namespaces auf 'Benutzer' zu beschränken, um sicherzugehen. Auch wenn "global read false" dies bereits abdeckt, bleibt diese Maßnahme bestehen. Für Transklusion: Anonyme Benutzer können Seiten in NS_GESPRAECH lesen, aber private Seiten werden blockiert, es sei denn, wir spiegeln den Inhalt in NS_GESPRAECH oder verwenden PageOwnership für den Lesezugriff.

Wir zeigen, wie man pro Seite den Lesezugriff auf '*' für ausgewählte Seiten setzt. Statt Lockdown verwenden wir $wgWhitelistReadRegexp, um bestimmte Titel auf einer privaten Wiki freizugeben. Lockdown bleibt für zusätzliche Einschränkungen, muss aber nicht für dieses Design verwendet werden. Zudem wird empfohlen, auf MW 1.43.2 zu aktualisieren, um die CVE-2025-6590-Schwachstelle zu beheben.

Fertig

Korrektur deiner bestehenden Zeilen

Zeilen wie $wgGroupPermissions['user']['NS_GESPRAECH'] = true;haben keine Wirkung: In $wgGroupPermissions stehen Rechte (z. B. read, edit), keine Namespace-Namen. Nutze stattdessen $wgNamespaceProtection (für Schreibschutz) und/oder Lockdown (für Rechte je Namespace/Spezialseite). MediaWiki+1

Ziel-Konfiguration (konkret)

1) Wiki privat halten, aber Gespräch: für Gäste sichtbar

# --- Basis: Wiki privat ------------
$wgGroupPermissions['*']['read']  = false;   # Anons sehen nichts, außer Whitelist
$wgGroupPermissions['user']['read'] = true;  # Angemeldete dürfen lesen

# --- Whitelist: erlaubte Titel/Namespaces für Anons ------------
# Ganze Namensräume via Regex freischalten:
$wgWhitelistReadRegexp = [
    '/^Gespräch:/',                               # Alle Seiten im Namespace "Gespräch"
    '/^Special:(Userlogin|CreateAccount|PasswordReset)$/',  # Login etc.
];

# Optional (Style/JS, wenn du sicher gehen willst – Beispiel Vector-2022):
$wgWhitelistRead = [
    'MediaWiki:Common.css', 'MediaWiki:Common.js',
    'MediaWiki:Vector-2022.css', 'MediaWiki:Vector-2022.js'
];

Erläuterung/Beleg: $wgWhitelistReadRegexp ist genau für dieses Szenario gedacht (privates Wiki, ganze Namespaces oder Muster freigeben) und funktioniert nur, wenn ['*']['read']=false gesetzt ist. MediaWiki

Transklusion: Anon-Leser sehen in Gespräch: nur Inhalte, die sie auch am Quell-Titel lesen dürften. Soll ein Baustein aus Werk: o. ä. öffentlich auftauchen, musst du entweder (a) diesen Baustein selbst öffentlich machen (siehe „PageOwnership“ unten) oder (b) die öffentlichen Fragmente in einen „öffentlichen“ Namespace verschieben/kopieren. MediaWiki

2) System-Namespaces nur für Admins editierbar

# --- Schreibschutz je Namespace (Anlegen/Ändern) ----------------
$wgNamespaceProtection[NS_TEMPLATE] = ['edit-template'];
$wgNamespaceProtection[NS_CATEGORY] = ['edit-category'];
$wgNamespaceProtection[NS_MODULE]   = ['edit-module'];
$wgNamespaceProtection[NS_HELP]     = ['edit-help'];

$wgGroupPermissions['sysop']['edit-template'] = true;
$wgGroupPermissions['sysop']['edit-category'] = true;
$wgGroupPermissions['sysop']['edit-module']   = true;
$wgGroupPermissions['sysop']['edit-help']     = true;

# MediaWiki:-Namespace bleibt via 'editinterface' geschützt.
# (empfohlen: interface-admins)

Schreibschutz je Namespace via $wgNamespaceProtection; MediaWiki: ist nativ auf editinterface begrenzt. MediaWiki Moves/Deletes/Protect in diesen Namespaces per Lockdown auf sysop begrenzen (optional, aber konsistent):

wfLoadExtension('Lockdown');

foreach ( [NS_TEMPLATE, NS_CATEGORY, NS_MODULE, NS_HELP] as $ns ) {
  $wgNamespacePermissionLockdown[$ns]['move']    = ['sysop'];
  $wgNamespacePermissionLockdown[$ns]['delete']  = ['sysop'];
  $wgNamespacePermissionLockdown[$ns]['protect'] = ['sysop'];
}

Lockdown setzt Rechte je Namespace/Aktion/Spezialseite; beachte, es „gewährt“ nicht gegen Core-Verbote. MediaWiki

3) Deine Gruppenlogik (smwcurator & andere Benutzer)

# Kuratoren
$wgGroupPermissions['smwcurator']['read'] = true;
$wgGroupPermissions['smwcurator']['edit'] = true;

# SMW Edit-Protection (nur für Seiten mit [[Is edit protected::true]] oder Schutz-UI):
$smwgEditProtectionRight = 'smw-pageedit';
$wgGroupPermissions['smwcurator']['smw-pageedit'] = true;

Damit können Kuratoren (außerhalb sysop-Tätigkeiten) alles lesen/bearbeiten; smw-pageedit greift nur für bewusst edit-geschützte Seiten. Semantic MediaWiki+1

Per-Seite-Freigaben & Transklusion aus „privaten“ Namespaces (Lösung)

Da du per Seite freigeben willst (inkl. transkludierbarer Stücke aus anderen Namespaces), brauchst du eine ACL-Erweiterung:

  • PageOwnership – gepflegt, GUI-basiert, unterstützt Gruppen, Transklusion und Semantic MediaWiki. Damit gibst du einzelnen Seiten (oder Seiten + Subseiten) explizite Leserechte für *, obwohl der Rest des Namespaces privat bleibt. Genau damit lässt sich deine Anforderung „Transklusion aus anderen Namespaces für Gäste sichtbar“ sicher umsetzen (nur die explizit freigegebenen Quellen werden öffentlich transkludierbar). MediaWiki Installationskern:
    wfLoadExtension('PageOwnership');
# (Rechte bleiben i.d.R. bei sysop; Verwaltung via Special:PageOwnershipPermissions)
    • Vorgehen: Quelle in Werk: öffnen → „Permissions“ → Reading → Gruppe * hinzufügen. Danach ist der Inhalt für Anons lesbar und kann in Gespräch: erscheinen.
    • Alternativ: PagePermissions (per-Seite Rechte; eher nutzerbezogen statt gruppenbasiert, aber aktiv gepflegt). Wenn du streng gruppenorientiert arbeiten willst, ist PageOwnership meist bequemer. MediaWiki

      Wichtig: Prüfe bei ACL-Erweiterungen stets gängige Umgehungswege (Transklusion, API, Diffs, Raw/Render, Vorschau, ExpandTemplates, SMW-Abfragen etc.). Die Doku listet typische Stolperfallen; teste im Inkognito-Fenster als unprivilegierter Nutzer. MediaWiki

Uploads/Dateien wirklich schützen

Wenn dein Wiki (teilweise) privat ist, Dateien dürfen nicht direkt aus /images/ vom Webserver kommen. Aktiviere img_auth.php (Uploadverzeichnis nicht öffentlich, Auslieferung über MediaWiki-Rechteschicht). MediaWikidoc.wikimedia.org

Bonus: Wenn du alles privat hältst und nur Gespräch: veröffentlichst

Du brauchst Lockdown nicht für die Anon-Freigabe; das erledigt $wgWhitelistRead(Regexp). Lockdown bleibt nützlich für Admin-Workflows (Move/Delete/Protect-Einschränkung) und zum generellen Härten (Spezialseiten limitieren). Beispiel „RecentChanges“ nur für angemeldete: $wgSpecialPageLockdown['Recentchanges'] = ['user'];

Nächste Schritte (kurz)

  1. Upgrade auf 1.43.2+ wegen CVE-2025-6590. MediaWiki
  2. Obige Whitelist-Konfig aktivieren (Gespräch:* für Anons). MediaWiki
  3. PageOwnership installieren und für gezielte Quellseiten (die du in Gespräch:* transkludierst) Reading→* setzen. MediaWiki
  4. System-Namespaces via $wgNamespaceProtection + optional Lockdown für Move/Delete/Protect. MediaWiki+1
  5. img_auth.php für Uploads. MediaWiki

Wenn du möchtest, passe ich dir das Snippet noch exakt auf NS_WERK / NS_GESPRAECH / NS_ANMERKUNG an (inkl. Sprechnamens-Regex mit „ä“) und markiere dir exemplarisch zwei Werk:-Seiten, die per PageOwnership öffentlich transkludierbar sind.

Neuer Lösungsansatz mit kompatblen Erweiterungen und Semantic ACL

Nikolaos:

Danke für dene Informationen.

Aufgrund von Inkompatibilität mit SMW kann ich an sich  nur Extension:Semantic ACL und Extension:Lockdown installieren und verwenden.

Extension:Semantic ACL ist vor 6 Tagen für SMW 5.0 und höher aktualisiert worden – dürfte somit kompatibel sein.

Für Extension:Semantic ACL wird jedoch wie folgt gewarnt "This extension turns off the parser cache for pages that have ACL permissions."

Welche Folgen hat diese Einschränkung des Pariser Cache gegebenenfalls für die allgemeine SMW Nutzung?

Sophos:

Nachgedacht

Ich denke, SMW erhält Daten beim Speichern oder Aktualisieren von Seiten. Die Extraktion erfolgt beim Parsen des Seiteninhalts, aber das Hauptparsing passiert bei der Speicherung. Ich frage mich, ob SMW neu extrahiert, wenn der Parser-Cache deaktiviert ist, und ob dies bei Transklusionen anders ist, besonders mit Zugriffskontrollen. Könnte es sein, dass SMW eine benutzerabhängige Cache-Lösung verwendet?

Normalerweise unterstützt MediaWiki Varianten des Parser-Caches mit CacheVaryOnUserSignature, aber in SMW wird der Parser-Cache oft deaktiviert, um Datenlecks zu vermeiden. Das führt zu höherem CPU-Verbrauch. Für SMW-Queries bleibt der Ergebnis-Cache davon jedoch unberührt. Wenn es um ACL-geschützte Inhalte geht, könnte es sein, dass Zugriffsberechtigungen das Caching beeinflussen.

Durchsuchen der Dokumentation zu Semantic ACL und Caching

Laut der Semantic ACL-Dokumentation wird der Parser-Cache für Seiten mit ACL-Berechtigungen deaktiviert. Die Auswirkungen: Seiten mit ACL-Eigenschaften haben keinen Parser-Cache, aber Seiten ohne diese sollten nicht betroffen sein. Es könnte auch Seiten betreffen, die Inhalte von ACL-geschützten Seiten einbinden.

Wir brauchen eine verlässliche Quelle, daher würde ich die Informationen als Inferenz kennzeichnen. Vielleicht könnten wir den Erweiterungscode auf GitHub überprüfen, um genauere Details zu finden. Ich werde nach dem Repository suchen, um sicherzugehen, dass die Infos korrekt sind.

Durchsuchen des Webs nach Semantic ACL Erweiterungdetails

Wir haben nun genug Quellen, um den Parser-Cache zu erklären. Zur Frage des Nutzers: Der Parser-Cache wird nur für Seiten mit ACL deaktiviert. Für diese Seiten bedeutet es, dass bei jeder Ansicht ein neues Parsen erfolgt, mit allen damit verbundenen Prozessen wie Template-Erweiterung, Lua-Modulen und SMW-Abfragen. Aber die Abfrageergebnisse könnten noch im Cache bleiben.

Untersuchen der Auswirkungen der Parser-Cache-Einschränkung

SMW hat seinen eigenen Abfrage-Cache, der vom Parser-Cache getrennt ist, sodass der ausgeschaltete Parser-Cache den SMW-Query-Cache nicht überschreibt. Inline-SMW-Abfragen auf Seiten ohne Parser-Cache führen bei jeder Ansicht zu neuen Ergebnissen, es sei denn, die Ergebnisse sind bereits im SMW-Cache. Die Deaktivierung des Parser-Caches beeinflusst die Job-Warteschlange eigentlich nicht, könnte aber die CPU-Auslastung durch häufigeres Parsen erhöhen.

Obwohl der Parser-Cache für anonyme Benutzer deaktiviert sein kann, können sie immer noch von CDN-Caching profitieren, es sei denn, der Inhalt unterscheidet sich je nach Berechtigung, was die Sicherheit gewährleistet. Das Deaktivieren des Parser-Caches ist die hauptsächliche Veränderung, nicht das Caching der CDN. SMW aktualisiert semantische Daten in der Regel bei Seite-Speichern, nicht bei jeder Ansicht.

Searching MediaWiki SMW update and cache behavior

Wenn der Parser-Cache deaktiviert wird, kann dies zu höheren CPU-Kosten und langsameren Seitenansichten führen. SMW-Cache kann dabei helfen. Es ist sinnvoll, nur wenige Seiten mit ACL zu versehen oder teure Abfragen über Transklusion auf öffentliche Seiten auszulagern. Eine weitere Option könnte sein, Ergebnisdaten auf einer Subseite zu speichern.

  • Dateicache: Für anonyme HTML-Seiten wäre der Dateicache relevant, aber bei einer privaten Wiki-Seite wird dieser deaktiviert.
  • Objektcache: Unverändert.
  • Lua-Modul-Bytecode-Cache: Wirkt sich nicht aus.

Ich werde die Antwort kurz und präzise auf Deutsch formulieren und gegebenenfalls eine kurze Checkliste einfügen.

  • Verlängerung ACL-Dokument: über das Deaktivieren des Parser-Caches (Website).
  • Manuelle Beschreibung: über den Parser-Cache und das vollständige Neuparsen bei Deaktivierung (Website).
  • SMW-Caching: auf Seiten und Abfrage-Caching-Einstellungen (Website).
  • Kategorie-Seitenwarnung: zur Performance- und Sicherheitsbeeinträchtigung (Website).

Die Interaktion bei Transklusion und Abfragen ist wichtig: Inline-Abfragen auf ACL-Seiten werden pro Ansicht neu berechnet, es sei denn, die Ergebnisse sind zwischengespeichert.

Auf der SMW Wiki-Seite wird erwähnt, dass die Erweiterung keine Versuche unternimmt, Transklusionen zu verhindern, was eine mögliche Einschränkung darstellt. Wenn das zutrifft, könnten Transklusionen durch die Einschränkung hindurchschlüpfen, aber eine neuere Aktualisierung könnte das Problem behoben haben. Die Erklärung bleibt: Historisch dokumentierte Einschränkung, prüfen in Ihrer Umgebung.

Fokus bleibt auf der Wirkung des Parser-Caches.

Fertig

Kurzfassung: Semantic ACL schaltet nur auf Seiten mit ACL-Eigenschaften den Parser-Cache ab. Das macht diese einzelnen Seiten teurer beim Aufruf (jede Ansicht wird frisch geparst), ändert aber nicht die Art, wie SMW seine Daten speichert/aktualisiert. Die Last spürst du v. a. auf Seiten mit vielen Templates/Lua/#ask-Abfragen – der Rest des Wikis bleibt normal gecacht. MediaWiki+1Semantic MediaWiki

Was das konkret bedeutet

  • Mehr CPU/Zeit pro View – nur auf ACL-Seiten. Ohne Parser-Cache wird bei jedem Aufruf komplett geparst (Templates expandieren, Lua ausführen, Parserfunktionen laufen, Inline-Queries auswerten). Seiten ohne ACL bleiben vom Parser-Cache bedient. MediaWikiSemantic MediaWiki
  • SMW-Datenhaltung bleibt „on save / via Jobs“. Semantic-Daten werden weiterhin beim Speichern bzw. über die Jobqueue aktualisiert – nicht bei jeder Seitenansicht. Das Abschalten des Parser-Caches erzeugt deshalb keine zusätzlichen Store-Writes, nur mehr Rechenzeit pro View. Semantic MediaWikiStack Overflow
  • Inline-#ask auf ACL-Seiten: Die Abfrage wird pro View neu evaluiert – es sei denn, du aktivierst die SMW-Query-Result-Cache. Standard ist aus; mit Cache (APCu/Memcached/Redis) reduzierst du DB-Last und Latenz. Wichtige Schalter:
    # Beispiel (wähle ein Backend, das du hast):
$smwgQueryResultCacheType = CACHE_ACCEL;   // oder CACHE_MEMCACHED / CACHE_REDIS
$smwgQueryResultCacheLifetime = 3600;      // Sekunden; 0 = bis zur Verdrängung
$smwgQueryResultCacheRefreshOnPurge = true;# &action=purge aktualisiert Ergebnisse
  • Semantic MediaWiki+2Semantic MediaWiki+2
  • Transklusion & Sicherheit: ACL-Erweiterungen, die Inhalte je nach Betrachter variieren, müssen Caching einschränken – sonst drohen Leaks (Seite für „mehr Rechte“ gecacht → später weniger Berechtigte sehen den Cache). Deshalb ist das Abschalten hier beabsichtigt. Teste trotzdem typische Wege (Transklusion, Suche, API, RecentChanges), denn page-spezifische Rechte bringen stets Performance-Trade-offs bzw. Leck-Risiken, wenn falsch konfiguriert. MediaWiki

Praxis-Tipps für dich (mit SMW 5.1 / MW 1.43)

  1. Scope klein halten: Vergib ACL nur den Seiten, die es wirklich brauchen (nicht ganze Namensräume pauschal). Dann bleibt der Effekt lokal. MediaWiki
  2. Schwere Abfragen entkoppeln: Lege teure #ask-Blöcke, die keine Rechte-Differenz brauchen, in öffentliche(gecachte) Baustein-Seiten aus und transkludiere sie in ACL-Seiten. So profitiert die teure Berechnung vom Cache. (Achte darauf, dass genau diese Quellseite öffentlich bleiben darf.) Semantic MediaWiki
  3. SMW-Query-Cache einschalten (s. oben) und ein schnelles Object-Cache-Backend konfigurieren (APCu/Memcached). Das dämpft die Mehrkosten des fehlenden Parser-Caches deutlich. Semantic MediaWiki
  4. Last realistisch einschätzen: Dein Wiki ist VPN-begrenzt und du bist (noch) einziger Sysop – die Mehrkosten sind in so einem Setup meist gut verkraftbar. (Bei späterem Publikums-Traffic zuerst die ACL-Fläche und Query-Hotspots profilen.)

Wenn du willst, stelle ich dir die konkreten Cache-Zeilen für deine Umgebung (APCu/Memcached) zusammen und markiere typische „heiße“ Seiten in Gespräch:/Werk: so, dass sie trotz ACL performant bleiben.

Nikolaos:

In meinem Fall brauchen zu Anfang alle Seiten ACL.

Im Grunde hängt es am Lektorat. Ich habe derzeit in meinem SMW etwa 29.000 Wikiseiten mit Inhalten von nur einem Wort bis zu einem Buch angelegt – jedoch sind 95% davon noch nicht korrektur gelesen und 15% der Wikiseiten enthalten vertrauliche Daten. Nach und nach kann ich erst die jeweiligen Seiten bis hin zu 80% der Wikiseiten freigeben.

Ich möchste jedoch bald bereits als Buch veröffentlichte Wikiseiten allegemeinen unangemeldeten User und zur Veröffentlichung vorbereitete Wikiseiten angeledeten User zugänglich machen.

Nutzung von Semantic ACL

Sophos:

Nachgedacht

Browsing web for Semantic ACL configuration and details

Okay, wir haben genug Quellen. Jetzt müssen wir einen Plan für die anfängliche ACL für alle Seiten vorschlagen. Da die Semantic ACL pro Seite über Eigenschaften funktioniert, benötigen wir eine Standardzugriffsrichtlinie: Standardmäßige Ablehnung („niemand“), dann weißlisten basierend auf Eigenschaften wie „Sichtbar für Gruppe“ oder „Sichtbar für“. Ich sollte die genauen Eigenschaftsnamen von Semantic ACL aufrufen.

Öffnen der Semantic ACL Seite zur Überprüfung

Okay, jetzt haben wir die genauen Eigenschaftsnamen und die Info, dass „der Parser-Cache deaktiviert wird“ und „durch Transklusionen funktioniert“. Das ist wichtig zu zitieren. Die Herausforderung: 29.000 Seiten, 95% benötigen Korrekturlesen, 15% sind vertraulich. Der Plan: Standard auf „leseverbieten“ setzen und dann mit den richtigen Semantik-ACL-Eigenschaften pro Seite steuern.

Für die „kaskadierenden“ ACLs unterstützt die Erweiterung nur Unterseiten, aber möglicherweise sind die Seiten keine Unterseiten. Eine andere Idee wäre es, die „Property Chain Lookups“ zu nutzen, falls auf einer Seite keine Einstellung vorgenommen wurde, aber das funktioniert nur für Unterseiten. Eine einfachere Lösung könnte sein, Page-Schemas oder Templates zu verwenden, um zentral ACL-Standards festzulegen.

Für das gewünschte Schema: Anfangs soll nur der smwcurator lesen können. Zustände der Veröffentlichung:

  • Öffentlich: „Visible to::public“ (überschreibt alle Verweigerungen)
  • Registriert: „Visible to::users“ (nur eingeloggte Nutzer)
  • Privat: „Visible to::whitelist“ + „Visible to group::smwcurator“ (oder nur Whitelist und kuratierte Gruppen).

Wenn die Seiten bereit sind, kann „Visible to::users“ bzw. „Visible to::public“ gesetzt werden.

Ich sollte „Editable by“ ähnlich setzen, vielleicht standardmäßig auf „Editable by::whitelist ; Editable by group::smwcurator“. Wir müssen auch die Performance besprechen: Wenn alle Seiten ACL haben, verlieren sie den Parser Cache, was die gesamte Seite bei jeder Ansicht neu parst. Bei 29k Seiten und möglicherweise nur wenigen aktiven Nutzern könnte die Performance auf einem Mac mini M1 akzeptabel sein, aber auf schwerwiegende Seiten sollten wir hinweisen und den SMW-Query-Cache aktivieren.

Ich muss den Parser-Cache für ACL-Seiten berücksichtigen, aber es gibt noch andere Caches wie den Objekt-Cache oder Message-Cache, die aktiviert werden können. Zudem könnte die Verwendung von APCu oder Memcached helfen. Eine stufenweise Rollout-Strategie wäre sinnvoll: Zuerst SemanticACL installieren, dann Templates und ACL-Einstellungen anpassen, und schließlich eine Massenbearbeitung über ReplaceText oder ein Bot durchführen. Außerdem müssen wir sicherstellen, dass gesperrte Seiten keine “count”-Daten durchlecken.

Erstellen eines Rollout-Plans für ACL-Strategien

Now that we have the necessary citations, I'll create a customized plan for the ACL setup. The goal is to configure the SemanticACL extension for a phased rollout. Initially, most pages will be restricted to the whitelist and curators. For publicly available pages, I’ll suggest the "Visible to::public" setting, and for registered users, "Visible to::users". I’ll also propose simplifying this with categories or template property mapping, leveraging their existing template.

For the ACL setup, you can use a switch template to manage visibility and edit permissions based on the "Freigabe" and "Bearbeiten" parameters. I'll suggest using the snippet to control both visibility and edit permissions. For batch setting, using the "ReplaceText" extension or category-based propagation could be explored, though the extension doesn't seem to support cascading via categories.

For pages without a "Visible to" property, it seems that if no property is present, access might be unrestricted. If I need to ensure default restrictions, we can use the template on every page. However, missing templates could expose some pages. Also, turning off parser cache for all pages might heavily impact performance.

To improve caching, using Varnish might not work well for user-specific content, but behind a VPN with low traffic, it's okay. APCu can be used for acceleration, and the ParserCache is unaffected unless it's an ACL page. For "public" pages, the ACL still affects caching, possibly turning it off, even if set to "Visible to::public."

Fertig

Verstanden, Nikolaos. Wenn alle Seiten anfangs ACL brauchen, ist Semantic ACL dafür der passende Hebel — aber dann gilt auch: alle diese Seiten verlieren den Parser-Cache. Unten bekommst du ein sauberes Setup, das

  • drei Sichtbarkeits-Stufen als ein Parameter in deiner Basis-Vorlage abbildet,
  • Kuratoren (smwcurator) alles sehen/bearbeiten lässt,
  • „öffentliche“ Seiten für Anons freigibt,
  • „angemeldete“ Seiten nur für eingeloggte User öffnet,
  • Transklusions- und Datei-Sicherheit sauber einbezieht.

Ich markiere die wichtigsten technischen Aussagen mit Quellen.

A) Wirkungen & Performance kurz

  • Semantic ACL deaktiviert den Parser-Cache auf jeder Seite, die ACL-Eigenschaften besitzt. Das ist Absicht, um keine Rechte-Leaks durch gecachte HTML-Ausgaben zu riskieren. Heißt: jede Ansicht dieser Seiten wird frisch geparst (Templates, Lua, #ask, …). MediaWiki+1
  • SMW-Datenhaltung bleibt „on-save / via Jobs“. Gegen die View-Kosten hilft der SMW Query-Result-Cache(APCu/Memcached/Redis). Aktiviere ihn, wenn du viele #ask auf ACL-Seiten hast. Semantic MediaWiki+1
  • Transklusion & Queries: Semantic ACL filtert transkludierte Inhalte und SMW-Abfragen je Betrachter; nicht Berechtigte sehen Platzhalter bzw. Ergebnisse ohne geschützte Seiten (Achtung: count ist eine Sondernummer). MediaWiki

B) Konfiguration (MW 1.43 / SMW 5.1)

1) Semantic ACL laden & Basisschalter

wfLoadExtension( 'SemanticACL' );

# Optional, wenn du Bücher als Unterseiten führst und von einem Root „vererben“ willst:
$wgSemanticACLEnableCascadingACL = true;  // dann [[Cascade permissions to subpages::1]] am Buch-Root setzen

Eigenschaften (auf der Seite einzutragen):

  • Lesen: [[Visible to:: public | users | whitelist | key ]] + [[Visible to group::Gruppe]] / [[Visible to user::User:Name]]
  • Editieren: [[Editable by:: public | users | whitelist ]] + [[Editable by group::…]] / [[Editable by user::…]] („public“ überschreibt alles; „users“ = nur eingeloggt; „whitelist“ = nur explizit genannte Nutzer/Gruppen.) MediaWiki

2) Deine Gruppenrechte

# Wiki bleibt grundsätzlich privat
$wgGroupPermissions['*']['read'] = false;

# Angemeldete dürfen lesen (Bearbeiten regelst du per ACL/Eigenschaften)
$wgGroupPermissions['user']['read'] = true;

# Kuratoren (sehen/bearbeiten alles; plus SMW-Edit-Protection)
$wgGroupPermissions['smwcurator']['read'] = true;
$wgGroupPermissions['smwcurator']['edit'] = true;
$smwgEditProtectionRight = 'smw-pageedit';
$wgGroupPermissions['smwcurator']['smw-pageedit'] = true;

(Die eigentliche Lese-/Edit-Freigabe steuerst du inhaltlich per Semantic ACL-Eigenschaften.) MediaWiki

3) SMW-Query-Cache aktivieren (dringend empfohlen)

# Wähle ein Backend, das du hast (APCu = CACHE_ACCEL, sonst Memcached/Redis):
$smwgQueryResultCacheType = CACHE_ACCEL;
$smwgQueryResultCacheLifetime = 3600;
$smwgQueryResultCacheRefreshOnPurge = true;

Semantic MediaWiki+1

4) Dateien wirklich schützen

Semantic ACL kann Platzhalter für geschützte Dateien anzeigen, verhindert aber nicht den Direktzugriff per Raw-URL. Für echte Dateischutz-Prüfungen img_auth.php nutzen (Uploads nicht web-öffentlich, Auslieferung über MediaWiki). MediaWiki+2MediaWiki+2

C) Deine drei Sichtbarkeitsstufen – als ein Vorlagen-Parameter

Du hast (fast) überall eine Standard-Vorlage drin — perfekt. Erweitere sie um z. B. Freigabe= mit Werten oeffentlich | angemeldet | intern. Die Vorlage setzt automatisch die richtigen ACL-Eigenschaften.

<!-- In deiner Basis-Vorlage, z. B. Vorlage:AufEinWortBereich -->
<!-- Standard: intern (nur smwcurator sieht/bearbeitet) -->
{{#switch: {{{Freigabe|intern}}}
 | oeffentlich =
   <!-- Öffentlich lesbar, Bearbeitung weiter kuratiert -->
   <div style="display:none">[[Visible to::public]]</div>
   <div style="display:none">[[Editable by::whitelist]] [[Editable by group::smwcurator]]</div>

 | angemeldet =
   <!-- Nur eingeloggte Leser, Kuratoren bearbeiten -->
   <div style="display:none">[[Visible to::users]]</div>
   <div style="display:none">[[Editable by::whitelist]] [[Editable by group::smwcurator]]</div>

 | intern =
   <!-- Nur Kuratoren sehen & bearbeiten -->
   <div style="display:none">[[Visible to::whitelist]] [[Visible to group::smwcurator]]</div>
   <div style="display:none">[[Editable by::whitelist]] [[Editable by group::smwcurator]]</div>
}}

Hinweise:

  • Die Properties in <div style="display:none">…</div> oder via #set verstecken die Anzeige im Output. Funktional sind sie identisch. MediaWiki
  • Transklusion: Wenn eine Gespräch:-Seite öffentlich ist, aber ein Werk:-Baustein intern bleibt, zeigt Semantic ACL dort einen Platzhalter. Möchtest du den Inhalt wirklich öffentlich sehen, gib die Quelle mindestens für users oder public frei. MediaWiki
  • Performance-Tipp: Für vielbesuchte, vollständig öffentliche Seiten kannst du die ACL-Eigenschaften ganz weglassen (Template-Branch „oeffentlich“ so ändern, dass keine Visible/Editable-Eigenschaften ausgegeben werden). Dann greift wieder der Parser-Cache. Teste das einmal — die Erweiterung deaktiviert den Cache nur, wenn ACL-Eigenschaften vorhanden sind. MediaWiki

D) Rollout mit 29 000 Seiten (praktikabel)

  1. Vorlage erweitern (wie oben) und sicherstellen, dass sie wirklich in allen Inhaltsseiten transkludiert ist. (Mit einer SMW-Suche/ReplaceText findest du Ausnahmen und fügst die Vorlage nach.)
  2. Default „intern“: Keine Änderung an den Seiten nötig — durch den Default der Vorlage sind alle sofort nur für smwcurator sichtbar/bearbeitbar.
  3. Freigaben setzen:
    • „als Buch veröffentlicht“ → |Freigabe=oeffentlich auf den betreffenden Seiten (und ihren transkludierten Quellen, soweit gewünscht).
    • „für angemeldete Leser“ → |Freigabe=angemeldet. (Massenhaft per ReplaceText, PageForms, Pywikibot o. ä.)
  4. Dateien: Bilder/Dokumente für öffentliche Bücher in eine Kategorie z. B. [[Category:PublicFiles]] und

E) Noch zwei Stolpersteine & Abhilfe

  • Zähler-Leaks: Vermeide auf öffentlichen Seiten format=count/count-Ausgaben über gemischt freigegebene Bestände, da Zähler u. U. nicht vollständig gefiltert werden. Nutze normale Ergebnislisten oder kapsle Counts in Seiten mit homogener Sichtbarkeitsstufe. MediaWiki
  • „Public“-Seiten mit Last: Wenn eine Seite wirklich öffentlich und stark frequentiert wird, entferne dort ACL-Eigenschaften (siehe oben), damit der Parser-Cache wieder greift. Für Seiten, die weiter ACL brauchen, federt der SMW-Query-Cache die Datenbanklast spürbar ab. MediaWikiSemantic MediaWiki

Wenn du möchtest, passe ich dir die Vorlage sofort auf NS_WERK / NS_GESPRAECH / NS_ANMERKUNG an (inkl. kleiner Test-Queries, die Seiten ohne Basis-Vorlage finden), und gebe dir img_auth.php-Konfig-Zeilen für deinen Server (Apache/Nginx).

Nikolaos:

zu B) 1) Semantic ACL laden & Basisschalter

habe ich so eingerichtet.

zu B) 2) Deine Gruppenrechte

hatte ich bereits so eingerichtet

zu B) 3) SMW-Query-Cache aktivieren

Derzeitig ist eingerichtet:

# $wgMainCacheType = CACHE_NONE;

$wgMainCacheType = CACHE_ACCEL;

$wgCacheDirectory = "$IP/cache";

$wgMemCachedServers = [];

falsch ist die syntax: $smwgQueryResultCacheLifetime = 3600;

richtiger ist die Syntax für eine Woche: $smwgQueryResultCacheLifetime = 60 * 60 * 24 * 7;

Letzteres ist der Default und muß nicht gesetzt werden, wenn eine Woche genügt.

Default ist: $smwgQueryResultCacheRefreshOnPurge = true;

muß daher nicht gesetzt werden. Wenn zu "false" gesetzt dann: "This means that purging the query cache is not allowed. The wiki will then retain the cache of embedded queries and their results fetched from the query engine."

Frage dazu: Sind meine ACCEL  Einstellungen richtig oder besteht da dennoch Bedarf an Änderung?

zu C) Deine drei Sichtbarkeitsstufen

Ich werde auf allen Wikiseiten je Bereich eine Vorlage je nach Art der Wikiseite haben, was viele schon haben. Diese enthält bereits folgende Abfrage:

{{#switch:{{{Güte}}}
| veröffentlicht     = [[Kategorie:AufEinWort veröffentlicht]]
| freigegeben       = [[Kategorie:AufEinWort freigegeben]]
| vollendet         = [[Kategorie:AufEinWort vollendet]]
| überarbeitet      = [[Kategorie:AufEinWort überarbeitet]]
| unüberarbeitet    = [[Kategorie:AufEinWort unüberarbeitet]]
| unvollendet       = [[Kategorie:AufEinWort unvollendet]]
| #default          = [[Kategorie:AufEinWort unüberarbeitet]]
}}

{{#switch:{{{Prüfstand}}}
| geprüft           = [[Kategorie:AufEinWort geprüft]] 
| ungeprüft         = [[Kategorie:AufEinWort ungeprüft]]
| #default          = [[Kategorie:AufEinWort ungeprüft]]
}}

Ich brauche also neben den allgemeinen Einstellungen nur je nach Güte und Prüfstand vergleichweise wie folgt vorgehen:

{{#switch:{{{Güte}}}
| veröffentlicht     = [[Kategorie:AufEinWort veröffentlicht]] [[Visible to::public]] [[Cascade permissions to subpages::1]]
| freigegeben       = [[Kategorie:AufEinWort freigegeben]] [[Visible to::user]] [[Cascade permissions to subpages::1]]
| vollendet         = [[Kategorie:AufEinWort vollendet]] [[Visible to::smwcurator]]

Da bereits vorhanden ist dies einfach zu ergänzen.

Frage dazu: ist das von mir richtig so gedacht?

zu D) Rollout mit 29 000 Seiten

da habe ich eine Rückfrage zu "SMW/replace text" und komme später darauf zurück.

Sophos:

Nachgedacht

$wgMainStashType wird oft standardmäßig auf $wgMainCacheType gesetzt. Für Konsistenz wäre es gut, sowohl auf CACHE_ACCEL oder Memcached zu setzen. APCu ist für Einzelserver geeignet, aber auch hier wichtig: es ist pro-Prozess und wird nicht zwischen jedem PHP-FPM-Prozess geteilt. Dennoch für den Benutzer, der einsame Node-VPN nutzt, ist das okay.

Bezüglich der "Visible"-Einstellung des Templates: Es sollte 'Visible to group::smwcurator' statt 'Visible to::smwcurator' sein. "user" sollte durch "users" ersetzt werden.

Die Cascade-Berechtigung funktioniert nur, wenn das Kaskadieren aktiviert ist. Ich sollte sicherstellen, dass $wgSemanticACLEnableCascadingACL auf true gesetzt ist. Außerdem sollte 'Visible to::user' in 'users' geändert werden. Für 'vollendet' erfordert es 'Visible to::whitelist' plus 'Visible to group::smwcurator'. Bei Bearbeitungsrechten würde 'Editable by group::smwcurator' plus 'Editable by::whitelist' empfohlen. Wenn ACL auf öffentlichen Seiten gesetzt wird, könnte der Parser-Cache deaktiviert werden; das sollte später entfernt werden.

Es wäre ratsam, beim Verwenden des VisualEditors auf die Sichtbarkeit von Eigenschaften zu achten und sie gegebenenfalls mit "noinclude" zu verstecken. Am besten sollte man #set anstelle von Inline-Triple-Klammern verwenden, um eine Anzeige im Kategoriebereich zu vermeiden. Für die Zitierung sollten wir weiterhin vorsichtig sein, besonders wenn aktuelle Dokumentationen notwendig sind.

Es ist wichtig, die Semantic ACL-Dokumentation zu überprüfen, insbesondere für Eigenschaften wie 'Visible to' und 'Editable by'. Auch die Cache-Verhalten, insbesondere für ACL-Seiten, sollten bestätigt werden. Die Einstellungen für SMW-Query-Cache müssen ebenfalls überprüft werden, um sicherzustellen, dass alle Werte korrekt sind. Außerdem: Bei unvollständiger APCu-Installation könnte es zu silent Fallbacks kommen.

Verifizieren von MediaWiki-Cache- und ACL-Einstellungen

Die Dokumentation zur Erweiterung "Semantic ACL" enthält die Eigenschaftsnamen und gibt an, dass "Visible to::" für zugelassene Benutzer oder Gruppen verwendet wird. Es scheint, dass die Werte 'public' und 'users' nicht explizit im Ausschnitt erwähnt sind, aber wahrscheinlich in der vollständigen Dokumentation zu finden. Ich sollte die Seite öffnen, um die Details zu überprüfen.

Öffnen der Seite für Details und akzeptierte Werte

Ich habe die korrekten Werte für "Visible to:" gefunden: 'public', 'users', 'whitelist', 'key' – also sollten wir den Benutzer darauf hinweisen, dass 'user' zu 'users' geändert werden muss. Auch "Visible to::smwcurator" muss zu "Visible to::

Überprüfen der Standardwerte für SMW-Cache-Lebensdauer

Durchsuchen der Webseite nach Lifetime-Parametern

Die Einstellungen für $wgMainCacheType=CACHE_ACCEL und $wgMemCachedServers sehen korrekt aus, falls APCu für PHP-FPM und CLI installiert ist. Ich sollte bestätigen, dass 'php -m' APCu anzeigt und mit den richtigen Parametern für den Cache arbeitet. Für bessere Performance wäre es gut, auch $wgParserCacheType und $wgSessionCacheType auf CACHE_ACCEL zu setzen. Laut der MW-Dokumentation könnte das jedoch nicht unbedingt notwendig sein.

Wenn sie CRON-Wartungsskripte über CLI ausführen und APCu verwenden, sollte apc.enable_cli aktiviert werden, um Daten zu teilen. Allerdings verwendet CLI einen separaten Prozess, bei dem das Caching nicht so wichtig ist. Für Hintergrundaufgaben ist das jedoch kein Problem und funktioniert gut mit aktivierter Option.

Viele setzen $wgMainCacheType = CACHE_NONE für CLI, weil APCu dort nicht funktioniert. Aber apc.enable_cli=1 löst das Problem. Hier eine bedingte Fallback-Lösung:

Außerdem sollte $wgUseFileCache für ACL-Seiten deaktiviert werden, da diese dynamisch sind. Verwenden Sie kein Dateicache für private Seiten!

Korrektur der Property-Namen

  • 'freigegeben' -> 'users' (nicht 'Visible to::user')
  • 'vollendet' -> 'smwcurator' (falsch)

Für „veröffentlicht“: Verwenden Sie [[Visible to::public]], aber bedenken Sie, dass bei öffentlicher Sicht der Parser-Cache für alle Seiten mit dieser Eigenschaft verliert. Ich schlag vor, ACL-Eigenschaften auf öffentlichen Seiten später zu entfernen, um den Parser-Cache zurückzugewinnen. Die Option "Editable by" hilft sicherzustellen, dass nur bestimmte Benutzer bearbeiten können.

Bei „freigegeben“/„intern“ sollten ähnliche Regeln gelten.

Aktivieren Sie das Kaskadieren von ACLs, aber seien Sie vorsichtig, da es ressourcenintensiv ist. Aufgerufen wird $wgSemanticACLEnableCascadingACL=true. Beachten Sie auch, dass die Gruppe smwcurator bereits Lesen/Schreiben-Rechte hat, während Visible to::whitelist den Zugang einschränkt.

Fertig

Super, das ist schon sehr gut vorbereitet. Ich gehe Punkt für Punkt durch und korrigiere nur das Nötige.

1) ACCEL / Caching – passt das so?

Kurz: Ja, deine Grundzeilen sind sinnvoll – mit zwei Checks.

  • $wgMainCacheType = CACHE_ACCEL; ist genau das, was MW für Single-Host empfiehlt, sofern APCu verfügbar ist. Prüfe auf dem Server, dass PHP-APCu geladen ist (und ggf. aktiviere apc.enable_cli=1, damit auch Wartungsskripte/APIs bei Bedarf profitieren). Wenn APCu fehlt, fällt MW sonst auf andere Caches zurück. MediaWiki+2MediaWiki+2
  • $wgMemCachedServers = []; bedeutet schlicht: kein Memcached – völlig ok, wenn du auf APCu setzt. MediaWiki
  • $wgCacheDirectory = "$IP/cache"; schadet nicht; MW nutzt es u. a. für Lokalisierungs-/Hilfs-Caches. MediaWiki

Optional (nicht zwingend): Du kannst Parser/Session-Cache explizit auf ACCEL setzen, aber bei 1.43 „erben“ sie ohnehin den MainCacheType.

SMW Query-Result-Cache

Setze zusätzlich (weil du viel #ask auf ACL-Seiten hast):

$smwgQueryResultCacheType = CACHE_ACCEL;        // aktiviert den SMW-Ergebnis-Cache mit APCu
# $smwgQueryResultCacheLifetime = 60 * 60 * 24 * 7; // (Default = 1 Woche)
# $smwgQueryResultCacheRefreshOnPurge = true;       // (Default)
# Optional: Nicht-eingebettete Queries länger cachen:
# $smwgQueryResultNonEmbeddedCacheLifetime = 60 * 30; // 30 Min (Default = 10 Min)

Defaults/Laufzeiten stimmen genau so, wie du sie beschrieben hast. Semantic MediaWiki+3Semantic MediaWiki+3Semantic MediaWiki+3

Mini-Checkliste für ACCEL: Auf dem Host APCu installiert? Ggf. apc.shm_size ausreichend (z. B. 128–256 MB) und falls CLI-Jobs relevant: apc.enable_cli=1. MediaWiki

2) Deine Vorlage / Stufenlogik (Güte/Prüfstand)

Die Idee ist perfekt – nur zwei kleine Korrekturen an den Property-Werten/Namen:

  • Es heißt users (Plural), nicht user.
  • Für gruppenbasierte Sichtbarkeit nutzt du zusätzlich Visible to group::… – nicht Visible to::smwcurator.
  • Kaskadierung funktioniert genau mit [[Cascade permissions to subpages::1]], aber nur, wenn du \$wgSemanticACLEnableCascadingACL = true; gesetzt hast (und beachte: etwas teurer). MediaWiki

Einsetzbares Snippet (direkt in deiner bestehenden #switch-Struktur):

{{#switch: {{{Güte}}}
| veröffentlicht =
  [[Kategorie:AufEinWort veröffentlicht]]
  [[Visible to::public]]
  [[Editable by::whitelist]] [[Editable by group::smwcurator]]
  [[Cascade permissions to subpages::1]]

| freigegeben =
  [[Kategorie:AufEinWort freigegeben]]
  [[Visible to::users]]
  [[Editable by::whitelist]] [[Editable by group::smwcurator]]
  [[Cascade permissions to subpages::1]]

| vollendet =
  [[Kategorie:AufEinWort vollendet]]
  [[Visible to::whitelist]] [[Visible to group::smwcurator]]
  [[Editable by::whitelist]] [[Editable by group::smwcurator]]

| überarbeitet =
  [[Kategorie:AufEinWort überarbeitet]]
  [[Visible to::whitelist]] [[Visible to group::smwcurator]]
  [[Editable by::whitelist]] [[Editable by group::smwcurator]]

| unüberarbeitet =
  [[Kategorie:AufEinWort unüberarbeitet]]
  [[Visible to::whitelist]] [[Visible to group::smwcurator]]
  [[Editable by::whitelist]] [[Editable by group::smwcurator]]

| unvollendet =
  [[Kategorie:AufEinWort unvollendet]]
  [[Visible to::whitelist]] [[Visible to group::smwcurator]]
  [[Editable by::whitelist]] [[Editable by group::smwcurator]]

| #default =
  [[Kategorie:AufEinWort unüberarbeitet]]
  [[Visible to::whitelist]] [[Visible to group::smwcurator]]
  [[Editable by::whitelist]] [[Editable by group::smwcurator]]
}}

Hinweise dazu:

  • Öffentliche Seiten & Performance: Solange Visible/Editable-Properties gesetzt sind, deaktiviert Semantic ACL den Parser-Cache auf dieser Seite. Wenn ein „veröffentlicht“-Artikel später wirklich uneingeschränkt öffentlich ist, kannst du die ACL-Properties dort wieder entfernen (dann greift der Parser-Cache erneut). MediaWiki
  • Transklusion: Wenn eine Gespräch:-Seite öffentlich ist, aber ein Werk:-Baustein „intern“, zeigt Semantic ACL dort Platzhalter. Willst du den Inhalt sichtbar machen, muss die Quelle zumindest users oder public sein (oder gezielt per Visible to group::…). MediaWiki
  • Verbergen der Properties im Output: Wie in der Doku empfohlen ggf. per <div style="display:none">…</div> oder {{#set: … }} kapseln, damit nichts „sichtbar“ wird. MediaWiki

3) Noch zwei praktische Tipps

  • File-Cache ausgeschaltet lassen (falls du daran dachtest): File-Cache cached HTML aggressiv und passt schlecht zu ACL-Seiten; Semantic ACL kümmert sich um den Parser-Cache, aber File-Cache würde ich in deinem Szenario nicht aktivieren. MediaWiki
  • Uploads absichern: Bleib bei img_auth.php für echte Dateischutz-Prüfung und nutze bei Bedarf \$wgSemanticACLPublicImagesCategory für gezielt öffentliche Medien. MediaWiki

Wenn du mir für „Werk/Gespräch/Anmerkung“ kurz die gewünschte Standard-Güte pro Namespace nennst, bau ich dir die Vorlage so, dass der Default je Namespace automatisch die richtige Stufe setzt (und wir nur dort überschreiben, wo abweichend). Und zu ReplaceText komme ich mit dir gern später ins Detail.

Danke für alle Hinweise.

Die Frage kamm heute auf, nun ist sie beantwortet.

Kümmern werde ich erneut darum, sobald die Kategorien und Attribute zu diesen Seiten organisiert sind, da ich auch anhand von Kategorien und Attriburten per #if Parser Abfragen dann die Rechte automatisch zuweisen kann.

{{#switch: {{{Güte|}}}
 | veröffentlicht =
   [[Kategorie:AufEinWort veröffentlicht]]
   [[Visible to::public]]
   [[Editable by::whitelist]] [[Editable by group::smwcurator]]
   [[Cascade permissions to subpages::1]]
 | freigegeben =
   [[Kategorie:AufEinWort freigegeben]]
   [[Visible to::users]]               <!-- nicht "user" -->
   [[Editable by::whitelist]] [[Editable by group::smwcurator]]
   [[Cascade permissions to subpages::1]]
 | vollendet =
   [[Kategorie:AufEinWort vollendet]]
   [[Visible to::whitelist]] [[Visible to group::smwcurator]]
   [[Editable by::whitelist]] [[Editable by group::smwcurator]]
 | überarbeitet =
   [[Kategorie:AufEinWort überarbeitet]]
   [[Visible to::whitelist]] [[Visible to group::smwcurator]]
   [[Editable by::whitelist]] [[Editable by group::smwcurator]]
 | unüberarbeitet =
   [[Kategorie:AufEinWort unüberarbeitet]]
   [[Visible to::whitelist]] [[Visible to group::smwcurator]]
   [[Editable by::whitelist]] [[Editable by group::smwcurator]]
 | unvollendet =
   [[Kategorie:AufEinWort unvollendet]]
   [[Visible to::whitelist]] [[Visible to group::smwcurator]]
   [[Editable by::whitelist]] [[Editable by group::smwcurator]]
 | #default =
   [[Kategorie:AufEinWort unüberarbeitet]]
   [[Visible to::whitelist]] [[Visible to group::smwcurator]]
   [[Editable by::whitelist]] [[Editable by group::smwcurator]]
}}

2) ACL aus vorhandenen SMW-Attributen ableiten

Wenn du bestehende Properties als Schalter verwenden willst (z. B. Freigabestufe), nutze #show—aber beachte: Werte, die du im selben Edit erst via #set setzt, sind für #show noch nicht verfügbar (erst nach Speichern/Joblauf).

{{#switch: {{#show: {{FULLPAGENAME}} | ?Freigabestufe }}
 | öffentlich = [[Visible to::public]]
 | angemeldet = [[Visible to::users]]
 | intern     = [[Visible to::whitelist]] [[Visible to group::smwcurator]]
 | #default   = [[Visible to::whitelist]] [[Visible to group::smwcurator]]
}}

3) Kaskadieren nur dort, wo sinnvoll

Wenn du ACLs vom „Buch-Root“ auf Unterseiten vererben willst, hast du zwei robuste Wege:

  • per Parameter (|kaskade=1) nur am Root setzen, oder
  • automatisch: [[Cascade permissions to subpages::1]] nur auf Seiten ohne Unterpfad. Eine einfache Heuristik:
    {{#ifeq: {{PAGENAME}} | {{BASEPAGENAME}} | [[Cascade permissions to subpages::1]] | }}

4) Zwei kleine Gotcha

  • Cache/Leistung: Jede Seite mit irgendeiner ACL-Property verliert den Parser-Cache. Für wirklich öffentliche, stark gelesene Seiten kannst du die ACL-Properties später wieder entfernen → Cache greift wieder.
  • Transklusion: Sichtbarkeit wird an der Quelle geprüft. Wenn ein öffentlicher Gespräch:-Artikel etwas aus Werk:transkludiert, muss die Quelle mindestens users (oder public) haben—sonst bleibt’s Platzhalter.

Wenn du soweit bist und die Kategorielogik steht, kann ich dir die Vorlage gern so umbauen, dass sie automatisch anhand deiner Kategorien/Properties schaltet (inkl. Fallbacks, damit nie „offen“ bleibt, was intern sein sollte).

SMW und ReplaceText suchen und ersetzen von einem Nichts

Nikolaos:

Danke, ich habe keine weiteren Fragen dazu – bitte keine weiteren  Aussagen und  Vorschläge deinerseits dazu.

Kommen wir zurück auf "D) Rollout mit 29 000 Seiten (praktikabel)"

Darin erwähnst du ich könne "Mit einer SMW-Suche/ReplaceText findest du Ausnahmen und fügst die Vorlage nach"

Wie kann ich 1. gemäß deiner Angaben mittels SMW etwas suchen das nicht ist und 2. mittels  RepaceText etwas ersetzen, daß nicht bereits da ist?

Sophos:

Nachgedacht

Die Frage ist klar: Wie findet man Seiten ohne Template in MediaWiki und Semantic MediaWiki (SMW)? Wir können eine Abfrage mit der "NOT"-Bedingung oder "-Has template::Template" verwenden, um Seiten zu finden, die kein Template haben. Eine konkrete Lösung könnte auch SMW-Abfragen sowie Werkzeuge wie PetScan oder CirrusSearch umfassen.

SMW kennt Templates nicht direkt, aber man kann Seiten mit der Eigenschaft "Has template" annotieren, meist durch eine spezielle Erweiterung (SESP). Mit dieser Erweiterung lässt sich ein Query wie [[Has template::!Template:Foo]] erstellen, um nach Seiten ohne Template zu suchen. Es gibt auch die Möglichkeit, "¬" oder "!" als Negation zu nutzen.

Um Seiten ohne ein Template zu finden, kann man in SMW [[!Has template::+]] nutzen, um Seiten ohne die Eigenschaft "Has template" zu filtern. Eine weitere Methode ist die Verwendung von CirrusSearch oder DynamicPageList. Mit insource:/{{\s*[Tt]emplate name/ kann man gezielt nach Seiten ohne bestimmte Template-Transklusion suchen.</nowiki>

Standardmäßig unterstützt MediaWiki ohne CirrusSearch keine insource-Suche oder Regex. Eine alternative Methode besteht darin, Special:WhatLinksHere zu verwenden, um Transklusionen zu finden. User haben vielleicht nicht CirrusSearch installiert, aber mit ReplaceText kann man auf Seiten ohne bestimmte Inhalte eine Bearbeitung vornehmen, auch wenn eine Negation nicht direkt möglich ist.

Um Seiten ohne ein spezifisches Template zu finden, könnte man CirrusSearch mit negativen Regex verwenden, falls verfügbar, oder "Special:WhatLinksHere". Für eine Ersetzung bietet ReplaceText die Möglichkeit, nach Vorlagen zu suchen und dann Text zu ersetzen, sofern der Text nicht bereits vorhanden ist. Man könnte auch SMW-Query- oder #ask-Abfragen nutzen, um Seiten ohne Vorlagen zu ermitteln.

Zur Suche nach Seiten ohne eine Vorlage in SMW: Man kann mit dem "Has template"-Property arbeiten und eine Abfrage mit "[[!Has template::+]]<nowiki></code>" durchführen, um Seiten ohne die spezifische Vorlage zu finden. Die Ersetzung in ReplaceText erfordert die Verwendung von regulären Ausdrücken, um Vorlagen nur an Seiten hinzuzufügen, die sie noch nicht enthalten. Fertig</blockquote>Alles klar—hier sind zwei praxistaugliche Wege, genau für deine Fragen: === 1) „Mit SMW etwas suchen, das nicht ist“ === Ohne zusätzliche Extensions „sieht“ SMW keine Vorlagentransklusionen. Einfacher Workaround: Lass '''deine Basis-Vorlage''' beim Transkludieren ein SMW-Flag setzen; dann kannst du gezielt ''Seiten ohne dieses Flag'' finden. ==== '''Schritt A – Flag in der Vorlage setzen''' ==== In die betroffene Basis-Vorlage (z. B. <code><nowiki>{{AufEinWortBereich}}) eine Zeile einfügen: [[Hat AufEinWortBereich-Vorlage::1]]

(Alternativ via #set: Hat AufEinWortBereich-Vorlage=1.)

Schritt B – Abfrage „Seiten ohne Vorlage“

Alle Seiten eines Namensraums, die das Flag nicht haben:

{{#ask:
 [[!Hat AufEinWortBereich-Vorlage::+]]
 | namespace = Werk     <!-- oder Gespräch / Anmerkung / (mehrere mit Komma) -->
 | limit = 500
 | format = table
 | mainlabel = Seite
}}

Erklärung: [[!Eigenschaft::+]] bedeutet „Seiten, die diese Eigenschaft gar nicht besitzen“. So findest du zuverlässig alle Seiten des/der Namespace(s), auf denen deine Basis-Vorlage nicht transkludiert ist.

Hinweis: Falls du das Flag neu in die Vorlage einbaust, müssen bestehende Seiten einmal neu geparst werden (Seiten aufrufen/„Purge“, oder Jobs laufen lassen), damit SMW das Flag setzt—sonst tauchen sie erst nach und nach aus den „ohne“-Listen heraus.

2) „Mit ReplaceText etwas einfügen, das noch nicht da ist“

Mit Special:ReplaceText geht das sauber per Regex (Negative Lookahead). Ziel: Nur Seiten ohne die Vorlage anfassen und dort die Vorlage oben (oder unten) einfügen.

Variante A – Vorlage oben einfügen

  • Auf Special:ReplaceText:
    • Häkchen bei „Use regular expressions“ setzen.
    • Search for (Regex): (?s)^(?!.*\{\{\s*(?:AufEinWortBereich|Template:AufEinWortBereich)\b)(.*)\z
  • Replace with: [{AufEinWortBereich|…Parameter…}} $1
  • Namespaces: nur die gewünschten (z. B. Werk, Gespräch, Anmerkung). Templates/Talk ausschließen.
  • Vorschau prüfen → ausführen.

Wie es funktioniert:

(?s) = DOTALL; ^(?!.*{{…}}) = am Anfang prüfen, dass nirgendwo im Text {{AufEinWortBereich vorkommt; (.*)\z = dann den gesamten Seiteninhalt fangen. Ersetzung: Vorlage + Zeilenumbruch + ursprünglicher Inhalt ($1).

Variante B – Vorlage unten anhängen

  • Search for: (?s)^(?!.*\{\{\s*(?:AufEinWortBereich|Template:AufEinWortBereich)\b)(.*)\z
  • Replace with: {{AufEinWortBereich|…Parameter…}}

Tipps:

  • Achte auf den exakten Vorlagennamen; die Regex oben erlaubt beide Schreibweisen ({{AufEinWortBereich… oder{{Template:AufEinWortBereich…).
  • Wenn du mehrere Basis-Vorlagen akzeptierst, erweitere die Alternativen in (?: … | … ).
  • Mach zuerst einen Dry-Run auf wenigen Seiten (z. B. nur Namespace „Werk“ und Limit/Seitenfilter), dann großflächig.

Damit hast du:

  • mit SMW [[!Eigenschaft::+]] eine zuverlässige Negativsuche („Seiten ohne Basis-Vorlage“),
  • mit ReplaceText + Regex ein massentaugliches Einfügen nur dort, wo es fehlt.
Abgerufen von „https://aufeinwort.info/w/index.php?title=Gespräch:Rechtevergabe_Semantic_MediaWiki&oldid=148769“