Computer: PhpWiki (aus Wiki)

dkracht

Gehört zu: Web Authoring
Siehe auch: WikiWiki

PhpWiki (aus Wiki)

Aufgabenstellung

PhpWiki hatte ich im Januar 2003 erstmals installiert. Damals benutzte ich die Version 1.3.2, habe aber die Installation schon bald nicht mehr aktiv benutzt (aus diversen auch beruflichen Gründen). Heute im Dezember 2003 will ich einen neuen Anlauf nehmen und PhpWiki zu meiner Key-Anwendung machen als “elektronischen Zettelkasten”.

In Sourceforge sehe ich, dass 1.3.x den Status BETA hat (aktuell 1.3.6 vom 16. November 2003). Mutig habe ich 1.3.6 ausprobiert, aber ich bekam nach dem Virgin Load, was gut aussah, leere Seiten angezeigt. Also sage ich mir: BETA sollte man nicht nehmen, zurück auf 1.2.2 mit Status STABLE. Version 1.2.2 hat dann auch auf Anhieb bestens funktioniert (nachdem ich register_globals = On im php.ini gesetzt hatte). Die Optik sah aber ein bisschen schlicht aus. Grund: Es gibt in 1.2.2 noch keine Themes, wie ich sie von 1.3.2 schon kannte und schätzte. Auch die PhpWiki-Plugins gibt es in 1.2.2 noch nicht.

Also fasste ich ein bisschen Mut und lud mir dir Version 1.3.3 herunter (1.3.2 hatte ich ja noch lauffähig auf meinem Notebook vom Januar 2003, hätte ich also notfalls kopieren können). Mit 1.3.3 lief ich in das gleiche Problem, wie oben bei 1.3.6, nämlich nach dem gut verlaufenen Virgin Load kam beim Klicken auf Links auf der schönen Startseite nur noch “Nichts”, bzw. Fehlermeldung vom Internet Explorer, dass das eine unsichere Seite sei und ob ich sie downloaden oder Öffnen wolle und mit welchem Programm dann bitteschön Es sah also so aus, als ob gar keine HTML-Seiten als Response produziert würden. Letzendlich erschienen die Seiten nicht.

Mit Version 1.3.3 kam ich wesentlich weiter, aber an einer Stelle habe ich mir die Zähne ausgebissen: Die Volltext-Suche funktioniert nur mit USE_PATH_INFO=false und mein Internet-PHP-Provider funktioniert nur mit USE_PATH_INFO=true. Also neuer Blick in Sourceforge: siehe da, es gibt seit 20.12.2003 neu die Version 1.3.7 “pre”.

Erfahrungen mit PhpWiki 1.3.7

Output-Kompression

Das Problem tritt bei PhpWiki 1.3.7 nicht mehr auf. (O.K.)

Formate von Datum und Uhrzeit

Muss genauso angepasst werden, wie schon unten bei PhpWiki 1.3.3 (O.K.)

Formatierung von Tabellen

Ist kein Problem (lediglich mangelnde Dokumentation). (O.K.)

Volltextsuche

Funktioniert sowohl mit USE_PATH_INFO=false als auch mit USE_PATH_INFO=true. Damit ist das Problen, das zur Einstellung der Nutzung von PhpWiki 1.3.3 führte ausgeräumt. Klasse! (O.K.)

Roll-out zum Web-Hosting-Provider

  • Installation von PhpWiki funktioniert problemlos (virgin load).
  • Für einen ersten Test lade ich die Inhalte aus meiner lokalen MySQL-Datenbank per PhpMyAdmin in die MySQL-Datenbank beim Provider.
  • Export des Datenbankinhalts als ZIPDUMP funktioniert bei PhpWiki 1.3.7 problemlos unter Windoes und unter Linux (beim Provider unter Linux ging es mit 1.3.3 nicht)
  • Import (Loadfile) des ZIPDUMP in die Datenbank hat zunächst das Problem FileFinder.php 143 file not found. Dies konnte ich umgehen durch Angabe eines relativen Pfades (relativ zum Phpwiki-Folder) d.h. “./tmp/filename.zip”. Dann wird die Eimgabedatei gefunden und verarbeitet. Die Verarbeitung funktioniert aber nicht richtig. Es wird immer nur die älteste Version einer Seite gelden und die neueren mit der Meldung “Editing Conflict” abgeleht. So kann man mit PhpWiki nicht sinnvoll arbeiten.

