Zum Inhalt springen

Gespräch:ShortURL's 2. Versuch

aus AufEinWort, der freien Forschung

Über diese Seite Gespräch

Short URL's 2. Versuch
ChatGPT Sophos GPT-4
21. März 2025 n. Chr. erst.  
Ausgabe 00
Ausgabe 00
unüberarbeitet ungeprüft
keine Datei

Hallo Sophos, du bist MediaWiki Spezialist, Wir haben zusammen Semantic MediaWIki auf meinem Mac mini M1 Server eingerichtet. Die folgende httpd-vhost.conf wurde so wie folgt eingerichtet , weil das Mediawiki nur über VPN Wireguard vom Internet erreichbar ist und daß mittels dnsmasq als DNS-Server auf dem M1 anfragen im LAN an https://wiki.aewi.de lokal auf 192.168.2.3 dem MediaWiki Server auflöst:

<VirtualHost *:443>
    ServerAdmin webmaster@aewi.de
    ServerName wiki.aewi.de
    DocumentRoot "/Library/WebServer/Documents"

    <Directory "/Library/WebServer/Documents">
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Require all granted
    </Directory>

    # Automatische Weiterleitung zur Hauptseite von MediaWiki
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]
    RewriteCond %{REQUEST_URI} ^/$
    RewriteRule ^/?$ https://de.wikipedia.org/w/index.php? [R=301,L]

    SSLEngine on
    SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"
    SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"

    ErrorLog "/opt/homebrew/var/log/httpd/aewi.de-error_log"
    CustomLog "/opt/homebrew/var/log/httpd/aewi.de-access_log" common
</VirtualHost>

Diese Regeln sind erforderlich, damit das MediaWiki im LAN erreichbar ist. Wenn jetzt auf shortURL umgestellt wird, können die bisherigen Regeln daher nicht einfach ersetzt werden, sondern müssen diesbezüglich ergänzt werden.

Nun habe ich folgenden Fehler: Wenn ich vergleichsweise die Kategorie "SMW" mit in einer Seite anlege, ist nach dem Speichern der Seite darin index.php?title=Kategorie:Semantic MediaWiki enthalten. Es wird "index.php?title=" hinzugefügt. Das führt dazu, dass die bereits angelegte Kategorie "SMW" nicht verlinkt und eine neue Seite mit dem Titel "index.php?title=Kategorie:SMW" zur erstellen angeboten wird.

Was kann dazu führen, das jeder Kategorie sozusagen das Präfix "index.php?title=" zugefügt wird?

Sophos:

Überlegt zu Ursache des "index.php"-Problems für 22 Sekunden

  • Analyzing MediaWiki issue
  • The user is setting up Semantic MediaWiki on a Mac mini M1 with specific configuration details. They're using a VirtualHost for HTTPS, with configurations like a ServerName and DocumentRoot. The issue occurs when creating a category like 'SMW' — instead of just linking to the category, the page includes a 'index.php?title=' in the URL. This suggests an issue with short URL settings or rewrite rules. I should delve into how the URL configuration interacts with MediaWiki's category creation.
  • Investigating URL configuration issue
  • The user is facing an issue where category URLs are prefixed with "index.php?title=" instead of the expected short URL. This is likely due to an incorrect configuration in LocalSettings.php for $wgArticlePath, which might still be set to something like "index.php?title=$1". The rewrite rule may also not be correctly applied to category pages. I'll look into how $wgArticlePath should be configured, usually something like "/wiki/$1", and double-check if rewrite rules cover categories properly.

Der Fehler, dass anstatt eines „sauberen“ ShortURLs immer „index.php?title=“ vorangestellt wird, weist typischerweise darauf hin, dass die Konfiguration für ShortURLs (also sowohl in den Apache‑Rewrite-Regeln als auch in den MediaWiki‑Einstellungen) nicht vollständig oder nicht konsistent eingerichtet wurde.

Mögliche Ursachen:

  • Unvollständige Rewrite-Regeln: Deine httpd-vhost.conf enthält derzeit nur eine Rewrite-Regel, die speziell den Aufruf der Hauptseite umleitet. Damit werden jedoch nicht alle internen Wiki-Anfragen (z. B. zu Kategorien oder Artikeln) korrekt auf das Script umgeleitet. Für ShortURLs benötigst du zusätzlich eine Regel, die alle Anfragen in den entsprechenden Pfad (z. B. /wiki/…) umwandelt und an /mediawiki/index.php weiterleitet.
  • Fehlende Anpassung in LocalSettings.php: MediaWiki generiert interne Links basierend auf den Werten von Variablen wie $wgScriptPath und $wgArticlePath. Wenn diese nicht angepasst werden – beispielsweise wenn $wgArticlePath weiterhin den Standardwert "index.php?title=$1" hat – dann werden die Links auch so aufgebaut, wie du es aktuell beobachtest.

Lösungsansätze:

  1. Rewrite-Regeln ergänzen: Ergänze in deiner Apache-Konfiguration eine Regel, die Anfragen im Format /wiki/… korrekt umschreibt, zum Beispiel: apache Kopieren RewriteRule ^/wiki/(.*)$ /mediawiki/index.php?title=$1 [L,QSA]
  2. So wird z. B. eine Anfrage an /wiki/Kategorie:SMW intern an /mediawiki/index.php?title=Kategorie:SMWweitergeleitet.
  3. LocalSettings.php anpassen: Stelle sicher, dass du in deiner LocalSettings.php folgende Einstellungen vornimmst: php Kopieren $wgScriptPath = "/mediawiki";
  4. $wgArticlePath = "/wiki/$1";
  5. Damit wird festgelegt, dass die Wiki-Seiten über den /wiki/ Pfad erreichbar sind und MediaWiki intern auch ShortURLs verwendet.

Zusammenfassung:

Das Präfix „index.php?title=“ wird angehängt, weil MediaWiki aktuell die Links in der Standardform generiert. Dies passiert, wenn die Rewrite-Regeln und die MediaWiki-Konfiguration für ShortURLs nicht vollständig oder konsistent umgesetzt sind. Durch Ergänzen der notwendigen Rewrite-Regel(n) und das Anpassen der $wgArticlePath-Variable in der LocalSettings.php sollte das Problem behoben werden.

Hast du hierzu bereits Anpassungen in der LocalSettings.php vorgenommen oder weitere Rewrite-Regeln getestet?

Nikolaos:

Ich habe short URL nicht eingestellt.

Die Konfiguration von  httpd.vhosts.conf hast du mir so erstellt. Nachdem was du mir darlegst müßte dem nach der folgende Teil das Problem verursachen:

    RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]

    RewriteCond %{REQUEST_URI} ^/$

    RewriteRule ^/?$ https://de.wikipedia.org/w/index.php? [R=301,L]

Ich mutmaße, daß MediaWiki beim Speichern einer Seite zu den Links "index.php?title=" ausliest und vorn zu einem Link anfügt.

Bevor ich short URL einrichte, will ich erst diesen Fehler beheben.

In localSettings stehen folgende Einträge, die damit in Zusammenhang stehen:

$wgScriptPath = "/mediawiki";

$wgServer = "https://wiki.aewi.de";

$wgCanonicalServer = "https://wiki.aewi.de";

$wgResourceBasePath = $wgScriptPath;

2/2

Sophos:

