OptiYummy-Update-2012

Zielpraezisierung

Im Jahre 2008 wurde das Optimierungsportal OptiYummy auf einem eigenen Linux-Server in Betrieb genommen. Zwar waren dafür mittelmäßige Kenntnisse in Bezug auf die Administration von Windowssystemen vorhanden, aber in Hinblick auf die Installation und Pflege von Linux-Systemen fehlten jegliche praktische Erfahrungen. Auf Rat eines Freundes (Linux-Experte) fiel damals die Wahl auf die openSUSE-Distribution 10.3 welche auch das MediaWiki 1.10.0 enthielt. Bis auf wenige Hürden, welche durch die Hilfe weiterer Linux-Experten genommen wurden, gestaltete sich die Inbetriebnahme des MediaWiki-Systems beherrschbar für jemanden, der sich nur mit Windows auskennt.

Leider werden für eine openSUSE-Distribution nur für eine begrenzte Zeit automatisiert Sicherheitsupdates eingespielt. Irgendwann ist also unbedingt ein Update auf eine neuere Version erforderlich, auch wenn das bisherige System noch stabil läuft.

Um den Betrieb des noch laufenden alten Systems nicht zu stören, sollte auf neuer Hardware die neueste openSUSE-Distribution mit der neuesten MediaWiki-Version installiert werden. Nach den im Jahr 2008 gesammelten Erfahrungen sollte das problemlos möglich sein.

Leider waren dann die Erfahrungen mit der Installation von MediaWiki 1.18 auf openSUSE 12.1 ziemlich deprimierend. Die Installation erfolgte parallel durch zwei Bearbeiter auf zwei unterschiedlichen PC. Dabei wurde versucht, möglichst systematisch in den von der alten Version bekannten Schritten vorzugehen:

• Erste Probleme gab es mit dem Fernzugriff mitteln NX-Protokoll und NoMachine-Client. Irgendwie klappte es dann in der einen Installation, nachdem es anfänglich auch nicht ging. In der anderen Installation gelang es nicht, mittels NoMachine-Client eine Verbindung zum Server herzustellen. So wurde hier der VNC-Zugriff genutzt.
• Das Klonen der benutzten SSD-Festplatten war ein mehr oder weniger zufälliger Prozess. Das kann sowohl an Schwächen der openSUSE-Live-CD in Hinblick auf die konkrete Hardware liegen. Das können aber auch Probleme mit den SSD-Platten sein.
• Am Schlimmsten war, dass die Inbetriebnahme des Wiki-Systems auf einem System scheiterte. Es wurde danach nur eine leere Seite im Browser angezeigt. Nach erneuter System-Installation (beginnend mit einer leeren Festplatte) gelang es, ein Test-Wiki zu installieren.
• Auf dem parallel installierten System lief alles zunächst relativ problemlos. Doch im laufenden Betrieb kam es immer wieder zu Problemen (z.B. sporadischer System-Stillstand, Update-Blockade).

Auf Grund der aufgetretenen Stochastik wurde beschlossen, von einem Betrieb des Wiki-Systems auf eigener Hardware und eigenem Betriebssystem Abstand zu nehmen und stattdessen ein normales Webhoster-Paket nutzen:

• Die Installation wird unter einem STRATO Hostingpaket PowerWeb Basic vorgenommen, welches über die erforderlichen Ressourcen für des Betrieb eines MediWiki-System verfügt.
• Diese Instalaltion wird im folgenden in nachvollziehbarer Form dokumentiert.

MediaWiki-System installieren

Das Web-Interface für Hosting-Pakete wird von Strato kontinuierlich modifiziert. Die Beschreibung entspricht dem Stand vom Anfang Juli 2012:

• Für Bestandskunden, deren Pakete PHP-Unterstützung enthielt, bot STRATO zu diesem Zeitpunkt einen kostenlosen Umzug auf eine Plattform an welche für dynamische Webanwendungen optimiert ist. Diesen Umzug muss man aktivieren, bevor man ein WikiSystem installieren kann! Angeboten wurde dieses Kostenlos Aktivieren auf der Hauptseite der Paket-Verwaltung.
• Wenn man den Anweisungen folgt, ist der Umzug auf die neue Plattform innerhalb weniger Sekunden erledigt.
• Die existierende Installation von optiyummy.de auf einem eigenen Server sollte natürlich erhalten bleiben, bis die neue Installation bei STRATO läuft. Deshalb wurde optiyummy.net als Domäne für die Einrichtung vorgesehen. Die zuvor bestehende Weiterleitung von optiyummy.net auf den eigenen Server wurde dazu zurückgesetzt.