Anwendungskatalog from MIME file Anwendungskatalog has edit conflicts – skipped Merge Edit Restore Anyway Anwendungskatalog from MIME file Anwendungskatalog has edit conflicts – skipped Merge Edit Restore Anyway Anwendungskatalog from MIME file Anwendungskatalog has edit conflicts – skipped Merge Edit Restore Anyway Anwendungskatalog from MIME file Anwendungskatalog has edit conflicts – skipped Merge Edit Restore Anyway Anwendungskatalog from MIME file Anwendungskatalog has edit conflicts – skipped Merge Edit Restore Anyway Anwendungskatalog from MIME file Anwendungskatalog is identical to current version 6 – skipped Anwendungskatalog from MIME file Anwendungskatalog has edit conflicts – skipped Merge Edit Restore Anyway Anwendungskatalog from MIME file Anwendungskatalog has edit conflicts – skipped Merge Edit Restore Anyway Anwendungskatalog from MIME file Anwendungskatalog has edit conflicts – skipped Merge Edit Restore Anyway Astronomie from MIME file Astronomie has edit conflicts – skipped Merge Edit Restore Anyway Astronomie from MIME file Astronomie has edit conflicts – skipped Merge Edit Restore Anyway

Erfahrungen mit PhpWiki 1.3.3

Die Fehlersuche kam zuerst nicht recht voran. Ich vermutete Ursachen an folgenden Stellen:

  • INDEX.PHP: SERVER_NAME und VIRTUAL_PATH (ich benutze Apache2 mit mehreren VirtualHosts)
  • PHP.INI register_globals = On
  • PHP.INI session.save_path = /temp
  • PHP.INI include_path = “.;\php\pear;…”

Nachdem das alles überprüft war und der Fehler immer noch auftrat, griff ich zum letzten Mittel: Einbau eines echo “hallo hier bin ich” in index.php am Ende unmittelbar vor Aufruf von lib/main.php. Das hatte einen verblüffenden Effekt. Es kamen einige böse Fehlermeldungen, dass die Session nicht gestartet werden kann, weil schon ein Response-Header ausgegeben wurde (mein echo), aber der eigentliche Fehler war weg. Man konnte per Klick von der Startseite auf die anderen Seiten verzweigen, ohne dass der Intrent Explorer mit diesen merkwürdigen Fehlermeldungen kam und letztlich die Seiten auch nicht anzeigte. Nun wurden alle Seiten schön angezeigt, wennauch begleitet von den neuen Fehlermeldungen wegen der Sessionverwaltung.

Die weitere Eingrenzung des Fehlerorts war einfach: Im lib/main.php ging es zur function handleAction() und von da zu function action_browse(), function actionpage() usw. in denen dann der wahre Bösewicht identifiziert werden konnte: $this->compress_output();. Die function compress_output finden wir in lib/Request.php als Methode in der class Request. Die ominöse Methode compress_output macht im Wesentlichen ein ob_start(‘ob_gzhandler’), was wohl den Ouput (die Response) komprimieren soll, aber wegen nicht näher analysierter gemeiner Kreuz- und Quer-Anhängigkeiten bzw. Nebenwirkungen zu unserem Fehlerverhalten führt. Also in lib/Request.php die drei Zeilen in compress_output auskommentiert und alles läuft bestens.

Wenn man mit dieser Erkenntnis mal in Google nach “phpwiki compress_output” sucht, bestätigt Jeff Dairiki: “Leaving the compress_output() code commented out is fine”. In der Version 1.3.6 gibt es dafür einen eigenen Konfigurations-Parameter define(‘COMPRESS_OUTPUT’, false);. Quelle: http://phpwiki.sourceforge.net/phpwiki?KnownBugs

Formate von Datum und Uhrzeit

Nach der Installation von PhpWiki 1.3.3 “out of the box” erscheinen Datum und Uhrzeit in den Fusszeilen der Seiten unter “Last edited on ….” in verstümmeltem Format. Die Tageszahl erscheint nicht und die Stunde fehlt. Diese Dinge habe ich wie folgt korrigiert:

Wenn man kein Theme aktiviert hat, muss man in lib/Theme.php folgendes ändern:

	 ////////////////////////////////////////////////////////////////
	 //
	 // Date and Time formatting
	 //
	 ////////////////////////////////////////////////////////////////


	 // var $_dateFormat = "%B %e, %Y";
	 var $_dateFormat = "%Y-%m-%d";
	 // var $_timeFormat = "%I:%M %p";
	 var $_timeFormat = "%H:%M:%S";

