Erreur 500 à l'import de .csv (oui, encore un !)

[Truite]

Bonjour,

 

Je suis un des innombrables débutants qui commence tout juste à bidouiller Prestashop. Je dois le faire dans le cadre du développement d'une interface web de "synchronisation" EBP-Prestashop (j'exporte les articles de la boutique en .xml depuis EBP, mon interface "convertit" ce fichier en .csv et l'ordonne selon les valeurs récupérées sous Prestashop).

Mon interface fonctionne très bien en local, renvoie les valeurs prévues dans Prestashop et les importe correctement (sans warnings ni champs tronqués) et en intégralité dans la BDD, avec suppression des produits déjà existants avant l'import.

Là où ça coince, c'est sur le serveur. L'envoi du CSV fonctionne, l'aperçu des premières lignes aussi. J'importe les données, ... j'attends ... puis j'ai une erreur 500. Un peu plus de quarante articles ont été importés sur les quatre-vingt disponibles dans le CSV, il doit y en avoir plus de 1500 dans le CSV final.

 

Déjà, j'apporte toutes les réponses aux questions fréquemment posées après avoir donné ce genre de description :

 

- Je suis sous la version 1.3.6.0 de Prestashop.

- Le serveur est chez 1&1.

- Tous les fichiers .htaccess ne contiennent que "Order deny,allow Deny from all".

- Tous les dossiers et fichiers ont des droits 755 et 644 respectivement.

- Mon CSV fait 15,3 Ko pour l'instant.

- Si j'envoie un fichier de 40 articles, il passe correctement, sans souci. Si je rajoute deux ou trois articles, ces derniers ne passent pas et j'ai l'erreur 500.

- L'envoi de la page d'erreur 500 ne se fait pas au bout d'un temps précis. Avec Firebug, j'ai pu constater que le temps d'attente variait entre 42 et 47 secondes, sans changement quelconque de fichier, code, paramètres, ... entre les essais.

- Dans AdminImport.php, j'ai cette ligne :

@ini_set('max_execution_time', 0);

- Dans config.inc.php, j'ai ces lignes :

@ini_set('upload_max_filesize', '100M');

@ini_set('display_errors', 'off');

define('_PS_DEBUG_SQL_', false);

- Même en passant ces dernières lignes à on et true, en autorisant l'affichage des erreurs sur le serveur et en passant en version de PHP pour le développement, pas moyen d'afficher les erreurs. Je ne dispose pas non plus de log d'erreurs.

- Avec phpinfo(), j'ai ces valeurs :

max_execution_time : 50000

max_file_uploads : 20

max_input_time : -1

max_input_vars : 5000

memory_limit : 90M

mysql.connect_timeout : 60

 

Toutes ces valeurs me permettent d'écarter beaucoup de solutions possibles.

