an TimmeHosting: Hab ich mal getest, weil mich das einfach keine Ruhe lässt. Klappt nicht. Bilder werden weiterhin nicht angezeigt und nur mit einem Kreuz hinterlegt. Hab jetzt mal einfach schnell einen Server local aufgesetzt wir Ihr Ihr das hier beschreibt (kann ja sein so wie ich in Produktiv im Einsatz habe nicht richtig ist): http://www.howtoforge.com/perfect-serve … spconfig-3 Auch mit diesen Installation als Ubuntu 13.04 und der Config Datei von Euch, keine Bilder im Backend. Ich kann einfach nicht mit dem Fehler leben den Amicron dort ausgibt, auch wenn alle Artikel sauber hochgeladen werden. Sieht halt schöner aus, wenn ich 100 Artikel hoch laden und er als Status mir 100 erfolgreiche angibt, anstatt mit 100 Fehler und keine konnte hochgeladen, sind aber da. Gruß Marco
Hi Holger, ja, werde auch den Server wieder mit Nginx laufen lassen und habe dann keine Fehler beim Scriptdurchlauf von Amicron. Komischerweise wenn ich die Bilder nehme in /media/image/… und anschliessen diese in /backend/media/image rein haue, die Bilder dann angezeigt werden. Auch klar, da im Backend der Pfad mit dem /backend angegeben ist. Aber ist das eine Lösung! Gruß Marco
Hallo freaxstore, die RewriteRule, die von timmehosting vorhin gepostet wurde und die bei denen funktioniert, habe ich dir schon vor einer Woche (Samstag) geschickt. Meiner Ansicht nach müsste sie aber funktionieren. Bist Du sicher, dass alle proxies, caches auch wirklich gelöscht sind? Mal mit Terminal oder FTP checken. Die RewriteRule ist auch quasi zwingend, wenn man sich die Angabe der Bild-pfade im HTML des Media-Managers im BAckend anschaut. Sie stehen dort nicht als relativ angegeben zu /backend/media/VERZEICHNISSE/image.jpg, sondern als /media/VERZEICHNISSE/image.jpg und die würden dann durch die RewriteRule umgeschrieben zu /backend/media/VERZEICHNISSE/image.jpg. Der Browser erzeugt letztgenannte URL, weil das Backend ja für ihn immer als /backend läuft und daran die /media/VERZEICHNISSE/image.jpg angehangen wird. Wenn Du dies nun quasi händisch durch das kopieren „physikalisch“ erledigst, dann findet das Backend natürlich Dateien. Irgendwas machst Du in der Serverkonfig falsch oder hast Du da bei Shopware noch etwas mit URL-Rewrites eingestellt? DieImage-Datenbanktabellen müssten in Ordnung sein, sonst könnte man keine Bilder im Frontend sehen. Grundsätzlich kannst Du das Kopieren der Dateien ja mit einem kurzen eigenen Skriptaufruf nach Import mit Amicron erledigen. Aber es ist meiner Ansicht nach ein Konfigurationsproblem auf deinem Server. Das solltest Du in den Griff bekommen können. @Amicron: Ich würde niemals eine so wichtige Schnittstelle mit einem Skript betreiben, das nicht fehlerfrei durchläuft. Wer sagt denn , dass es wirklich immer alles korrekt aktualisiert. Manuell überprüft man nur einen kleinen Ausschnitt zu einem gegebenen Zeitpunkt. Wenn ein Importskript mit Fehler stoppt, dann darf es gar nichts aktualisieren, sondern muss den Originalzustand wieder herstellen. Alles andere ist ein undefinierter Zustand und die Datenintegrität ist nicht gewährleistet. Persönlich halte ich jedes andere Vorgehen für einen Designfehler, aber gut, das müsst ihr selber wissen. Für die 500er-Fehler auf unterdimensionierten Webhostingpaketen und sei es nur wegen Speicherlimitierungen in Konfigurationsdateien kann Amicron aber wirklich nichts. [quote=„freaxstore“]Hi Holger, ja, werde auch den Server wieder mit Nginx laufen lassen und habe dann keine Fehler beim Scriptdurchlauf von Amicron. Komischerweise wenn ich die Bilder nehme in /media/image/… und anschliessen diese in /backend/media/image rein haue, die Bilder dann angezeigt werden. Auch klar, da im Backend der Pfad mit dem /backend angegeben ist. Aber ist das eine Lösung! Gruß Marco[/quote]
[quote]Für die 500er-Fehler auf unterdimensionierten Webhostingpaketen und sei es nur wegen Speicherlimitierungen in Konfigurationsdateien kann Amicron aber wirklich nichts.[/quote] habe z.B. keinen unterdimensioniertes Webspace Paket sondern einen Server mit ausreichend Power und es läuft trotzdem nicht. Gleiches gilt bei anderen Hostern und bei Managed und Root Servern, die auf dem Apache laufen.
Hi Holger, im Backend habe ich nichts umgestellt und erst mal so gelassen. Du meinst wahrscheinlich in den Grundeinstellungen -> Storefront -> SEO/Routereinstellungen. Nein, dort nichts. Alles erstmal so gelassen. Habe händisch auf dem Server direkt mal Cache Ordner gelöscht, aber auch hier kein positives Ergebnis. Obwohl, beim 1x hochladen des Bildes im Backend hat er es mir angezeigt, aber zu früh gefreut. Dann habe ich weitere hochgeladen und schon wieder alle mit einem Kreuz hinterlegt. Tja, ich weiß da wirklich nicht mehr weiter. Es wird sicher an mir liegen, aber ich sehe den Fehler nicht. Eigentlich kann man da auch nicht so viel verkehrt machen. Der Server ist lokal frisch aufgesetzt, Konfig-Einstellungen von Timme Hosting genommen und Shopware drauf und alle Installationsbedingungen werden erfüllt beim installieren. Wollte schon längst wieder Online sein mit dem Shop, aber der Drang nach Nginx und dadurch einen sauberen Scriptdurchlauf von Amicron zu haben ist sehr hoch. Gruß Marco
[quote=„freaxstore“]Hi Holger, im Backend habe ich nichts umgestellt und erst mal so gelassen. Du meinst wahrscheinlich in den Grundeinstellungen -> Storefront -> SEO/Routereinstellungen. Nein, dort nichts. Alles erstmal so gelassen. Habe händisch auf dem Server direkt mal Cache Ordner gelöscht, aber auch hier kein positives Ergebnis. Obwohl, beim 1x hochladen des Bildes im Backend hat er es mir angezeigt, aber zu früh gefreut. Dann habe ich weitere hochgeladen und schon wieder alle mit einem Kreuz hinterlegt. Tja, ich weiß da wirklich nicht mehr weiter. Es wird sicher an mir liegen, aber ich sehe den Fehler nicht. Eigentlich kann man da auch nicht so viel verkehrt machen. Der Server ist lokal frisch aufgesetzt, Konfig-Einstellungen von Timme Hosting genommen und Shopware drauf und alle Installationsbedingungen werden erfüllt beim installieren. Wollte schon längst wieder Online sein mit dem Shop, aber der Drang nach Nginx und dadurch einen sauberen Scriptdurchlauf von Amicron zu haben ist sehr hoch. Gruß Marco[/quote] Bitte poste mal Deine komplette Vhost-Konfiguration - ich nehme an, Du hast noch irgendeine andere location drin (à la location ~* .(jpg|jpeg|png|gif|css|js|ico)$ {}), die bei Bildern Vorrang vor der Shopware-Konfiguration hat.
Hier die von meiner lokalen Installation. Euer Script füge ich einfach unter ISPConfig 3 ein. In der Datei selber habe ich selber noch nichts selber eingestellt. server { listen \*:80; server\_name freaxstore1.local www.freaxstore1.local; root /var/www/freaxstore1.local/web; index index.html index.htm index.php index.cgi index.pl index.xhtml; location ~ \.shtml$ { ssi on; } error\_page 400 /error/400.html; error\_page 401 /error/401.html; error\_page 403 /error/403.html; error\_page 404 /error/404.html; error\_page 405 /error/405.html; error\_page 500 /error/500.html; error\_page 502 /error/502.html; error\_page 503 /error/503.html; recursive\_error\_pages on; location = /error/400.html { internal; } location = /error/401.html { internal; } location = /error/403.html { internal; } location = /error/404.html { internal; } location = /error/405.html { internal; } location = /error/500.html { internal; } location = /error/502.html { internal; } location = /error/503.html { internal; } error\_log /var/log/ispconfig/httpd/freaxstore1.local/error.log; access\_log /var/log/ispconfig/httpd/freaxstore1.local/access.log combined; ## Disable .htaccess and other hidden files location ~ /\. { deny all; access\_log off; log\_not\_found off; } location = /favicon.ico { log\_not\_found off; access\_log off; } location = /robots.txt { allow all; log\_not\_found off; access\_log off; } location /stats { index index.html index.php; auth\_basic "Members Only"; auth\_basic\_user\_file /var/www/clients/client1/web2/web/stats/.htpasswd\_stats; } location ^~ /awstats-icon { alias /usr/share/awstats/icon; } location ~ \.php$ { try\_files /badc0ffa79ae0b0140fd2aaf03b90c62.htm @php; } location ~ \.php$ { try\_files $uri =404; include /etc/nginx/fastcgi\_params; fastcgi\_pass 127.0.0.1:9000; fastcgi\_param SCRIPT\_FILENAME $document\_root$fastcgi\_script\_name; fastcgi\_param HTTPS $fastcgi\_https; } location @php { try\_files $uri =404; include /etc/nginx/fastcgi\_params; fastcgi\_pass 127.0.0.1:9011; fastcgi\_index index.php; fastcgi\_param SCRIPT\_FILENAME $document\_root$fastcgi\_script\_name; #fastcgi\_param PATH\_INFO $fastcgi\_script\_name; fastcgi\_intercept\_errors on; } location /cgi-bin/ { try\_files $uri =404; include /etc/nginx/fastcgi\_params; root /var/www/clients/client1/web2; gzip off; fastcgi\_pass unix:/var/run/fcgiwrap.socket; fastcgi\_index index.cgi; fastcgi\_param SCRIPT\_FILENAME $document\_root$fastcgi\_script\_name; fastcgi\_intercept\_errors on; } location ~ /(engine|files|templates|media/[a-z]+)/ { } location / { index index.html index.php shopware.php # Defining rewrite rules rewrite shopware.dll /shopware.php; rewrite files/documents/.\* /engine last; rewrite images/ayww/(.\*) /images/banner/$1 last; if (!-e $request\_filename){ rewrite . /shopware.php last; } } location ~ \.(tpl|yml|ini)$ { deny all; } location /install { location /install/assets { } if (!-e $request\_filename){ rewrite . /install/index.php last; } } }
Benutzt Du ISPConfig als Control Panel? Deaktiviere mal “Eigene Fehlerseiten” (bzw. entferne diesen Teil aus der Konfiguration: error\_page 400 /error/400.html; error\_page 401 /error/401.html; error\_page 403 /error/403.html; error\_page 404 /error/404.html; error\_page 405 /error/405.html; error\_page 500 /error/500.html; error\_page 502 /error/502.html; error\_page 503 /error/503.html; recursive\_error\_pages on; location = /error/400.html { internal; } location = /error/401.html { internal; } location = /error/403.html { internal; } location = /error/404.html { internal; } location = /error/405.html { internal; } location = /error/500.html { internal; } location = /error/502.html { internal; } location = /error/503.html { internal; } ). Weiterhin ist location ~ \.php$ { try\_files $uri =404; include /etc/nginx/fastcgi\_params; fastcgi\_pass 127.0.0.1:9000; fastcgi\_param SCRIPT\_FILENAME $document\_root$fastcgi\_script\_name; fastcgi\_param HTTPS $fastcgi\_https; } überflüssig.
[quote=“Artur Nietsch”] habe z.B. keinen unterdimensioniertes Webspace Paket sondern einen Server mit ausreichend Power und es läuft trotzdem nicht. Gleiches gilt bei anderen Hostern und bei Managed und Root Servern, die auf dem Apache laufen.[/quote] Der einzige Unterschied bei den php-ini Dateien ist aber das Speicherlimit für ein php-Skript. Damit ist die Leistungsfähigkeit eines Servers hinsichtlich dieses Parameters nicht ausreichend. Das ist eigentlich die Schlussfolgerung, wenn die Informationen im Post vollständig sind. Gilt natürlich nicht für den zweiten Fehler.
Hi TimmeHosting, habe ich gemacht. Immer noch das gleiche. Habe den Shopcache geleert (über Terminal), Browser Cache geleert, alle Browser getestet (Firefox,Safari,Chrome). Immer das gleiche. Ja, benutze ISPConfig 3. Wie gesagt, habe ja auch den lokalen Server (Ubuntu 13.04) nach Eurer Anleitung von Falko Timme auf http://www.howtoforge.com aufgesetzt, um hier zu schauen ob mein Server Online irgendwo in der Config falsch ist. Habe hier zu Hause demnach ein sauber und frischen aufgesetzten Server zum testen, um weitere Fehler auszuschliessen. Ich finde es bemerkenswert wie einem geholfen wird hier, nur warum fruchtet es nicht bei mir. Debian habe ich natürlich auch schon getestet, der Tag hat ja 24Std. Nur da habe ich Probleme mit meinen SSD Platten mit der Trimm Funktion, was jetzt hier aber nicht zum Thema gemacht werden soll. Ich will doch nur Bilder sehen 
Gruß Marco
[quote=„hth“] @Amicron: Ich würde niemals eine so wichtige Schnittstelle mit einem Skript betreiben, das nicht fehlerfrei durchläuft. Wer sagt denn , dass es wirklich immer alles korrekt aktualisiert. Manuell überprüft man nur einen kleinen Ausschnitt zu einem gegebenen Zeitpunkt. Wenn ein Importskript mit Fehler stoppt, dann darf es gar nichts aktualisieren, sondern muss den Originalzustand wieder herstellen. Alles andere ist ein undefinierter Zustand und die Datenintegrität ist nicht gewährleistet. Persönlich halte ich jedes andere Vorgehen für einen Designfehler, aber gut, das müsst ihr selber wissen. Für die 500er-Fehler auf unterdimensionierten Webhostingpaketen und sei es nur wegen Speicherlimitierungen in Konfigurationsdateien kann Amicron aber wirklich nichts. [/quote] Beim Script ist mir auch aufgefallen, wenn ich eine Kategorie ändere, das dies beim Abgleich einfach ignoriert wird. Ich muss entweder komplett abgleichen oder vorher einen Artikel in dieser Kategorie anwählen und dann abgleichen, ansonsten bleibt die Kategorie unangetastet. Lösche ich eine Kategorie in AF11, dann wird das zur Kategorienleiche in Shopware. Wird nicht gelöscht, muss dann händisch im Backend passieren. Status eMails sollen laut Amicron auch automatisch bei Rechnungsdruck in AF11 in Shopware automatisch versendet werden. Macht es auch nicht bei mir. Setzt zwar den Status um, mehr aber auch nicht.
[quote]Der einzige Unterschied bei den php-ini Dateien ist aber das Speicherlimit für ein php-Skript. Damit ist die Leistungsfähigkeit eines Servers hinsichtlich dieses Parameters nicht ausreichend. Das ist eigentlich die Schlussfolgerung, wenn die Informationen im Post vollständig sind. Gilt natürlich nicht für den zweiten Fehler.[/quote] Der Server ist schon Leistungsstark und wie gesagt, es ist ein kompletter Server. Dies kann bestimmt nicht eine Mindestanforderung von Amicron sein. Und ich kann mir nicht vorstellen, dass die Grundfunktionen des Scripts mit der Leistung des Servers zu tun haben. Es geht um simple Abfragen. [quote] Beim Script ist mir auch aufgefallen, wenn ich eine Kategorie ändere, das dies beim Abgleich einfach ignoriert wird. Ich muss entweder komplett abgleichen oder vorher einen Artikel in dieser Kategorie anwählen und dann abgleichen, ansonsten bleibt die Kategorie unangetastet.[/quote] Dieses Problem hatte ich auch. Tritt bei einem Hoster auf und bei dem anderen Hoster nicht auf. Es kann nicht sein, dass eine API Schnittstelle zur Verfügung gestellt wird und das Script derart tief eingreifen muss um eben einfachfache Abfragen durchlaufen zu lassen. Ich vermute es wird ja nicht anders sein wie bei ASCII.
Folgende Einstellung in meiner PHP.ini: allow\_url\_fopen=Off Dann ist bei mir der besagte json Fehler weg: [code]
Could not decode json
json_last_error: Syntaxfehler
<title>302 Found</title>[/code] Dann kommt nur noch dieser hier: [code]Bei dem Scriptaufruf ist ein Fehler aufgetreten:
## No Success
<?xml version="1.0" encoding="iso-8859-1"?><status>
<status_data>
<message>OK</message>
<mode>UPDATED</mode>
<function>WRITE ARTIKEL</function>
<id>44</id>
<script_version_major>3</script_version_major>
<script_version_minor>2</script_version_minor>
</status_data>
</status>[/code] Und habe noch den Apache2 laufen ;-) Gruß MarcoKommentiere ich diese Fehlerausgabe aus im Script, die er mir anzeigt, kommt dieser natürlich nicht mehr Dann steht auch dort, das er mal wirklich Artikel erfolgreich hochgeladen hat Aber ist das die Erfüllung ? Jetzt stellt sich hier die Frage, was hier abgefragt wird mit $decodeResult ? [code]if (!$decodedResult[‘success’]) { echo "
No Success
"; return; }[/code] So jetzt aber erstmal Fussball. Gruß Marco
Das Script lässt mich nicht in Ruhe. Bin ja kein Programmierer und verstehe das nicht wirklich. Ich Vergleich mal das Script mit einer Alarmanlage mit optischer Warnanzeige. Die Alarmanlage hat öfters Fehlalarm und die optische Warnanzeige blinkt. Weil dies nervt, drehe ich die Glühlampe aus der Warnanzeige raus und habe Ruhe. Die Alarmanlage hat natürlich weiter Fehlalarm, was mir dann aber nicht mehr auffällt. Das Script verhält sich nicht so wie die Alarmanlage, obwohl ich hier die Warnanzeige (Fehlermeldung) deaktiviere. Der Fehler wird ja in meinen Augen nur ausgeblendet für mich weil es nervt, aber der sollte ja weiter vorhanden sein. Ist es ja anscheinend nicht, da ja jetzt ein erfolgreicher Artikel Abgleich statt findet und das Script mir anzeigt wie viel Artikel erfolgreich aktualisiert bzw. hochgeladen worden sind . Sollte ja dann, wenn ich das mit der Alarmanlage vergleiche mit 0 Artikel abgleichen. Scheint hier das Script falsch zu arbeiten ? Gruß Marco
Hallo freaxstore, clever, alle Programmstellen ausblenden, die die Fehler ausgeben und man kann ruhig schlafen ;). Spass bei Seite: Es ist natürlich Blödsinn, einzelne Teile der Fehlerbearbeitungsroutine auszublenden, dann bekommt man keine korrekte Erfolgsmeldung. Da ich das Import-Modul nicht kenne, kann ich nicht 100% sagen, was genau da jetzt abläuft. Sowohl deine als auch der gepostete Fehler (Seite 4 hier) deuten aber darauf hin, dass das Importmodul auf dem API-Client im Shopware WIKI aufbaut http://wiki.shopware.de/Neue-Shopware-A … Ressourcen . Schau auch mal in meine Antwort auf Seite 4. In dem WIKI-Beispiel gibt es eine Routine „protected function prepareResponse($result, $httpCode)“ am Ende. Dort werden die Erfolgs- und Fehlermeldungen mit den einzelnen if -Abfragen erstellt. Sobald eine der Bedingungen erfüllt ist, wird die Meldung ausgegeben und die Routine abgebrochen. jsondecode oder json allgemein ist eigentlich nur das Format, in dem steht, ob das Skript erfolgreich war oder nicht, welcher Fehler aufgetreten ist. Wenn das Import Modul „json last error“ ausgibt, dann haben die Probleme nichts mit dem Format json zu tun. Das ist eine falsche Interpretation. Bei Arthur Nietsch war es ein 302-Error beim dem Versuch den Artikel zu aktualisieren. Sind alle Abfragen auf Fehler negativ verlaufen, dann gibt der API-Client automatisch eine Erfolgsmeldung, weil er bei „intaktem“ Skript und Fehler schon vorher abgebrochen worden wäre (mit der Fehlermeldung). Wenn Du nun die Fehlerabfrage, die bei dir zum Tragen kommt auskommentierst, dann schreibt er automatisch „Erfolg“. Aber irgendetwas hat trotzdem nich fuktioniert. @Leistung und Skripte (Arthur Nietsch): Die Konfigurationsdateien dienen gerade dazu, die Rechnerressourcen für einzelne „Prozesse/Skripte“ zu limitieren. Das ist genau die Aufgabe von Direktiven in der php.ini wie: max_execution_time (max. Skriptkaufzeit) max_input_time memory_limit (max. Speicher, der verwendet werden darf, das war doch bei Nietsch schon ein Problem) Die würde ich auch als erstes testen. Die Limitierungen dienen dazu, dass ein Skriptaufruf (ein Wesbeitenaufruf), nicht den ganzen Server lahmlegt. Schließlich sollen mehr als ein Nutzer darauf zugreifen können. Bei Apache gibt es auch noch eine andere Stelle, die maximale Skriptlaufzeiten festlegt und die php.ini „überstimmt“. Vielleicht ist dies der Unterschied zu nginx, aber dafür kenne ich mich mit nginx nicht gut genug aus. Mit „so tief“ in einen Server eingreifen hat das aber alles nichts zu tun, das sind ganz einfache, simple Konfigurationen. Problematisch ist es aber, jetzt für Shopware generell alle Limits aufzuheben, dann hat man unter Umständen keine Leistungsreserven. [quote=„freaxstore“]Kommentiere ich diese Fehlerausgabe aus im Script, die er mir anzeigt, kommt dieser natürlich nicht mehr Dann steht auch dort, das er mal wirklich Artikel erfolgreich hochgeladen hat Aber ist das die Erfüllung ? Jetzt stellt sich hier die Frage, was hier abgefragt wird mit $decodeResult ? [code]if (!$decodedResult[‚success‘]) { echo "
No Success
"; return; }[/code] So jetzt aber erstmal Fussball. Gruß Marco[/quote]
[quote=“freaxstore”]Hi TimmeHosting, habe ich gemacht. Immer noch das gleiche. Habe den Shopcache geleert (über Terminal), Browser Cache geleert, alle Browser getestet (Firefox,Safari,Chrome). Immer das gleiche. Ja, benutze ISPConfig 3. Wie gesagt, habe ja auch den lokalen Server (Ubuntu 13.04) nach Eurer Anleitung von Falko Timme auf http://www.howtoforge.com aufgesetzt, um hier zu schauen ob mein Server Online irgendwo in der Config falsch ist. Habe hier zu Hause demnach ein sauber und frischen aufgesetzten Server zum testen, um weitere Fehler auszuschliessen. Ich finde es bemerkenswert wie einem geholfen wird hier, nur warum fruchtet es nicht bei mir. Debian habe ich natürlich auch schon getestet, der Tag hat ja 24Std. Nur da habe ich Probleme mit meinen SSD Platten mit der Trimm Funktion, was jetzt hier aber nicht zum Thema gemacht werden soll. Ich will doch nur Bilder sehen Gruß Marco[/quote] Hast Du Dir das Error-Log der Webseite mal angesehen? Wie sieht Dein Vhost jetzt aus?
Hi TimmeHosting; hier ein kleiner Auszug: 2013/06/01 14:27:41 [error] 1962#0: \*1 open() "/var/www/freaxstore1.local/web/backend/media/image/thumbnail/tee01\_banner\_140x140.png" failed (2: No such file or directory), client: 192.168.1.51, server: freaxstore1.local, request: "GET /backend/media/image/thumbnail/tee01\_banner\_140x140.png HTTP/1.1", host: "www.freaxstore1.local", referrer: "http://www.freaxstore1.local/backend/" 2013/06/01 14:27:44 [error] 1962#0: \*1 open() "/var/www/freaxstore1.local/web/backend/media/image/thumbnail/banner151a8a59e0ba29\_140x140.jpg" failed (2: No such file or directory), client: 192.168.1.51, server: freaxstore1.local, request: "GET /backend/media/image/thumbnail/banner151a8a59e0ba29\_140x140.jpg HTTP/1.1", host: "www.freaxstore1.local", referrer: "http://www.freaxstore1.local/backend/" 2013/06/01 14:27:45 [error] 1962#0: \*1 open() "/var/www/freaxstore1.local/web/backend/media/image/thumbnail/banner151a8a59e0ba29\_140x140.jpg" failed (2: No such file or directory), client: 192.168.1.51, server: freaxstore1.local, request: "GET /backend/media/image/thumbnail/banner151a8a59e0ba29\_140x140.jpg HTTP/1.1", host: "www.freaxstore1.local", referrer: "http://www.freaxstore1.local/backend/" 2013/06/01 14:27:45 [error] 1962#0: \*1 open() "/var/www/freaxstore1.local/web/backend/media/image/thumbnail/banner151a8a59e0ba29\_140x140.jpg" failed (2: No such file or directory), client: 192.168.1.51, server: freaxstore1.local, request: "GET /backend/media/image/thumbnail/banner151a8a59e0ba29\_140x140.jpg HTTP/1.1", host: "www.freaxstore1.local", referrer: "http://www.freaxstore1.local/backend/" Sprich nur Fehlermeldung das er die Bilder nicht findet. vHost sieht jetzt so aus: erver { listen \*:80; server\_name freaxstore1.local www.freaxstore1.local; root /var/www/freaxstore1.local/web; index index.html index.htm index.php index.cgi index.pl index.xhtml; location ~ \.shtml$ { ssi on; } error\_log /var/log/ispconfig/httpd/freaxstore1.local/error.log; access\_log /var/log/ispconfig/httpd/freaxstore1.local/access.log combined; ## Disable .htaccess and other hidden files location ~ /\. { deny all; access\_log off; log\_not\_found off; } location = /favicon.ico { log\_not\_found off; access\_log off; } location = /robots.txt { allow all; log\_not\_found off; access\_log off; } location /stats { index index.html index.php; auth\_basic "Members Only"; auth\_basic\_user\_file /var/www/clients/client1/web2/web/stats/.htpasswd\_stats; } location ^~ /awstats-icon { alias /usr/share/awstats/icon; } location ~ \.php$ { try\_files /badc0ffa79ae0b0140fd2aaf03b90c62.htm @php; } location @php { try\_files $uri =404; include /etc/nginx/fastcgi\_params; fastcgi\_pass 127.0.0.1:9011; fastcgi\_index index.php; fastcgi\_param SCRIPT\_FILENAME $document\_root$fastcgi\_script\_name; #fastcgi\_param PATH\_INFO $fastcgi\_script\_name; fastcgi\_intercept\_errors on; } location /cgi-bin/ { try\_files $uri =404; include /etc/nginx/fastcgi\_params; root /var/www/clients/client1/web2; gzip off; fastcgi\_pass unix:/var/run/fcgiwrap.socket; fastcgi\_index index.cgi; fastcgi\_param SCRIPT\_FILENAME $document\_root$fastcgi\_script\_name; fastcgi\_intercept\_errors on; } location ~ /(engine|files|templates|media/[a-z]+)/ { } location / { index index.html index.php shopware.php # Defining rewrite rules rewrite shopware.dll /shopware.php; rewrite files/documents/.\* /engine last; rewrite images/ayww/(.\*) /images/banner/$1 last; rewrite backend/media/(.\*) media/$1 last; if (!-e $request\_filename){ rewrite . /shopware.php last; } } location ~ \.(tpl|yml|ini)$ { deny all; } location /install { location /install/assets { } if (!-e $request\_filename){ rewrite . /install/index.php last; } } } Hab das rewrite backend/media/(.*) media/$1 last; wieder rein genommen. Immer noch das gleiche Ergebnis. Vielleicht habt Ihr noch eine Idee. Gruß Marco
Hi hth, ja, ich weiß, clever ist das nicht. Aber wollte mal sehen was dann passiert Habe mir aber nicht das Ergebnis im Shop angeschaut…*lach*. Da passierte dann nämlich gar nichts mehr. Sprich in der php.ini allow\_url\_fopen=Off hat dieser Eintrag bewirkt, das json Error weg war, aber dann hat er auch keinen Artikel Abgleich zum Shop gemacht. Also wieder auf “ON” und json Error da und Abgleich geht wieder. Ich les mir mal die WIKI durch. Gruß Marco
Klar passiert bei deiner php.ini Änderung nichts mehr. Was hast Du hier für Werte? max_execution_time (max. Skriptkaufzeit) max_input_time memory_limit (max. Speicher, der verwendet werden darf, das war doch bei Nietsch schon ein Problem) setz mal max_execution_time auf einige Minuten (ist in Sekunden) und memory_limit auf 2048 oder so (wieviel Artikel sind es denn?) max_input deaktivier einfach, ich meine -1 ,aber das musst Du noch mal im PHP-Manual kontrollieren. [quote=“freaxstore”]Hi hth, ja, ich weiß, clever ist das nicht. Aber wollte mal sehen was denn passiert Habe mir aber nicht das Ergebnis im Shop angeschaut…*lach*. Da passierte dann nämlich gar nichts mehr. Sprich in der php.ini allow\_url\_fopen=Off hat dieser Eintrag bewirkt, das json Error weg war, aber dann hat er auch keinen Artikel Abgleich zum Shop gemacht. Also wieder auf “ON” und json Error da und Abgleich geht wieder. Ich les mir mal die WIKI durch. Gruß Marco[/quote]