Problemlösungen {PmWikiDe}

Mein Wiki zeigt Warnungen an: "Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead".

Das wird von einer Änderung in PHP Version 5.5 für die preg_replace()-Funktion verursacht. PmWiki beruht seit Version 2.2.56 nicht länger auf dem überholten Feature (es wird empfohlen auf die jüngste Version aufzufrischen), aber viele Rezepte tun es noch. Beachten Sie, dass auch dann, wenn die Warnung auf eine Zeile in pmwiki.php verweist, die Quelle des Problems eine lokale Konfiguration oder ein Rezept sein kann.

Rezepte und Oberflächen (Skins) werden derzeit aufgefrischt auf PHP 5.5. Sehen Sie nach, ob der Autor eine jüngere Version im Kochbuch veröffentlicht hat. Wenn Sie Ihr PmWiki und Ihre Rezepte aufgefrischt haben und die Warnung noch immer erscheint, finden Sie so heraus, welches Rezept die Warnung verursacht:

Für die PmWiki-Version 2.2.71 oder jüngere Versionen schalten Sie in der config.php-Datei das Diagnosewerkzeug ein:
$EableDiag = 1;
Besuchen Sie dann Ihr Wiki mit der Aktion 'ruleset', zum Beispiel http://www.pmwiki.org/wiki/PmWiki/PmWiki?action=ruleset oder folgen Sie einem Verweis wie [[Main.HomePage?action=ruleset]]. Diese Seite listet alle Markup-Regeln auf. Jene, die potentiell mit PHP 5.5 unverträglich sind, werden mit dem Dateinamen, der Zeilennummer und dem Suchmuster, das diese Warnung verursacht hat, gekennzeichnet.

Wenn die ?action=ruleset-Seite keine so gekennzeichneten Regeln aufführt, kann es sei, dass entweder die Rezepte die preg_replace()-Funktion direkt aufrufen oder sie definieren Suchen&Ersetzen-Muster in unverträglicher Art und Weise. In solchen Fällen sollte Ihre Warnung den Dateinamen und die Zeilennummer enthalten und wenn nicht, kommen Sie ihm so auf die Spur: Deaktivieren Sie in der config.php-Datei alle Rezepte: eingefügte Dateien aus dem cookbook-Verzeichnis oder eigene Skins oder alle Zeilen, die Suchmuster enthalten. Sie können den Zeilen ein # voranstellen, um sie zu deaktivieren. Testen Sie dann das Wiki. Wenn Sie alles deaktiviert haben, sollte die Warnmeldung verschwinden.

Als Nächstes lassen sie die Anpassungen eine nach der anderen wieder zu, testen Sie jedes Mal das Wiki. Wenn an einer Stelle die Warnungen wieder auftauchen, haben Sie den Übeltäter. Die zuletzt zugelassene Anpassung verträgt sich nicht mit PHP 5.5.

Sie können sich an den Autor wenden und (freundlich) darum bitten, das Rezept an PHP 5.5 anzupassen, jüngeren PmWiki-Versionen sind neue Hilfsfunktionen hinzugefügt, die das vereinfachen, siehe Eigene Auszeichnungen. Wenn Sie das Rezept nicht vom Autor repariert bekommen, erzählen Sie's uns (auf englisch), und wir versuchen die Änderungen vorzunehmen.

Bedenken Sie, dass viele Provider erlauben, verschiedene Versionen von PHP einzusetzen. Sehen in der Dokumentation ihres Hosters nach, um zu erfahren, wie eine PHP-Version vor 5.5 eingestellt werden kann.

Schließlich: es ist möglich, die Warnungen zu unterdrücken. Setzen Sie dazu diese Zeile an den Anfang Ihrer config.php:
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);
Das sollte aber nur eine vorübergehende Lösung sein, die nur solange bestehen bleiben sollte, bis Ihre Rezepte repariert worden sind.

Mein Wiki Zeigt Warnungen an: "PHP Deprecated: crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format".

Möglicherweise haben Sie Konfigurationseinstellungen, die in älteren PHP-Versionen funktionierten. Hier wird gezeigt, wie Sie sie aufspüren und wie Sie versuchen können, sie zu berichtigen.

In Ihrer (farm)config.php-Datei oder anderen lokalen Dateien oder in Cookbook-Dateien können Sie jeden Aufruf von crypt durch pmcrypt ersetzen, z. B.:
$DefaultPasswords['edit'] = crypt("my_password"); # DEPRECATED
$DefaultPasswords['edit'] = pmcrypt("my_password"); # OK
$DefaultPasswords['edit'] = array(pmcrypt("pass1"), pmcrypt("pass2")); # OK

