Imaginaerum

Il faut inclucre le fichier config.php de prestashop $config = dirname(dirname(dirname(__FILE__))) . '/config/config.inc.php'; include_once $config; dirname(dirname(dirname(__FILE__))) fait pointer vers la racine, il faut donc peut être modifier l'inclusion des dirname pour avoir le bon chemin. car dans le code que je donne plus haut, j'inclus depuis un fichier situé dans un de mes plugins

On peut faire comme on veut en fait... là c'est la facilité de les placer les unes derrières les autres. si ona besoin de changer l'ordre il surffit de recuperer les images associées au produit et de reaffecter la position

C'est tout à fait ça... je te laisserais bien volontiers mon coe source, mais il y a trop d'éléments et methodes liées à mon script. du coup ca serait plus compliqué à comprendre... Mais voilà comment ca fonctionne. On a une image source (http, ftp, etc...). De mon côté, je fait un @file_get_contents de cette image. Il faut egalement avoir un id_product pour créer un nouvel objet image: $image_content = @file_get_contents('/path/vers/l_images'); (On peut faire notre file_get_contents vers une url pour peut que la lecture http soit faisable depuis la source) $image = new Image; $image->id_product = $product_id; $image->position = Image::getHighestPosition($product_id) + 1; $image->cover = 0; $image->legend = array($lang_id => $legend); puis enfin: if (($image->validateFields(false, true)) === true && ($image->validateFieldsLang(false, true)) === true && $image->add()) { /* SEE \controllers\admin\AdminImportController.php */ $tmpfile = tempnam(_PS_TMP_IMG_DIR_, 'ps_import'); $path = $image->getPathForCreation(); $fp = fopen($tmpfile, 'w+'); fputs($fp, $image_content); fclose($fp); if (is_file($tmpfile)) { ImageManager::resize($tmpfile, $path . '.jpg'); $images_types = ImageType::getImagesTypes('products'); foreach ($images_types as $image_type) { ImageManager::resize($tmpfile, $path . '-' . stripslashes($image_type['name']) . '.jpg', $image_type['width'], $image_type['height']); } unlink($tmpfile); return $image->id; } else { $image->delete(); } } On notera qu'on met directement l'extension .jpg. Si on veut être "propre" et strict, il faudrait recupérer la config presta et determiner si on est jpg ou png Il faut donc pour la recette : - un id_product - une image - créer un objet image Il faut faire attention a: - ce que l'image existe pas déjà et qu'elle soit affectée à un produit, sinon on aura a chaque fois la même image affectée au produit (d'où la necessité d'avoir une clé unique qui dans ce cas est la légende (car on a pas trop le choix au final). sauf si on commence à comparer le contenu de l'image, sa taille en octet, etc...

Tout par mysql, du code et des portions de code du core... C'est à dire que suivant l'id shop et lang je génére un nom de legende assez unique en fait (pas top, mais obligé)... Du coup je check si ma legende existe. Si oui, on ne fait rien ou on update l'image si elle est différente. Si non, j'importe celle-ci... Par le biais de bouts de code du core et des insertion mysql. Y a un controller qui donne une partie de la solution : \controllers\admin\AdminImportController.php où l'oin retrouve une methode $image->add(); Si la methode resize echoue, presta supprime l'image qu'il a inseré dans la base et le fichier temporaire qu'il a tenté d'importé...

C'est ce qui me semblait flou... Je présumais de l'existence d'un cache dédié à MySQL... Mais j'ai pas pris la peine d'aller jeter un oeil dans les classes DB...

J'utilise celles du core... mais j'avais pas lu tous le code des classes : getValue($sql, $use_cache = true); J'avais pas du tout vu l'argument $use_cache

c'est juste un ratio... Si panier produit A = 5 et B vaut 1.5 pour 1 qté de A ca fait 5*1.5 Bref... Aprés faut qu'on "capture" la commande pour ensuite mettre à jour tout ca tranquillement... Donc faut recupérer les commandes, les flagger une fois traitées (sinon ca va decrementer à l'infini) puis faire nos calcule et ajuster les stock des combinaisons... le tout via un hook ou un cron.

dés l'instant où le systéme de caisse génére de l'export ou a des webservice, la mise a jour des stocks temps réel est simple... Je suis d'ailleurs sur un projet de ce type. mise à jours stock toutes les 6 heurs depuis des fournisseurs. Donc peut importe le logiciel, fournisseur, transporteur il doit impérativement fournir l'etat des stock... aprés c'est les dev qui gérent

Non je n'ai jamais fait ce dev, d'ailleurs je débute sur presta. Mais je suis developpeur et je pense avoir bien assimilé tout le "core" de presta et j'ai une grosse expérience ecommerce sur du magento... Donc d'aprés ce que j'en ai vu c'est tout a fait faisable... Sauf que je passerrais pas un ajax plutôt que par une modif de block ou création de module.... dans la mesure où j'aime pas du tout la gestion des théme presta (imaintenable sur le long terme)... Utiliser les textures reviendrait a créer autant d'attributs que de produit et donc de combinaisons exponentielles... bref: sur 10000 produits ca pue ! Donc en gros à l'affichage d'un produit, je ferais une recup des id atributs et je recupererais l'image de la combi et je substituerais le block couleur par ma recup ajax... Ajax permet d'inclure un js en autoinclude et de gérer son code et ses données comme on veut. L'inconvénanient c'est une requette http supplémentaire et du temps de chargement... (j'applique ca dans un autre domaine (prix modifiés à la volée) et ca marche instantanément sur un bon dédié)

Avant de remonter les bugs, j'aimerais les soumettre ici. Le cache prest est un peu flou... et il génére des absurdités... J'ai crée un module d'import qui se lance par période et d'optimise par la mise en mémoire d'objet et données. Il ne met à jours les objets presta que si necessaire et desactive automatiquement les cache prestashop (smarty + cache). (et il ne travaille qu'a des heures impossible (pour un site b2b) Bref... Sauf qu'avec tout ca, les requetes mysql sont out sur certains cas... Avec xcache ca marche à peu prés... mais j'ai testé les différents cache et le cache FS (file system) est parterre... Si je fais : $query = 'SELECT id_image FROM ' . $this->getTable('image_lang') . ' WHERE legend=' . $this->pSQL($legend) . ' AND id_lang=' . $this->getIdLang(); (la methode getTable, pSQL et getIdLang sont propres à mes scripts ;) ) La sortie m'indique des id alors que ce n'est pas la cas (j'ai vidé le catalogue par le biais du module cleaner de presta). Si le catalogue n'atait pas vidé et que j'appliquais ceci alors que des id auraietn changés : CATASTROPHE ! Bref... A l'inverse si je fais ca : $query = 'SELECT id_image FROM ' . $this->getTable('image_lang') . ' WHERE legend=' . $this->pSQL($legend) . ' AND id_lang=' . $this->getIdLang() . ' AND ' . rand(0, 555555555) . '!=' . rand(555555556, 9999999999); Il y a plus de soucis... (d'ailleurs on peut tourner sans cache avec ca... Donc je suppose qu'on a des cache mysql ou autre.... sauf que les vider sur des taches cron est pas une bonne idée... Vider systématiquement des caches même sur des cron reviendrait à pas utiliser de cache ou alors une partie de la journée... Même si mon cron fait en sorte de mettre à jour ces fameux cache que lorsqu'il y a necessité (changement de valeur d'une données).... Bref... Si quelqu'un veut tester ou a des retours... NB: pourquoi les objets gére t il le cache ? la methode update de l'objet Object clean tout ca systématiquement. je veux bien que ca soit l'endroit le plus facile à gérer.... Mais la POO a pour philosophie de separer les flux... On a rien en admin qui permette de gérer les caches (vider, gérer)... En gros presta essaye de se debrouiller comme il peut avec ses caches et au final les dev sont obligés de les gérer comme il peuvent... C'est catastrophique si on ne prends pas en compte les caches sur des taches de fond. on se retrouve avec une appli qui bouffe de la mémoire et rame pour rien.

SELECT cl.name AS category_name, i.id_image AS image_id, p.id_product, p.id_category_default, p.on_sale, p.quantity, pl.name, pl.description, pl.description_short FROM 5y1_product p, 5y1_category_lang cl, 5y1_product_lang pl, 5y1_image i WHERE p.id_product = pl.id_product AND cl.id_category = p.id_category_default AND (p.id_product = i.id_product AND i.cover=1) Sauf qu'on ne récupére que l'id de l'image cover... car l'url est pas stockée et passer par mysql pour faire un explode de l'id pour obtenir un equivalent /img/3/5/35.jpg serait trop lourd et il faudrait passer par des procédures stockées... d'autant qu'on peut avoir du png et que l'url du site peut varier (utilisation de CDN par exemple) Pour obtenir l'url on va passer par PHP... du coup on a pas forcément besoin de l'id de l'image car une methode de la classe produit le fait. $id_image = Product::getCover($id_product); if (sizeof($id_image) > 0) { $image = new Image($id_image['id_image']); $image_url = _PS_BASE_URL_._THEME_PROD_DIR_.$image->getExistingImgPath().".jpg"; }

En fait non... L'image de la combinaison sert juste a afficher la bonne image au clic sur la couleur... Pour mettre une image à la place de la couleur on peut évidement pas passer par la texture.... faut modifier le bloc pour qu'à la volée il récupére non pas la couleur mais une des images affectée à la combinaison... ce demande du developpement.

Faudrait essayer de mettre un setTimeout sur l'execution du js pour voir si ca vient pas de l'ordre d'affichage du dom...

Voici la requête: SELECT cl.name AS category_name, p.id_product, p.id_category_default, p.on_sale, p.quantity, pl.name, pl.description, pl.description_short FROM 5y1_product p, 5y1_category_lang cl, 5y1_product_lang pl WHERE p.id_product = pl.id_product AND cl.id_category = p.id_category_default Ca ajoute le nom de la category signalée par le id_category_default... Par contre j'ai pas compris le lien photo ?

Je vois pas de soucis ^^... ils fonctionnent Au passage : 404 sur http://fonts.googleapis.com/css?family=Open%20Sens:400,300,700,600 C'est Open%20Sans (Open+Sans) et non Sens et 404 sur http://www.masquarade.be/themes/midnight/css/modules/blockuserinfo/blockuserinfo.css Sinon trés sympa :)