imagecache :: files/images/imagecache-pfad ausserhalb der drupalinstallation legen

Abgesehen vom Sinn:
Erstelle einfach einen Symbolischen Link des Ordners wohin du es haben möchtest
Z.B

ui, dafür brauch ich aber root-zugriff, ne?
hab ich leider nicht. ist nur strato-hosted webspace...

ach so, und der sinn ist hier beschrieben (drupal liefert bilder für mein flash-frontend zu langsam aus).

kann ich eine solche umleitung nicht auch in ner .htaccess erstellen?

Da musst du dir was anderes überlegen, um die Thumbnails zu erzeugen. Der Clou an ImageCache ist ja der, dass das Modul die Thumbnails für ein Bild erst bei Aufruf des Thumbnails erzeugt, wenn es noch nicht vorhanden sein sollte.

Wenn du nun die Bilder in ein anderes Verzeichnis legst, werden dir sicherlich das eine oder andere Thumbnail fehlen, da diese nicht erzeugt werden, da ImageCache vom Zugriff auf das Thumbnail nichts mitbekommt.

darum geht es ja: imagecache mitzuteilen, dass sein verzeichnis ausserhalb der installation liegt. wo es hinschreibt lässt sich sicher irgendwie einstellen.
normalerweise wird der pfad ja über den dateisystem-pfad eingestellt.

Nein, der Pfad lässt sich nicht einstellen, ausser du hackst das Modul -- ausserdem, wie gesagt ist es prinzip-bedingt, dass die thumbnails nicht ausserhalb der drupal-Installation liegen KÖNNEN, siehe die Doku.

Der Bootstrap wird nur dann ausgeführt, wenn das Thumbnail-Image nicht gefunden wird, dafür sorgen die Einträge in der .htaccess-Datei. Vielleicht klemmts da ja...

na klar hacken, darauf läuft es eh hinaus. die frage ist, was ich alles hacken muss, damit der pfad aus den filesystem-einstellungen übernommenw ird, der ausserhalb der installation führt.

welche .htaccess-Einträge könnten da denn klemmen?

ich hab die pfadausgabe nun mit hilfe des artikels http://drupal.org/node/224913 und der dortigen template-funktion angepasst, aber leider erzeugt imagecache immer noch kein verzeichnis auserhalb des installationsverzeichnisses. kann mir da noch jemand nen tip geben? danke!

ein kleiner tip wäre schon toll.
z.b., ob ich weiter im imagecache.modul suchen soll oder ob es eher sache des filehandlings ist.
ich könnte mir auch vorstellen, dass man einfach alle erzeugten dateien innerhalb des drupal/files-verzeichnisses in ein verzeichnis ausserhalb drupal/../files spiegelt.
wie würde denn das gehen?

bittebitte
daaaaaanke!

Wie waere es denn mit mod_rewrite ?

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

klingt gut.
du meinst in der .htaccess. leider kenne ich mich nicht so gut aus mit indianerzeugs.
kannste mir da mehr drüber sagen, wie ich da was konfigurieren müsste...

hab erbarmen!
danke.

Kann ich leider wirklich nicht - muesste mich auch erst einlesen.

Aber mod_rewrite ist gut dokumentiert. www.modrewrite.de

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

mod_rewrite leitet doch aber nur die url um und bewegt keine files.
damit wirds glaub ich eher nicht gehen, vermute ich.

Wenn URL bla durch mod_rewrite zur URL blubber wird dann landen doch auch Dateien in blubber wenn man bla anspricht.

Wenn dem nicht so ist sollte ich mich grad schwer irren.

http://httpd.apache.org/docs/2.0/misc/rewriteguide.html

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Wo der Webserver keinen Zugriff hat, bringt auch kein Apache-Modul etwas ;)

Ich verstehe ehrlich gesagt nicht wo der Sinn / das Problem liegt. Nach Durchfliegen der beiden Freds würde ich mal einfach sagen: Die Diagnose ist völlig falsch!

