CSV-Import: Image URLs

[m4rcel82]

Hallo.

 

Kann mir bitte kurz jemand erklären, wie das funktioniert mit dem importieren von Produkten mit samt Produktbildern? Google konnte mir leider nicht richtig helfen.

 

Also den CSV-Import hab ich schon mal hinbekommen.

Ich hab auch eine Spalte mit den Bild-URLs. (Hab die Bilder in einem eigens erstellten Ordner auf dem Server abgelegt.) Die URLs im CSV sind absolut.

 

 

Ich erhalte leider folgende Meldung: "Error copying image"

 

Ich hab das Gefühl, das liegt an irgend welchen Ordner-Berechtigungen.

 

 

Wie genau funktioniert der Vorgang des automatischen Bild-Imports? Werden auch gleich sämtliche Thumbnails generiert? Welche Ordner müssen beschreibbar sein?

Was muss ich beachten?

 

Vielen Dank für die Hilfe.

[guest*]

Wo liegen die Bilder ? Am Besten am Server in einem Unterordner anders als /img!. Auch dein Ordner /img muss Schreibrechte besitzen, dort werden die Bilder dann sozusagen reinkopiert. Ohne Schreibrechte klappt es nicht. Ja es werden auch alle thumbnails generiert und die verschiedenen Größenansichten.

[m4rcel82]

Vielen Dank.

 

Hab mir jetzt mal den Ordner "img" angeschaut. Jetzt versteh ich auch, wo die Bilder hinkommen.

Also dann setz ich mal die Schreibrechte für "img" (inkl. Unterordner).

 

Danke schön!

 

Gruss, Marcel

[guest*]

Bitte, aber ja nicht die Bilder händisch dort einfügen, du musst sie aus einen extra Ordner mittels csv dort reinschreiben lassen. Anfangs werden dort auch jede Menge temporäre (/tmp) Bilder angelegt, die du dann händisch löschen kannst, wenn du magst. Aber bitte nichts dort händisch rein, sonst funktioniert es nicht..

[m4rcel82]

Vielen Dank für deine Hilfe.

 