Auf der Paket-Hauptseite wird für "In wenigen Schritten zu Ihrer Webanwendung!" geworben. Zu Konfiguration der unterschiedlichsten Anwendungen gelangt man auch über den Menüpunkt Homepagegestaltung > AppWizard > Wiki:

• Die von STRATO bereitgestellte MediaWiki-Version (im Beispiel 1.15.2-4) hinkt der aktuellen Version von www.mediawiki.org immer um einige Versionsnummern hinterher (im Beispiel 1.19.1). Die Auswirkung auf die Funktionalität sind sicher gering.
• Nach Wahl von Jetzt Installieren erfolgt die Installation in 4 Schritten:

1. MediaWiki - Einstellungen zur Administration

• Bezeichnung: OptiYummy
• Benutzername: WikiSysop
• Passwort: ganz geheim
• E-Mail Adresse: admin@domain.de

2. MediaWiki - Domain Einstellungen

• Die bestehende Domäne optiyummy.net wurde infolge der zurückgesetzten Weiterleitung als verwendbar für das WikiSystem angeboten.
• Nach Auswahl der Domäne genügt ein Weiter.

3. MediaWiki - Datenbank

• Es wird die MySQL-Version 5.x benutzt
• Den Kommentar "Datenbank für OptiYummy" kann man beibehalten.

4. MediaWiki - Fertigstellen

• Man muss die Lizenz-Bedingungen akzeptieren.
• Das Verzeichnis für das WikiSystem ist Beispiel mediawiki_02.
• Das Fertigstellen dauert nur einige Sekunden.

Danach steht ein MediaWiki-System in seiner Grundeinstellung zur Verfügung.

Wiki-System individuell konfigurieren

Geht man für das Paket erneut in Homepagegestaltung > AppWizard, so wird OptiYummy dort als MediaWiki-Anwendung gelistet. Hier sollte man die zugeörigen Details aufrufen:

• Die Datenbank verwalten wir erst später.
• Die Links zur Webseite und zum Admin-Bereich führen beide zur Startseite des Wiki-Systems. Dort kann man nur die Verwaltung durchführen, welche nach Anmeldung als WikiSysop möglich sind.

Man benötigt den Zugang direkt auf die Dateien des Wiki-Systems im Homeverzeichnis. Von STRATO werden für den Zugriff auf das Homeverzeichnis sowohl ein FTP- als auch ein SSH-Zugang zur Verfügung gestellt:

• Server: ftp.strato.de bzw. ssh.strato.de
• Benutzername: Domän-Name (im Beispiel: www.optiyummy.net)

Leider gelangt man mit beiden Zugriffsmechanismen zu unterschiedlichen Ziel-Ordnern. Nur der unverschlüsselte Zugang per FTP ermöglichte den Zugriff auf das Wiki-Verzeichnis mediawiki_02. Sehr komfortabel ist dabei z.B. die Nutzung des Total-Commanders.

Vergeben von Nutzerrechten

Die folgenden Einstellungen sind in der Datei LocalSettings.php vorzunehmen, welche sich im Wiki-Verzeichnis mediawiki_02 befindet. Dazu wurde mittels Total-Commander eine lokale Kopie von LocalSettings.php erzeugt. Diese wird schrittweise verändert und zum Test der Wirkung wieder per FTP 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;

Das Versenden von E_Mails wurde abgeschalten:

$wgEnableEmail      = false;
$wgEnableUserEmail  = 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 = "http://creativecommons.org/licenses/by/3.0/";
$wgRightsText = "Creative Commons";
$wgRightsIcon = "http://i.creativecommons.org/l/by/3.0/88x31.png";

Anpassung des Erscheinungsbildes

Eigenes Logo und Favicon:

• Die erforderlichen Dateien werden per FTP in den images-Ordner kopiert.
• in LocalSettings.php wird die Zeile:

$wgLogo             = "";

• ersetzt durch:

## Eigenes Logo 135x135 Pixel einbinden
$wgLogo = "/images/logo.gif";
$wgFavicon = "/images/favicon.ico";