Überlegt zur MediaWiki-Konfiguration und Rewrite-Regeln für 58 Sekunden

  • Überprüfung der URL-Konfiguration
  • Die Konfiguration in der httpd.vhosts.conf lässt vermuten, dass der Rewrite-Befehl das Problem verursacht, insbesondere mit den Weiterleitungen, die MediaWiki beim Speichern von Seiten erstellt. Es könnte sein, dass dabei immer noch die alten index.php?title=-Links entstehen. Um die Kurz-URLs zu aktivieren, möchte der Nutzer diesen Fehler beheben. Die Einträge in der LocalSettings.php(z.B. $wgScriptPath, $wgServer) scheinen gut gesetzt zu sein, aber die Kurz-URL-Konfiguration muss noch angepasst werden.
  • Fehleranalyse bei URL-Konfiguration
  • Bevor die Kurz-URL eingerichtet wird, muss der Fehler mit den Kategorie-Links behoben werden. Der Nutzer weist darauf hin, dass beim Speichern von Seiten das Präfix "index.php?title=" zu den Links kommt, statt nur "Kategorie:SMW". Die Rewrite-Regeln in der httpd.vhosts.conf betreffen nur die Root-URL, aber die generierten Links werden dennoch in dem Standardformat "index.php?title=" erstellt, weil die Kurz-URL noch nicht konfiguriert ist. Die $wgArticlePath-Einstellung erzeugt die Links in diesem Format.
  • Erklärung der MediaWiki-Linkerstellung
  • Der Nutzer erwartet scheinbar, dass die Links in einer freundlicheren Form angezeigt werden. Aber ohne die Kurz-URL-Konfiguration erstellt MediaWiki standardmäßig Links im Format "index.php?title=...". Die Umleitungsregel betrifft nur die Startseite ("/"), aber intern erzeugt MediaWiki weiterhin Links mit "index.php?title=...". Um den Fehler zu beheben, muss der Nutzer entweder die Kurz-URL einrichten oder die $wgArticlePath-Einstellung anpassen. Es handelt sich also um keine Fehlfunktion, sondern um die Standardkonfiguration von MediaWiki, wenn Kurz-URLs nicht aktiviert sind.

Die Tatsache, dass in deinen Links „index.php?title=Kategorie:SMW“ erscheint, ist das normale Verhalten von MediaWiki, wenn Short URLs (also benutzerfreundlichere URL-Formate) nicht konfiguriert sind. MediaWiki verwendet standardmäßig einen Artikelpfad, der genau diese Schreibweise generiert, sofern du in deiner LocalSettings.php nicht explizit etwas anderes definierst.

Wichtige Punkte im Detail:

  • Rewrite-Regel im VirtualHost: Die Regel apache Kopieren RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]
  • RewriteCond %{REQUEST_URI} ^/$
  • RewriteRule ^/?$ https://de.wikipedia.org/w/index.php? [R=301,L]
  • bewirkt lediglich, dass beim Zugriff auf die Root deines Domains (also „https://wiki.aewi.de/“) eine Weiterleitung zur MediaWiki-Installation erfolgt. Diese Regel greift aber nicht, wenn es um die Generierung von internen Links in den Wiki-Seiten geht.
  • Interne Linkgenerierung: MediaWiki erstellt intern Links gemäß dem Wert der Variable $wgArticlePath. Hast du keinen anderen Wert dafür gesetzt, wird standardmäßig der Wert "index.php?title=$1" genutzt. Das ist also kein Fehler, sondern die Standardkonfiguration.
  • Deine LocalSettings.php: Mit den aktuellen Einstellungen: php Kopieren $wgScriptPath = "/mediawiki";
  • $wgServer = "https://wiki.aewi.de";
  • $wgCanonicalServer = "https://wiki.aewi.de";
  • $wgResourceBasePath = $wgScriptPath;
  • wird nicht explizit ein anderer Artikelpfad definiert. Dadurch wird MediaWiki weiterhin den Standardartikelpfad verwenden und Links in der Form „index.php?title=…” erzeugen.

Zusammenfassung:

Die von dir beobachteten Links sind das erwartete Verhalten, solange Short URLs nicht eingerichtet wurden. Solltest du anstelle der „index.php?title=…“-Schreibweise lieber kürzere, sauberere URLs wünschen, müsstest du in deiner LocalSettings.php beispielsweise Folgendes setzen:

php

Kopieren

$wgArticlePath = "/wiki/$1";

und in deiner Apache-Konfiguration die entsprechenden Rewrite-Regeln ergänzen, um Anfragen an /wiki/… korrekt an /mediawiki/index.php?title=$1 weiterzuleiten.

Möchtest du diesen Standardzustand so beibehalten oder planen wir gemeinsam den Schritt zur Einrichtung von Short URLs?

Nikolaos:

ich habe nun "$wgArticlePath = "/wiki/$1";" hinzugefügt und das Verhalten, welches für mich ein Fehler war, ist nun weg.

Sophos:

Nachgedacht für 10 Sekunden

  • Bestätigen der Lösung
  • Super, es scheint, dass das Hinzufügen von "$wgArticlePath = "/wiki/$1";" das Problem mit den langen URLs behoben hat und nun die kurzen Links richtig generiert werden, ohne das "index.php?title=" Präfix.
  • Braucht der Nutzer noch Unterstützung oder ist alles jetzt in Ordnung? Wenn es noch etwas gibt, lass es mich wissen!

Das klingt super! Durch die Änderung von

php

Kopieren

$wgArticlePath = "/wiki/$1";

weist du MediaWiki an, die internen Links in der kürzeren Form zu generieren, sodass nicht mehr der Standardpfad "index.php?title=" verwendet wird. Damit ist der Fehler, den du beobachtet hast, behoben.

Falls du später doch auf Short URLs umstellen möchtest, müssten noch entsprechende Rewrite-Regeln in der Apache-Konfiguration ergänzt werden, damit Anfragen an /wiki/… korrekt an /mediawiki/index.php?title=$1 weitergeleitet werden.

Hast du noch weitere Fragen oder benötigen wir noch weitere Anpassungen?

Nikolaos:

Für short URL ist in httpd.conf folgendes eingestellt:

LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so

In LocalSettings.php müßte ich für Short URL's nur noch $wgUsePathInfo = true;  einfügen – richtig?

Wie muß jedoch die Konfiguration des folgenden Block in httpd.vhots.conf eingerichtet werden:

    RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]

    RewriteCond %{REQUEST_URI} ^/$

    RewriteRule ^/?$ https://de.wikipedia.org/w/index.php?

Die Funkton dieser Weiterleitung soll wegen der DNSmasq Einstellung, daß Anfragen an https://wiki.aewi.de im Lan verarbeitet werden ja so bleiben.

Sophos:

Reasoned about short URL configuration für 51 Sekunden

  • Configuring short URLs and redirection
  • The user wants to set up short URLs while maintaining DNSmasq redirection for LAN requests. To enable short URLs in MediaWiki, setting $wgUsePathInfo = true in LocalSettings.phpshould be enough.
  • For the block in httpd.vhosts.conf, consider a rule like this to support both short URLs and the redirection:
  • This ensures both functionality works.
  • Configuring short URLs with redirection
  • The user already has a redirection rule in httpd.vhosts.conf for the root URL to /mediawiki/index.php. However, they want to enable short URLs with $wgUsePathInfo = true. To keep the redirection working and add short URL functionality, the configuration should include:
  • This ensures both redirection and short URL support.
  • Configuring short URLs with path info
  • To handle short URLs with $wgUsePathInfo = true, the configuration should include:
  • This ensures short URLs like /wiki/SomeArticlecorrectly map to /mediawiki/index.php/SomeArticle. The root redirection can stay as is, but consider using a relative redirect for consistency.

Die Einstellung

php

Kopieren

$wgUsePathInfo = true;

in deiner LocalSettings.php ist genau richtig, um MediaWiki dazu zu bringen, den übergebenen PATH_INFO-Teil zu interpretieren – also damit Anfragen über Short URLs verarbeitet werden. Gleichzeitig hast du bereits den Block für die Root-Weiterleitung, der aufgrund der DNSmasq-Konfiguration gewünscht ist.