Wie im anderen Fred schon gesagt wurde, hat Drupal mit dem Ausliefern der Bilder nichts am Hut, wenn als Download-Methode "public" eingestellt ist, was defaultmäßig der Fall ist. Weiß man den Dateinamen der gewünschten Bilddatei, ist der Pfad der Imagecache-Version ganz einfach über den Namen des Imagecache-Preset zusammenstellbar.

Wenn ich das folgende Bild direkt aufrufe, hat bei gleichen Voraussetzungen (public Download) im Leben kein Drupal der Welt etwas damit zu tun. Wozu auch? http://www.iserlohn-roosters.de/files/imagecache/breite_250px_hoehe_vari...

Also bevor man hier in mehreren Threads parallel alle Pferde mit einem falsch diagnostizierten Problem scheu macht, sollte der Urheber sich nochmal ans Debugging machen ;)

Wenn du nicht was ganz krudes gebastelt hast, dann machst du einen Aufruf ans System / Drupal, was dir dein XML liefert, dass du in Actionscript verwurstest. Das ist das EINZIGE Skript, was da überhaupt läuft. Nun weiß ich natürlich nicht was du dir darin gebacken hast, wie lahm der Server PHP-mäßig ist (Strato eben...), wieviele Trillionen Aufrufe du da auf einmal machst, etc. Das sind Fragen denen DU nachgehen musst.

Aber beim Ausliefern einer schäbbigen JPG-Datei direkt übern Webserver hängt nunmal nichts weiter dazwischen als eine Reihe von Routern und einige Kilometer Glasfaser- und Kupferkabel...

--
http://www.alexander-langer.de

nun, ich habe eine version, die die dateien innerhalb der drupalinstallation abfragt und die hinkt mächtig. und eine weitere version, die die bilder ausserhalb der installation sucht und findet flitzt wie ne eins.
beide nutzen die selbe xml-datei, nur dass die eine vorgeneriert da liegt und die andere von einer drupal-view erzeugt wird.
das diese xml nur einmalig von der flashdatei eingelesen wird, kann das geschwindigkeitsmanko nicht an der erzeugungsgeschwindigkeit der xml-datei liegen.
und wenn ausserdem die flashseite ohne drupalbackend wunderbar funktioniert, dann muss es doch an der auslieferung der bilder durch drupal liegen.
firebug zeigt mir ja auch die zeiten an, die der browser benötigt, um das bild nach anfrage zu erhalten und die sind viel zu lang.

ich sage ja, ich weiß nicht, woran das liegt.
aber ist es nicht so, dass drupal mächtig viele skripte abrattert, bevor es einen inhalt ausliefert?

laß doch mal deine diagnose hören...

Ja, aber ein JPG ist kein von Drupal dynamisch generierter Content. Ich schreibe es gerne nochmal: Beim public Download ist bei Zugriff auf Dateien im files-Ordner über den Webserver KEIN Skript involviert. Wie denn auch?

Gib mir Zugriff auf dein System und ich schaue mal, aber bei Shared Hosting Paketen ist man in punkto Diagnose schon stark eingeschränkt...

--
http://www.alexander-langer.de

ich weiß, dass kein skript läuft.
ich weiß aber nicht, warum es bei drupal länger dauert, das bild zu laden.
und zugang zu einem kundensystem kann ich ledier nicht gewähren.

tasache ist jedenfalls, dass es "ewig" dauert, bis das bild geliefert wird.
hm...

ich hab jetzt mal ne umleitung eingerichtet. über
http://hanspeterschroeder.de/
erreichst du die flashseite ohne cms-backend und über
http://cms.hanspeterschroeder.de/
erreichst du die drupal-backend-flash-seite.

die eine läd an einer 106kb jpg-datei 219 ms, die andere braucht dafür 2,33 s !!!

bin gespannt...

Ich kann den Effekt beobachten, aber ich kann ohne Zugriff auf Konfiguration und Protokolle nicht weiter nachforschen. Die meisten hier vertretenen User und ich können dich auf Anhieb mit Websites zuwerfen, wo ein direkter Zugriff auf Imagecache-Bilder völlig problemlos ist.

Was aber intern bei der Abfrage von http://cms.hanspeterschroeder.de/login/files/imagecache/xml_output/files... im Vergleich zu http://hanspeterschroeder.de/images/SmartShop.jpg anders läuft, kann man so von außen nicht diagnostizieren.