Änderungen in der Datei "/skins/MonoBook.php":

• In der MediaWiki-Version 1.15 kann man noch über Änderungen in dieser Datei überflüssige Elemente der Oberfläche ausblenden. Zumindest ab der MediaWiki-Version 1.18 ist dies nicht mehr möglich!
• Die folgenden Änderungen in der Datei "MonoBook.php" im "Skin"-Ordner bergen die Gefahr, dass Änderungen bei Updates verloren gehen. Doch zuvor besteht die Gefahr, dass man die Struktur dieser Datei versehentlich durch die Änderungen zerstört:

Achtung: Vorher eine Kopie der Orignal-Version von MonoBook.php erzeugen und sichern.

Ausblenden von Items in der Fußzeile:

• Alle nicht gewünschten Items wurden mit Kommentar /* */ ausgeklammert
• Nur disclaimer (=Impressum) blieb erhalten:

$footerlinks = array(
  /*'lastmod', 'viewcount', 'numberofwatchingusers', 'credits', 'copyright',*/
  /*'privacy', 'about',*/ 'disclaimer', /*'tagline',*/
 );

Ausblenden des Werkzeuge-Menüs für nichtangemeldete Nutzer:

• Finden des folgenden Abschnitts (Suchen nach p-tb):

        <div class="portlet" id="p-tb">
        <h5><?php $this->msg('toolbox') ?></h5>
 

• Ersetzen durch die folgenden Zeilen:

        <div class="portlet" id="p-tb">
        <?php if($this->data['loggedin']) { ?>
        <h5><?php $this->msg('toolbox') ?></h5>
 

• Weiter unten steht das Ende des soeben editierten div-Blockes. Dort sucht man folgenden Abschnitt:

         wfRunHooks( 'MonoBookTemplateToolboxEnd', array( &$this ) );
 ?>
         </ul>
     </div>
   </div>
 

• Dort ergänzt man die Zeile (zwischen den beiden /div), welche das neue "if"-Statement schließt:

         wfRunHooks( 'MonoBookTemplateToolboxEnd', array( &$this ) );
 ?>
         </ul>
       </div>
     <?php } ?>		
   </div>
 

Ausblenden der Register-Tabs für nichtangemeldete Nutzer:

Man sucht in "MonoBook.php" die folgende Zeile:

