Search:

Werbung:

Google+:

Archiv:


Jens Matheuszik — 1. Januar 2012, 18:24 Uhr

MAMP und MediaWiki laufen endlich nach Update auf Mac OS X Lion


Vorab der Hinweis: Dieser Beitrag ist wohl nur für die Pottblog-Leser interessant, die a) einen Apple Mac besitzen und b) aus welchen Gründen auch immer einen eigenen Webserver aufsetzen wollen oder aufgesetzt haben. Das ist beispielsweise dann ganz sinnvoll, um man eine Internet-Seite vorab offline auf dem eigenen Rechner zu testen – wie beispielsweise ein selbstgehostetes Blog wie das Pottblog selbst. Da vielleicht andere auch das selbe Problem haben/hatten, wollte ich meinen Lösungsweg beschreiben – ohne natürlich da irgendeine Garantie für zu übernehmen. Bei mir hat es aber geklappt!

Auf dem Mac benutzt man dazu beispielsweise Lösungen wie MAMP (siehe auch den (englischsprachigen) Wikipedia-Beitrag zu MAMP), die einen Webserver (Apache), eine Datenbank (MySQL) und eine Programmiersprache (PHP) zur Verfügung stellen.

Ich selber habe MAMP vor einiger Zeit ((die sich wohl eher in Jahren als in Monaten bemisst)) installiert, um eine lokale Variante von MediaWiki ((die Wiki-Software, die auch bei Wikipedia genutzt wird)) zu installieren. Das klappte damals ohne Probleme – doch als ich das letztens irgendwann wieder mal nutzen wollte, ging es nicht. Das hatte – wie sich inzwischen herausstellte – mehrere Gründe:

MAMP: Apache startet unter Mac OS X Lion nicht

Der Apache-Server, den MAMP eigentlich beim Aufrufen starten sollte, wollte sich nicht starten lassen. Erst wusste ich nicht, woran es lag, aber dann fiel mir ein, dass ich zwischenzeitlich Mac OS X Lion ((die neue Betriebssystemsoftware von Apple)) installiert hatte und es vielleicht daran liegen könnte.

Eine kurze Google-Recherche ergab, dass die von mir verwendete MAMP-Version 1.x ((genau weiß ich es gerade nicht)) mit Lion nicht so recht will, also aktualisierte ich auf die neue Version 2.0.

MAMP 2.0: Apache startet, MediaWiki nicht

Danach startete dann Apache zwar, aber der Aufruf von MediaWiki klappte nicht – der Bildschirm blieb leer bzw. weiß. Das lag daran, dass PHP standardmäßig die Fehler nicht anzeigte. Nach einer kurzen Suche fand ich den Forenbeitrag How to turn on PHP errors? und aktivierte die Anzeige von PHP-Fehlern.

MediaWiki: PHP-Fehler „unexpected T_NAMESPACE, expecting T_String“

Nach der Anzeige der Fehler wurde mir keine leere bzw. weiße Seite mehr angezeigt, dafür kam dann ein Fehler der ungefähr so lautete:

Parse error: syntax error, unexpected T_NAMESPACE, expecting T_STRING

Dieser Fehler resultiert wohl daher, dass es neben der MediaWiki-internen Funktion Namespaces seit der neuen PHP-Version 5.3 auch eine PHP-interne Funktion namens Namespaces gibt, so dass es hier zu Problemen kam.

Auf icesquare.com fand ich drei mögliche Wege, das ganze zu beheben:

  1. PHP von Version 5.3 auf Version 5.2 zu „downgraden“
  2. MediaWiki auf eine neuere Version zu aktualisieren
  3. Den Code von MediaWiki zu ändern

Ich probierte erst einmal den für mich einfachsten Weg – die Aktualisierung von MediaWiki auf die neue Version, wie sie auf der MediaWiki-Seite „Upgrading“ beschrieben wurde.

MediaWiki: MySQL-Problem: „Unknown character set: ‚mysql4′“

Im Laufe des MediaWiki-Upgrades hatte ich erst noch kurzfristig ein kleines MySQL-Problem (wenn man sich nicht an seine MySQL-Passwörter erinnert…), aber das klärte sich recht schnell. Dann kam jedoch ein größeres Problem, denn beim Aktualisieren der alten MediaWiki-Tabellen kam folgende (sinngemäße und zum Teil hier gekürzte) Meldung:

Die letzte Datenbankabfrage lautete: CREATE TABLE IF NOT EXISTS `account_requests` (
[…] ) ENGINE=MyISAM, DEFAULT CHARSET=mysql4 […]
Die Datenbank meldete den Fehler: „1115: Unknown character set: ‚mysql4‘ (localhost)“.

Leider scheiterte an dieser Stelle die Upgrade-Installation und es ging nicht weiter…

Die Fehlermeldung bezüglich des unbekannten Zeichensatzes kam andauernd wieder und es stellte sich schnell heraus, dass es der Bug 29102 war, der schon ein wenig bekannt war.

Um diesen Bug zu fixen orientierte ich mich an der oben erwähnten 3. Option – der Änderung des Codes von MediaWikis.

Manuelles Codefixing von MediaWiki: Namespace:: wird zu MWNamespace::

Die unter icesquare.com vorgestellten Schritte hielt ich jedoch nicht 1:1 ein, denn beispielsweise der 1. Schritt (Änderung der Namespace.php) war nicht (mehr) notwendig – das hatte wahrscheinlich schon das MediaWiki-Upgrade erledigt.

Auch die Schritte 5-8 befolgte ich nicht, da ich keine Lust hatte irgendwelche Shell-Scripte anzulegen ((ja, das soll zwar an sich auf dem Server funktionieren, aber bisher hatte ich mich da nicht mit beschäftigt)). Stattdessen habe ich das ganze manuell erledigt, denn dort wurde eigentlich nur gefordert, dass man in dem entsprechenden Verzeichnis /wiki/includes/ alle Referenzen auf die Namespaces-Funktion entsprechend abändert.
Sprich: In jeder Datei des Verzeichnis, in der die Namespace-Funktion adressiert wurde, habe ich stattdessen die MWNamespace-Funktion adressiert, das heißt ich habe

Namespace::

durch

MWNamespace::

ersetzt.

Weiterhin falscher Zeichensatz bei MediaWiki: Anpassung der Tabellen-Optionen

Es klappte leider immer noch nicht, doch ein wenig Recherche führte mich zum 17. Beitrag in diesem Forum (bzw. dieser Mailingliste).

Dort wurde vorgeschlagen einfach im Verzeichnis /wiki/maintenance/archive jedes Auftreten von

/*$wgDBTableOptions*/

durch

ENGINE=InnoDB, DEFAULT CHARSET=binary

zu ersetzen. Danach funktionierte dann auch das Aktualisieren der MySQL-Tabellen im MediaWiki-Upgradescript und danach lief auch endlich MediaWiki wieder lokal auf meinem Rechner!

MediaWiki läuft!

Nach ein bisschen Frickelei, Suche im Netz und händischen Eingriffen klappte es endlich! Dafür, dass ich eigentlich keine Ahnung von PHP habe, war ich schon ein wenig zufrieden, dass es dann endlich klappte.

Jetzt kommt dann als nächstes WordPress in das Entwicklungssystem – man muss ja nicht (wie ich es bisher fast immer gemacht habe…) Änderungen im laufenden Betrieb vornehmen. :)


2 Kommentare »

RSS feed for comments on this post. TrackBack URI.

    Es gab einen kritischen Fehler auf deiner Website.

    Erfahre mehr über die Fehlerbehebung in WordPress.