[gelöst] Bilder nur im privaten Dateisystem sichtbar ??

Das sind recht wenig Infos, um den Fehler zu suchen. Überprüf doch bitte mal, ob die Pfade zu den Bildern stimmen.

Kann es vielleicht sein, dass du zwischen öffentlich und privat hin- und hergeschaltet hast? Dann beachte den Hinweis beim Dateisystem:

Es gab bereits von Anfang an Probleme, daher musste ich auf Privat umstellen, sonst werden eben die Bilder der image gallery nicht angezeigt.

Kurioserweise bleiben meine Blogbilder (per Tiny eingebunden) sichtbar, alle per FUpload (über "Inhalt erstellen / Bilder") verschwinden im Öffentlichen.

Die Pfade sind übrigens in beiden Modis identisch, nur werden eben im "Öffentlichen" keine Bilder angezeigt ....

Urgs! Den privaten Modus willst du definitv nicht benutzen um deine Bilder anzuzeigen. Da muss der Webserver für jedes Bild (inklusive Bilder des Themes), jede JS und jede CSS Datei die zu einer Seite gehört eine Instanz von Drupal booten. Da machen dann schon relativ wenig Besucher deinen Webserver platt, wenn sie zeitgleich darauf zugreifen.

Bezüglich deines eigentlichen Problems: Schau mal unter admin/settings/image. Vielleicht stimmt da der Pfad nicht.

Was ich will und was Drupal macht, sind leider 2 Paar Stiefel. Die Pfade stimmen und kurioserweise sind auch die Bilder im korrekt angegebenen und gefundenen Pfad da. Aber angezeigt werden sie eben nur im privaten Modus.

Auch ein neues Hochladen mit öffentlicher Einstellung funktioniert nicht. Die Dateien werden nicht hochgeladen, nur angelegt und erscheinen dann mit dem roten Kreuz.

Steht der Modus auf Privat, erhalte ich in den Eigenschaften im Browser den Pfad www.domain.xxx/system/images/test.jpg und alles ist ok.
Steht der Modus auf Öffentlich, erhalte ich dagegen den korrekten Pfad www.domain.xxx/sites/default/files/images/test.jpg udn darin befinden sich auch die Bilder. Nur sie werden nicht angezeigt.

Das Problem besteht übrigens bei nem Kollegen ebenfalls bei Strato, womit ich fast glaube, dass es an der Serverkonfig liegen muss.

Bilder, die ich per Tyni MCE eingebunden habe, funktionieren komischerweise in beiden Modis und immer wird der ..../system/.... Pfad angezeigt. Gehe ich in den öffentlichen Modus, kann ich aber auch da nix einbinden aber bestehende Bilder werden wenigstens angezeigt.

So, ne Anfrage im Strato Support Chat war schonmal ein Griff ins Klo. Wurde zuerst abgecancelt, das sei nicht das Mailformular und als ich darauf hinwies, das ich doch annehme, das ich im Support Chat bin und der Text ein wenig ausführlicher wurde, weil ich ja ne halbe Ewigkeit warten musste ....

Naja, die Dame hatte keine Ahnung und gab es an die Technik weiter, die sich melden wird.

Für was brauch ich da nen Chat, wenn der net helfen kann ?? Sonst fragen die immer nach aber ich glaube, die Gute wollte bald in den Mittag ....

Naja ....

Nachtrag:

So, habe bei denen angerufen und es ist laut Hotline alles in Ordnung.

Was ich aber herausgefunden habe:

Wenn ich "SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006" aus der .htaccess herausnehme, geht alles 1A !!

Was heisst das jetzt ??

Kann ich das nun weglassen oder muss ich irgendwie herausfinden, warum der Handler nicht funktioniert ?? Ich habe leider keine Zugriffe auf die Logs des Servers ....