Damit du aber auch die internen Wiki-Seiten via Short URL erreichst, benötigst du in der Apache-Konfiguration einen zusätzlichen Rewrite-Eintrag, der alle Anfragen, die mit „/wiki/“ beginnen, an das MediaWiki-Script mit PATH_INFO weiterleitet. Ein typisches Beispiel wäre:

apache

Kopieren

RewriteEngine On

# Weiterleitung von https://wiki.aewi.de/ zur MediaWiki-Startseite

RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]

RewriteCond %{REQUEST_URI} ^/$

RewriteRule ^/?$ /mediawiki/index.php [R=301,L]

# Rewrite-Regel für Short URLs: Alle Anfragen unter /wiki/ werden an index.php mit PATH_INFO weitergeleitet

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^wiki/(.*)$ /mediawiki/index.php/$1 [L,QSA]

Erklärung im Detail:

  • Root-Weiterleitung: Der erste Block bleibt weitestgehend unverändert. Er sorgt dafür, dass ein Aufruf von https://wiki.aewi.de/(also der Root) an /mediawiki/index.php weitergeleitet wird. So wird deine DNSmasq-Konfiguration nicht beeinträchtigt.
  • Rewrite-Regel für Short URLs: Die zusätzliche Rewrite-Regel sorgt dafür, dass alle Aufrufe, die mit /wiki/ beginnen (z. B. /wiki/Kategorie:SMW), an /mediawiki/index.php/<Rest> weitergeleitet werden. Dabei sorgt der angehängte Pfad (das $1) dafür, dass MediaWiki den Titel korrekt als PATH_INFO erhält. Die Bedingungen apache Kopieren RewriteCond %{REQUEST_FILENAME} !-f
  • RewriteCond %{REQUEST_FILENAME} !-d
  • verhindern, dass bestehende Dateien oder Verzeichnisse (zum Beispiel Bilder oder CSS-Dateien) ebenfalls umgeschrieben werden.

Zusammengefasst:

  • In LocalSettings.php:
    • Setze $wgUsePathInfo = true;
    • Stelle sicher, dass du auch $wgArticlePath = "/wiki/$1"; definiert hast.
  • In httpd.vhosts.conf:
    • Lasse die bestehende Root-Weiterleitung, um DNSmasq-bezogene Zugriffe korrekt zu behandeln.
    • Füge zusätzlich eine Rewrite-Regel hinzu, die alle /wiki/… Anfragen an /mediawiki/index.php/$1weiterleitet.

Mit dieser Konfiguration wird der gewünschte Effekt erzielt: Deine Root-Weiterleitung bleibt bestehen, und die Short URL-Funktionalität wird vollständig aktiviert.

Ist das in etwa, was du erreichen möchtest?

Nikolaos:

Ich habe deine Konfiguration entsprechend übernommen. Das MediaWiki ist nicht mehr online erreichbar. Gebe ich im Browser "https://wiki.aewi.de" ein, werde ich zu einer leeren Seite an "https://wiki.aewi.de/wiki/Hauptseite" weitergeleitet. Was ist falsch?

Sophos:

Nachgedacht für 57 Sekunden

  • Analyzing redirect issue
  • The user reports that after updating the configuration, entering "https://wiki.aewi.de" redirects to "https://wiki.aewi.de/wiki/Hauptseite" but the page is blank. Seems like there's an issue with the Apache rewrite rules in the VirtualHost configuration. They mention using a root redirect and a new rule for "/wiki/" rewriting. I need to check the previous configuration block to see if there's a conflict or missing setting. Let’s analyze the rules carefully to figure out what might be wrong.
  • Untersuchung der Umleitungsprobleme
  • Ich schaue mir das Rewrite der URL an und denke, dass es möglicherweise mit dem Einsatz von PATH_INFO statt Query-Parametern zu tun hat. In der ursprünglichen Regel wird für /wiki/ ein PATH_INFO-Verfahren benutzt, aber vielleicht funktioniert das nicht wie erwartet, falls PHP PATH_INFO nicht unterstützt. Das könnte zu einem leeren Bildschirm führen. Alternativ könnte es auch eine Umleitungsschleife geben, da die Hauptseite als "Hauptseite" umgeleitet wird, was eine weitere Verarbeitung auslöst.
  • Fehleranalyse für Umleitungsproblem
  • Die Umleitung scheint aufgrund des PATH_INFO-Ansatzes nicht korrekt zu funktionieren, wenn PHP die Pfadinformationen nicht richtig verarbeitet. Ein möglicher Fehler könnte darin liegen, dass Apache oder PHP den PATH_INFO nicht weitergibt, falls "AcceptPathInfo" nicht aktiviert ist. Die einfachere Lösung könnte sein, die Rewrite-Regel auf die Query-String-Methode umzustellen, also:
  • Das könnte helfen, das Problem mit der leeren Seite zu lösen.

Wenn du nach der Umstellung eine leere Seite erhältst und die URL in etwa so aussieht:

arduino

Kopieren

https://wiki.aewi.de/wiki/Hauptseite

und intern zu

bash

Kopieren

/mediawiki/index.php/Hauptseite

umgeschrieben wird, liegt das Problem sehr wahrscheinlich daran, dass dein Webserver (oder PHP) den PATH_INFO-Teil nicht korrekt übergibt. Das heißt, MediaWiki erhält nicht die Information, welcher Artikel (hier "Hauptseite") geladen werden soll.

Zwei Ansätze zur Behebung:

  1. PATH_INFO korrekt unterstützen: Wenn du den Ansatz mit $wgUsePathInfo = true; beibehalten und die Rewrite-Regel in der Form apache Kopieren RewriteRule ^wiki/(.*)$ /mediawiki/index.php/$1 [L,QSA]
  2. nutzen möchtest, musst du sicherstellen, dass dein Apache/PHP PATH_INFO unterstützt. Oft hilft es, in deinem VirtualHost (oder in einer passenden Directory-Direktive) folgende Zeile hinzuzufügen: apache Kopieren <Directory "/Library/WebServer/Documents/mediawiki">
  3.     AllowOverride All
  4.     Require all granted
  5.     AcceptPathInfo On
  6. </Directory>
  7. Dadurch wird Apache angewiesen, den zusätzlichen Pfad (also "/Hauptseite") an die index.php weiterzureichen.
  8. Rewrite-Regel auf Query-String umstellen: Alternativ kannst du den Rewrite so anpassen, dass der Artikelname als Query-Parameter übergeben wird. Dazu änderst du die Rewrite-Regel in: apache Kopieren RewriteRule ^wiki/(.*)$ /mediawiki/index.php?title=$1 [L,QSA]
  9. Und in deiner LocalSettings.php solltest du dann auch $wgUsePathInfo = false; belassen (oder diesen Eintrag entfernen), denn dann wird MediaWiki den Titel über den Query-Parameter (title) auslesen.

Zusammengefasst:

Der leere Seiteninhalt entsteht, weil der übergebene PATH_INFO-Teil („/Hauptseite“) nicht verarbeitet wird. Entweder aktivierst du AcceptPathInfo On für den MediaWiki-Ordner, oder du passt die Rewrite-Regel an, sodass der Artikelname als Query-Parameter übermittelt wird.

Welche Variante für dich in Frage kommt, hängt davon ab, ob du lieber den PATH_INFO-Ansatz nutzen möchtest oder auf den Query-String umsteigen willst. Hast du schon in deinen Apache-Logs nach Fehlermeldungen gesucht? Das könnte weitere Hinweise liefern.

Nikolaos:

Alle verschiedenen Konfigurationen, die wir ausprobiert haben funktionieren nicht.

Versuchen wir es mit .htaccess. Gebe mir bitte die Informationen und alle Anweisungen die ich benötige um die .htaccess Datei anzulegen, ihr Rechte zu vergeben und sie in das httpd Konzept einzubinden.