foreach($this->data['content_actions'] as $key => $tab) {

und fügt unmittelbar nach "$tab)" die fett markierte Bedingung ein:

foreach($this->data['content_actions'] as $key => $tab) if($this->data['loggedin']==1) {

Datei-Upload mit PHP

Die max. Größe für den PHP-unterstützten Upload einer Datei muss man in php.ini-Dateien festlegen. Im Beispiel wird für das Wiki-System die Version PHP 5.2.17 (cgi-fcgi) verwendet:

• Auf einem eigenen Server müsste man in den Dateien /etc/php5/apache2/php.ini und /etc/php5/cli/php.ini die Begrenzung z.B. auf 200 MByte ändern:

upload_max_filesize = 200M

• Der Wert soll im Beispiel so groß sein, weil die vorhandenen Datenbank-Inhalte des alten Wiki-Systems wahrscheinlich über das PHP-Webinterface hochgeladen werden müssen.

Damit man auf die erforderliche Ordner mit den php.ini-Dateien Zugriff erhält, muss man sich mittels SSH verbinden:

• Im Ordner \opt\RZphp52\etc\ findet man die Datei php.ini. Darin modifiziert man in einer lokalen Kopie die vorhandene Zeilen von 10M auf 200M:

post_max_size = 200M
upload_max_filesize = 200M

• Leider hat man keine Schreibrechte auf die Originaldatei, so dass man hier nicht weiter kommt!
• Zumindest für das Wiki-System kann man die maximal hochladbare Dateigröße anpassen, indem man die lokale Kopie von php.ini per FTP-Zugriff in das Wurzelverzeichnis des Wiki-Systems speichert (dort, wo auch LocalSettings.php liegt). Auf der Hochlade-Seite wird im Wiki-System der erhöhte Größenwert dann angezeigt und das Hochladen von Dateien > 10MB funktioniert dann!

Für das Wiki-System muss man zusätzlich die Konfiguration der Datei-Größe über LocalSettings.php vornehmen:

• Das deaktivierte Upload:

$wgEnableUploads       = true;

• 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' );
## erfordert Directories images/archive, images/thumb and images/temp (all writable)
$wgHashedUploadDirectory = false; # nicht Bilder-Verzeichnisstruktur "/a/ab/foo.png" verwenden

Hinweis zu Filetypen:

• svg Bildertyp in dieser MediaWiki-Konfiguration nicht darstellbar
• zip wird anderweitig als unzulässig blockiert, auch wenn in obiger Liste!

Die für LaTex erforderlichen texvc-Komponenten befinden sich bereits im Ordner math. Man muss in der zugehörigen Zeile in LocalSettings.php die Variable auf true setzen:

$wgUseTeX           = true; # erfordert Directory images/math

• Nach dem Aktualisieren der LocalSettings.php sollte man die erforderliche Ordner anlegen und das Hochladen eines Bildes bzw. das Erstellen einer Formel testen. Beim Hochladen eines Bildes wird auch die maximal mögliche Dateigröße angezeigt.
• Leider funktionierte LaTex nicht (Parser-Fehler: texvc-Programm wurde nicht gefunden!).

Vorhandene Datenbank importieren

Erkenntnis- Update:
Der im Jahre 2012 gewählte Weg des Daten-Imports erwies sich infolge späterer Erfahrungen als zu umständlich. Die bereitgestellte Update-Funktion für MediaWiki-Datenbanken löst die Probleme fehlender Tabellen-Einträge "automatisch" (Siehe: Übertragen von Inhalten). Die folgende Beschreibung widerspiegelt also einen veralteten Erkenntnis-Stand.

Vor dem Import der vorhandenen Datenbank in Form einer sql-Datei sollte man die zusätzlich erforderlichen Datei-Inhalte in den MediaWiki-Ordner kopieren:

• dies betrifft den gesamte Datei-Struktur des alten images-Ordners.
• man muss darauf achten, dass nach dem Hochladen per FTP die Ordner die Datei-Attribute 755 und die Dateien die Attribute 644 besitzen.

Das Importieren einer Datenbank-Datei erwartet man unter Paket > Verwaltung > Datenbankverwaltung. Auf den ersten Blick findet man jedoch nur das Exportieren von Datenbanken. Aber laut Aussage des STRATO-Supports ("gegoogelt") geht es:

• "Ich kann Sie beruhigen, der Karteireiter wurde nicht entfernt. Sie können Daten importieren, wenn Sie in dem Phpmyadmin links oben auf das kleine eckige Symbol "SQL" klicken. Es geht dann in einem Popupfenster ein kleines Fenster auf mit dem Karteireiter "Dateiimport". Der andere Weg ist, wenn Sie auf der linken Seite oben auf den Datenbankbezeichner DB... klicken und im mittleren Bereich auf den Karteireiter "SQL"."

Das funktioniert auch, aber leider scheitert der Import dort an der maximalen Dateigröße: 2.048KB!

Eine eigene Anfrage an den STRATO-E-Mail-Support ergab dann nach 2 Tagen folgende erfolgversprechende Antwort:

• Datenbank bei STRATO importieren: http://www.strato-faq.de/919
  
• Es besteht aber auch die Möglichkeit, die Datenbank mit MySQL Dumper zu exportieren, um diese dann zu importieren (Open Source): http://www.mysqldumper.net/
• Sollten Sie eine Datenbank exportiert haben, die nicht von STRATO stammt, dann ist in der Regel in der MySQL Datei eine Linie die mit "create database" beginnt, diese müsste normalerweise gelöscht werden, da sonst eine Fehlermeldung kommt.

Ein Blick in die zu importierende optiyummy.sql-Datei bestätigte den Hinweis:

-- MySQL Administrator dump 1.4
--
-- ------------------------------------------------------
-- Server version	5.0.45
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
--
-- Create schema optiyummy
--
CREATE DATABASE IF NOT EXISTS optiyummy;
USE optiyummy;
:

Um die sql-Datei beim Editieren nicht zu zerstören, wurde der HxD-Hexeditor verwendet:

• Die beiden Zeilen

CREATE DATABASE IF NOT EXISTS optiyummy;
USE optiyummy;

• sollten durch Überschreiben der ersten Zeichen in Kommentare umgewandelt werden:

-- ATE DATABASE IF NOT EXISTS optiyummy;
-- optiyummy;

• Die modifizierte sql-Datei muss sich dann auf dem Webspace im Hauptverzeichnis befinden. Welches Verzeichnis damit gemeint ist, musste noch "erforscht" werden.

Bevor man der detaillierten Anleitung unter http://www.strato-faq.de/919 folgt, sollte man die vorhandene Datenbank des bisher "leeren" MediaWiki-Systems sichern. Falls etwas schief geht, kann man dann hoffentlich den Ausgangszustand wieder herstellen:

• Paket > Verwaltung > Datenbankverwaltung
• die vorhandene Datenbank mit dem Cursor anwählen > Exportieren (mit Standard-SQL-Konfig) > OK
• die SQL-Datei landet dann im Download-Ordner des Browsers.

Nun folgt man der Anleitung unter http://www.strato-faq.de/919:

• Hierfür benötigt man das Programm putty.exe, welches vorsichtshalber mit Administratorrechten gestartet wurde (Programm muss nicht installiert werden!).
• Nach der Anmeldung kann man mittels des ls-Befehls sehen, wo man sich befindet:

login as: optiyummy.net
optiyummy.net@ssh.strato.de's password:
optiyummy.net> ls
cgi-bin  cgi-data  index.html  mediawiki_01  mediawiki_02
optiyummy.net>

• Dies zeigt, man kann die sql-Datei per FTP-Zugriff hochladen, dort hat man Zugriff auf das Hauptverzeichnis.
• Die erforderliche Angaben zur Datenbank findet man in LocalSettings.php.
• Der Befehl (mit den aktualisierten Angaben) führt dann jedoch zu einer Fehlermeldung:

optiyummy.net> mysql -h rdbms -u BENUTZERNAME -pPASSWORT DBxxxxxx < optiyummy.sql
ERROR 1050 (42S01) at line 27: Table 'archive' already exists

• Vorhandene Tabellen können also nicht überschrieben werden!
• Deshalb wurden über das Webinterface der Datenbankverwaltung sämtliche Tabellen markiert und gelöscht.
• Danach funktionierte der Import über Putty.
• Textseiten ohne Bilder werden danach richtig angezeigt.
• Alle Seiten mit Bildern brachten eine Fehlermeldung:

1054: Unknown column 'img_sha1' in 'field list' (rdbms.strato.de).

Es funktioniert also immer noch nicht! Deshalb wurde nach dem gleichen Prinzip die ursprüngliche "leere" Datenbank zurück importiert, um die Bedeutung dieser Spalte zu erkunden.

• Zuvor wurde die Liste aller 34 Tabellen-Namen aus optiyummy.sql als Bildschirm-Hardcopy gesichert. Nur diese Tabellen müssen aus der originalen "leeren" Datenbank gelöscht werden!
• Über das Datenbank-Webinterface erkennt man, dass das Feld img_sh1 Bestandteil der Tabelle image ist.
• Das Feld img_sha1 besitzt folgende Eigenschaften (unter Ändern abrufbar): Typ=VARBINARY / Länge=32 / Null=notnull / der Rest ist leer

In der "leeren" Datenbank sind danach nur die 34 Tabellen zu löschen, welche wieder mit Inhalt importiert werden sollen. D.h. im Beispiel wurden folgende Tabellen nicht gelöscht:

• category
• change_tag
• page_props
• protected_titles
• tag_summary
• updatelog
• valid_tag

Danach wurde über Putty erneut fehlerfrei optiyummy.sql importiert:

• Erwartungsgemß kommt beim Aufruf einer Bilderseite wieder obiger Fehler.
• Nun muss in der image-Tabelle das erforderliche Feld am Tabellen-Ende ergänzt werden: das Feld ist als Index zu markieren!

Danach war die Freude groß, denn alle Bilder waren auf den Seiten vorhanden!

Aber es fehlen noch weitere Felder in der Datenbank:

• Beim Aufruf eines Bildes (oder beliebigen Datei) für die Funktion „LocalFile::getHistory“:

1176: Key 'oi_name_timestamp' doesn't exist in table 'oldimage' (rdbms.strato.de)

• oi_name_timestamp als Index hinzufügen für die Felder oi_name und oi_timestamp.
• Danach kommt nächster Fehler beim Aufruf eines Bildes:

1054: Unknown column 'oi_metadata' in 'field list' (rdbms.strato.de)

• Achtung: Verbesserte Versionen der Datenbank sollte man mittels Putty sichern (exportieren), bevor man sie aus Versehen durch ein falsche Änderung zerstört:

mysqldump DBxx --add-drop-table -h rdbms -u BENUTZERNAME -pPASSWORT > datei.sql

Der nächste fehlende Eintrag oi_metadata müsste als neues Feld hinter oi_timestamp hinzugefügt werden. (Typ=MEDIUMBLOB / Länge=32? / Null=notnull / der Rest leer):

• Nach einigen Versuchen wurde beschlossen, dass dies für einen mySQL-Laien nicht beherrschbar ist, diese und weitere erforderliche Felder zu ergänzen.
• Von der neuen "leeren" Datenbank sollte nur die Tabelle oldimage importiert werden:

1. In einer neuen Datenbank alle Tabellen löschen, außer die Tabelle oldimage. Datenbank (enthält nur oldimage-Tabelle) mittels Putty-Umgebung exportieren.
2. In der komplette Datenbank nur die oldimage-Tabelle löschen, dann die "leere" Datenbank (mit oldimage-Tabelle) importieren.

Danach waren alle erforderlichen Einträge in der oldimage-Tabelle enthalten und Bilder konnten ohne Fehlermeldung aufgerufen werden!

Nun verbarg sich noch ein offensichtlicher Fehler in der Datenbank:

• Beim Aufruf Spezialseiten > Statistk für die Funktion "SiteStatsUpdate::cacheUpdate“:

1054: Unknown column 'ss_active_users' in 'field list' (rdbms.strato.de)

• Ein Vergleich mit einer neuen "leeren" Datenbank zeigte, dass in der Tabelle site_stats nur das eine Feld ss_active_users nach dem Feld ss_users fehlte.
• Typ=BIGINT / Länge=20 / Null=null / Standard=-1 / der Rest leer.
• Das Ergänzen dieses einfachen Feldes erscheint für den SQL-Laien beherrschbar.
• Das neue Feld ist nicht als Index zu kennzeichnen!
• Danach konnte die Statistik ohne Fehler dargestellt werden!

Ein weiterer Datenbank-Fehler tritt bei Löschen von Seiten und Dateien auf:

1054: Unknown column 'ar_page_id' in 'field list' (rdbms.strato.de) 

• Am Ende der archiv-Tabelle ist die Länge von ar_len auf 10 zu erhöhen
• Dann sind an Ende der archiv-Tabelle noch die Felder ar_page_id und ar_parent_id zu ergänzen. Diese erhalten die gleichen Eigenschaften, wie das aktualisierte ar_len: (Typ=INT / Länge=10 / Attribute=UNSIGNED / Null=null / Standard=NULL)

Problematisch sind nun noch interne Links, welche Sonderzeichen verwenden:

• Hier hilft nur die Korrektur des Links durch Ersatz der Sonderzeichen durch Umschreibungen.
• Die Seiten bzw. Bilder müssen neu erzeugt bzw. hochgeladen werden (auf Basis der falsch benannten).

Probleme mit modifizierten URL

In der vorherigen Installation auf einem eigenen Server erfolgte ein externer Link auf eine Seite des Wiki-Systems in der Form:

http://www.optiyummy.de/index.php/SeitenName

In der aktuellen Installation bei Strato sind nun andere Links in folgender Form erforderlich:

http://www.optiyummy.de/index.php?title=SeitenName

Das führt natürlich zu Problemen, wenn bereits externe Links auf einzelne Seiten des Wiki-Systems existieren. Diese führen nun grundsätzlich ohne Fehlermeldung nur noch zur Hauptseite des Wiki-Systems.

Die Ursache wurde in der CGI-Unterstützung gefunden:

• Die ursprüngliche Form resultierte aus der nicht benutzten CGI-Unterstützung.
• Die aktuelle Form ist Resultat der beim Provider standardmäßig aktivierten CGI-Unterstützung.

Dieses Problem der Short-URL wird auf bei MediWiki.org beschrieben. Anscheinend ist man für künftige Installationen auf der sicheren Seite, wenn man die CGI-Unterstützung nutzt. Leider muss man dafür existierende externe Links ändern, soweit man dafür die Möglichkeit hat.