Wenn man ein Theme akiviert hat, z.B. MacOSX, muss man im Theme d.h. in themes/MacOSX/themeinfo.php folgendes ändern:

  /*
* You may adjust the formats used for formatting dates and times
* below.  (These examples give the default formats.)
* Formats are given as format strings to PHP strftime() function See
* http://www.php.net/manual/en/function.strftime.php for details.
* Do not include the server's zone (%Z), times are converted to the
* user's time zone.
	*/
  // $Theme->setDateFormat("%A, %B %e, %Y"); // must not contain time
  $Theme->setDateFormat("%A, %B %d, %Y"); // must not contain time
  // $Theme->setTimeFormat("%l:%M:%S %p");
  $Theme->setTimeFormat("%H:%M:%S");

Textformatierung für Tabellen

Die Unterstützung von Tabellen ist in TextFormattingRules so schön beschrieben, allerdings konnte ich dem Text dort nicht entnehmen, dass ich ein Plugin dafür benötige. Das vollständige Tabellenbeispiel lautet dann (Wobei man das Plugin nur dann benötigt, wenn man als unwissender Anfänger ein Häckchen bei Use new markup gemacht hat. Im Old Markup geht’s in der Tat ohne.):

Version Funktionen
1.2.6 LDAP Authentication, SQLServer, DBA, Flat File
1.2.4 Plugins: OldStyleTable, PhpWeather, WikiBlog,…
1.2.3 Themes, Plugins
1.2.2 Keine Themes, keine Plugins

Nun sagt mein PhpWiki aber, das es OldStyleTable.php nicht findet. Dieses Plugin habe ich mir dann einfach aus 1.2.4 besorgt und im mein 1.2.3 lib/plugin eingestellt. Alles läuft nun bestens. Toi, toi, toi!

Fulltext-Suchfunktion

Es funktionieren weder die Title-Search- noch die Full-Text-Search-Funktionen.

Symptome
Nach dem Klicken auf den Such-Button in der FindPage erscheint immer die HomePage. Der WebBrowser zeigt eine URL ohne den pagename= an http://dietrich.kracht.free.fr/phpwiki/index.php?s=mist
Eingrenzung
Wenn man die Such-URL per Hand in das Adressenfeld des WebBrowsers richtig ein gibt, funktioniert die Suche.%%%z.B. http://dietrich.kracht.free.fr/phpwiki/index.php?pagename=FullTextSearch&s=spar %%%Es scheint, die Action-URL im Suchformular wird von irgend einem Modul verfälscht (main.php?).
Umgehung
Wenn man in index.php USE_PATH_INFO auf false setzt, funktioniert alles.

Roll-out ins Internet zum Hosting Provider free.fr

Als erstes werden die leeren Tabellen den der MySQL-Datenbank mit Hilfe des mitgelieferten SQL-Scripts angelegt.

Dann wird in index.php die Datenbank-Einzelheiten server-spezifisch festgelegt:

  //////// 2003-12-14 Dietrich Kracht
  if ($HTTP_HOST == 'dietrich.kracht.free.fr') {
		$DBParams[['dsn'] = 'mysql://user:passwd@sql.free.fr/databasename';
  } else if ($HTTP_HOST == 'lonzo.kr8.de') {
		$DBParams[['dsn'] = 'mysql://root@localhost/phpwiki';
  } else {
		$DBParams[['dsn'] = 'mysql://root@localhost/phpwiki';
  }

So kann ich das WikiWiki zunächst lokal testen und dann zum Provider hochladen.

Der erste Aufruf des Wiki beim Provider mit http://dietrich.kracht.free.fr/phpwiki führte noch zum Fehler in FileFinder.php 110 php_uname() disabled. Dies wird von PhpWiki benutzt um das Trennzeichen für Pfad-Aufzählungen zu ermitteln (Windows=’;’, Unix=”:”). Um den Fehler zu vermeiden, wurde ersteinmal das Trennzeichen festverdrahtet in FileFinder.php codiert.

Nach dieser Korrektur taucht ein weiterer Fehler auf. Der Internet Explorer sagt: XML Dokument kann nicht dargestellt werden <DOCTYPE html …> darf nicht in Zeile 4 stehen… Eine Wiederholung im Mozilla Firebird Browser gibt genaueren Aufschluss. Vor dem <?xml …. ?>-Header steht bereits eine Fehlermeldung: index.php:384 putenv() has been disabled for security reasons…. Also raus mit dem putenv(‘LC_TIME=de_DE’) und nun endlich funktioniert mein PhpWiki beim Provider im offenen Internet.

Unlösbares Problem: Provider verlangt USE_PATH_INFO=true und damit funktioniert die Volltextsuche nicht

Konsequenz: Versuch mit PhpWiki 1.3.3 eingestellt. Neuer Versuch mit PhpWiki 1.3.7 (s.o.)

— Main.DietrichKracht – 28 Dec 2003