Sophos:

Reasoned about .htaccess setup and configuration für 16 Sekunden

  • Bedenken zur .htaccess-Konfiguration
  • Ich muss hier sicherstellen, dass ich alle wichtigen Schritte zur Verwendung der .htaccess-Datei für den Apache-Server bei einer MediaWiki-Installation abdecke. Dazu gehören das Erstellen der Datei, das Festlegen der richtigen Berechtigungen und das Einfügen in die Konfiguration des httpd. Außerdem muss ich die Anweisungen zur Aktivierung von .htaccess und den Modifikationen für VirtualHosts (wie AllowOverride All) bieten. Ich werde auch den chmod-Befehl erwähnen, um die Berechtigungen korrekt zu setzen.
  • Anleitung zur .htaccess Konfiguration
  • Um MediaWiki mit kurzen URLs via .htaccess zu konfigurieren, muss ich folgende Schritte umfassen:
  • Sicherstellen, dass mod_rewrite aktiviert ist (LoadModule rewrite_module ...).
  • Die .htaccess-Datei im MediaWiki-Verzeichnis erstellen (z. B. /Library/WebServer/Documents/mediawiki).
  • Inhalt der .htaccess: RewriteEngine On, dann Rewrite-Regeln für kurze URLs wie Umleitungen und Regel für den Zugriff auf index.php.
  • Rechte setzen: chmod 644 .htaccess.
  • In der Apache-Konfiguration AllowOverride Allfür das Verzeichnis sicherstellen.
  • Apache neu starten und ggf. Fehlerprotokolle prüfen.

Hier eine umfassende Anleitung, wie du .htaccess für Short URLs mit MediaWiki einsetzen kannst:

1. Voraussetzungen

  • mod_rewrite aktivieren: Stelle sicher, dass in deiner Apache-Konfiguration das Rewrite-Modul geladen ist. apache Kopieren LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so
  • AllowOverride aktivieren: Damit Apache .htaccess-Dateien beachtet, musst du im entsprechenden <Directory>-Block (z. B. im DocumentRoot) AllowOverride All aktivieren. Beispiel in deiner httpd.conf oder in der VirtualHost-Konfiguration: apache Kopieren <Directory "/Library/WebServer/Documents">
  •     Options Indexes FollowSymLinks MultiViews
  •     AllowOverride All
  •     Require all granted
  • </Directory>

2. .htaccess Datei anlegen

  1. Datei erstellen: Lege im Verzeichnis an, in dem du die Rewrite-Regeln einsetzen möchtest. – Falls deine MediaWiki-Installation in /Library/WebServer/Documents/mediawiki liegt und du die Regeln nur für MediaWiki anwenden willst, erstelle die .htaccess dort. – Alternativ kannst du die .htaccess auch im DocumentRoot (/Library/WebServer/Documents) ablegen und die Regeln so formulieren, dass sie nur für die entsprechenden URLs greifen.
  2. Dateiinhalt: Hier ein Beispiel, das die Weiterleitung von /wiki/… Anfragen über den Query-Parameter abwickelt – das vermeidet PATH_INFO-Probleme: apache Kopieren RewriteEngine On
  4. # Weiterleitung der Root-URL an die MediaWiki-Startseite
  5. RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]
  6. RewriteCond %{REQUEST_URI} ^/$
  7. RewriteRule ^/?$ /mediawiki/index.php [R=301,L]
  9. # Rewrite-Regel für Short URLs: Leite /wiki/XYZ an index.php?title=XYZ weiter,
  10. # sofern die Datei oder das Verzeichnis nicht existiert.
  11. RewriteCond %{REQUEST_FILENAME} !-f
  12. RewriteCond %{REQUEST_FILENAME} !-d
  13. RewriteRule ^wiki/(.*)$ /mediawiki/index.php?title=$1 [L,QSA]
  14. Hinweis: Wenn du Short URLs über PATH_INFO (also /mediawiki/index.php/XYZ) nutzen möchtest, müsstest du statt des Query-Strings $wgUsePathInfo = true; in LocalSettings.php aktivieren und die Rewrite-Regel dementsprechend anpassen. Da wir aber hier den Query-Parameter nutzen, bleibt $wgUsePathInfo auf dem Standardwert (also false).
  15. .htaccess Rechte setzen: Wechsle in das Verzeichnis, in dem die .htaccess liegt, und setze die Berechtigungen so, dass der Webserver sie lesen kann. Zum Beispiel: bash Kopieren chmod 644 .htaccess
  16. Diese Einstellung gibt dem Besitzer Lese-/Schreibrechte und allen anderen nur Leserechte.

3. Apache-Konfiguration neu laden

Nachdem du die Änderungen vorgenommen hast, starte Apache neu, damit die neuen Einstellungen übernommen werden:

bash

Kopieren

sudo apachectl restart

oder (je nach System)

bash

Kopieren

sudo systemctl restart httpd

4. MediaWiki LocalSettings.php anpassen

Stelle sicher, dass in deiner LocalSettings.php folgende Zeilen gesetzt sind:

php

Kopieren

$wgScriptPath = "/mediawiki";

$wgArticlePath = "/wiki/$1";

$wgServer = "https://wiki.aewi.de";

$wgCanonicalServer = "https://wiki.aewi.de";

$wgResourceBasePath = $wgScriptPath;

Da du die Rewrite-Regel so konfiguriert hast, dass der Artikelname als Query-Parameter übergeben wird, ist es nicht erforderlich, $wgUsePathInfo zu aktivieren.

5. Testen und Fehlersuche

  • Browser-Test: Rufe https://wiki.aewi.de auf. Du solltest auf die MediaWiki-Startseite weitergeleitet werden. Anschließend sollten Seiten wie https://wiki.aewi.de/wiki/Hauptseite korrekt geladen werden.
  • Apache-Logs überprüfen: Falls weiterhin Probleme auftreten, schaue in die Error-Logs von Apache (z. B. in /opt/homebrew/var/log/httpd/aewi.de-error_log), um Hinweise zu erhalten.

Diese Anleitung fasst alle nötigen Schritte zusammen, um .htaccess in dein httpd-Konzept einzubinden, die Datei korrekt anzulegen und zu konfigurieren. So kannst du Short URLs (in diesem Fall via Query-Parameter) in deiner MediaWiki-Installation realisieren, ohne auf PATH_INFO angewiesen zu sein.

Funktioniert das so für dich, oder gibt es noch weitere Fragen bzw. Probleme?

Nikolaos:

Ich kann doch auch anstelle von "$wgArticlePath = "/wiki/$1";" dann auch "$wgArticlePath = "/$1";" einstellen, da ich wiki ja bereits als subdomain habe – oder?

Sophos:

Nachgedacht für 10 Sekunden

  • Explaining article path configuration
  • The user is asking if they can set $wgArticlePath = "/$1" instead of $wgArticlePath = "/wiki/$1" because they already have "wiki" as a subdomain. Yes, in principle, that works. However, you’ll need to adjust the rewrite rules in Apache. The URL will have to be rewritten from /Titel to index.php?title=Title. Make sure your .htaccess rules reflect this setup for smooth operation. If done correctly, the slash after the domain might not be needed, since the subdomain handles the path.
  • Erklärung zur Artikelpfad-Konfiguration
  • Ja, da du einen Subdomain wie wiki.aewi.de verwendest, kannst du $wgArticlePath auf "/$1" einstellen, sodass Artikel wie https://wiki.aewi.de/Hauptseite angezeigt werden. Allerdings muss die Umleitungsregel in Apache oder .htaccess entsprechend angepasst werden. Wenn du .htaccess verwendest, musst du Anfragen von der Root-Ebene umschreiben, zum Beispiel mit:
  • Wichtig: Achte darauf, dass statische Dateien ausgeschlossen werden.