Tja, gute Frage! Drupal_Security_Do_Not_Remove_See_SA_2006_006 ist ein von Strato vergebener, symbolischer Name. Da wirst du dich wohl durch deren Security Advicements zur Nummer 2006/006 durchgraben müssen. Alternativ dazu mal die komplette .htaccess posten. Die SetHandler Direktive ist kontextsensitiv, d.h. worauf sie sich bezieht steht im umgebenden oder Container. Was sie macht wird mit einer "Action" Direktive festgelegt.

Danke für die Info.

Das Problem habe ich hier gefunden:

http://drupal.org/node/652002

Strato setzt gar kein SET HANDLER, womit wohl alle Liebesmühe umsonst wären. Das Problem haben alle Strato Kunden. Entferne ich den SET HANDLER aus der .htaccess Datei, dann gehen plötzlich auch andere Sachen, deren Ursache ich ganz woanders vermutet habe.

Z.B. konnte ich im Theme Garland keine anderen Farben auswählen. Ohne die .htaccess Angabe mit dem SET HANDLER funzt das plötzlich enwandfrei.

Ich habe Strato nun um Stellungnahme gebeten, da ich Drupal gern unverändert auf deren drupalfähigen Webspace laufen lassen würde, da sie ja damit werben ....

Sie sitzt im files Verzeichnis, wo auch das Verzeichnis für die Bilder (images) liegt, also /sites/default/files/.htaccess ....

Na, da haben wir doch dann die Lösung des Problems. In http://drupal.org/node/652002 stehts eigentlich schon drin:

Dein /sites/default/files Verzeichnis ist sowas wie die allgemeine Ablagehalde für sämtliche Uploads und vom Design her so angelegt, dass dort alles ohne zutun von Drupal heruntergeladen werden kann. Vom Prinzip her ist das sinnvoll und auch notwendig, wenn man Wert darauf legt, seinen Webserver nicht zu überlasten, weil für jedes Element einer Seite (auch für Theme files) eine Drupal Instanz gebootet werden muss. Der Teufel steckt allerdings im Detail. Sollte es ein Benutzer schaffen, eine PHP Datei hochzuladen und dann abzurufen, kann er beliebigen Code auf dem Server ausführen. Genau das soll diese SetHandler Direktive verhindern indem sie einen Dummy Handler ("Drupal_Security_Do_Not_Remove_See_SA_2006_006") für Dateien unter /sites/default/files einträgt, der einen Zugriff auf Scripte in diesem Verzeichnis ins Leere laufen läßt. Irgendwie scheint sich das aber nicht mit der Strato Webserver config zu vertragen.
Die privaten Downloads funktionieren bei dir halt trotzdem weil du mit ihnen diese .htaccess Datei umgehst. Alles in allem läuft die ganze Angelegenheit wohl unter "Dinge die man wissen muss" und "ach deßhalb ist ein erfahrener Sysadmin sein Geld wert". Schwer zu sagen, wem (Drupal, Apache, PHP, Strato) man dafür übers Kniee legen sollte.

Du kannst auf diesen SetHandler unter folgenden Vorraussetzungen verzichten:

• Es ist ausgeschlossen, dass irgendwer Dateien mit .php Endung hochlädt
• Der Webserver ist so konfiguriert, dass Dateien wie test.php.zip auch tatsächlich als ZIP und nicht als PHP Dateien verarbeitet werden

Mit anderen Worten: Solange niemand außer dir Dateien hochladen kann, brauchst du dieses Sciherheitsheitsfeature auch nicht.

Danke für Deine ausführliche Info.

Nunja, eigentlich wollte ich auch anderen die Möglichkeit zum Hochladen geben aber Strato hat sich gemeldet und sie sind dran ....

So, bei mir läuft nun alles.

Der Support hat zwar (noch) nicht geantwortet aber es hat sich was getan.

Ich vermute, dass Set Handler aktiviert wurde. Nun gehen sowohl die Bilder als auch die Garlandkonfiggeschichte.