--
http://www.alexander-langer.de

man kann aber vermutungen anstellen. und meine war, dass es an der auslieferung der bilder liegt.

mit imagecache hab ich prinzipiell gar kein proplem, denn es erstellt ja ganz brav die bilder. so wie ich das verstanden hab, hält sich imagecache nach der erstellung der bilder ja auch artig zurück.

was würdest du denn als nächstes prüfen?

die header-responses beider versionen unterscheiden sich in folgenden punkten (im folgenden immer zuerst die version ohne cms):

und die mit-cms-version besitzt noch den eintrag

ausserdem hat version zwei noch zwei cookie-werte, anstatt nur einem:

hm, ob das was zu sagen hat....

Apache Konfiguration der Webs anschauen, globale Konfig anschauen, .htaccess Dateien anschauen, PHP Konfig anschauen, evtl. lokale PHP Einstellungen anschauen, usw. usf.

--
http://www.alexander-langer.de

Apache-Konfiguration
ist halt strato webhosting (PowerWeb Paket-A).

php-einstellungen
http://hanspeterschroeder.de/info.php

.htacces
ist die .htacces ist die standard-drupal-datei drupal 5.7.

imagecache ist version 5.x-2.0

Wie eingangs erwähnt, ist Diagnose bei Shared Web sehr eingeschränkt. Die werden bei Strato nicht so nett sein ihre Konfig-Files rauszurücken.. ;)

Meine Vermutung wäre, dass da irgendwo irgendwann irgendwer so "nett" war so nen Schmu in eie .htaccess (oder eben in irgendeinem Konfig-Panel) einzutragen, womöglich noch mit irgendwelchen schmuigen Rewrites...

Die Site selbst liegt noch auf den alten Sun Enterprise Systemen von Strato. PHP wird hier via CGI im Apache ausgeführt, was beim Starten langsamer ist als mod_php, auch kommt kein Bytecode Cache zum Einsatz. Ich habe nie ausprobiert, was passiert, wenn ich PHP auf ein 100kB Bild loslasse, um es nach ausführbarem Code zu durchsuchen. Gut möglich, dass dies auf den Strato Möhrchen ne Weile dauern würde...

--
http://www.alexander-langer.de

P.S.:
Du könntest dir auch x Requests sparen und in deinem XML auch gleich die Bilder direkt einbauen, anstatt sie nachzuladen.

--
http://www.alexander-langer.de

bilder in ein XML einbauen?

In dem Modul, dass dir den XML Code bastelt, statt die URLs der Bilder einfach eine serialisierte Form (z.B. Base64) der Bilddateien reinhauen. So spart man die Serveranfragen für jedes einzelne Bild.

--
http://www.alexander-langer.de

meinst du, dass ein anbieterwechsel das problem löst?
wenn ja, wen würdest du empfehlen?

die sind ja eigentlich gar nicht das problem, wenn man sich die reine flashversion anguckt. ist ja auf dem selben server.
daher verstehe ich auch nicht, wieso apache bei der einen jpg-anfrage php-code dazwischenschießen soll und bei der anderen nicht.
wie du schon sagst ruft er da ja nur ne jpg auf...

naja, du meinst ja, wegen der .htaccess.
ich check die gleich noch mal....

Das wäre jetzt, so lange man die echte Ursache nicht kennt, geraten.

Im Bereich Shared Hosting würde ich wohl am ehesten noch HostEurope empfehlen, aber das ist nicht so ganz meine Baustelle, da ich seit Jahren schon ausschließlich den Murks ausbade, den ich mir auf den eigenen Kisten einbrocke.

--
http://www.alexander-langer.de

Primär nicht, sekundär schon. Und wenn wir an die primäre Ursache nicht herankommen, müssen wir uns einen Workaround bauen.

Normalerweise dürfte es nur eine einzige direkt im files-Ordner geben. In den darunterliegenden Verzeichnissen ./imagecache/... sollte es keine geben (jedenfalls legt IC selbst keine an).

--
http://www.alexander-langer.de

