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 nach den automatisch generierten Einstellungen die folgenden Zeilen (eventuell bereits vorhandene Variablenzuweisungen werden damit überschrieben - es wirkt der jeweils letzte Wert!)

##----------------------------------------------------------
## 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: Darstellung dieser Bilder 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

Achtung: An dieser Stelle mussten später zusätzliche Optionen gesetzt werden. Siehe unten bei nachträgliche Anpassungen.

Maximal mögliche Dateigröße erhöhen:

• Die maximal hochladbare Dateigröße wird durch die PHP-Konfiguration des Servers festgelegt (bei STRATO im Beispiel zur Zeit 128MB).
• Auch ohne Zugriff auf die originale Datei php.ini kann man diesen Wert ändern (z.B. auf 400MB), 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 = 400M
; Maximum allowed size for uploaded files.
upload_max_filesize = 400M

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

• Update vom 14.01.2023: Leider geht der Datenbank-Export inzwischen nicht mehr so einfach! Eine Fehlermeldung weist darauf hin, dass man dafür eine Process-Berechtigung benötigt:

 Warning: Using a password on the command line interface can be insecure.
 mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump table spaces

• Das Exportieren der Datenbanken "beliebiger" Größe funktioniert aber 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.
  • 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

• Update vom 14.01.2023: Zum Glück funktioniert der Datenbank-Import immer noch so einfach (Weil große Datenbanken mit PhpMyAdmin nicht importiert werden können!), Nur eine Warnung weist auf die unsichere Verwendung des Passwortes hin:

 Warning: Using a password on the command line interface can be insecure.

Leider erwartet Mediawiki 1.35 für alle Tabellen-Bezeichnern der Datenbank einen bei der Installation zufällig generierten Prefix (im Beispiel: "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 (z.B. "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.35 werden durch Ausführen des Update-Script im Web-Browser generiert nach Aufruf von:

 https://www.optiyummy.net/mw-config/index.php 

1. Bestätigen der Spracheinstellungen mit Weiter.
2. Wert des $wgUpgradeKey für das vorhandene Wiki als Aktualisierungsschlüssel eingeben (ohne die ""), danach Weiter.
3. MediaWiki-Tabellen aktualisieren mit Weiter bestätigen.

Danach läuft das MediaWiki wie gewünscht mit den portierten Inhalten.

HitCounters-Extension installieren

Da der HitCounter bereits beim Update auf die MediaWiki-Version 1.31 installiert wurde, existieren die erforderlichen, zusätzlichen Datenbank-Einträge bereits. Deshalb muss nur die aktuelle Version der HitCounter-Extension wieder installiert werden:

• Dazu wurde die aktuelle stabile Version der Extension:HitCounters heruntergeladen.
• Der Inhalt der Archivdatei wurde in den MediWiki-Ordner /extensions/HitCounters/ gespeichert.
• In der Datei LocalSettings.php musste zur Aktivierung dann die zugehörige Befehlszeile ergänzt werden:

wfLoadExtension( 'HitCounters' );

• Danach steht die Zahl der bisher getätigten Seitenaufrufe wieder zur Verfügung.

Weitere Anpassungen des Erscheinungsbildes

Druckversion der Seiten anpassen

Standardmäßig werden in der Druckversion die externen Links in voller Länge eingeblendet, welche sich hinter den in den Seiten dargestellten Kurzformen verbergen. Die Druckausgabe sollte jedoch der Bildschirmdarstellung entsprechen, weshalb man die Ausgabe der externen Links unterdrücken muss:

• Eine Änderung in den MediaWiki-Systemdateien ist dafür nicht erforderlich.
• Man editiert als WikiSysop-Nutzer einfach die Seite "MediaWiki:Print.css" (Eintragen in das Suchfeld und Seite aufrufen):
• In der dargestellten Seite ergänzt man den Code:

#content a.external.text:after,
#content a.external.autonumber:after {
content: none;
}

Dieser überschreibt dann die Default-Definitionen im MediaWiki Source-Code. Er wirkt jedoch nicht für das Werkzeug "Druckversion", sondern nur für das normale Drucken im Browser!

Hinweis:

