Diese Meldung von WordPress beim Versuch ein Bild hochzuladen, kann sich aus vielerlei Gründen einstellen. Einen Unterschied macht es bereits, ob die Meldung schon unmittelbar nach der Neuinstallation auftritt, oder einen aus heiterem Himmel in einer bestehenden Installation trifft, in der bisher alles einwandfrei funktionierte.
Bei einem geeigneten Hostingprodukt und den Standarddateirechten eines frisch installierten WordPress-Pakets sollte das System sofort einsatzbereit sein, und der Medienupload problemlos funktionieren.
Wenn das Hochladen von Medien gleich nach der Installation schon scheitert, ist das ein Hinweis darauf, dass etwas mit der Konfiguration nicht stimmt, möglicherweise vom Server, oder auch PHP. Wahrscheinlicher ist allerdings, dass PHP als Apache-Modul eingerichtet ist, und man als WordPress-User nicht mit den Dateirechten ausgestattet ist, die den gesetzten Dateirechten entsprechen.
Nachfolgend eine Auflistung bereits ermittelter Ursachen dafür, die den Bildupload ganz oder teilweise (z.B. Datei auf dem Server, aber in der Mediathek nicht sichtbar, oder es fehlt das Vorschaubild) blockierten.
Nicht ASCII-konforme Zeichen (z.B. Umlaute) in Dateinamen können bewirken, dass Vorschaubilder in der Mediathek nicht angezeigt werden. Stattdessen bekommt man eine graue Fläche. Die Originaldatei kann jedoch betrachtet und verwendet werden.
Das zugeteilte Pensum an Festplattenspeicher ist aufgebraucht, z.B. weil zu viele Backupkopien behalten wurden, oder weil die Kapazitäten des Hostingpakets unterdimensioniert sind. Das wird auch zu Problemen bei Updates von Komponenten oder WordPress selbst führen und erfordert daher dringende Behebung. Aus den verfügbaren Informationen in der Verwaltungsoberfläche des Webhostingprodukts sollte das ggf. hervorgehen.
Das PHP zur Verfügung gestellte memory_limit wurde überschritten. Manche Themes definieren zusätzliche Bildgrößen, mithin gar nicht mal wenige. Im Moment wo beim Upload die Zuschnitte gemacht werden, steigt dann der Speicherbedarf. Reicht der Speicher nicht aus, bricht der Prozess mit einem Fehler ab.
Im Zusammenhang mit der Verwendung des Plugins Post Type Switcher landeten Bilder zwar auf dem Server, wurden aber nicht in die Mediathek aufgenommen.
Im Zusammenhang mit Sicherheitsplugins oder auch manuellen Sicherheitseinstellungen (.htaccess
) kann ein sich auf das Uploadverhalten auswirkender Fehler ebenfalls auftreten (an 403-Meldung im Debugmodus zu erkennen). Mithin ganz plötzlich, ohne dass sich etwas durch Updates geändert hätte (beispielsweise durch ein Serverupdate, z.B. neuere Apache-Version). Liegt eine .htaccess
-Datei im Verzeichnis wp-content
oder wp-content/uploads
könnte diese von einem Sicherheitsplugin dort abgelegt worden sein. Die Datei umbenennen und es dann nochmal versuchen verschafft Gewissheit.
Es gab eine Phase, da setzte ich unter anderem das Sucuri Security Plugin ein, das man so konfigurieren kann, dass Verzeichnisse vor Zugriffen geschützt werden. Nach der Deinstallation des Plugins blieb die eine oder andere .htaccess
zurück. Auch das konnte nach Umstellungen in der Serverumgebung dazu führen, dass die Mediathek von »heute auf morgen« keine Bilder mehr annahm (in einem Fall nach einem Update auf Apache 2.4.18 bewirkte eine „vergessene“ .htaccess
unter anderem auch, dass jQuery nicht mehr geladen wurde).
Auch durch ein Theme oder Plugin bedingte Skriptfehler (neu installiert und aktiviert? oder gab es grade ein Update?) haben das Potential, gewohnte Funktionalität zu blockieren (500er-Fehler). Passiert es nach einem Update oder unvermittelt (»beim letzten Mal funktionierte noch alles«) hilft es zu ermitteln, was sich seit diesem Status verändert hat (ggf. upgedatete Elemente vorübergehend deaktivieren). Recht konkret werden die Informationen dann, wenn man in der Datei wp-config.php
folgende Zeile einfügt:
Schnellverfahren (Fehler gleich im Browser anzeigen)
define('WP_DEBUG',true)
Diskretes Verfahren (Fehler in ein Debuglog schreiben lassen)
define('WP_DEBUG',true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Den Vorgang der den Fehler auslöst wiederholen und anschließend die Datei debug.log
aus dem Verzeichnis wp-content
downloaden und nachsehen, wer oder was den Fehler erzeugte.
Sobald die Ursache gefunden ist, die Codezeilen ausmarkieren oder löschen und die wp-config.php
erneut hochladen. Je nach eingesetzten Plugins oder Theme kann so ein Log durch das Aufzeichnen sich permanent wiederholender Fehler oder Hinweisen ansonsten über die Zeit recht groß werden.
Plugins wie Query Monitor zeigen Fehler ebenfalls an, und sind dabei recht ausführlich.
PHP-Version
In einem Fall führte die Umstellung auf PHP 5.6.x bei einem ganz bestimmten Hoster zu dem Fehlerbild. Eine Umstellung auf eine andere Version löste das Problem wieder.
Auch nur einmal gesehen war die Änderung der Art und Weise, wie man die PHP-Version auswählt. Früher ging das über .htaccess
, später musste man die Version direkt in den Einstellungen bestimmen (und nichts weiter tun). Ein „Fallback“ auf die niedrigste noch verfügbare PHP-Version als Apache-Modul nach der Umstellung führte auch hier zu Problemen beim Upload und Aktualisierungen von Komponenten.
ImageMagick
Beim Hoster webgo stieß ich mehrfach auf das hier beschriebene Problem mit ImageMagick.
Schreibe einen Kommentar