[gelöst] nach update auf 7.37 kein Bilder upload möglich
am 25.05.2015 - 22:20 Uhr in
Hallo drupal community,
nach einem mehr oder minder erfolgreichen update von 7.34 auf 7.37 habe ich Probleme.
Nr.1: der upload von Bildern/pdf's funktioniert nicht mehr, es kommt die beiliegende Fehlermeldung, Zugriff verweigert. Kann das an den Zugriffsrechten liegen, im gesamten sites Ordner und den Unterordnern = 755. Stimmt das so? Wo erfahre ich für den Fall, welche Rechte welche Ordner haben sollten? IMCE und CKeditor sind in Verwendung.
Nr.2: hier kommt eine ganze Fehler-Litanei:
Hab ich einen Ordner "private" nicht angelegt, wo sollte er liegen? Ich hatte mir eine komplett "frische" Installation von drupalcenter heruntergeladen, entpackt und unverändert auf den Server geladen, wie kann dabei ein Ordner fehlen? Egal, ich erstelle ihn gerne - aber wohin?
Warning: is_dir(): Unable to find the wrapper "private" - did you forget to enable it when you configured PHP? in file_prepare_directory() (Zeile 437 von /home/.sites/312/site9828120/web/includes/file.inc).
Warning: XMLWriter::openUri(): Unable to find the wrapper "private" - did you forget to enable it when you configured PHP? in XMLSitemapWriter->openUri() (Zeile 39 von/home/.sites/312/site9828120/web/sites/all/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
Fehlt beim xml writer auch ein Ordner?
Warning:XMLWriter::openUri(private://xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM/1.xml): failed to open stream: No such file or directory in XMLSitemapWriter->openUri() (Zeile 39 von /home/.sites/312/site9828120/web/sites/all/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
Warning: XMLWriter::openUri(): xmlNewTextWriterFilename : cannot open uri in XMLSitemapWriter->openUri() (Zeile 39 von /home/.sites/312/site9828120/web/sites/all/modules /xmlsitemap/xmlsitemap.xmlsitemap.inc).
Das kann ich ebenfalls nicht entschlüsseln. Ich hab einen sehr alten Foreneintrag zu einer ähnlichen Fehlermeldung gefunden, weiß nicht, ob das hier auch brauchbar wäre - ein patch.
Notice: Undefined index: name in system_requirements() (Zeile 34 von /home/.sites/312/site9828120/web/modules/system/system.install).
Notice: Undefined index: version in system_requirements() (Zeile 36 von /home/.sites/312/site9828120/web/modules/system/system.install).
Wer hilft mir bei der Entwirrung und Korrektur?
Mit bestem Dank,
Martin
Anhang | Größe |
---|---|
fehlermeldung-bei-uploadversuch.PNG | 298.23 KB |
- Anmelden oder Registrieren um Kommentare zu schreiben
Dann beschreibe mal genau,
am 25.05.2015 - 22:51 Uhr
Dann beschreibe mal genau, wie Du den Update gemacht hast und zwar Punkt für Punkt. Für mich sieht das so aus, als hättest Du die Datenbank beschädigt. Wenn es vor dem Udate ein Private Filesystem gegeben hatte (zu erstellen unter Konfiguration > Medien > Dateisystem) sollte diese Definition auch nach dem Update in der Datenbank vorhanden sein.
Ich hoffe, Du hast einen Backup vom alten Zustand (Datenbank und File-System). Außerdem sollte man den Update immer erst auf einem Testsystem durchführen um zu sehen, ob alles glatt geht. Man spielt nie zuerst auf dem Life-System!
Wenn Du Dein Vorgehen genau erklärst, kann man Dir vielleicht helfen, aber Deine Beschreibungen reichen dazu nicht.
.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *
update Beschreibung
am 26.05.2015 - 07:30 Uhr
Hallo Werner,
Ja, ein backup habe ich, dh. eine Kopie aller Drupal Dateien am Server und natürlich der Datenbank.
Das update habe ich wie folgt gemacht
1.) nicht gebrauchte Module entfernt
2.) alles gesichert
3.) mir eine aktuelle Version 7.37 geholt
4.) diese auf den Server hochgeladen und in einem Unterverzeichnis installiert, settings.php angepasst und beschreibbar gemacht/wieder zurück
5.) durch veränderten serverseitigen Pfad die neue Installation in Gang gesetzt und erfolgreich getestet
Danach dachte ich mir nichts mehr, die alte Installation zu entfernen.
habe dann die neue drupal Installation vom Unterverzeichnis ins Hauptverzeichnis verschoben und gestartet.
Die Datenbank habe ich nicht angefaßt, hatte auch vorher nie (oder nicht bewußt) ein privates Dateisystem angelegt.
Mit der gleichen Prozedur habe ich 2 andere webprojekte ebenso erfolgreich upgedatet, die zwar etwas kleiner waren (und bei alfahosting, wo alles etwas einfacher läuft) - aber trotzdem. Diese "Problem"projekt ist bei world4 you gehostet.
Ich hoffe meine Angaben sind informativ genug - bin bei so speziellen Fragen noch unerfahren.
lg Martin
Ich habe mit Deiner
am 26.05.2015 - 09:31 Uhr
Ich habe mit Deiner Vorgehensweise Probleme. Was ist mit dem originalen sites-Verzeichnis passiert? Das wird nämlich beim Update grundsätzlich ausgespart, d.h. es wird aus der neuen Version alles außer dem sites-Verzeichnis hochgeladen. Da scheint bei Dir das Problem zu liegen. Im sites-Ordner liegen die spezifischen Informationen für die Installation wie die zusätzlichen Module oder Themes sowie alle hochgeladenen Dateien und Bilder. So wie Du es beschreibst, hast Du das sites-Verzeichnis einfach durch das neue ersetzt und nur die settings.php angepaßt. Das ist falsch. Hier noch mal meine Vorgehensweise:
Spiegeln des Systems auf einen lokalen Rechner
Update wie folgt
Danach den Update auf dem Life-System durchführen und wieder testen.
Bei einem Modul-Update führe ich den auch zunächst auf dem lokalen System durch und teste. Danach kommt erst der Update auf dem produktiven System. Auch dabei nie den update.php vergessen.
Prüfe bitte noch mal genau, wo Deine Vorgehensweise von meiner abweicht. Du hast nämlich evtl. nicht alle Details hier vermerkt.
.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *
zum update Vorgang ergänzt
am 26.05.2015 - 13:37 Uhr
In meiner Aufzählung habe ich das vergessen zu erwähnen: natürlich hab ich den alten sites Ordner gesichert und in die neue Installation eingefügt.
Wie gesagt, bei zwei anderen projekten hat es anstandslos funktioniert. Alle Module sind nach dem update ordnungsgemäß gelaufen.
Auch der hier beschriebene Problemfall lief noch fehlerfrei, als ich ihn im Unterverzeichnis testweise laufen ließ - wobei ich nicht alle Funktionen geprüft habe, muss ich zugeben.
Wie kommt es, dass
a.) alle erforderlichen Bilder angezeigt werden (da bestand am Anfang ein Problem, sie wurden erst angezeigt, nachdem ich die Zugriffsrechte neu eingerichtet habe)
b.) ein upload von Bildern nicht funktioniert, weil Zugriff nicht möglich.
Sind die Rechte 755 (ordner), 644 (dateien) so wie sie sein sollen oder gibts da spezielle Anforderungen?
Das hängt von der Art der
am 26.05.2015 - 16:22 Uhr
Das hängt von der Art der Installation ab. Wenn der Webserver-Prozess unter einer anderen ID läuft wie der FTP-user, der die Daten auf den Server gespielt hat, sollen das files-Verzeichnis und alle Unterordner auf 777 stehen, die Dateien sollten dann 666 haben, damit die Rechte ausreichend sind.
.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *
Datei upload weiter unklar
am 26.05.2015 - 17:33 Uhr
Mit der 777 Einstellung konnte ich das Problem nicht lösen, habs wieder auf 755 zurückgestellt, wie in den anderen Projekte auch.
Ich habe zwischenzeitlich die Module ckeditor + imce ausgetauscht, aber der upload geht dennoch nicht. Zugriff verweigert.
Gibts noch andere Ideen, wie ich das lösen könnte, außer meine Kopie des alten drupal wieder hochzuladen?
Ohne auf die Innereien Deiner
am 26.05.2015 - 18:05 Uhr
Ohne auf die Innereien Deiner Installation zu sehen, kann Dir vermutlich niemand weiterhelfen. Dazu braucht es Admin und FTP-Zugang. Aus Deiner Beschreibung kann ich nicht erkennen, wo das Problem liegen könnte. Sorry
.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *
Hallo,hast Du mal alle
am 27.05.2015 - 07:19 Uhr
Hallo,
hast Du mal alle Chaches geleert?
private://xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM/1.xml
Das ist eine gecachte Datei, die ist sicher nicht vorhanden oder?
Soweit ich weiss sollte im privaten Filesystem ach eine durch Drupal generierte .htaccess vorhanden sein.
Ist diese da, wenn Du das private Dateisystem anschaltest?
MfG
Robert
https://awri.ch
Ich habe eine Schweizer Tastatur und daher kein scharfes ß ;-)
ja alle caches geleert
am 27.05.2015 - 10:19 Uhr
Hallo Robert,
die caches wie gesagt sind alle geleert. Die genannte Datei ist eben schon vorhanden, auch der Ordner. Dennoch habe ich nicht verstanden wie und wo man das "private Dateisystem" anschalten kann. Wo es (private://) sich befindet? Einen solchen Ordner gibts nicht, ist er bei der Übersiedelung verloren gegangen? Da fehlt es mir einfach an Grundsatzwissen.
Beim Problem mit der xml sitemap denke ich schon an eine radikale Lösung, deinstallieren und die sitemap neu erstellen lassen - das ist nicht so schlimm.
Viel schwieriger wirkt sich der Defekt aus, dass keine Dateien mehr hochgeladen werden können. Weil der Kollege oben gemeint hat, ohne Einblick ins System geht es nicht. Sehe ich auch so. In dem webprojekt sind umfangreiche vertrauliche (weil Therapiesachen) Daten, daher kann ich hier im Forum niemanden reinschauen lassen.
Falls noch wer zum upload Problem eine Idee hat, bitte gerne, ansonsten danke für eure Bemühungen.
Probleme nachupdate auf 7.37
am 27.05.2015 - 10:28 Uhr
Das grösste Problem ist immer noch, dass kein Dateiupload möglich ist, z.B. beim Versuch, Bilder einzufügen und wenn ich auf "server durchsuchen" gehe.
Ich vermute auch, dass es ohne tieferen Einblick nicht geht. Ich selbst kenne mich da zu wenig aus. Den Zugang darf ich wegen der Vertraulichkeit der Daten nicht weitergeben. Es ist ein Projekt, in dem sich TherapeutInnen über psychologische Inhalte und Fallbeispiele austauschen/weiterbilden. Danke für deine Bemühungen.
Ein privates Filesystem wird
am 27.05.2015 - 10:29 Uhr
Ein privates Filesystem wird unter Konfiguration > Medien > Dateisystem eingeschaltet. Damit aber nicht über Tricks darauf zugegriffen werden kann, gibt man dazu meist einen Pfad an, der außerhalb des DocumentRoot der Webseite und damit auch außerhalb der Drupal-Installation liegt. Wenn Du das beim Umzug nicht berücksichtigt hast, sind diese Daten nicht mit umgezogen.
.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *
danke, war wichtig
am 27.05.2015 - 11:17 Uhr
Daran habe ich nicht gedacht, so gut kenne ich Drupal noch nicht - ich erinnere mich aber jetzt wieder an den Eintrag und dass am Server ein Ordner außerhalb war, der sich auch nicht löschen/bewegen ließ.
Somit kann ich das eventuell wieder reparieren. Danke.
Problem(e) gelöst
am 03.06.2015 - 08:43 Uhr
Also: spät aber doch habe ich Lösungen für die Fehler gefunden.
1.) das Modul xmlsitemap deinstalliert, dann einen ordner ausserhalb drupal angelegt und in den einstellungen vom wieder installierten xmlsitemap-modul diesen speicherort angegeben. damit hat das gleich geklappt. nun kenne ich auch ein stück mehr hintergrund von drupal.
2.) wegen dem blockierten bilder upload: zufällig finde ich eine fehlermeldung, dass ein modul oder installiertes teil NICHT mit der aktuellen drupal version 7.37 zusammenpasst. Ich finde das modul media-youtube (name so ähnlich) und entferne dieses, update, cron, caches geleert und siehe da, der upload jeglicher dateien läuft wieder. da hat anscheinend das nicht kompatible modul den IMCE blockiert.
Danke jedenfalls für alle Beiträge.