Konnte die Datei nicht auf die Festplatte kopieren.

Solange Du die nicht ständig abrufbar hast, ist das kein Problem. Du kannst aber bei schweren Bedenken eine in einem leeren Verzeichnis erstellen, dieses mit .htaccess schützen und dann jottlieb und mir Link und PW per PN senden.

 

Hab es mir mal angeschaut, es ist eigentlich nichts auffälliges dabei. Ich bin mir sehr sicher, dass es ein Problem beim Hoster ist. Möglicherweise gibt es ein Problem mit dem temporären Verzeichnis (Zugriffrechte, Quota).

Könntest Du vielleicht testweise irgendein 08/15-Uploadscript installieren und schauen, ob HTTP-Uploads überhaupt funktionieren?

Achja, die info-Datei solltest Du jetzt seeehr schnell (schneller als sonst ) löschen.

 

Achja, falls testhalber mal woanders Webspace brauchst, dann sag hier im Thread bescheid. Dann könnte ich dir schnell einen Account einrichten.

 

Jau, hab grad was Zeit. Schick mal rüber. Kannst Du auch verschlüsselt via www.zirona.com/kontakt machen. FTP-Zugang wäre auch nicht verkehrt, dann könnte ich kurz ein anderes Upload-Script testen.

Es ist übrigens keine gute Idee gewesen, das phpinfo als Dump in HTML zu speichern. Auf diese Weise wurden Deine Cookies in der Datei gespeichert, und in den Cookies stand u.a. Dein WordPress-Passwort als MD5-Hash. Den hätte ich mit etwas Glück in zwei Sekunden, mit Pech in knapp zwei Stunden geknackt.

 

Ich hatte das selbe Problem mit Wordpress. Die WP-Einstellungen waren korrekt und die Ordner hatten die korrekten Zugriffsrechte. Dazu funktionierte der Upload nur im Wordpress nicht und deshalb konnte ein Problem mit dem Server ausgeschlossen werden.

Nach einigen Suchen bin ich dann auf das Problem gestossen: open_basedir
Ist die Funktion in PHP aktiviert, kann ein Skript nur auf Dateien zugreifen, die im selber Verzeichnis oder darunter liegen. Nicht aber auf Datien, die in höheren Verzeichnissen sind.

Das Problem liegt also am Wordpress: Das Upload-Skript liegt im wp-admin Ordner. Relativ dazu liegt das Standard-Uploadverzeichnis also im Pfad "../wp-contents/uploads". Da das aber in einem höheren Verzeichnis ist, wird der Zugriff von open_basedir verhindert.

Es gibt drei Möglichkeiten, das Problem zu lösen:
- Änderung von Wordpress, so dass über ein Skript im Grundverzeichnis der Upload verarbeitet wird. Damit wird der Pfad zu "wp-contents/uploads" und das Skript kann auch mit open_basedir darauf zugreifen. Das müsste aber ein Wordpress-Entwickler machen.
- open_basedir deaktivieren oder das Grundverzeichnis zu den open_basedir Pfaden hinzufrügen. Das geht nur über die Server-Konfiguration und dürfte nicht bei allen Hostern möglich sein.
- Das Uplaod-Verzeichnis in den Ordner wp-admin verschieben. Keine schöne Lösung, damit sollten Uploads aber wieder funktionieren.

 

Hallo,

ich denke nicht, dass es an Wordpress selbst liegt. Ich habe seit gestern das gleiche Problem nach einer Umstellung eines Servers von PHP4 auf PHP5. Ich bin noch am rätseln woran das genau an PHP5 liegt.

Ich vermute dass der Hoster seinen Server geupdatet hat, dass ist die einzigste Erklärung die mir einfällt, da ich selbst ein Hoster bin.

*EDIT*
Also das Problem scheint definitiv an der PHP5 Etch Version zu liegen. Ich habe soeben auf PHP4 wieder umgestellt und schon geht wieder der Blogger. Nun, also entweder hat PHP5 in der aktuellen Version ein Bug oder Wordpress kommt nicht mit der Version klar. Eines von beiden wird es wohl sein

 

Hallo,

Ist das noch aktuell? Ich hatte gerade das gleiche Problem nach der Umstellung von PHP4 auf PHP5 (im Zuge der Umstellung von Debian-Sarge auf Etch, könnte also noch mehr Umstellerei daran schuld sein).

In der php.ini gibt es einen Eintrag "open_basedir" der steht bei mir auf "/pfad/zum/blog". Das war auch schon bei PHP4 so.

Seit der Umstellung scheint auch noch "upload_tmp_dir" wichtig zu sein, das hatte vorher keinen Eintrag in der ini. Ich hab mir also ein Verzeichnis "/pfad/zum/blog/temp/" angelegt und mit den Einstellungen

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

funktioniert das Bilderhochladen wieder.

Grüße, Max

 

Hallo Max,

das Problem besteht nach wievor. Das hat nicht wirklich etwas mit Debian Etch zu tun, eher mit der PHP5 Version (Version 5.2.0-8 Etch) unter Debian Etch. Mit PHP4 gibt es keinerlei Probleme, auch unter Etch nicht.

Ich habe auch bei Kollegen nachgefragt, die das Problem auf eigenen Servern bestätigen konnten.

Sicher mag das mit der Eintragung in der php.ini zu funktionieren, ist jedoch keine Dauerlösung wenn man Hoster ist und viele viele Kunden hat. Und extra httpd Special Einträge anlegen macht auch kein Sinn, da die Pfade des Wordpress von Kunden immer unterschiedlich sein können. :neutral:

 

Ich hab nicht ausprobiert, was passiert, wenn upload_tmp_dir nicht innerhalb von open_basedir liegt. Vielleicht geht das auch, dann müsste der Massenhoster die Variable nur einmal setzen (wobei er sich halt Gedanken mache muss über den Umstand, dass dann auch alle das gleiche Verzeichnis nutzen. Oder er muss es so setzen dass es im Kontext der einzelnen User doch wieder ein userspezifisches Verzeichnis ist, also irgendwas in dessen Home-Verzeichnis).

Nachträglich pro User bei schon vorhandenen Kunden ändern ist allerdings echt ein Problem....

Wenn es in der Kombination Etch/PHP4 auch geht, ist es ein PHP5-Problem. Ich hab Etch/PHP4 in dieser Hinsicht nicht ausprobiert, ich hab zwar nach dem Upgrade auf Etch schon brav getestet, ob mein Blog geht, bin aber nicht auf die Idee gekommen, auch speziell das Bilderhochladen nochmal zu testen.:-|

 

Ohje. Jetzt hat mich genau dieses Problem bzw. diese Fehlermeldung erwischt -- mit WP 2.5.1 allerdings!
Habe das hier dokumentiert -- vielleicht hat ja jemand einen Tipp? Das nervt leider sehr und macht WP quasi unbrauchbar ...