• In der aktuellen Version von MediaWiki war auch dem Nutzer WikiSysop das Editieren dieser CSS-Seiten mit Auswirkung auf alle Nutzer nicht möglich. Zum Glück stand der gewünschte Inhalt jedoch schon drin (wahrscheinlich durch die Übernahme der alten Datenbank-Inhalte.
• Zur Erlangung der Editierrechte wurden für den WikiSysop die zusätzlichen Benutzerrechte "Oberflächenadministrator" aktiviert. Dies funktionierte!
• Da die Spezialseiten nicht mehr angezeigt werden, Aufruf über Suchfeld "Spezial:Spezialseiten" -> dort "Benutzerechte".

Erstmalig ab dieser MediaWiki-Version wurde im Kopf einer gedruckten Seite nach "Aus OptiYummy" eine unsinnige Zeile "Zur Navigation springenZur Suche springen" ergänzt:

• Die zugehörigen Texte findet man im Ordner \app\skins\MonoBook\i18n\ in der Datei de.json.

"monobook-jumptonavigation": "Zur Navigation springen",
"monobook-jumptosearch": "Zur Suche springen",

• Hier genügt ein Ersatz beider Texte durch ein Leerzeichen für ein "sauberes" Druckbild.

Einbinden von Videos

Die [Extension:EmbedVideo] läuft ab der MediaWiki-Version 1.19. Damit wird es unter anderem möglich, Youtube-Videos in die Seiten einzubetten:

• Die ZIP-Datei der Extension ist über obigem Link zu laden. Der Inhalt muss in den Ordner "/Extension/EmbedVideo/" kopiert werden.
• Die Registrierung in der Datei LocalSettings.php erfolgt mittels:

wfLoadExtension( 'EmbedVideo' );

Danach funktioniert das Einbetten und Abspielen von Videos, wenn der Browser HTML5-kompatibel ist oder der Flashplayer installiert wurde:

• Ob dies bei dem eigenen Browser der Fall ist, sieht man am folgenden Beispiel:

• Anscheinend gibt es hier vor allem Probleme mit dem alten Internet-Explorer!
• Die Syntax für das Einbetten von Videos findet man auf der [MediaWiki-Seite der EmbedVideo-Extension].

Rendern von mathematischen Formeln

Mit der MediaWiki-Version 1.18.0 wurde die Funktion $wgUseTeX=true aus dem Kern des Wiki-Systems entfernt. Stattdessen muss man jetzt dafür eine Extension nutzen. Da die Extension:Math nur zusammen mit dem texvc-Programm funktioniert, welches für das genutzte STRATO-Paket nicht zur Verfügung steht, kann man die Extension:SimpleMathJax verwenden:

• Die Installation der SimpleMathJax-Extension genügt das Anlegen des Ordners Extension/SimpleMathJax und das Hineinkopieren des heruntergeladenen Inhalts.
• Die SimpleMathJax-Extension muss in der Datei LocalSettings.php registriert werden:

wfLoadExtension( 'SimpleMathJax' );
$wgSmjSize = 125;

• Versucht man damit im Editor z.B. die folgende Zeile einer Formel zu speichern:

  <math>c = \frac{E \cdot b \cdot t^3}{4 \cdot L^3} </math> 

• dann sollte die folgende Formel erscheinen:
  

Ausblenden von Links fuer nicht angemeldete Nutzer

Hierfür sind Eingriffe in einige Systemdateien erforderlich. Diese Änderungen sind nach einem eventuellen Update u.U. wieder zu regenerieren!

Ausblenden von Registerkarten für nicht angemeldete Nutzer

• Folgende Änderungen sind vor der ersten Zeile der Datei \skins\MonoBook\includes\MonoBookTemplate.php' zu ergänzen (Originaldatei zuvor sichern!):

<?php global $wgUser; if( !$wgUser->isAllowed('edit') ) { ?>
     <style type="text/css">
       #ca-viewsource { display: none !important; }
     </style> 
   <?php } ?>

<?php global $wgUser; if( !$wgUser->isAllowed('edit') ) { ?>
     <style type="text/css">
       #ca-talk { display: none !important; }
     </style> 
   <?php } ?>
  
<?php global $wgUser; if( !$wgUser->isAllowed('edit') ) { ?>
     <style type="text/css">
       #ca-history { display: none !important; }
     </style> 
   <?php } ?>
  
<?php global $wgUser; if( !$wgUser->isAllowed('edit') ) { ?>
     <style type="text/css">
       #ca-nstab-main { display: none !important; }
     </style> 
   <?php } ?>

<?php global $wgUser; if( !$wgUser->isAllowed('edit') ) { ?>
     <style type="text/css">
       #ca-nstab-project { display: none !important; }
     </style> 
   <?php } ?>

<?php global $wgUser; if( !$wgUser->isAllowed('edit') ) { ?>
     <style type="text/css">
       #ca-nstab-special { display: none !important; }
     </style> 
   <?php } ?>

Ausblenden der Werkzeuge (für nicht angemeldete Nutzer)

• Für die Wiki-Vorgängerversionen wurden trotz ständig geänderter Implementierung immer Möglichkeiten im Netz gefunden, die Werkzeug-Box für unangemeldete Nutzer auszublenden. Bisher ist dies noch nicht gelungen.
• Das Erzeugen der Werkzeug-Box erfolgt auch in der Datei \skins\MonoBook\includes\MonoBookTemplate.php, wo man durch Ergänzen von 2 Zeilen die Toolbox komplett "Auskommentieren" kann:

	protected function getToolboxBox( $toolboxItems ) {
		$html = ;
/** Beginn Auskommentierung
		$html .= $this->getBox( 'tb', $toolboxItems, 'toolbox' );
*/ // Ende Auskommentierung
		return $html;
	}

• Es wäre sicher für jemanden, der dieser Skriptsprache mächtig ist, relativ einfach, dort eine if-Anweisung mit dem Test des Benutzerstatus zu ergänzen.
• Das radikale Ausblenden ist jedoch unkritisch, da man als Autor nur wenige Funktionen daraus benötigt. Insbesondere "Datei hochladen" wurde bereits im Sidebar ergänzt (beim Update auf Version 1.31).

Fusszeile nur mit Impressum

• Dafür muss ebenfalls in der Datei \skins\MonoBook\includes\MonoBookTemplate.php die folgende Zeile mit der Definition der gewünschten FooterLinks ergänzt werden:

$validFooterLinks = array('disclaimer', 'tagline'); // Nur Impressum in Fusszeile

• Diese Zeile ist direkt vor den Zeilen für das Schreiben der Fußzeilen-Einträge einzufügen:

if ( count( $validFooterLinks ) > 0 ) {
    $html .= Html::openElement( 'ul', [ 'id' => 'f-list' ] );
    foreach ( $validFooterLinks as $aLink ) {
        :

• Anstatt "Impressum" erscheint "Haftungsausschluss" als Text, der Link führt jedoch zur Impressum-Seite. Dieser Text kann noch in einer Übersetzungstabelle geändert werden -> \languages\i18n\de.json in der Zeile:

"disclaimers": "Haftungsausschluss",

Resultat

1. Das Erscheinungsbild der Querformat-Darstellung (auf Desktop und Smartphone) hat sich im Vergleich zur Vorgänger-Version praktisch kaum verändert.
2. Auf dem Smartphone erscheint jetzt im Hochformat ein angepasstes Seiten-Layout.
3. Wichtig:
   • Der Safari-Browser unter iOS liefert unabhängig vom konkreten Gerät beim Aufruf einer OptiYummy-Seite nach sehr langsamen Laden die Fehlermeldung "Parsen der Antwort nicht möglich".
   • Hier kann nur der Umstieg auf einen anderen Browser (z.B. Firefox) empfohlen werden! Der genannte Fehler tritt laut Mitteilungen im Internet seit Jahren bei bestimmten Seiten-Layouts auf.

Nachtraegliche Anpassungen

Fehler-Vorschaubilder

Im Sommer 2022 trat ein Problem beim Erstellen der Vorschaubilder (Thumbnails) für die Dateiübersicht und angepasste Größen in Artikeln auf. Dabei wurden nachträglich Änderungen an der LocalSettings.php durchgeführt:

• Der Fehler "Vorschaubild konnte nicht erstellt werden. Error 25" ist laut diesem Beitrag auf eine zu geringe Speicherzuweisung der Shell für den ImageMagick-Converter zurückzuführen.
• In diesem Wiki trat der Fehler auch bei kleinen Dateigrößen auf. Die vorgeschlagene Lösung funktioniert trotzdem.
• Vermutlich hat eine im Hintergrund vom Hoster durchgeführte Änderung der Shellkonfiguration des Servers dazu geführt.
• In LocalSettings.php wurden bei den Einstellungen für den ImageMagick-Converter folgende Optionen hinzugefügt:

 ##fix for thumbnail error 25:
 $wgMaxImageArea = 3e7;
 $wgMaxShellMemory = 1024000;
 $wgMaxShellFileSize = 204800;

• Die Werte entsprechen etwa dem doppelten bis dreifachen der Standardeinstellung. Ob auch kleinere Anpassungen funktionieren, wurde noch nicht getestet.
• Beim Bearbeiten der Fehlermeldungen fiel auf, dass diese zusätzlich eine Warnung hinsichtlich der Locale-Einstellung auftrat.
• Die Option $wgShellLocale = "C.UTF-8" wurde durch $wgShellLocale = "en_US.UTF-8" ersetzt. Die C-Einstellung (= Computer) wäre zwar eigentlich korrekter, ist aber auf dem Server des Hosters nicht verfügbar.