Ja, das ist grundsätzlich möglich. Da du wiki.aewi.de als Subdomain nutzt, kannst du in der LocalSettings.php den Artikelpfad auch so einstellen:

php

Kopieren

$wgArticlePath = "/$1";

Dann würden z. B. Seiten so aussehen:

arduino

Kopieren

https://wiki.aewi.de/Hauptseite

Wichtige Punkte, die du dabei beachten musst:

  • Rewrite-Regeln anpassen: Da sich der Artikelpfad ändert, musst du auch die Rewrite-Regeln (egal ob in .htaccess oder in der Apache-Konfiguration) entsprechend anpassen, damit Anfragen an „/Hauptseite“ korrekt an dein MediaWiki weitergeleitet werden. Beispiel in einer .htaccess-Datei (im DocumentRoot oder im MediaWiki-Verzeichnis): apache Kopieren RewriteEngine On
  • # Leite die Root-URL an die MediaWiki-Startseite weiter
  • RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]
  • RewriteCond %{REQUEST_URI} ^/$
  • RewriteRule ^/?$ /mediawiki/index.php [R=301,L]
  • # Rewrite-Regel für Short URLs: Leite alle Anfragen (außer existierende Dateien/Verzeichnisse) an index.php?title=… weiter
  • RewriteCond %{REQUEST_FILENAME} !-f
  • RewriteCond %{REQUEST_FILENAME} !-d
  • RewriteRule ^(.*)$ /mediawiki/index.php?title=$1 [L,QSA]
  • Statische Ressourcen: Achte darauf, dass statische Dateien (Bilder, CSS, JS etc.) nicht von der Rewrite-Regel betroffen sind. Dafür helfen die Bedingungen !-f und !-d, die verhindern, dass bereits existierende Dateien und Verzeichnisse umgeschrieben werden.
  • LocalSettings.php anpassen: Neben $wgArticlePath sollten auch folgende Einstellungen stimmen: php Kopieren $wgScriptPath = "/mediawiki";
  • $wgServer = "https://wiki.aewi.de";
  • $wgCanonicalServer = "https://wiki.aewi.de";
  • $wgResourceBasePath = $wgScriptPath;

Wenn diese Anpassungen vorgenommen werden, kannst du die saubereren URLs nutzen, die direkt unter der Subdomain liegen.

Funktioniert das so für dich?

Nikolaos:

Wo stelle ich wie sicher, daß nun .htaccess auch ausgelesen wird. Wie muß nun httpd.vhosts.conf eingerichtet werden?

Was muß ich für  .htaccess hinzufügen, wenn ich folgendes habe:

<VirtualHost *:443>

    ServerAdmin webmaster@aewi.de

    ServerName wiki.aewi.de

    DocumentRoot "/Library/WebServer/Documents"

    <Directory "/Library/WebServer/Documents">

        Options Indexes FollowSymLinks MultiViews

        AllowOverride All

        Require all granted

    </Directory>

    SSLEngine on

    SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"

    SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"

    ErrorLog "/opt/homebrew/var/log/httpd/aewi.de-error_log"

    CustomLog "/opt/homebrew/var/log/httpd/aewi.de-access_log" common

</VirtualHost>

Sophos:

Rationalisiert über .htaccess und Apache-Konfiguration für 15 Sekunden

  • Analyzing .htaccess settings
  • Die Frage zur Sicherstellung, dass die .htaccess-Datei ausgelesen wird, hängt von der Einstellung der Direktive AllowOverride ab – sie muss auf "All" gesetzt sein, wie im Beispiel des VirtualHost. Die httpd.conf oder httpd.vhosts.conf muss richtig konfiguriert werden, damit .htaccess-Regeln übernommen werden. Es ist wichtig, sicherzustellen, dass der Directory-Schutz korrekt eingerichtet ist. Insgesamt sollte man darauf achten, die richtigen Berechtigungen und Konfigurationen zu setzen.
  • Vergewissern, dass .htaccess gelesen wird
  • In der VirtualHost-Konfiguration ist bereits „AllowOverride All“ im <Directory>-Block gesetzt, was sicherstellt, dass .htaccess-Dateien gelesen werden. Es ist wichtig, die richtigen Dateiberechtigungen für die .htaccess-Datei im DocumentRoot zu überprüfen. Wenn MediaWiki im „/mediawiki“-Verzeichnis installiert ist, sollte .htaccess entweder dort platziert oder der DocumentRootangepasst werden. Die Rewrite-Regeln im .htaccess müssen aktiviert werden, zum Beispiel für kürzere URLs von MediaWiki. Die Konfiguration scheint korrekt, solange „AllowOverride All“ in der Directory-Anweisung bleibt.

Hier eine Schritt-für-Schritt-Anleitung, um sicherzustellen, dass Apache deine .htaccess-Datei ausliest und wie du deine VirtualHost-Konfiguration sowie die .htaccess einrichtest:

1. Sicherstellen, dass .htaccess ausgelesen wird

  • AllowOverride All: In deinem VirtualHost-Block hast du bereits einen Directory-Abschnitt für dein DocumentRoot definiert: apache Kopieren <Directory "/Library/WebServer/Documents">
  •     Options Indexes FollowSymLinks MultiViews
  •     AllowOverride All
  •     Require all granted
  • </Directory>
  • Durch die Direktive AllowOverride All erlaubst du, dass in diesem Verzeichnis (und seinen Unterverzeichnissen) alle .htaccess-Dateien und deren Anweisungen (z.B. Rewrite-Regeln) gelesen und angewendet werden.
  • Mod_rewrite aktivieren: Stelle sicher, dass das Rewrite-Modul geladen ist (wie in deiner Konfiguration durch den Eintrag LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so). Ohne dieses Modul werden Rewrite-Regeln in .htaccess nicht verarbeitet.
  • Dateiberechtigungen: Die .htaccess-Datei sollte in dem Verzeichnis liegen, in dem du die Rewrite-Regeln anwenden möchtest (z. B. im DocumentRoot oder im Unterordner, in dem MediaWiki liegt) und vom Webserver lesbar sein. Ein üblicher Berechtigungswert ist: bash Kopieren chmod 644 /Library/WebServer/Documents/.htaccess

2. VirtualHost-Konfiguration (httpd.vhosts.conf)

Deine VirtualHost-Konfiguration sieht grundsätzlich korrekt aus. Hier noch einmal der relevante Ausschnitt:

apache

Kopieren

<VirtualHost *:443>

    ServerAdmin webmaster@aewi.de

    ServerName wiki.aewi.de

    DocumentRoot "/Library/WebServer/Documents"

    <Directory "/Library/WebServer/Documents">

        Options Indexes FollowSymLinks MultiViews

        AllowOverride All

        Require all granted

    </Directory>

    SSLEngine on

    SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"

    SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"

    ErrorLog "/opt/homebrew/var/log/httpd/aewi.de-error_log"

    CustomLog "/opt/homebrew/var/log/httpd/aewi.de-access_log" common

</VirtualHost>

  • Wichtig: Da AllowOverride All gesetzt ist, wird Apache .htaccess-Dateien im DocumentRoot und allen Unterverzeichnissen berücksichtigen. Es ist also nicht nötig, spezielle Anweisungen in der VirtualHost-Konfiguration selbst hinzuzufügen, um .htaccess zu aktivieren.

3. Beispiel .htaccess für MediaWiki Short URLs

Wenn du MediaWiki mit Short URLs betreiben möchtest (z. B. mit $wgArticlePath = "/$1";), kannst du folgende .htaccess-Datei im DocumentRoot ("/Library/WebServer/Documents") oder in einem entsprechenden Unterverzeichnis anlegen:

apache

Kopieren

