Wie kann ich Fehler verfolgen und wissen, ob sie vom PmWiki-Kern oder von einer lokalen Konfiguration oder von AddOns/Rezepten herrühren?

Die PHP-Programmiersprache hat unlängst einige Funktionen entfernt oder missbilligt, die PmWiki in der Vergangenheit häufig in AddOns/Rezepten/Skins eingesetzt hat. Der PmWiki-Kern stützt sich nicht mehr auf diese Funktionen, aber einige AddOns tun es weiterhin – hier wird gezeigt, wie Sie sie identifizieren.

Die PmWiki-Architektur erlaubt AddOns (Rezepte, Skins) und lokalen Konfigurationen Aktionen anzumelden, die PmWiki zu einem späteren Zeitpunkt ausführen soll. So kommt es, dass die PHP-Warnung eine Zeile in der pmwiki.php-Datei anzeigt, auch wenn diese von einem Rezept verursacht wird.

Es wird empfohlen, die jüngsten Versionen von PmWiki und all Ihrer Rezepte zu benutzen – bekannte Probleme könnten schon bereinigt worden sein. Nehmen wir an, der Fehler taucht bei den jüngsten Versionen auf.

(1) Zuerst deaktivieren Sie alle AddOns und lokale Konfigurationen (config.php, farmconfig.php, Group.php) – kommentieren Sie sie aus – und testen Sie Ihr Wiki. Wenn die Warnungen bleiben, benachrichtigen Sie uns so schnell wie möglich mit den Informationen, wie der Fehler reproduziert werden kann und wie Ihre Installation (PHP-Version) aussieht. Wenn der Fehler nicht mehr auftaucht, gehen Sie über zu (2).

(2) Aktivieren Sie eine lokale Konfiguration oder ein AddOn und testen Sie ihr Wiki, um zu sehen, ob der Fehler auftaucht.

(3) Wenn der Fehler nicht auftaucht, ist die Ursache des Fehlers wohl woanders. Wenn Sie weitere AddOns aktivieren könnten, gehen Sie zurück zu (2).

(4) Wenn der Fehler aufgetaucht ist, wird er womöglich durch das letzte AddOn oder die letzte Konfiguration verursacht, die Sie aktiviert haben. Durchsuchen Sie die Dokumentation und das Kochbuch nach jüngeren Versionen oder kontaktieren Sie den Autor, der sich um die Wartung und Pflege des Addons kümmert, oder hinterlassen Sie eine Nachricht in der "talk page". Wenn das nicht funktioniert, kontaktieren Sie uns in unserem Problemverfolgungssystem (PITS). Entwickler finden Dokumentationen dazu, wie sie ältere AddOns updaten können, unter Eigene Auszeichnungen und Funktionen.

(5) Deaktivieren Sie das fehlerhafte AddOn wieder und wenn es weiter AddOns gibt, die Sie aktivieren möchten, gehen Sie zu zurück (2).

PmWiki hat eine freundliche und reagierende Gemeinschaft und wir könnten in der Lage sein, rasch Lösungen bereitzustellen.

Nach einem PmWiki-Upgrade erscheinen Warnungen "Token invalid or missing" und die Änderungen werden nicht gespeichert.

Einige lokale Anpassungen könnten ein Update erfordern, bitte sehen Sie hier nach Upgrades#pmtoken.

Nach Upgrades der Website, des Hostings oder des Browsers funktionieren einige Skin-Stile/-Farben und möglicherweise lokale Stile, Rezepte und eingebettete Bilder nicht mehr.

Wenn Sie in Ihrer lokalen Konfiguration die Variablen $PubDirUrl oder $FarmPubDirUrl mit dem http://-Schema definiert haben, ersetzen Sie es durch https://. Auf sicheren Websites laden die jüngsten Browser keine Inhalte von unsicheren URLs.

Nach einem PHP-Upgrade sind einige meiner Regeln deaktiviert worden und ein Tooltip sagt mir (in Englisch) "Markup rule ... is obsolete and has been disabled. See pmwiki.org/Troubleshooting".

Die überholte Markup-Regel sollte in dem Tooltiptitel erscheinen und sollte es einfach machen zu identifizieren, welche eigene Konfiguration oder welches Addon/Rezept diese Meldung verursacht hat. Wenn das nicht offensichtlich ist, folgen Sie den Schritten in dem ersten Abschnitt. Entwickler können die Dokumentation, wie man alte Addons verbessert, in Eigene Auszeichnungen und Funktionen finden.

Mein Wiki zeigt die Warnung an: "Deprecated: Function create_function() is deprecated".

PHP Version 7.2 missbilligte eine Funktion, die PmWiki für Markupdefinitionen und Musterersetzungen benutzt. Es wird empfohlen, PmWiki auf die jüngste Version zu aktualisieren und alle Addons und Skins aus den Kochbüchern? aufzufrischen. Addons in der Kategorie PHP 7.2 werden als kompatibel mit PHP 7.2 angesehen. Wenn Sie ein gewisses Addon brauchen, das noch nicht aufgefrischt wurde, kontaktieren Sie uns. Um Ihre eigenen Addons aufzufrischen, müssen Sie womöglich Ihre Aufrufe von Markup() erneuern, siehe die Seiten Eigene Auszeichnungen, Funktionen und Angepasste Seitenlistenreihenfolge.

