OptiYummy-Update 1.31 auf 1.35
Problem
Nachdem das System in der Version 1.31 fast ein Jahr lang stabil gelaufen war, änderte sich plötzlich das äußere Erscheinungsbild, ohne dass zuvor eine Änderung in der Konfiguration vorgenommen wurde. Die Rahmen des MonoBook-Design fehlten und der Navigationsbereich befand sich nicht mehr links vom Inhalt, sondern unterhalb des Seiten-Inhalts:
- Bei einem einzelnen Nutzer war dieses Problem vor einigen Monaten auch schon aufgetreten, aber nirgendwo sonst.
- Nun tritt dieses Problem permanent überall auf.
- Da die Erzeugung des Seitenquelltextes durch die Komponenten des MediaWiki-Systems selbst erfolgt (welches nicht geändert wurde) vermute ich eine Änderung auf dem Server, von dem aus die Seiten ausgeliefert werden.
- Die erste Reaktion des STRATO-Service war das Betonen der Verantwortung des Kunden für seine Web-Präsenz, im Beispiel also für die Lauffähigkeit des eigenen MediaWiki-Systems.
- Experimente mit den Original-Dateien des MonoBook-Skins konnten einen Einfluss der eigenen Anpassungen ausschließen.
- Deshalb soll das WikiSystem von Grund auf neu installiert werden. Das Einspielen der alten Inhalte nach dem vorherigen Sichern des aktuellen Zustandes sollte nach den bisherigen Erfahrungen einigermaßen problemlos gelingen.
Installation des MediaWiki-Systems mit STRATO-AppWizard
Das Web-Interface für Hosting-Pakete wird von STRATO kontinuierlich modifiziert. Diese Beschreibung entspricht dem Stand vom Dezember 2020:
- Damit eine Domain (hier: optiyummy.net) für das neue Wiki-System verwendet werden kann, darf sie nicht extern umgeleitet oder von anderen Anwendungen belegt sein! Dies ist über die Domain-Verwaltung des Webhosting-Paketes zu realisieren (interne Umleitung z.B. auf /.
- Wichtig: Es können nur Domains verwendet werden, welche bei STRATO noch nicht für die Installation eines MediaWiki verwendet wurden (Diese sind dann in der Auswahlliste gekennzeichnet durch "App ist bereits installiert" - wie man dieses Kennzeichen rückgängig macht, ist sicher ein weiteres Problem!).
- Auf der Startseite des Kundenlogin findet man unten in der Navigationsleite den Eintrag WordPress & Co.
- Nach Wählen dieser Funktion findet man in der Kategorie Community-Software die Möglichkeit zur MediaWiki-Installation.
- Die Domäne optiyummy.net wurde infolge des Einhaltens der obigen Bedingungen in der Liste zur Auswahl angeboten
- Nach dem Ausfüllen der geforderten Angaben betätigt man "Fertigstellen".
Das erstellte MediaWiki-System besitzt folgende Konfiguration:
- Version 1.35.0
- Es wurde ein Ordner "/STRATO-apps/mediawiki_11/app" angelegt (app-Ordner: Unterschied zu vorherigen Installation!)
- Danach steht ein MediaWiki-System in seiner Grundeinstellung zur Verfügung.
Wiki-System individuell konfigurieren
Man benötigt den Zugang direkt auf die Dateien des Wiki-Systems im Homeverzeichnis. Von STRATO werden für den Zugriff auf das Homeverzeichnis ein SSH-Zugang zur Verfügung gestellt:
- Server: ssh.strato.de
- Benutzername: Domän-Name (im Beispiel: www.optiyummy.net)
Vergeben von Nutzerrechten
Die folgenden Einstellungen sind in der Datei LocalSettings.php vorzunehmen, welche sich im Wiki-Verzeichnis mediawiki_11 befindet. Dazu wurde eine lokale Kopie von LocalSettings.php erzeugt. Diese wird schrittweise verändert und zum Test der Wirkung wieder per SSH in das Wiki-Verzeichnis kopiert.
Wichtig: Standardmäßig können auch anonyme Nutzer Wiki-Seiten editieren! Deshalb sollte man als erste Aktionen die Nutzerrechte ändern. Dazu ergänzt man in der Datei LocalSettings.php am Ende die Zeilen:
## Benutzerverwaltung ## Nur noch angemeldeten Benutzern das Bearbeiten erlauben $wgGroupPermissions['*']['edit'] = false; ## Neuanmeldungen verbieten $wgGroupPermissions['*']['createaccount'] = false; ## Anlegen neuer Seiten nur für angemeldete Nutzer $wgGroupPermissions['*']['createpage'] = false; ## Anlegen neuer Diskussionen nur für angemeldete Nutzer $wgGroupPermissions['*']['createtalk'] = false; ## Verstecken der Edit-Section-Links vor nichtangemeldeten Nutzern $wgDefaultUserOptions['editsection'] = false; ## Ausschalten der Links auf IP-Diskussionsseiten rechts oben $wgShowIPinHeader = false;
Es wird ein Creative Commons Lizenzmodell für die Inhalte benutzt. Zulässig ist folgende Verwertung der Inhalte:
- Verteilung: kopieren, verbreiten und öffentlich Aufführen
- Modifikation: Anpassung der Inhalte an die eigene Arbeit
- Kommerzielle Verwertung
Unter der Bedingung:
- der Namensnennung des Autors oder des Lizenzsgebers,
- ohne den Eindruck zu erwecken, bei der Verwertung Unterstützung erhalten zu haben.
Dazu sind folgenden Variablen in LocalSettings.php zu ergänzen:
$wgRightsUrl = "https://creativecommons.org/licenses/by/3.0/"; $wgRightsText = "Creative Commons"; $wgRightsIcon = "https://i.creativecommons.org/l/by/3.0/88x31.png";
Indizierung durch Suchmaschinen reglementieren
- Im MediWiki ist standardmäßig eingestellt, dass alle Suchmaschinen alle Seiten indizieren dürfen. Dafür wird in der Datei includes\DefaultSettings.php der Eintrag $wgDefaultRobotPolicy = 'index,follow'; genutzt.
- Wie dies realisiert ist, kann man sich im Browser im Quelltext der generierten Seiten anschauen. Im Beispiel werden bestimmte Spezialseiten vom MediaWiki mittels "noindex,nofollow" explizit für die Suchmaschinen verboten.
- Unabhängig davon sollte man in das Stammverzeichnis des Wiki-Systems eine Textdatei robots.txt ablegen:
- Die Suchmaschinen lesen beim Finden einer Webseite zuerst diese Datei im Stammverzeichnis der Domäne.
- In dieser Datei kann beschrieben werden, ob und wie die Suchmaschine (Robot) die Seiten erfassen darf.
- Es ist wichtig, unsinnige Robots auszusperren, um nicht unsinnigen Datenverkehr für das Wikisystem zu erzeugen.
- Für Laien ist es günstig, als Grundlage die Datei robot.txt der Wikipedia zu verwenden. Auf konkrete Verzeichnisse der Wikipedia bezogene Einträge (z.B. /wiki/) muss man löschen!
Anpassung des Erscheinungsbildes
Wahl des MonoBook-Skin
- Standardmäßig ist in der Version 1.35 der Skin "vector" eingestellt.
- Durch Änderung in LocalSettings.php kann man "monobook" wählen:
## Default skin: you can change the default skin. Use the internal symbolic ## names, ie 'monobook', 'vector': $wgDefaultSkin = "monobook";
- Ein Ausblenden von Funktionen für nichtangemeldete Nutzer wird vorläufig nicht vorgenommen!
Eigenes Logo und Favicon:
- Die erforderlichen Dateien werden per SSH in den images-Ordner kopiert.
- in LocalSettings.php wird die Zeile:
$wgLogo = [ '1x' => "$wgResourceBasePath/resources/assets/wiki.png" ];
- ersetzt durch:
## Eigenes Logo 135x135 Pixel einbinden $wgLogo = "/images/logo.gif"; $wgFavicon = "/images/favicon.ico";
- Achtung: Funktioniert nicht, da der Direktzugriff auf Dateien im image-Ordner durch .htaccess-Datei abgeblockt wird (1.35 enthält):
<IfModule rewrite_module> RewriteEngine On RewriteOptions inherit # Fix for bug T64289 Options +FollowSymLinks </IfModule>
- Ist inhaltlich zu ersetzen durch (.htaccess aus Version 1.31):
# Protect against bug 28235
<IfModule rewrite_module>
RewriteEngine On
RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]
RewriteRule . - [forbidden]
</IfModule>
Hochladen von Dateien konfigurieren
Für das Wiki-System muss man die Konfiguration der Datei-Größe und die zu verwendende Verzeichnis-Struktur über LocalSettings.php vornehmen:
- Das deaktivierte Upload:
$wgEnableUploads = false;
- wurde ersetzt durch folgende Beschreibung, welche zusätzlich die Ordnerstruktur und erlaubte Inhalte spezifiziert:
$wgEnableUploads = true; $wgMaxUploadSize = 1024*1024*200; # 200MB $wgUploadSizeWarning = 1024*1024*10; # 10MB $wgUseImageResize = true; $wgUseImageMagick = true; $wgImageMagickConvertCommand = "/usr/bin/convert"; $wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'zip', 'pdf', 'hlp', 'swf', 'wmv', 'svg' ); ## Directories images/archive, images/thumb and images/temp werden automatisch angelegt! $wgHashedUploadDirectory = false; # nicht Bilder-Verzeichnisstruktur "/a/ab/foo.png" verwenden
Maximal mögliche Dateigröße erhöhen:
- Die maximal hochladbare Dateigröße wird durch die PHP-Konfiguration des Servers festgelegt (bei STRATO im Beispiel 64MB).
- Auch ohne Zugriff auf die originale Datei php.ini kann man diesen Wert ändern (z.B. auf 200MB), indem man eine Datei php.ini mit folgendem Inhalt in das Wurzelverzeichnis des Wiki-Systems speichert (dort, wo auch LocalSettings.php liegt):
[PHP] ; Maximum size of POST data that PHP will accept. post_max_size = 200M ; Maximum allowed size for uploaded files. upload_max_filesize = 200M
Inbetriebnahme des erweiterten Editors
Seit der Version 1.18 enthält der Source-Code bereits die Extension:WikiEditor. Diese muss man in der Datei LocalSettings.php nur noch registrieren:
- Dazu ist am Ende der Datei folgende Codezeile zu ergänzen;
wfLoadExtension( 'WikiEditor' );
Uebertragen der Inhalte
Das Übertragen der gesicherten Inhalte aus dem alten Wiki-System erfolgt weitestgehend über Kommandos in der Putty-Konsole:
- Mit dem Befehl mysqldump sollte man zuerst den aktuellen Zustand der neuen, leeren Datenbank als SQL-Datei in das aktuelle Stamm-Verzeichnis des MediaWiki-Systems exportieren, damit der Ausgangszustand nach einer misslungenen Implementierung der neuen Inhalte wieder regeneriert werden kann:
mysqldump DBxx --add-drop-table -h rdbms -u BENUTZERNAME -pPASSWORT > datei.sql
- Das Exportieren der Datenbanken "beliebiger" Größe funktioniert bei STRATO inzwischen auch sehr gut innerhalb der Paketverwaltung mittels des Tools PhpMyAdmin (Aufruf mit Datenbanken und Webspaces > Datenbankverwaltung > DBxxxxxxx > PhpMyAdmin starten):
- In der Registerkarte Exportieren muss man als Export-Format SQL wählen.
- Diese Datei wird hierbei auf den lokalen PC übertragen und besitzt ungefähr die doppelte Größe, wie die mittels mysqldump erzeugte Datei.
- Man sollte auch von der neuen Datenbank mittels Exportieren in PhpMyAdmin eine SQL-Datei erzeugen (falls die mittels mysqldump erzeugte Datei nicht funktioniert).
- Die im Tool myPhpAdmin exportierte alte Datenbank wird dann für den späteren Import in die neue Datenbank benutzt.
- Vor dem Import der vorhandenen alten Datenbank in Form einer SQL-Datei sollte man die zusätzlich erforderlichen Datei-Inhalte in den neuen MediaWiki-images-Ordner kopieren:
- Dies betrifft die gesamte Datei-Struktur des alten images-Ordners. Diese kann man mittels cp-Befehl in PUTTY kopieren, nachdem man den neuen Original-images-Ordner zuvor umbenannt hat (zur Vermeidung von Namenskonflikten), z.B.:
cp -rp mediawiki_10/images STRATO-apps/mediawiki_11/app
- In Web-Interface von PhpMyAdmin sollte man vor dem Import für die neue Datenbank alle Einträge löschen (Alle Tabellen markieren und dann löschen), um einen definierten Ausgangszustand zu erhalten.
- Der Import der alten Datenbank (aus PhpMyAdmin exportiert) muss im PUTTY mittels des mysql-Befehls erfolgen:
mysql -h rdbms -u BENUTZERNAME -pPASSWORT DBxxxxxx < optiyummy_export.sql
Leider erwartet Mediawiki 1.35 für alle Tabellen-Bezeichnern der Datenbank den Prefix "xlpj_", welcher in den Tabellenbezeichnern der Version 1.31 nicht vorhanden war (also z.B. xlpj_actor anstatt actor). Zum Glück blieben die Tabellenbezeichner selbst gültig:
- Nach erfolgreichem Import der alten Datenbank erscheinen deren Tabellen in der Struktur-Ansicht von PhpMyAdmin.
- Nachdem man alle ausgewählt hat, kann man den Präfix "xlpj_" diesen markierten Tabellen-Bezeichner voranstellen.
Die Datenbank-Strukturen der Versionen 1.31 und 1.35 sind trotzdem noch unterschiedlich. Deshalb muss bei jedem MediaWiki-Update auch ein Update der Datenbank erfolgen:
- Die fehlerhaften Datenbank-Einträge für die aktuelle Version 1.31 werden durch Ausführen des Update-Script im Web-Browser generiert nach Aufruf von:
https://www.optiyummy.net/mw-config/index.php
- Bestätigen der Spracheinstellungen mit Weiter.
- Wert des $wgUpgradeKey für das vorhandene Wiki als Aktualisierungsschlüssel eingeben (ohne die ""), danach Weiter.
- MediaWiki-Tabellen aktualisieren mit Weiter bestätigen.
Danach läuft das MediaWiki wie gewünscht mit den portierten Inhalten.