RewriteEngine On

# Weiterleitung der Root-URL an die MediaWiki-Startseite

RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]

RewriteCond %{REQUEST_URI} ^/$

RewriteRule ^/?$ /mediawiki/index.php [R=301,L]

# Rewrite-Regel für Short URLs: Leite alle Anfragen, außer es handelt sich um existierende Dateien oder Verzeichnisse, an MediaWiki weiter.

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)$ /mediawiki/index.php?title=$1 [L,QSA]

Erläuterungen:

  • Root-Weiterleitung: Damit wird sichergestellt, dass der Zugriff auf https://wiki.aewi.de (also Root) automatisch an die MediaWiki-Startseite weitergeleitet wird.
  • Rewrite-Regel für Short URLs: Alle Anfragen, die nicht auf eine vorhandene Datei oder ein Verzeichnis zeigen, werden an /mediawiki/index.phpmit dem Query-Parameter title weitergereicht. Das funktioniert gut mit deiner Einstellung $wgArticlePath = "/$1"; in der LocalSettings.php.

4. Weitere Schritte

  1. .htaccess anlegen:
    • Lege im gewünschten Verzeichnis (z. B. /Library/WebServer/Documents/) eine Datei namens .htaccessan.
    • Füge den oben gezeigten Inhalt ein.
  1. Berechtigungen setzen: Stelle sicher, dass die Datei lesbar ist: bash Kopieren chmod 644 /Library/WebServer/Documents/.htaccess
  3. Apache neu starten: Damit alle Änderungen wirksam werden, starte Apache neu: bash Kopieren sudo apachectl restart
  4. (oder, falls dein System systemd nutzt, sudo systemctl restart httpd)
  5. Testen: Rufe https://wiki.aewi.de in deinem Browser auf.
    • Solltest du über die .htaccess richtig weitergeleitet werden und deine MediaWiki-Seiten (wie z. B. https://wiki.aewi.de/Hauptseite) korrekt angezeigt werden, ist alles richtig eingerichtet.

Mit diesen Schritten stellst du sicher, dass .htaccess von Apache ausgelesen wird und deine VirtualHost-Konfiguration die nötigen Voraussetzungen dafür bietet. Hast du noch weitere Fragen oder Probleme?

Nikolaos:

muß .htaccess im Verzeichnis /Library/WebServer/Documents oder im Verzeichnis /Library/WebServer/Documents/mediawiki liegen?

Sophos:

Reasoned about .htaccess placement für 16 Sekunden

  • Überlegungen zur .htaccess-Platzierung
  • Es kommt darauf an, wie du die Umschreiberechte einrichten möchtest. Wenn dein DocumentRoot /Library/WebServer/Documents ist und du die kurzen URLs umschreiben möchtest, sollte die .htaccess-Datei in diesem Verzeichnis liegen, damit die Regel für eingehende URLs von dort angewendet wird. Falls du jedoch nur das Umschreiben für MediaWiki auf /Library/WebServer/Documents/mediawiki anwenden möchtest, platzierst du sie dort mit entsprechenden Regeln. Normalerweise wird sie jedoch im DocumentRoot platziert.
  • Platzierung der .htaccess bei Short URLs
  • Die .htaccess-Datei sollte im DocumentRoot (/Library/WebServer/Documents) liegen, wenn du Short URLs wie https://wiki.aewi.de/Hauptseiteverwenden möchtest. Das hängt mit der Tatsache zusammen, dass die Regel beim Zugriff auf den DocumentRoot angewendet wird. Im umgekehrten Fall, wenn du nur URLs innerhalb des /mediawiki-Verzeichnisses umschreiben willst, könnte die .htaccess auch dort stehen. In unserem Fall ist jedoch der DocumentRoot am sinnvollsten, weil er die gesamten URL-Anfragen auf die MediaWiki-Installation umleitet.

Das hängt davon ab, welche URL-Struktur du erzielen möchtest:

  • .htaccess im DocumentRoot (/Library/WebServer/Documents): Wenn du Short URLs direkt unter deiner Subdomain (also z. B. https://wiki.aewi.de/Hauptseite) nutzen möchtest, muss die .htaccess im DocumentRoot liegen. Dort wird die Rewrite-Regel alle Anfragen abfangen und, sofern keine echte Datei oder ein echtes Verzeichnis existiert, an /mediawiki/index.php?title=$1 weiterleiten.
  • .htaccess im MediaWiki-Verzeichnis (/Library/WebServer/Documents/mediawiki): Würde die .htaccess nur in diesem Unterverzeichnis liegen, würden die Rewrite-Regeln nur für URLs greifen, die bereits den Pfad /mediawiki/ beinhalten. Das ist meist nicht gewünscht, wenn du saubere URLs ohne den Medienpfad in der URL haben möchtest.

Für dein Setup, bei dem du die Domain wiki.aewi.de als Subdomain nutzt und die URLs direkt von dort lesen möchtest, empfiehlt es sich, die .htaccess im DocumentRoot zu platzieren. So wird sichergestellt, dass alle Anfragen wie https://wiki.aewi.de/Hauptseite korrekt verarbeitet und an die MediaWiki-Installation weitergeleitet werden.

Hast du weitere Fragen dazu?

Nikolaos:

Folgende Regel wurde in httpd-vhosts.conf noch hinzugefügt:

RewriteEngine On

    RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]

    RewriteCond %{REQUEST_URI} ^/$

    # RewriteRule ^/?$ /mediawiki/index.php [R=301,L]

    RewriteRule ^/?$ https://de.wikipedia.org/w/index.php? [R=301,L]

Soll diese bestehen bleiben?

Sophos:

Reasoned about Apache rewrite rules für 26 Sekunden

  • Überprüfen der Rewrite-Regel
  • Die Regel, die hier hinzugefügt wurde, bedeutet: Wenn der Host der URL wiki.aewi.de ist und die Anfrage-URI nur das Root-Verzeichnis („/“) ist, wird eine permanente Weiterleitung (301) zu https://de.wikipedia.org/w/index.php? durchgeführt. Ob diese Regel bestehen bleiben sollte, hängt davon ab, ob der Benutzer diese Art von Weiterleitung wirklich möchte. Wenn ja, ist sie korrekt, sonst könnte sie entfernt oder angepasst werden.
  • Überprüfen der Weiterleitungsregel
  • Die Weiterleitungsregel im httpd-vhosts.confsorgt dafür, dass Anfragen an den Root-Tag "/" zu https://de.wikipedia.org/w/index.phpweitergeleitet werden. Diese Regel ist sinnvoll, wenn man den Zugriff auf die Hauptseite von MediaWiki über die Domain genießen möchte. Wenn jedoch die .htaccess-Datei bereits eine Umleitung für "/" beinhaltet oder weiterführende Regeln existieren, könnte die Regel im VirtualHost redundant sein. Bei einem konsistenten URLs könnte diese Regel entbehrlich sein; andererseits bietet sie eine klare Weiterleitung zur MediaWiki-Hauptseite.

Die Regel sorgt dafür, dass bei Aufruf von „https://wiki.aewi.de“ (also der Root der Subdomain) automatisch zur MediaWiki-Installation weitergeleitet wird – in deinem Fall zu „https://de.wikipedia.org/w/index.php?“. Wenn das auch dein gewünschtes Verhalten ist, solltest du die Regel beibehalten.

Hinweise:

  • Redirection vs. interner Rewrite: Diese Regel löst eine externe Weiterleitung (301 Redirect) aus. Das bedeutet, dass der Browser die URL ändert. Falls du stattdessen eine unsichtbare, interne Weiterleitung möchtest, müsstest du auf den Redirect-Flag verzichten. Für deine DNSmasq-Konstellation und den gewünschten Zugang im LAN ist der externe Redirect meist unproblematisch.
  • Konsistenz im Setup: Da du mit .htaccess bereits Rewrite-Regeln für die Short URLs einrichtest, solltest du prüfen, ob die Root-Weiterleitung nicht doppelt definiert wird. Oft ist es sinnvoll, die Weiterleitung an einer zentralen Stelle (z. B. in der VirtualHost-Konfiguration) zu belassen, um sicherzustellen, dass der Zugang zur Startseite immer konsistent erfolgt.

Fazit:

Wenn du weiterhin möchtest, dass beim Aufruf von „https://wiki.aewi.de“ die Besucher automatisch zur MediaWiki-Startseite weitergeleitet werden, solltest du diese Regel in der VirtualHost-Konfiguration stehen lassen. Andernfalls – falls du diesen Redirect ausschließlich über .htaccess steuern möchtest – könntest du ihn aus der VirtualHost-Konfiguration entfernen, wobei du darauf achten musst, dass die .htaccess-Datei korrekt gelesen wird.

Passt das so zu deinen Anforderungen?

Nikolaos:

Mit der neuen Regel aus .htaccess müßte wenn die Weiterleitung zu "https://wiki.aewi.de/Hauptseite" erfolgen oder?

Sophos:

Reasoned about .htaccess rule behavior für 22 Sekunden

  • Überprüfen der .htaccess-Weiterleitung
  • Der Nutzer fragt, ob bei der neuen .htaccess-Regel die Weiterleitung wirklich zu "https://wiki.aewi.de/Hauptseite" führt. Ich verstehe die Frage so: Wenn eine Weiterleitung durch die neue Regel erfolgt, sollte sie tatsächlich diese URL ansprechen. Um das zu bestätigen, müssen wir die Details der Regel überprüfen. Falls die Regel kurze URLs umschreibt, müsste sie bei der Anfrage für "Hauptseite" zur richtigen URL führen. Wichtig ist, genau zu wissen, wie diese Regel formuliert ist.
  • Überprüfen der .htaccess-Regeln
  • Die aktuelle .htaccess-Regel definiert, dass Anfragen an die Root-URL an "/mediawiki/index.php" weitergeleitet werden. Sie umfasst außerdem ein Regel für die interne Umleitung von kürzeren URLs wie "Hauptseite". Der Nutzer fragt, ob die Weiterleitung mit der neuen Regel zur URL "https://wiki.aewi.de/Hauptseite" führen sollte. Tatsächlich sorgt die Regel für eine Umleitung der Root-URL nach MediaWiki und behandelt Weiterleitungen für Artikel wie "Hauptseite" durch interne Umleitungen, ohne die URL im Browser zu ändern.

Ja, genau. Mit der neuen .htaccess-Regel – vorausgesetzt, du hast in der LocalSettings.php $wgArticlePath = "/$1";eingestellt – sollte der Aufruf von „https://wiki.aewi.de/Hauptseite“ intern so umgeschrieben werden, dass MediaWiki den Artikel „Hauptseite“ lädt, während in der Adresszeile der saubere Pfad erhalten bleibt.

Dabei wirkt die Rewrite-Regel für alle Anfragen, die keiner existierenden Datei oder keinem existierenden Verzeichnis entsprechen, und leitet sie intern an /mediawiki/index.php?title=$1 weiter. Dadurch wird der Short URL-Effekt erzielt, ohne dass der Standardpfad (index.php?title=) in der URL angezeigt wird.

Kurz zusammengefasst:

  • Der Root-Aufruf (nur „https://wiki.aewi.de“) wird extern per Redirect auf die Startseite weitergeleitet (wie in deiner VirtualHost-Konfiguration).
  • Alle weiteren Aufrufe wie „https://wiki.aewi.de/Hauptseite“ werden intern umgeschrieben, sodass der Artikel „Hauptseite“ geladen wird, während die URL im Browser unverändert bleibt.

Passt das zu deinen Erwartungen?

Nikolaos:

Jetzt habe ich https://wiki.aewi.de/Seitenname. Der Fehler bestand die ganze Zeit darin keine .htaccess Datei anzulegen. Auch Die Regel daß "https://wiki.aewi.de" auf "https://wiki.aewi.de/Hauptseiete" weiterleitet geht nun. Kategorien lassen sich nun ohne einen Zusatz wie "index.php?title=" anlegen.

Sophos:

Rücksichtnahme auf die Konfiguration für 6 Sekunden

  • Bestätigen der Lösung
  • Es scheint, dass der Nutzer nun vorankommt. Der Fehler war, wie er sagt, das Fehlen einer .htaccess-Datei. Jetzt funktioniert die Weiterleitungsregel von „https://wiki.aewi.de“ auf „https://wiki.aewi.de/Hauptseite“ wie gewünscht. Außerdem können Kategorien jetzt problemlos angelegt werden, ohne den Zusatz „index.php?title=“. Das ist großartig, wenn alles nun wie erwartet funktioniert und die Rewrite-Regeln richtig umgesetzt sind. Es hört sich so an, als ob das Problem jetzt behoben ist!

Das ist großartig zu hören! Es freut mich, dass jetzt alles wie gewünscht funktioniert – kurze URLs, die Weiterleitung auf die Hauptseite und auch die Kategorieerstellung ohne den Zusatz „index.php?title=…“. Falls du noch weitere Fragen oder Anpassungen benötigst, stehe ich gern zur Verfügung.

Nikolaos:

Nun löst jedoch Wireguard VPN ttps://wiki.aewi.de/Seitenname nicht mehr auf. wg0 ist am start.

Die folgende Konfiguration wirkt sich offenbar über VPN global aus, da auch hops://pma.aewi.de nicht mehr über VPN erreichbar ist:

RewriteEngine On

# Leite die Root-URL an die MediaWiki-Startseite weiter

RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]

RewriteCond %{REQUEST_URI} ^/$

RewriteRule ^/?$ /mediawiki/index.php [R=301,L]

# Rewrite-Regel für Short URLs: Leite alle Anfragen (außer existierende Dateien/Verzeichnisse) an index.php?title=… weiter

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)$ /mediawiki/index.php?title=$1 [L,QSA]