Leider hat das einstellen der Berechtigung noch nichts genützt. Ich vermute irgendwie, es liegt wohl an der absoluten URL. (inkl. "http://www...). Ich hab jetzt mal die PHP-Fehlermeldungen eingeschaltet und erhalte folgenden Fehler:

Warning: copy() [function.copy]: Unable to access [...]

 

Die angegebene URL (ein anderer Ordner als der "img") des Bildes kann ich aber problemlos aufrufen im Browser.

Muss ich evt. eine relative URL angeben?

[guest*]

Nein, keine relative URL. Ich habe die Bilder auch alle so importiert: http://www.xxx.xx/bilder/bildname.jpg als Beispiel.

[m4rcel82]

Hab hier noch was gefunden.

Könnte ein Problem bei der PHP-Einstellung 'allow_url_fopen' sein:

http://bytes.com/topic/php/answers/906916-how-fix-copy-function-copy-unable-error-server

[guest*]

allow_url_fopen muss auf on sein, das wird aber auch bei der Installation gecheckt und mit rotem Kreuz gekennzeichnte. Ignoriert man das, dann arbeiten die Scripte auch nicht korrekt.

[m4rcel82]

Hm...

allow_url_fopen ist on.

Eine Idee, woran es sonst noch liegen könnte?

Die Fehlermeldung "Warning: copy() [function.copy]: Unable to access [...]" deutet ja schon darauf hin, dass Probleme beim Lesen der Original-Datei und nicht beim Schreiben auftreten, oder?

 

Merci & Gruss

[guest*]

Ja und Nein. Er sagt nur, dass bei der Kopierfunktion der Bilder der Zugang blockiert wird. Kann am Format der Bilder hängen, das er nicht mag, oder eben auch ein Rechteproblem. Ist der Ordner /img und alle Unterordner davon mit 777 oder zumindest 775 vergeben ? Wenn ja, kann es nur noch am Format der Bilder liegen.

Ich hatte mit dem XTC-Shop auch mal so ein Problem. Ich habe mir die Bilder alle neu vom Hersteller holen müssen, weil diese obwohl im Format .jpg, umkonvertiert wurden und sie dann kein reines .jpg-Format übergeben haben. Deshalb wollte der Server die Bilder auch nicht.

[m4rcel82]

Hab da noch was gefunden.

Es liegt wohl am safe_mode.

 

http://www.prestashop.com/forums/topic/73135-solved-1-error-1-an-error-occurred-while-copying-image/

(Post #8)

...und das:

http://www.nethercottconstructions.com/en/content/56-divide-product-images-into-subdirectories

[m4rcel82]

Hab das mit der Activate legacy images compatibility auf "no" gestellt.

 

Ich kann aber den letzten Punkt dieser Anleitung mit dem Generator nicht durchführen.

Ich kann zwar htaccess generieren, krieg danach aber ein

 

Forbidden

 

You don't have permission to access ...

 

 

...dann muss ich das .htaccess File wieder löschen, damit ich überhaupt wieder auf die Seite komme. (...seltsamer htaccess-Generator) :-)

[guest*]

Hi, Achtung! Adrian (nethercott) hat ja geschrieben, dass 1.4.3. eine andere Struktur hat. Überhaupt hat die 1.4.4. eine komplett andere Struktur als die Vorwersionen in der Umschreibung der Links. Also keine alten Posts mit deiner Version verwenden, das kann nämlich nicht funktionieren. Der .htaccess-Generator generiert die Links für die Version die du einsetzst. Wird da was geändert, dann funktioniert es nicht mehr.

[guest*]

Warum hat jede letzte Version eine andere Struktur in der Linkumschreibung ? Ganz einfach: Presta hat bereits hier für das Multishopmodul angepasst. Ohne diesen Anpassungen ist es nicht möglich Multishop zu laufen.

[m4rcel82]

Ähm.. Also was bedeutet das genau für mich?

Ich habe den safe_mode eingeschaltet. Habe deshalb Activate legacy images compatibility auf "no" gestellt.

Ich hab übrigens Version 1.4.4.1.

Wenn ich ein htaccess generiere, erhalte ich danach die Forbidden-Meldung und muss das htacces File wieder löschen.

Wie generiere ich dann ein funktionstüchtiges htaccess File? Das benötige ich ja sowieso, oder?

[m4rcel82]

Muss ich den safe_mode ausschalten?

[guest*]

Alles zurückprogrammieren was du da eingestellt hast. Habe ja geschrieben, dass Adrian das für die Version 1.4.2.5. und 1.4.3 angegeben hat. 1.4.4.0 und 1.4.4.1 haben eine komplett andere Linkstruktur (re-write-Anweisungen). safe_mode ist meines Erachtens standardmäßig auf off. Kann ich aber leider nicht genau sagen.

Im spanischen Forum habe ich soeben einen Eintrag gefunden: der User hatte auch Probleme Bilder upzuloaden. Ihm wurde geraten den safe_mode abzuschalten. Bei dem User hat es auch dann geklappt.

[m4rcel82]

Hallo.

 

Habe nun auch den safe_mode ausschalten lassen.

Das Kopieren der Bilder funktioniert nun einwandfrei.

 

Ist das Ausschalten des safe_mode nicht problematisch? Schafft man dadurch nicht eine Sicherheitslücke?

 

Gruss & Danke für die Hilfe!

[guest*]

Nein. Standard muss es ausgeschaltet sein, sonst funktioniert der Upload garnicht. Sicherheitslücke vielleicht für falsch konfigurierter anderer Software, aber nicht für Presta, weil der solche Dinge anders abfängt. Prestashop sollte wenn möglich nur unter managed oder Dedi-Server laufen und nicht mit anderen tausenden Projekten zusammen. Provider stellen 0815-Pakete zur Verfügung die für alle gelten, das ist für kleine Webspaces schon ok so, aber nicht für spezielle Profi-Software.

[multimediaelectronic]

Hi,

 

habe das selbe Problem, wie m4rcel82 zu Anfang dieses Threads und hoffe ihr könnt mir weiterhelfen. Auf meiner Suche hier im Forum wurde ich leider nicht weiter fündig.

 

Meine Serverinfos

 

PrestaShop-Version: 1.4.5.1

Informationen auf Ihrem Server: Linux infong 2.4 #1 SMP Thu Nov 25 01:59:22 UTC 2010 i686 GNU/Linux Linux infong 2.4 #1 SMP Thu Nov 25 01:59:22 UTC 2010 i686 GNU/Linux Linux infong 2.4 #1 SMP Thu Nov 25 01:59:22 UTC 2010 i686 GNU/Linux

Version der Server-Software: Apache

PHP-Version: 5.2.17

MySQL-Version: 5.0.[spam-filter]log

 

Ich habe einen Shop prall gefüllt mit Ware und habe natürlich keine Lust alles händisch zu kopieren, also habe ich die

Importfunktion genutzt meine Produkte zu laden.

Bis auf die Bilder klappt das auch schon ganz ordentlich, allerdings muss ich gestehen, dass ich mit meinen Ideen zum Bilderimport am Ende bin und nun hoffe hier die entsprechende "Eingebung" zu bekommen.

 

Im ersten Stepp habe ich 2 verschieden Quellen gewählt für den Upload meiner Bilder. Einmal auf meinem lokalen PC und einmal im Netz.

Folgende Fehlermeldung bekomme ich:

• Fehler beim Kopieren des Bildes:http://meinweb.de/images/original/Bild.jpg
  
• Fehler beim Kopieren des Bildes:F:\shopbilder\fertig\Bild.jpg
  

Da die Fehlermeldung"Fehler beim Kopieren des Bildes:"die einzige ist, die ich bekomme habe ich mich bei meiner Suche nach Fehlerbehebung darauf konzentriert.

 

 

Folgende Einstellungen habe ich bereits vorgenommen.

 

/img Order hat volle Rechte (777 inkl. Unterordner)

des weiteren habe ich eine php.ini erstellt mit folgenden Einträgen

allow_url_fopen = on

Bei fopen ist interessant, dass phpinfo "on" und "off" entsprechend ausgibt wenn ich es aktiviere/deaktiviere. im Shop steht aber immer unter Information "Fopen auf Ihrem Server aktivieren", egal was eingestellt ist

 

user_agent = "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9)Gecko/20071025 Firefox/2.0.0.9"

Den user_agent Eintrag hab ich aufAnraten eines Freundes eingefügt, weil er meinte damit könnte der Fehler auch zusammenhängen.

Auch den safe_mode habe ich bereits aktiviert bzw. deaktiviert.

Die o.g. Einträge habe ich in verschiedensten Konstellationen durchgespielt....alle ohne Erfolg. Die Bilder wollen nicht auf meinen Webserver.

Dieser ist im übrigen bei 1und1 gehostet, wobei ich nicht glaube, dass es hier Probleme geben kann. Oder hat da schon jemand andere Erfahrungen gemacht ?

 

Zu guter letzt wollte ich mir mal die php Fehler loggen und hab u.g. Code mit in die php.ini gesetzt. Da tut sich aber leider auch nicht wirklich was. d.h. es wird weder eine errorlog datei auf meinem Webserverr angelegt geschweige denn sichtbar irgendwo was eingetragen, von daher kann ich mit logs nicht dienen. Vielleicht hat ja zu diesem Thema auch jemand eine Idee.

 

Wäre für Hilfe sehr dankbar..

 

Oliver

 

php.ini

error_reporting = E_ALL & ~E_NOTICE

 

; Print out errors (as a part of the output). For production web sites,

; you're strongly encouraged to turn this feature off, and use error logging

; instead (see below). Keeping display_errors enabled on a production web site

; may reveal security information to end users, such as file paths on your Web

; server, your database schema or other information.

display_errors = On

 

; Even when display_errors is on, errors that occur during PHP's startup

; sequence are not displayed. It's strongly recommended to keep

; display_startup_errors off, except for when debugging.

display_startup_errors = Off

 

; Log errors into a log file (server-specific log, stderr, or error_log (below))

; As stated above, you're strongly advised to use error logging in place of

; error displaying on production web sites.

log_errors = On

 

; Set maximum length of log_errors. In error_log information about the source is

; added. The default is 1024 and 0 allows to not apply any maximum length at all.

log_errors_max_len = 1024

 

; Do not log repeated messages. Repeated errors must occur in same file on same

; line until ignore_repeated_source is set true.

ignore_repeated_errors = Off

 

; Ignore source of message when ignoring repeated messages. When this setting

; is On you will not log errors with repeated messages from different files or

; sourcelines.

ignore_repeated_source = Off

 

; If this parameter is set to Off, then memory leaks will not be shown (on

; stdout or in the log). This has only effect in a debug compile, and if

; error reporting includes E_WARNING in the allowed list

report_memleaks = On

 

; Store the last error/warning message in $php_errormsg (boolean).

track_errors = Off

 

; Log errors to specified file.

error_log = "/kunden/homepages/37/d47110815/htdocs/shop/phperror.log"

 

 

 

------------------------------------------------------------------------------------------------------

 

Nachtrag:

sitze nun auch heute schon wieder den ganzen Morgen und befürchte es liegt an der fopen Einstellung.

Habe das ganze mal auf nem lokalen Xampp probiert und siehe da, es läuft alles . Hier wird auch die

Optionale Einstellungen

• Öffnung externer URLs erlaubt
  

nicht angemeckert.

Deshalb hab ich die php.ini des xampp mal komplett angepasst und hochgeladen, aber leider ohne erfolg :-( eigentlich funktioniert die umschaltunf des fopen befehls auch anstandslos, denn in der php.ini bekomme ich ordentlich "ON" und "OFF" angezeigt. Nur

der Shop scheint das nicht akzeptieren zu wollen.

 

Hat nicht einer ne Idee für mich ?

[guest*]

Provider anschreiben, vermutlich hat er deine Domain für eine eigene ini.php nicht freigeschaltet. Hatte das soeben auch, dass ich in die ini was eingegeben habe und der Server mir was komplett anderes angezeigt hat. Auch die gleiche Einstellung in der config.inc.php hat er ignoriert.

[multimediaelectronic]

Hallo CD2500

vielen Dank für Deine Antwort.

Ich hatte bei 1 und 1 telefonisch angefragt, ob es irgendeine Beschränkung bezgl. des fopen Eintrags in meiner PHP gibt. Dies wurde aber verneint.

Kann es denn sein, dass der Server wirklich manche Befehle aus der php.ini nicht annimmt, obwohl die Ausgabe in phpinfo

diese Änderung mit klarem ON und OFF bestätigt ???

[guest*]

Ob es sein kann. Ich habe diesen gleichen Streit mit meinem Provider nach einer Woche mit drohender Kündigung beendet. Er hat nun endlich eingesehen, dass egal was ich in die ini schreibe der Server nicht nimmt. Er hat sich entschuldigt und dann zugegeben, dass er vergessen habe die Domain freizuschalten. Möglich ist es ja gewesen, aber offensichtlich ungerne gesehen...

 

Die Kontrolle hast du wenn du eine info.php erstelltst und die Wert dort ausliest. Aber Achtung die info.php liest in der ersten Spalte das aus, was du eingetragen hast und die zweite Spalte ist das was am Server Standard ist. Meiner Erfahrung nach müssen aber beide Spalten die gleichen Werte haben... Zumindest hat mein Provider das heute so angepasst und beide Kolumnen sind gleich. War bei mir auch so wie bei dir Spalte a) anders als Spalte

[multimediaelectronic]

so sieht die Ausgabe meiner phpinfo aus. Master und Local zeigen beide das selbe, von daher denke ich mal das sieht gut aus.

allow_url_fopen On On

 

Habe mir aus dem Internet mal ein kleines Script gezogen, welches ohne Fehler durchläuft.

 

 

1 <?php

2 $handle = fopen("c:/testdatei.txt","r");

3 /* an dieser Stelle wird das handle erzeugt

4 und mit der Funktion fopen() praktisch mit

5 der Datei testdatei.txt zum Lesen verknüpft

6 */

7 fclose ($handle);

8 /* löst das handle von der Datei

9 und gibt sie somit wieder frei

10 */

11 $dataname="testdatei_2.txt";

12 $handle_2=fopen($dataname,"r");

13 /* versucht die in der Variablen

14 $dataname angegeben Datei zu öffnen

15 */

16 fclose($handle_2);

17 ?>

 

Eigentlich kann es dann doch jetzt nur noch an der PHP Version selber, liegen oder ? Bei mir auf dem lokalen Server geht es ja. Und wenn ich die php.ini von meinem lokalen Server nehme und es läuft auf meinem 1und1 Space nicht, bleibt ja eigentlich nicht mehr viel übrig !? Hat event. jemand Erfahrung mit PHP 5.2.17 in Verbindung mit dem Prestashop ? Auf meinem lokalen Server läuft die PHP 5.3.8.

[guest*]

Ich fahre jetzt auch 5.3.8 vor einem Monat noch 5.2.17. Hatte mit der Version aber keinerlei Probleme, aber dafür mit 500er Fehlern mit dem aktuellen CGI-Script der 5.3.8. Ist echt schwer zu sagen. Da sollte man sich eher mit dem Provider in Verbindung setzen, weil das offensichtlich ein serverspezifisches Problem ist.

[guest*]

Das Thema wird HIER weitergeführt