also die .htaccess weist diesen eintrag nicht auf, ist wie gesagt auch ganz und gar die von drupal 5.7.

eine ebene über drupal liegt noch eine .htachhes, die aber nur folgendes enthält:

ich hab gehötz hosteurope soll verkauft werden und man kann sich nicht sicher sein, ob deren leistungspacket und gerätepark/einstellungen so bleiben.

hm, kein plan.

Myteriöses Moped, das du da fährst.

--
http://www.alexander-langer.de

P.S.:

Wenn du mir Unwürdigem halbwegs vertraust, würde ich dir anbieten dir temporär ein Web auf einem Server unter meiner Fuchtel anzulegen. Wenn da alles wie gewünscht läuft, weißt es liegt am Hoster. Wenn nicht, habe ich wenigstens mehr Möglichkeiten nach Ursachen zu forschen.

--
http://www.alexander-langer.de

das hat ja wenig mit vertrauen zu tun, vielmehr mit verträgen.
dein angebot ist aber trotzdem sehr nett, vielen dank.

ich habe es mun allerdings noch mal lokal ausprobiert und es schleicht genauso.
meine vermutung ist damit meiner meinung nach etwas mehr untermauert, dass es an drupal an sich hängt.

der vorschlag von DEREINE ganz oben - kann man das auf shared hosting irgednwie machen, dass man da was in die .htaccess schreibt?

Ich mauere "natürlich" dagegen:

http://www.iserlohn-roosters.de/files/imagecache/breite_250px_hoehe_vari...

http://www.bluefire-jeans.com/sites/files-bluefire/imagecache/presse_ueb...

http://www.jm-metall.de/files/imagecache/220x150/files/produkte/bandbieg...

http://www.stahl-control.de/files/imagecache/kernprodukte_teaser/files/i...

--
http://www.alexander-langer.de

Wenn du keinen SSH Zugang mit entsprechenden Rechten hast (gibt es zuweilen auch bei Shared Hosting): Nein.

Selbst dann wäre es nur ein weiterer Versuche ohne Garantie auf irgendetwas.

--
http://www.alexander-langer.de

mit bilderlinks mauern?

der eigentliche direkte bilderaufruf bei meiner seite ist auch nicht langsam.
http://cms.hanspeterschroeder.de/login/files/imagecache/xml_output/files/images/SmartShop.jpg

hm...

2.2s - 5.6s für ein 100k Bild finde ich schon reichlich...

Und BTW:
Wäre das wirklich NICHT langsam, würdest du damit ja nur deiner eigenen Theorie widersprechen.

--
http://www.alexander-langer.de

nun, der direkte bildaufruf mit dem link daueert ja nicht so lange - komischerweise....

STRANGE!

Doch, bei mir schon, sowohl vom Büro aus als auch von daheim. Unter 2s geht da nüscht. Und als Content Type schmeißt er jedes Mal einenn "text/html (NS_IMAGELIB_ERROR_LOAD_ABORTED)". Zu dem Fehler gibts aber im Netz keine Erläuterungen.

--
http://www.alexander-langer.de

womit siehst du das denn?

https://addons.mozilla.org/en-US/firefox/addon/6647

--
http://www.alexander-langer.de

was ist da der unterschied zu firebug?
ist das sowas wie der fiddler, nur für firefox?

Mit HttpFox kann man eben auch HTTP Request und Response Header einsehen. Fiddler? Ich kenne nur den Verteidiger der so heißt.. Nashville Predators glaub ich ;)

--
http://www.alexander-langer.de

der fiddler macht das für den IE.
http://www.fiddlertool.com/fiddler/

Ah, der geächtete Browser...

--
http://www.alexander-langer.de

jups.
der aber leider immer noch meistverbreitete.

Klar, bei der Anzeige. D.h. aber nicht, dass ich darin entwickeln muss. Ich kann mir das Leben auch anderweitig schwer machen.

Aber jedem Tierchen sein Plaisierchen.

--
http://www.alexander-langer.de

nicht entwickeln, nur muss es dort auch laufen.
leider hält sich ja niemand an die CSS-Regeln des Konsortiums...

nuja.