Sophos:

**Reasoned about VPN and URL resolution** für 23 Sekunden

  • Analyzing Wireguard VPN issue
  • It looks like the .htaccess configuration could be interfering with the VPN access by rewriting requests to the MediaWiki index. The rule for redirecting requests to /mediawiki/index.php?title=$1 could be blocking or altering the way URLs are resolved vs trying to access via the VPN.
  • Since it affects links globally (like pma.aewi.de), it's likely the rewrites are overriding expected URL resolutions. I’d suggest reviewing these rules, perhaps easing redirection for VPN connections.
  • Considering .htaccess rewriting conflict
  • The rewrite rule in .htaccess seems to apply to all requests, not just wiki.aewi.de, which might be interfering with other domains like pma.aewi.de. Since the second rewrite doesn't include a host condition, it applies globally, even affecting non-Wiki subdomains using the same DocumentRoot. To fix this, I suggest adding conditions to restrict rewrites to wiki.aewi.de. You could add a condition for HTTP_HOST, or move .htaccess into the mediawiki folder if only that should apply.

Das Problem liegt daran, dass deine Rewrite-Regeln in der .htaccess aktuell global auf alle Anfragen angewendet werden – also auch für andere Subdomains wie pma.aewi.de. Das passiert, weil die zweite Rewrite-Regel keine Einschränkung auf den HTTP_HOST enthält.

Um das zu beheben, musst du sicherstellen, dass die Regel für die Short URLs nur für Anfragen an wiki.aewi.de gilt. Das erreichst du, indem du auch dort eine RewriteCond hinzufügst:

apache

Kopieren

RewriteEngine On