Außerdem sollten Sie, wenn Sie Passwörter mit einem Stern (*) gesperrt haben, diese Sterne durch '@lock' ersetzen:
$DefaultPasswords['edit'] = '*'; # DEPRECATED
$DefaultPasswords['edit'] = '@lock'; # OK (and no pmcrypt)

Die $DefaultPasswords-Variablen haben gewöhnlich Schlüsselwörter wie 'edit', 'attr', 'read', 'upload, 'publish'.

Einige Ihrer Seitendateien könnten immer noch die alte Sternsperrung haben. Dateien, die in der Vergangenheit mit der Sternsperrung ausgeliefert wurden, sind Site.GroupAttributes, SiteAdmin.GroupAttributes, Site.AuthUser und/oder PmWiki.GroupAttributes in den Verzeichnissen wikilib.d und/oder wiki.d. Sie müssten Sie in einem Texteditor bearbeiten und jegliche Zeilen unter den folgenden ersetzen:
passwdedit=*
passwdattr=*
passwdread=*
passwdpublish=*
passwdupload=*

Bearbeiten Sie die Datei und ersetzen Sie den Stern (*) durch das Wort @lock in jeder der existierenden Zeilen. Fügen Sie diese Zeilen nicht hinzu, wenn Sie noch nicht existieren, und verändern Sie keine Zeilen, die nach dem Gleichheitszeichen ('=') etwas anderes enthalten als den Stern. Speichern Sie die Seite, laden Sie sie wieder hoch in Ihr Wiki und die Warnungen sollten verschwinden. (Wenn Sie eine Wiki-Farm betreiben, könnten Sie diese Dateien in mehreren wiki.d-Verzeichnissen haben.)

Nach einem PHP-Upgrade sind einige meiner Seiten völlig leer, einige haben leere oder fehlende Abschnitte, aber die Sidebar und die Aktionslinks sind sichtbar.

Das kann verursacht sein durch eine Änderung in PHP 5.4, die die Funktion htmlspecialchars() berührt.

Die einfachste vorübergehende Abhilfe wäre, in Ihrer php.ini oder in .user.ini die default_charset-Direktive auf einen 8-bit-Zeichensatz zu setzen, z. B. cp1252:

       default_charset = "windows-1252"

Oder manchmal funktioniert dies in local/config.php:

       ini_set("default_charset", "windows-1252");

Eine dauerhaftere Abhilfe wäre, Ihre PmWiki-Installation auf eine jüngere PmWiki-Version upzugraden, ebenso ihre Rezepte – und in Ihren eigenen Rezepten ersetzen Sie alle Aufrufe von htmlspecialchars() durch PHSC(), eine PmWiki-Hilfsfunktion für solche Fälle.

Eine leere Seite kommt von der Tatsache, dass in PHP 5.4 die Standardkodierung von einer 8-bit-Kodierung zu einer validierten UTF-8-Kodierung mit variabler Byteanzahl umgeschaltet wurde und dass ein ungültiger UTF-8-String zurückgewiesen wird. Wenn Ihr Wiki eine 8-Bit-Kodierung benutzt, ist es so gut wie sicher, dass das kein gültiges UTF-8 ist. Schlimmer, selbst wenn Sie UTF-8 nutzen, könnten manche Browser ungültige Bits übertragen. Deshalb gibt die PHSC()-Funktion immer vor, dass sie eine 8-bit-Kodierung übersetzt, in der alle Bits gültig sind.

Warum sehe ich befremdliche Fehler nach einem Upgrade?

Versichern Sie sich, dass alle Dateien erneuert wurden, insbesondere pmwiki.php.

Diese Frage taucht manchmal auf, wenn ein Administrator nicht dem Rat gefolgt ist, der auf den Seiten zur Installation und zu ersten Einstellungen gewöhnlich wenig hervorgehoben ist, und die Datei pmwiki.php umbenannt hat anstatt ein index.php-Wrapper-Skript zu schreiben. Wenn Sie pmwiki.php in index.php umbenannt haben, hat das Upgrade Ihre index.php-Datei nicht erneuert. Löschen Sie die alte Version (index.php) und erzeugen Sie ein index.php-Wrapper-Skript, dann kann das nicht wieder vorkommen.

Manchmal versagt ein FTP- oder ein anderes Kopierprogramm dabei, alle Dateien ordentlich zu übertragen. Eine Möglichkeit, das zu überprüfen, ist der Vergleich der Dateigrößen.