Das Rezept PccfToPcfOverride kann eine vorübergehende Lösung liefern, bis Sie all Ihren Add-Ons ein Update verpasst haben.

Beachten Sie, dass PmWiki selbst diese Funktion nicht nutzt, aber (ältere) AddOns könnten Instruktionen anmelden, die erst später abgearbeitet werden sollen. So kommt es, dass die Warnung eine Zeile in pmwiki.php aufzeigt, selbst wenn sie durch eine lokale Konfiguration oder ein AddOn ausgelöst wurde.

Wie Sie herausfinden können, welches Addon die Warnung hervorbringt, finden Sie in dem ersten Abschnitt.

Mein Wiki zeigt eine Warnung 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 PmWiki selbst diese Funktion nicht nutzt, aber (ältere) AddOns könnten Instruktionen anmelden, die erst später abgearbeitet werden sollen. So kommt es, dass die Warnung eine Zeile in pmwiki.php aufzeigt, selbst wenn sie durch eine lokale Konfiguration oder ein AddOn ausgelöst wurde.

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:
$EnableDiag = 1;
Besuchen Sie dann Ihr Wiki mit der Aktion 'ruleset', zum Beispiel https://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, konsultieren Sie den ersten Abschnitt, um dem Fehler auf die Spur zu kommen.

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.

Siehe Kategorien

Mein Wiki zeigt Warnungen an: "PHP Deprecated: crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format" oder "Uncaught ArgumentCountError: crypt() expects exactly 2 arguments, 1 given".

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/MISSBILLIGT
$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/MISSBILLIGT
$DefaultPasswords['edit'] = '@lock'; # OK (und kein 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.)

Mein Wiki zeigt Warnungen an: "Compilation failed: invalid range in character class".

Ein Zeichenklassenbereich (character class range) ist etwas in eckigen Klammern wie [A-Z]. Eine ungültige Zeichenklasse könnte so aussehen: [Z-A], wo das "Z"-Zeichen nicht vor dem "A"-Zeichen kommen sollte. Es ist vielleicht nicht so offensichtlich, aber es wäre innerhalb von eckigen Klammern mit einem Bindestrich zwischen den falschen Zeichen.

Wenn Sie tatsächlich eher einen Bindestrich (ein Minus) finden wollen anstelle eines Zeichenbereichs, müssten sie ihn (es) an den Anfang oder das Ende stellen:
[-AZ] oder [AZ-]

Um den Fehler aufzuspüren, siehe die erste Frage auf dieser Seite. Prüfen Sie außerdem die Variablen $GroupPattern, $NamePattern, $MakePageNamePatterns, $ROSPatterns und andere lokal konfigurierten Kern-Variablen, die in ihrem Namen "Pattern" oder "Patterns" enthalten.

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.

Manchmal wird das verursacht durch unzureichende Dateirechte auf dem Server. Der PHP-Prozess braucht Schreib-/Lese-Rechte (rw) für alle Dateien im wiki.d- und im uploads-Verzeichnis und Leserechte (r) für die Dateien im wikilib.d-Verzeichnis sowie das Recht, in ein Verzeichnis zu wechseln (x) für diese Verzeichnisse. Ziehen Sie die Dokumentation Ihres Providers zurate, um mehr zu erfahren.

Außerdem kann das durch eine Änderung in PHP 5.4 verursacht sein, 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.

Sehr lange Seiten mit tausenden von Zeilen könnten leer erscheinen nach dem Hinzufügen einiger zusätzlicher Zeilen. Das können vorformatierter Text, Tabellen, Text innerhalb bedingter Auszeichnungen oder Text in einer eigenen Auszeichnung sein.

Das kann verursacht sein von den PHP-Beschränkungen, wie weit man beim Suchen nach Übereinstimmungen in regulären Ausdrücken voraussehen und zurück gehen kann. Sie könnten die sehr lange Seite in mehrere Seiten oder die sehr lange bedingte oder eigene Auszeichnung in separate Abschnitte/Blöcke zerlegen oder Sie könnten die PHP-Begrenzungen erhöhen, indem Sie das Folgende zur local/config.php-Datei hinzufügen:
@ini_set('pcre.backtrack_limit', 10000000);

Warum sehe ich befremdliche Fehler nach einem Upgrade?

Versichern Sie sich, dass alle Dateien erneuert wurden, insbesondere pmwiki.php und alle Dateien im scripts/-Verzeichnis.

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 von 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.

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?

Wenn Sie eine Fehlermeldung wie diese sehen:

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 einem 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 der folgenden Alternativen 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 der local/config.php-Datei 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, "406 Not Acceptable", "418 I'm a teapot" oder "Internal Server Error" zurück. Das passiert mit einigen Einträgen, aber nicht mit allen.

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.

Alternativ könnten Sie das Rezept Cookbook:EncodePost ausprobieren.

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 (seit PHP 5.4.0 entfernt). 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 nur mit den 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 (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 (wenn nötig) 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.