# Leite die Root-URL an die MediaWiki-Startseite weiter (nur für wiki.aewi.de)

RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]

RewriteCond %{REQUEST_URI} ^/$

RewriteRule ^/?$ /mediawiki/index.php [R=301,L]

# Rewrite-Regel für Short URLs: nur für wiki.aewi.de

RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)$ /mediawiki/index.php?title=$1 [L,QSA]

Mit dieser Anpassung greift die Rewrite-Regel für Short URLs nur, wenn der HTTP_HOST wiki.aewi.de ist. Somit wird der Rewrite nicht global angewendet und andere Subdomains (wie hops.aewi.de oder pma.aewi.de) bleiben davon unberührt – auch über dein Wireguard-VPN.

Falls du weitere Fragen hast oder noch etwas unklar ist, lass es mich gerne wissen.

Nikolaos:

Danke. muß man httpd neu starten, damit diese zusätzliche condition greift?

Sophos:

Nachgedacht für ein paar Sekunden

  • Erklären der Notwendigkeit eines Neustarts
  • Wenn die .htaccess-Datei geändert wird, ist normalerweise kein Neustart von Apache (httpd) erforderlich, da diese Datei bei jeder Anfrage gelesen wird. Es gibt jedoch Ausnahmen, zum Beispiel bei Änderungen an der VirtualHost-Konfiguration oder der httpd.conf-Datei — in diesem Fall muss ein Neustart durchgeführt werden. In deinem Fall, wenn du nur die .htaccess-Datei anpasst, ist kein Neustart notwendig. Bei Änderungen an der Hauptkonfiguration braucht es jedoch einen Neustart.

Nein, für Änderungen in der .htaccess-Datei ist in der Regel kein Neustart des Apache-Servers erforderlich, da diese Datei bei jedem Request neu eingelesen wird. Nur wenn du Änderungen an der Hauptkonfiguration (z. B. httpd.conf oder VirtualHost-Dateien) vornimmst, ist ein Neustart notwendig.

Nikolaos:

Es war ein Neustart erforderlich.

Sophos:

Reasoned about .htaccess and Apache configuration für 6 Sekunden

  • Erklären von Apache Neustart
  • Ich muss in diesem Fall erklären, dass ein Neustart von Apache manchmal nötig ist, etwa wenn sich der Zugriff auf .htaccess-Dateien ändert oder der Server Konfigurationsänderungen nicht automatisch übernimmt. Normalerweise liest Apache die .htaccess bei jedem Request ein. Doch je nach Server-Konfiguration oder Caching kann ein Neustart erforderlich sein. In deinem Fall war das der Fall, aber generell erfordert eine Änderung an .htaccess nicht immer einen Neustart.

Das ist eher ungewöhnlich, denn normalerweise werden Änderungen an der .htaccess bei jedem Request neu eingelesen. In deinem Fall war offenbar aufgrund von Caching oder einer spezifischen Serverkonfiguration ein Neustart notwendig, um die zusätzlichen Bedingungen zu übernehmen. Es kann also nicht generell ausgeschlossen werden, dass ein Neustart erforderlich ist, wenn sich die Konfiguration ändert.

Nikolaos:

Coaching wäre möglich, vielleicht habe ich nicht genügend Seiten oder Funktionen ausgeführt, um das Coaching neu zu laden., ein Grund an sich, warum ich den M1 lieber bei Änderungen neu starte, als nur einen Dienst zu Restarten. Nur Änderungen in der LocalSettings.php wirken sich an sich unmittelbar aus, wenn dann mum nman nur das Cache der jeweiligen Wikiseite durch reload löschen.

Sophos:

Razoniert über .htaccess und VPN-Konfiguration für 5 Sekunden

  • Überlegungen zum Coaching
  • Also, der User spricht darüber, dass Coaching grundsätzlich möglich ist, aber möglicherweise nicht genug Seiten oder Funktionen ausgeführt wurden, um es neu zu laden. Er bevorzugt es, den M1 nach Änderungen neu zu starten, anstatt nur einen Dienst neu zu starten. Nur Änderungen in der LocalSettings.php wirken sich sofort aus, und dann muss nur der Cache der jeweiligen Wiki-Seite durch ein Reload gelöscht werden. Klingt nach einer praktischen Herangehensweise, um sicherzustellen, dass alles richtig funktioniert.
  • Das ist ein interessanter Punkt. In der Theorie sollten Änderungen an der .htaccess sofort greifen, weil sie bei jedem Request neu eingelesen wird. Allerdings können auf einem System wie dem M1 – je nach Caching oder speziellen Konfigurationseinstellungen – manchmal nicht alle Änderungen direkt wirksam werden. Daher kann es sein, dass du durch einen kompletten Neustart sicherstellst, dass alle Dienste und Caches geleert werden.

Im Gegensatz dazu werden Änderungen in der LocalSettings.php von MediaWiki direkt bei der nächsten Anfrage angewendet (abgesehen von eventuell internem Caching), sodass hier oft nur ein Neuladen der Seite oder ein manuelles Leeren des Caches notwendig ist.

Wenn du also den kompletten Neustart bevorzugst, um sicherzugehen, dass alle Änderungen global übernommen werden, ist das durchaus ein vernünftiger Ansatz.

Nikolaos:

Der M1 braucht etwa 2 Minuten für einen Restart – das kann man getrost in Kauf nehmen.

Sophos:

Nachgedacht für einige wenige Sekunden

  • Anerkennend antworten
  • Okay, der User erwähnt, dass der M1 ungefähr 2 Minuten für einen Neustart braucht und das akzeptiert. Wenn das für sie in Ordnung ist, dann kann ich das bestätigen. Eine mögliche Antwort könnte sein: "Wenn das ein akzeptabler Zeitrahmen ist, ist das durchaus akzeptabel. Manchmal ist ein kompletter Neustart wirklich die sicherste Methode, um sicherzustellen, dass alle Änderungen korrekt übernommen werden. Es kann auch sinnvoll sein, einen festen Prozess dafür zu haben, vor allem bei häufigen Konfigurationsänderungen."

Das ist eine durchaus vernünftige Herangehensweise – wenn ein kompletter Neustart von etwa 2 Minuten für dich in Ordnung ist, dann ist es eine zuverlässige Methode, um sicherzustellen, dass alle Änderungen in der Konfiguration vollständig übernommen werden. Auf Systemen wie dem M1, wo manchmal Caches oder spezielle Einstellungen eine sofortige Übernahme der .htaccess-Änderungen verhindern können, ist ein kompletter Neustart oft die sicherste Option.

Nikolaos:

Danke soweit. Nun kümmern wir uns im nächsten Chat darum wie man in SMW das Semantic Glossary an den Start bekommt.

Sophos:

Razoniert über SMW Semantic Glossary für 13 Sekunden

  • Preparing for next chat
  • Die Benutzerin/der Benutzer hat mich darüber informiert, dass wir im nächsten Chat das "Semantic Glossary" in SMW besprechen werden. Es scheint keine direkte Frage zu sein, sondern eher ein Hinweis auf das Thema, das behandelt wird. Hmm, also sollte ich darauf eingehen, indem ich mich darauf freue, das Thema zu besprechen. Eine mögliche Antwort könnte sein: „Gerne, das klingt spannend. Wir können das Semantic Glossary in SMW besprechen!“ So klingt es positiv und hilfsbereit. Auch passt die Antwort zum Gesprächsverlauf.

Alles klar, das klingt nach einem spannenden nächsten Schritt. Ich freue mich darauf, dir im nächsten Chat dabei zu helfen, das Semantic Glossary in SMW zu aktivieren und zu konfigurieren. Bis dahin!

Abgerufen von „https://aufeinwort.info/w/index.php?title=Gespräch:ShortURL%27s_2._Versuch&oldid=257879“