Vergewissern Sie sich, dass auch die Dateien im wikilib.d/-Verzeichnis erneuert worden sind. Manchmal ist es eine gute Idee, das wikilib.d/-Verzeichnis vor dem Upgrade zu löschen. (Lokale Kopien der Dateien werden in wiki.d/ und nicht in wikilib.d/ gespeichert.)

Vergewissern Sie sich, dass die Dateirechte richtig gesetzt sind. Die offiziellen Dateien haben einen eingeschränkten Satz von Rechten, die vielleicht nicht für Ihre Site passen.

Wenn Sie ein angepasstes Muster für $GroupPattern benutzen, sorgen Sie dafür, dass es Site ($SiteGroup) und seit PmWiki 2,2 auch SiteAdmin ($SiteAdminGroup) enthält. Ansonsten könnte die Eingliederung (des Upgrades) versagen (z. B. fehlende SiteAdmin-Gruppe für PmWiki 2.2 und später) und/oder Login funktioniert nicht. Zusätzlich sollte auch Main ($DefaultGroup) hinzugefügt werden.

Ich bekomme plötzlich Nachrichten wie "Warning: fopen(wiki.d/.flock): failed to open stream: Permission denied..." und "Cannot acquire lockfile" ... Was ist verkehrt?

Etwas (oder jemand) hat die Rechte an der wiki.d/.flock-Datei oder dem wiki.d/-Verzeichnis verändert, sodass der Webserver nicht mehr in der Lage ist, die "Lock"-Datei zu schreiben. Die normale Lösung ist, die .flock-Datei einfach aus dem wiki.d-Verzeichnis zu löschen — PmWiki wird dann eine neue Datei anlegen. Überprüfen Sie aber auch die Rechte am Verzeichnis wiki.d/ selbst. (Man kann die Rechte am wiki.d/-Verzeichnis mit FileZilla (open-source FTP-Programm) leicht prüfen und ändern, indem man auf die Datei mit der rechten Maustaste klickt → File attributes (Dateirechte)).

Meine Verweise in der Sidebar scheinen auf nicht existierende Seiten zu zeigen, obwohl ich genau weiß, dass ich sie angelegt habe. Wo sind die Seiten?