Je ne serai pas l'utilisateur principal de l'interface que j'ai conçu. Il est prévu de virer tous les articles de la boutique chaque semaine pour les remplacer par le CSV qui contiendra donc toutes les modifications effectuées en magasin toutes les semaines, ainsi que tous les ajouts. Je ne peux pas me permettre de subdiviser le CSV principal en plusieurs CSV, et les envoyer un par un sur l'interface (surtout s'il y en a des dizaines) Tant pis si le chargement est long, le but est plutôt de supprimer un maximum d'étapes entre EBP et Prestashop.

 

Existe-il une solution à laquelle je n'aie pas pensé, ou que j'aie loupé sur le net, ou dois-je bidouiller la fonction productImport() de AdminImport.php pour automatiser la divison du CSV principal en plusieurs dizaines de petits CSV ?

 

Merci d'avance !

Edited June 28, 2013 by Truite (see edit history)

[Gregory Roussac]

Hello,

 

Alors 1.3.6 ça commence vraiment a dater pour le coup. Telecharge une 1.4.11, mets tes scripts et retest.

 

Ensuite tu as regardé tes logs Apache, et mysql ? On dirait un classique 'mysql has gone away'. Quel est le serveur ? mysql.connect_timeout : 60 c'est très court au final, normalement c'est 180 je crois.

 

La reponse avec firebug est vide ? @ini_set('display_errors', 'off'); à on aussi ? define('_PS_DEBUG_SQL_', false); à true ? Tu flush dans ton script comme dans AdminImport le fait normalement ?

[Truite]

Déjà, merci pour m'avoir répondu !

 

Ensuite, entretemps, je me suis rendu compte que finalement non, mon import ne passait pas non plus intégralement en local. Je n'avais pas d'erreur 500, les messages de bon déroulement de l'action étaient affichés moins de 30 secondes après le début de l'opération, ... et moins d'articles étaient importés en boutique, et ce même en recopiant les variables du phpinfo() du serveur sur mon php.ini local.

Ayant un log d'erreurs en local (et pas sur le serveur chez 1&1), j'ai pu me rendre compte qu'un appel à un module renvoyait un 404. Je l'ai ajouté même en pensant que ça ne résoudrait pas grand chose. Puis il restait d'autres erreurs dans des fichiers Admin (un Array to String conversion dans AdminTools.php, ou un nom du genre).

 

Puis je suis finalement passé à la version 1.5.4.1 de Prestashop sur le serveur. Après avoir adapté mon interface aux nouveaux champs disponibles à l'import et recrée toutes les catégories, j'ai envoyé un nouveau CSV dans la section Import.

Au final, il y a un léger mieux. J'ai environ 70 articles importés, mais j'ai toujours une erreur 500 (avec une page "Oops, something went wrong. Try to refresh this page or feel free to contact us if the problem persists."). Par contre, le délai d'attente devient très aléatoire, j'attends entre 50 secondes et 3 minutes 20 pour voir la page d'erreur. Même en ajoutant une ligne ini_set('mysql.connect_timeout',180); dans config.inc.php et en passant la ligne define('_PS_MODE_DEV_', false); à true dans defines.inc.php, puis en repassant php en version dev et en autorisant l'affichage des erreurs, rien ne change (et Firebug ne renvoie toujours rien de spécial).

 

Je suis encore en train d'adapter la nouvelle version en local.

[Max84]

Si je comprends bien, ton problème n'a rien à voir avec la liaison EBP - Prestashop (sinon, il y a ça, discuté par ailleurs sur le forum : http://www.vaisonet....erelle-ebp.html ) ?

 

Le problème c'est l'import du fichier CSV ?

 

Ensuite, ce n'est pas parce que tu tentes de modifier la modification de php (timeout, taille des pièces-jointes, etc ...), que 1&1 te laisse faire.

 

De plus en mettant un @ devant les ini_set, l'hébergeur ne mettra pas d'erreur.

 

Commence par enlever tous les @ (par exemple @ini_set('max_execution_time', 0) .

Il est probable que tu crois avoir un temps illimité et que cela soit faux. Pareil pour les autres paramétrages.

[Truite]

Merci pour la réponse !

 

Effectivement, mon interface ne semble pas poser de problème, elle "convertit" un fichier .xml provenant d'EBP en fichier .csv pour Prestashop, de manière à ce que les colonnes EBP soient changées et ordonnées en colonnes Prestashop. L'aperçu sur Prestashop me montrant que les colonnes ont bien été ordonnées et le fait que les premiers produits soient correctement importés me confirment qu'il y aurait un problème au niveau du serveur.

 

Je récapitule donc tous les changements que j'ai effectué :

- Version de Prestashop : 1.5.4.1

- dans config.inc.php : ajout de ini_set('mysql.connect_timeout',180);

- dans defines.inc.php : ligne define('_PS_MODE_DEV_', true); et retrait des @ en face des lignes ini_set('display_errors', 'on');

- dans AdminImportController.php : ini_set('max_execution_time', 0);

- version de PHP : PHP dev (sous 1&1).

- affichage des erreurs activé chez l'hébergeur.

 

Infos du serveur (phpinfo()) :

- max_execution_time : 50000

- max_input_time : -1

- max_input_vars : 5000

- memory_limit : 90M

- mysql.connect_timeout : 60

J'ai aligné mon php.ini en local sur ces valeurs.

 

Résultats :

- erreur 500 environ 50 secondes après confirmation de l'import (je ne peux même pas me fier à une valeur restant constante).

- environ 70 articles importés (et parfois un article partiellement importé) sans problème sur les 80 du CSV.

- aucune erreur affichée autre que la page d'erreur 500.

- pas d'accès au log d'erreurs possible.

- importation réussie en local en un peu plus d'une minute, rien dans le log d'erreurs, je vais tenter un autre test dès que j'aurai accès à une liste plus vaste de produits, afin de voir si cela ne finit pas par bloquer à terme.

Edited July 2, 2013 by Truite (see edit history)

[Max84]

Est ce que 1&1 propose XDebug sur leurs hébergements ?

 

Est ce un problème de charge ou de taille => as tu testé un fichier plus petit ?

[Truite]

Merci pour la réponse !

 

Je ne crois pas qu'il soit possible d'utiliser XDebug chez 1&1.

Je viens d'essayer un fichier avec 70 articles (13 Ko). Tous sont importés avec succès en 53 secondes.

Puis j'ai tenté de refaire passer mon fichier habituel de 76 articles (14 Ko). 73,5 sont importés avec succès en 52 secondes (le .5 correspond à un article dont seule la moitié des caractéristiques est passée), puis erreur 500.

J'ai à nouveau essayé de le faire passer (toujours le fichier de 76 articles, sans aucun changement). 74 articles sont importés avec succès en 48 secondes, puis erreur 500.

Troisième essai, 74,5 articles importés en 48 secondes puis erreur 500.

Quatrième essai, 73 articles importés en 49 secondes puis erreur 500.

 

EDIT : J'ai eu accès à un fichier d'articles plus conséquent (101 articles). Sur serveur, le diagnostic est le même (un peu plus de 70 articles importés en un peu plus de 50 secondes, puis erreur 500), en local aussi (tous les articles sont importés sans problème en un peu moins de deux minutes).

 

EDIT 2 : Je viens de me rendre compte que mon max_execution_time côté serveur était repassé à 30. Ça ne semble toutefois pas avoir d'incidence sur l'importation du fichier (toujours pas d'erreur affichée, le chargement prend toujours environ 50 secondes).

J'ai fini par placer une ligne set_time_limit(0); au début de config.inc.php et de AdminImportController.php. J'ai vu ailleurs que 1&1 autorisait les modifications du php.ini et fournissait même un script pour permettre d'appliquer les changements plus rapidement. J'ai donc crée un php.ini perso.

Puis j'ai exécuté le script avec succès, quasiment tous les dossiers ont un nouveau php.ini. Je vous l'accorde, c'est pas très beau, et ça ne résout toujours pas le problème. J'ai 72,5 produits importés en une minute, ou 74 produits importés en 52 secondes, ...

 

EDIT 3 : J'ai également ajouté la possibilité de récupérer le log d'erreurs. Celui-ci fonctionne et renvoie les erreurs du script précédent (le php.ini ne veut pas se copier dans le dossier contenant les logs de trafic) ... mais ne renvoie rien à la suite de la tentative d'import. Absolument rien, pas un seul caractère concernant la probable origine de l'erreur 500. Et les temps d'exécution sont toujours aussi aléatoires.

 

Je récapitule donc toutes mes données :

- Prestashop 1.5.4.1

- Contenu du php.ini personnalisé :

allow_url_fopen = On

error_log = /chemin_absolu/.../error.log

log_errors = On

default_socket_timeout = 600

max_execution_time = 600

max_input_time = 600

mysql.connect_timeout = 600

upload_max_filesize = 64M

- define('_PS_MODE_DEV_', true); dans defines.inc.php

 

EDIT 4 : Je continue les essais, je viens de constater que l'importation peut même s'arrêter en plein milieu d'un champ (ici, l'image), et comme d'habitude, ça n'arrive pas systématiquement :

 

Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg, libjpeg: recoverable error: Premature end of JPEG file in /chemin_absolu/classes/ImageManager.php on line 365

 

Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '/homepages/42/d416330084/htdocs/img/p/7/6/76.jpg' is not a valid JPEG file in /chemin_absolu/classes/ImageManager.php on line 365

 

Warning: imagecopyresampled(): supplied argument is not a valid Image resource in /chemin_absolu/classes/ImageManager.php on line 190

 

Résultat à l'appui : une image blanche remplace l'image du dernier produit. Dans d'autres essais, l'image passe sans que je n'aie rien changé, ni au niveau des paramètres du serveur, ni au niveau du code.

Edited July 4, 2013 by Truite (see edit history)

[Gregory Roussac]

Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg, libjpeg: recoverable error: Premature end of JPEG file in /chemin_absolu/classes/ImageManager.php on line 365

 

Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '/homepages/42/d416330084/htdocs/img/p/7/6/76.jpg' is not a valid JPEG file in /chemin_absolu/classes/ImageManager.php on line 365

 

Warning: imagecopyresampled(): supplied argument is not a valid Image resource in /chemin_absolu/classes/ImageManager.php on line 190

 

 

 

Hello,

 

Une image est pourrie, un png enregistré en jpg par exemple, ou l'adresse est mauvaise et envoi sur une 404 qu'il convertit en jpg. Mets un debug pour trouver l'image qui plante.

 

Cordialement

[Truite]

Merci pour la réponse !

 

Comme je l'ai dit, l'erreur n'arrive pas systématiquement. Il m'a suffi de ré-exécuter l'import du fichier pour que l'article avec l'image posant problème finisse par passer correctement, image incluse.

J'ai vérifié toutes mes images, chacune s'appelle bien nom.jpg et toutes s'ouvrent correctement. Je vais détailler un peu mon .csv pour expliquer.

 

Voici une ligne-type du .csv :

 

;1;Boîtier moyen tour - Noir - avec Alimentation - Desktop Sylver - mod 321;Boîtiers;35.95;;;0;;;;;COM01BA;;;;4712839550620;;;;0;;;;;;;COM01BA;;;1;;1;../filegen/images/COM01BA.jpg;1;;;;

 

Dans le .csv, j'ai donc actuellement 101 lignes de ce type. En important ce .csv dans Prestashop, chaque attribut renseigné se retrouve à sa place, l'aperçu me le confirme.

Dans le .xml provenant de EBP, on peut trouver la référence d'une image parmi les attributs. Le dossier /filegen/images contient quant à lui toutes les images exportées manuellement depuis EBP et renommées en fonction de leur référence. Dans mon interface, le lien de l'image est généré dans le .csv, puis une partie du code vérifie si le fichier en découlant existe bien. Si non, une erreur est renvoyée.

Au vu du problème qui me tombe dessus, je pense que l'erreur 500 se provoque en partie parce que l'analyse du fichier doit se couper brusquement, et la raison qui provoque cette coupure reste inconnue.

Je m'appuie sur cette déduction en analysant deux de mes constatations :

 

Puis j'ai tenté de refaire passer mon fichier habituel de 76 articles (14 Ko). 73,5 sont importés avec succès en 52 secondes (le .5 correspond à un article dont seule la moitié des caractéristiques est passée), puis erreur 500.

 

je viens de constater que l'importation peut même s'arrêter en plein milieu d'un champ

 

Quand l'importation se fait, les premières lignes passent correctement, puis l'importation doit s'arrêter en plein milieu d'une ligne, et n'analyser que les premiers attributs d'une ligne, ou se couper en plein milieu du lien de l'image, et donc ne récupérer qu'un nom partiel et donc invalide.

J'ai recherché l'image citée dans l'erreur des posts au-dessus. Elle s'est effectivement bien créée lors d'une importation suivante, elle s'affiche correctement, que ce soit sous Prestashop ou Windows. L'image source est également valide.

 

Après, il n'est effectivement pas exclu que le problème provienne des images (à cette étape du problème, on peut tout soupçonner). Mais alors, en sachant qu'aucune modification ne leur est apportée, que toutes semblent valides, que parfois elles s'importent et parfois non, comment pourrait-on l'expliquer ?

 

EDIT : Je dispose désormais d'un fichier de 910 articles (147 Ko). Même diagnostic. Passage réussi en 12 minutes en local, erreur 500 sur le serveur après 53 secondes et 74 articles importés.

Edited July 6, 2013 by Truite (see edit history)

[sebban]

Bonjour, j'ai moi aussi le même problème, je n'ai pas essayer en local, je suis chez 1&1, sous prestashop 1.5.4.1 et je n'ai malheureusement que 60 articles qui s'importent, je n'ai fait aucune modification de fichier. si quelqu'un a une idée. merci

[Oron]

Bonjour, j'ai moi aussi le même problème, je n'ai pas essayer en local, je suis chez 1&1, sous prestashop 1.5.4.1 et je n'ai malheureusement que 60 articles qui s'importent, je n'ai fait aucune modification de fichier. si quelqu'un a une idée. merci

 

Bonjour

 

Pour erreur 500 voir ici si cela peut résoudre le problème :

Erreur 500 PrestaShop - Comment la résoudre !

[Truite]

J'avais vu cet article. J'aurais bien dit que j'étais dans le cas du temps maximum d'exécution dépassé, mais au vu des données aléatoires qui me sont renvoyées et le fait que rien ne change même en modifiant le php.ini, je ne pense pas.

 

En fin de compte, étant resté trop longtemps sur ce problème, j'ai dû passer à un autre projet. J'ai recodé mon interface pour que mon .csv soit tronqué en plusieurs petits .csv de 70 articles. C'est assez pénible de devoir les importer un par un, mais il n'y a pas vraiment d'autre solution.

[arsenalol]

Il existe une solution pour contourner le souci : Dans le fichier AdminController.php ( /www/override/classes/controller)

Il faut ajouter une condition dans la fonction productImport() : 

if ($product->id && Product::existsInDatabase((int)$product->id, 'product'))

{
      // Ne rien faire
}
else
{
     le reste du code
}

Ce qui nous donne donc : 

  ....
            else
            {
                if (array_key_exists('id', $info) && (int)$info['id'] && Product::existsInDatabase((int)$info['id'], 'product'))
                    $product = new Product((int)$info['id']);
                else
                    $product = new Product();
            }

            //-----Condition ajoutée------
            if ($product->id && Product::existsInDatabase((int)$product->id, 'product'))
                
            {
                // Ne rien faire
            }
            else
            {// Code déjà existant :
                if (array_key_exists('id', $info) && (int)$info['id'] && Product::existsInDatabase((int)$info['id'], 'product'))
                {
                    ....
                    ...
                    Product::addFeatureProductImport($product->id, $id_feature, $id_feature_value);
                }
                // clean feature positions to avoid conflict
                Feature::cleanPositions();
            }
        }// C'est l'accolade qu'il faut ajouter pour fermer le else

Et vous importer le fichier CSV autant de fois qu'il le faut.
Seule condition : Avoir l'ID du fichier CSV qui correspond à l'ID que prestashop affectera au produit.

 

Normalement, ce bout de code dit : 

- ok, ce produit existe déjà ( l'ID existe deja), donc je vais mettre à jour tous les champs => ça prend du temps

 

En commentant ces lignes :

- ok ce produit existe déjà, donc je ne fais rien.

Comme ça, en important le même fichier plusieurs fois, on finit par importer tous les produits .

Edited May 25, 2014 by arsenalol (see edit history)

[mandoraa]

Bonjour,

 

Je ne trouve pas de fichier AdminController.php dans ( controllers/admin/)...

J'ai le problème d'import csv aussi, en moyenne 95 produits par csv des fois ça passe des fois non alors qu'ils font la même taille.

 

@+

Mandora

[arsenalol]

/www/override/classes/controller

[mandoraa]

je l'ai trouvé dans www/classes/controller et non pas dans override.

 

@+

[arsenalol]

Oui, en effet, c'est dans www/classes/controller. Ce fichier existe dans 2 dossiers différents, c'est pour ça.

[mandoraa]

je vais essayer un csv de 50 produits d'abord avant de modifier le code.