Modul Updates per Webseite schlagen fehl - Rechte-Problem auf lokalem xampp?

Wenn dein xampp auf Windows läuft, sieh mal nach, ob der Ordner und seine Unterordner/Dateien mit einem Schreibschutz versehen sind und hebe den ggf. auf.

Schreibschutz gibts nicht auf die Dateien und Ordner...

das Problem muss irgendwie mit PHP zu tun haben... mit der neuesten Version vermute ich

Welche Versionen nutzt du denn, Apache? PHP? sind die Ordner als auch die Dateien vom Webserver-User schreibbar?

so, jetzt habe ich wieder das Problem, dass ich Module nicht updaten kann.

bzw. kann ich aus irgend nem Grund keine Verzeichnisse innerhalb des Modulordners (sites/all/modules/modulname) löschen... was dazu führt, dass die Updateprozedur das Verzeichnis nicht gelöscht kriegt, um das neue Modul dann dort hin zu entpacken.

nutze xampp v. 3.1.0.3.1.0 - Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
PHP 5.47
MySQL 5.5.27

der witz ist, bei nem Xamp v.2.6 irgendwas, mit älterem php 5.3x tritt dieser Fehler nicht auf.

Beschreibbar ist das Modules Verzeichnis, denn ich kann per URL zu nem Modul, dieses auch im Webinterface installieren.

Hallo, hatte das Problem auch - allerdings ausschließlich beim Modul Video. Habe dann einfach per FTP das Modul gelöscht, die Fehlermeldungen ignoriert und dann die neue Version installiert. Hat prima geklappt.

Gruß
Alex

sicher is das ne lösung, aber die updatefunktion im backend ist dann doch schon etwas bequemer... irgend einen grund muss es ja geben, wieso drupal hier rumspinnt.

Wie du schon richtig vermutet hast, liegt der Fehler wohl an deiner PHP Version - grundsätzlich läuft Drupal wohl mit der 5.4, hat aber aufgrund recht vieler Änderungen von PHP an einigen Stellen noch Probleme - der Update Prozess scheint eine davon zu sein.
Ich würde dir raten wieder auf die Version 5.3.x zurückzuwechseln - es sei denn du benötigst irgendwelche Features, die dir wirklich nur PHP 5.4 bietet.
Die alten XAMPP Versionen bekommst auf der Sourceforge Seite:
http://sourceforge.net/projects/xampp/files/

Weitere Infos zum Thema unter Anderem hier:
http://drupal.org/node/1813548

Auf drupal.org gibt es auch noch weitere Postings zum Thema - da müsstest du einmal selbst die Suche bemühen..

SteffenR

Aber warum tritt der Fehler nur bei einem Modul auf (bei mir Video) und bei allen anderen funktioniert das update problemlos?

Das hatte ich schon in Erwägung gezogen, allerdings hat 1und1 vor kurzem bekanntgegeben, dass ab 1. April 13 auf php 5.4 umgestellt wird - zwangsweise... Und daher wärs eigentlich ratsamer, das Projekt unter diesen Bedingungen zu testen bevor es live geht...

2 Monate hab ich ja noch

Hast du denn auch wirklich alle Schreibberechtigungen in den Ordnern überprüft ?
Hat der FTP-Nutzer auch wirklich Schreib/Lösch Berechtigungen in den entsprechenden Ordnern ?
Passen die Nutzer / Gruppen vom Ordner - hier am Besten schauen, welche Nutzer / Gruppen den anderen Modulordnern zugeordnet wurden. Kann gut sein, dass PHP 5.4 sich hier anders verhält als die 5.3-er Version, bei der es ja noch geklappt hat oder?
Ist dein temporäres Verzeichnis korrekt konfiguriert ?

Hast du die Log-Files vom Apache auf weitere PHP-Fehlermeldungen überprüft - vlt. lässt sich da ja schon etwas herauslesen..

SteffenR

Ich denke das passt alles.
Wenn ich zb neue Bilder hochladen, werden die ja auch erst in temp gespeichert und dann ins zielverzeichnis verschoben...

Auch der drupal Status meldet das alles ok wär

Per FTP kann ich problemlos Updates, aber nich per backend...

das liegt an den gruppenrechten des ftp nutzers

Anfängerfrage:
und wo soll ich da auf meinem lokalen xampp was umstellen? muss ja dann im filezilla server sein, oder?

angenommen es wäre so wie du sagst, wie erklärst du dir dann den Sachverhalt, dass ich zb. die Sprachaktualisierungen über ein Modul vornehme - und diese ohne Probleme funktionieren... aber die *.po files landen auch im temp ordner und werden zur Sicherheit umbenannt (so zumindest immer der grüne Hinweistext nach dem Update der Sprachfiles)...

irgendwie passt das alles nicht so zusammen, muss da am Montag noch mal schauen...