Verweise in der Sidebar müssen mit einer Wikigruppe qualifiziert sein, damit sie ordentlich funktionieren (benutzen Sie [[Gruppe.Seite]] anstatt [[Seite]].
Und schreiben Sie SideBar mit einem großen 'B'.

Warum sehe ich die Nachricht "PHP Warning: Cannot modify header information - headers already sent ..." oben auf meiner Seite.

Wenn das der erste oder einzige angezeigte Fehler ist, ist das gewöhnlich ein Zeichen dafür, dass vor dem <?php oder hinter dem ?> in einer Anpassungs-Datei wie config.php zusätzliche Leerzeichen oder leere Zeilen vorhanden sind. Überprüfen Sie die Dateien noch einmal und versichern Sie sich, dass es keine zusätzliche Zeichen, Leerzeichen oder leere Zeilen vor dem einleitenden <?php gibt. Es ist oft am einfachsten und am sichersten, alle schließenden ?> einfach zu löschen und wegzulassen. In Windows könnte es nötig sein, aber sollte nicht nötig sein, einen Editor zu benutzen, der die LFCR-Zeilenenden in LF-Zeilenenden in der local/config.php-Datei ändern kann (z. B. das frei erhältliche notepad++) oder einen Hex-Editor.

Wenn Sie die Datei speichern, sollte der Zeichensatz entweder cp1252/Windows1252 oder UTF-8 ohne BOM (Byte Order Mark) sein. notepad++ ist ein Editor, der das leistet.

Wenn Sie die Dateien übertragen, stellen Sie in Ihrem FTP-Programm die Übertragung im Textmodus ein oder, wenn das nicht hilft, im Binärmodus.

Wenn die Warnung nach anderen Warnungen oder Fehlermeldungen erscheint, lösen Sie zuerst die anderen Probleme und die Warnung dürfte verschwinden.

Wie bekomme ich eine PHP-Warnung über function.session-write-close weg?

Sie sehen eine Fehlermeldung wie diese:

Warning: session_write_close() [function.session-write-close]:
open(/some/filesystem/path/to/a/directory/sess_[...]) failed: No such file
or directory (2) in /your/filesystem/path/to/pmwiki.php on line NNN

PmWiki benutzt manchmal PHPs session-handling-Funktionen zum Verfolgen der Sitzung. Damit die Verfolgung der Sitzung funktioniert, müssen Informationen in ein Verzeichnis auf dem Server gespeichert werden. Das Verzeichnis muss existieren und die Webserver-Software muss Schreibrechte für dieses Verzeichnis haben. Für diese Beispiel sei die Webserversoftware so konfiguriert, dass es die Daten in das Verzeichnis

schreibt, aber das Verzeichnis existiert nicht. Die Lösung ist, wenigstens eine Alternative auszuführen:

• Legen Sie das Verzeichnis an und vergewissern Sie sich, dass es vom Webserver beschrieben werden kann.
• Setzen Sie einen session_save_path-Wert, der auf ein beschreibbares Verzeichnis zeigt, z. B. in config.php:

Warum fordert mich PmWiki mehrfach zur Eingabe eines Passwortes auf, das ich schon längst eingegeben habe?

Das kann wie aus dem Nichts passieren, wenn Ihr Provider/Hoster ein Upgrade auf PHP 5.3 vorgenommen hat und Sie ein älteres PmWiki benutzen. Eine jüngere PmWiki-Ausgabe wird das Problem lösen.

Alternativ kann das ein Zeichen dafür sein, dass der Browser keine Cookies akzeptiert oder dass PHPs Sitzungsbehandlungsfunktionen auf dem Server nicht sauber konfiguriert sind. Wenn der Browser Cookies akzeptiert, versuchen Sie $EnableDiag=1; in local/config.php zu setzen, rufen sie PmWiki mit ?action=phpinfo auf und prüfen Sie, dass Sitzungen (sessions) aktiviert sind und dass der session.save_path einen brauchbaren Wert hat. Beachten Sie, dass mehrere PHP-Versionen unter Windows erwarten, dass ein session_save_path explizit gesetzt ist (das können Sie in der local/config.php-Datei machen). Versuchen Sie auch, session.auto_start in ihrer php.ini auf 1 zu setzen.

Sehen Sie auch bei der Frage Ich muss mich zweimal einloggen weiter unten nach.

Ich habe config.php bearbeitet, aber wenn ich auf meine Wikiseiten sehe, sehe ich nur"Parse error: parse error, unexpected T_VARIABLE in somefile on line number.".

Sie haben einen Fehler in dem PHP-Code gemacht, den Sie in die config.php eingefügt haben. Der häufigste Fehler, der zu einem T_VARIABLE-Fehler führt, ist ein vergessenes Semikolon am Ende einer hinzugefügten Zeile. Der Dateiname und die Zeilennummer zeigen, wo sie nach dem Fehler suchen müssten.

Suchen und Seitenlisten hörten auf zu funktionieren, nach dem ich ein Upgrade gemacht habe — Fehler werden nicht gemeldet, aber Verweise auf andere Seiten erscheinen nicht (oder erscheinen nicht so wie sie sollten) — was ist da los?

Gehen Sie sicher, dass auch alle Dateien aus dem wikilib.d/-Verzeichnis ersetzt wurden. Insbesondere hört sich das so an, als fehlte die Site.PageListTemplates-Seite (wenn keine Verweise auftauchen) oder als sei es eine ältere Version (wenn die Verweise nicht erscheinen wie sie sollten). Stellen Sie auch sicher, dass Leserechte (attr) für die Seiten Site.PageListTemplates und Site.Search gesetzt sind.

Einige meiner Einträge (posts) kommen mit "403 Forbidden"-Fehlern, "Not Acceptable" oder "Internal Server Error" zurück.

Ihr Server hat möglicherweise mod_security aktiviert. Das mod_security-"Feature" scannt alle hereinkommenden Einträge auf verbotene Wörter oder Phrasen, die anzeigen, dass jemand versucht, das System zu hacken. Wenn nur eines davon auftaucht, gibt Apache den "403 Forbidden"- oder "406 Not Acceptable"-Fehler zurück. Gewöhnlich sind es Phrasen wie "curl", "wget", "file(" und "system(", die tendenziell mod_security anstoßen, obwohl es noch viele weitere gibt (abhängig von der Konfiguration, Prozentzeichen, HTML-Tags, internationalen Zeichen).

Da mod_security die Seitenanforderung (request) unterbricht und die "forbidden"-Nachricht zurücksendet, bevor PmWiki je eine Chance hatte zu starten, ist es kein Fehler in PmWiki, und es gibt wenig, was PmWiki dagegen tun kann. Stattdessen muss man die Webserverkonfiguration ändern, um mod_security zu deaktivieren oder man konfiguriert mod_security so um, dass es die verbotenen Wörter erlaubt. In einige Sites ist es möglich, mod_security zu deaktivieren, indem SecFilterEngine off in einer .htaccess-Datei eingefügt wird.

Ich erhalte folgende Nachricht, wenn ich versuche ein Bild hochzuladen. Was kann ich tun?

Warning: move_uploaded_file(): SAFE MODE Restriction in effect. The script whose uid is 1929 is not allowed to access /home/onscolre/public_html/pmwikiuploads/Photos owned by uid 33 in /home/onscolre/public_html/pmwiki/scripts/upload.php on line 198

PmWiki can't process your request

?cannot move uploaded file to /home/onscolre/public_html/pmwikiuploads/Photos/FoundationPupilsIn1958.jpeg

We are sorry for any inconvenience.

Ihr Server ist mit dem aktivierten PHP-Safe-Mode konfiguriert. Konfigurieren Sie Ihr Wiki so, dass es ein site-weiten Upload-Präfix nutzt, erzeugen Sie dann das upload/-Verzeichnis manuell und setzen Sie die Rechte auf 777 (anstatt PmWiki das Verzeichnis anlegen zu lassen).

Ich sehe neuerdings "Division by zero error in pmwiki.php..." auf meiner Site. Was ist da los?

Es ist ein Fehler, der mit Tabellen-Auszeichnungen und nur bei Versionen von PHP >= 4.4.6 oder >= 5.2.0 auftaucht. Oft scheint er "aus dem Nichts" aufzutauchen, weil der Serveradministrator ein stilles Upgrade von PHP vorgenommen hat. Versuchen Sie ein Upgrade auf eine spätere PmWiki-Version, um den Fehler zu beseitigen oder versuchen Sie, das Folgende in local/config.php einzutragen:

$TableRowIndexMax = 1;

Ich muss mich zweimal (2-mal) einloggen. –oder– Mein Passwort wird nicht verlangt, obwohl das eigentlich so sein sollte. –oder– Ich habe mein Passwort geändert, aber es ist immer noch das alte aktiv. –oder– Mein config.php-Passwort überschreibt nicht mein farmconfig.php-Passwort.

Das kann passieren, wenn (farm)config.php oder ein eingefügtes Rezept die Funktion CondAuth() oder RetrieveAuthPage(), PageTextVar(), PageVar() und mögliche andere Funktionen direkt aufruft, bevor (das nötige) AuthUser eingefügt wurde.

Die Reihenfolge in config.php ist sehr ausschlaggebend.

Beim Bearbeiten einer vorhandenen Seite verursacht das "Save" ein Nicht-Antworten des Servers (nicht eine leere Seite, gar keine Antwort, ein endloser Versuch, eine Verbindung aufzubauen). Um davon wegzukommen, ist es nötig, eine andere Seite aufzurufen (z. B. durch einen Klick auf deren Link im Menü). Und Horror!, die ...?action=edit ist blockiert, es wird unmöglich, eine Seite zu bearbeiten.

Wenn das Speichern einer bearbeiteten Seite eingeleitet wird, wird eine (versteckte) Datei namens .flock im wiki.d-Verzeichnis erzeugt. So lange diese Datei existiert, ist es unmöglich, eine (andere) Datei zu speichern. Die Datei .flock zeigt an, dass eine Speicherung nach einer Bearbeitung im Gange ist, und wird automatisch gelöscht, wenn die Bearbeitung erfolgreich mit "Save" abgeschlossen wird. Im Falle eines Crash bei der Speicherung wird diese Datei nicht vernichtet. Das Heilmittel ist, mit einem FTP-Programm, das auf das Anzeigen versteckter Dateien eingestellt ist, die .flock-Datei zu löschen. Und alles ist wieder gut. Dieses Verhalten wird typischerweise verursacht durch einen Fehler, der (direkt oder indirekt) eine Endlosschleife in einem Rezept verursacht, das durch das Speichern der bearbeiteten Seite ausgelöst wurde.

Ich erhalte den Fehler "Data Mismatch - Locking FAILED!"

Das ist wahrscheinlich kein PmWiki-Fehler. PmWiki kann wegen eines zugrundeliegenden Dateisystemproblems keine Sperrdatei erzeugen. Zum Beispiel ist die 'disk quota' ausgeschöpft (z. B. durch eine Fehlerlogdatei oder durch hochgeladene Dateien), oder es gibt Probleme mit den Schreibrechten im Dateisystem.