Lionel Guichard

Il suffit de déposer le dossier vizzup_product dans le répertoire /module de prestashop. Comme un module classique.

Bonjour à tous, Voici un module permettant d'attacher vidéo à une fiche produit. Ce module ajoute une formulaire d'édition en back office dans la fiche produit. Quant à l'affichage en front office, il utilise thickbox intégré à prestashop pour afficher le player flash contenant la vidéo. Je vous laisse découvrir le fonctionnement sur la version de démonstration disponible à cette adresse : http://prestashop.inouit.com Ce module utilise la solution vidéo Vizzup, pour l'utiliser il faut disposer d'une clé d'API. Plus d'informations sur le site http://www.vizzup.com 26.03.2009, sortie Version 0.1 : ================================= - Version intiale vizzup_product_v0.1.zip

Je suis pas vraiment d'accord avec toi sur les ORM. Les performances actuel sont bien meilleur depuis l'intégration de PDO ! Un ORM ce n'est pas 42 couche d'abstraction il utilise seulement la couche du type de BD utilisé, ensuite c'est PDO qui fait le reste. Votre mini truc perso convient peut-être à vos besoins puissent que vous utilisez MYSQL, voir postgre mais ce n'est peut-être pas le cas pour tout le monde Au final sur votre mini truc perso on cherche pas mal comment manipuler le bouzin, un bon coup d'objet la dessus pourrait rafraîchir la bête ! Le mélange array, objet est vachement confu. D'ailleurs ce n'est pas pour rien que des grands comme "Dailymotion" utilise les composants de framework reconnus pour leurs dev. ex : http://www.symfony-project.org/blog/2009/02/18/dailymotion-powered-by-symfony

Je n'ai pas dis que ce n'est pas totalement dépourvu de structure, mais ça manque. Je ne parle pas forcément de structure MVC qui ne définie que les spécifications de 3 couches d'abstraction pour un développement. Mais de la façon de l'avoir implémenté. Par exemple les fichiers .php à la racine du site comme controller, index.php?module=order&action=view serait plus propre. Le model qui n'emporte pas d'ORM et qui renvoie une fois sur deux des objets ou tableau ce qui rend la manipulation des données difficile. Parfois tu récupère une array parfois un object c'est très bizarre. L'autre point c'est que la surcharge du code n'est possible qu'avec les hook Le but n'est pas de débattre sur ce qu'il existe aujourd'hui, je pense qu'on est tous les deux conscient qu'il y a un travail de refactoring à faire. Maintenant, c'est de savoir comment le faire Voilà, voilou

Ah je viens d'apprendre que le répertoire /themes et la vue de PS xD C'est comme /classes c'est le model ou le controller ? j'avoue j'hésite là Bref, je pense pas qu'on soit là pour débattre sur les erreurs d'interprétation de l'un ou l'autre, mais on ne peut pas vraiment dire que PS est construit sur un modèle MVC, mais je pense que tu en es conscient ;o)

Je propose une évolution de la surcharge du thème de prestashop, qui est bien trop réduite à ce jour. 1er point : La surcharge des fichiers .php qui sont à la racine n'est pas possible 2ème point : Impossible de surcharger le "model" de BD (répertoire /classes) dans le thème. 3ème point : Impossible de surcharger une classe myModule Ca limite énormément la personnalisation et on est trop souvent obligé de toucher aux fichiers du core. Je propose une architecture plus stucturée comme ceci : /themes/pestashop/controller/header.php /themes/pestashop/classes/myClass_*.php /themes/pestashop/modules/myblock/myblock.php /themes/pestashop/templates/*.tpl C'est une ébauche mais l'idée est là, je pense qu'une structure MVC plus structurée pourrait être très bénéfique pour PS et les prochaines versions à venir Personnellement, je vois mal comment on va mettre à jour facilement nos projets en production avec l'architecture actuelle

Oui oui je regarde le svn Je suis dessus, effectivement il ne reconnait pas les accents, c'est assez problèmatique pour une boutique en FR

@ericlemoine, de rien J'ai trouvé d'autres problèmes bloquants la semaine dernière (Url image, tag etc..) Je vais essayer de faire une version corrigée cette semaine.

Je continue le débug de cet import CSV qui apporte pas mal de misères aux utilisateurs Lorsque vous avez un CSV avec des lignes videos pour les caractéristiques d'un produit, vous avez un joli message d'erreur "Tentative de piratage", rassurez vous, vous n'êtes pas un hackeur Le problème vient de ce bout de code dans la fonction productImport() qui ne vérifie pas si le caractéristique est vide : foreach ($features AS $feature => $value) { if (!strncmp($feature, '#F_', 3)) { $feature_name = str_replace('#F_', '', $feature); $id_feature = Feature::addFeatureImport(Tools::strtolower($feature_name)); $id_feature_value = FeatureValue::addFeatureValueImport($id_feature, $product->{$feature}); Product::addFeatureProductImport($product->id, $id_feature, $id_feature_value); } } Remplacer par : foreach ($features AS $feature => $value) { if (!strncmp($feature, '#F_', 3) AND !empty($value)) { $feature_name = str_replace('#F_', '', $feature); $id_feature = Feature::addFeatureImport(Tools::strtolower($feature_name)); $id_feature_value = FeatureValue::addFeatureValueImport($id_feature, $product->{$feature}); Product::addFeatureProductImport($product->id, $id_feature, $id_feature_value); } }

Bonsoir à tous, Après plusieurs heures de péripéties à essayer de faire fonctionner cet import CSV... Voici une solution pour ceux qui cherchent encore. Il y effectivement un bug majeur avec la langue par défaut du back office. En effet par défault pour remplir les champs link_rewrite des tables le code utiliser l'id_lang à 1. Donc si votre langue courante du back office n'a pas un ID de 1 ça ne fonctionne pas... Exemple ligne 618 du fichier AdminImport.php Remplacer if ((isset($product->link_rewrite) AND empty($product->link_rewrite)) OR !$valid_link) $product->link_rewrite = Tools::link_rewrite($product->name[1]); par if ((isset($product->link_rewrite) AND empty($product->link_rewrite)) OR !$valid_link) $product->link_rewrite = Tools::link_rewrite($product->name[intval(Configuration::get('PS_LANG_DEFAULT'))]); Il y a de nombreux endroits à modifier, je vous fournit le patch dès que possible.

Pas forcément besoin de scanner tous les répertoires. Vu qu'avec la table tab on sait quel module est appelé on sait qu'il faut autoloader le repertoire classes/ Ou sinon encore mieux, un __autoload() dans la classe Module !

Hihi Tant qu'on y est pour avoir une structure un peu hiérarchisé sur le module on pourrait : - Dans l'__autoload du config.inc.php charger également les classes qui peuvent être ajoutées dans le module, sinon dans /module/AdminMyTab.php on est obligé de faire un require /module/MyTab.php pas très propre. - Voir avoir une structure du module de la sorte : /module/myModule/admin/AdminMyTab.php -> petite modification sur le toolbar.php /module/myModule/classes/Tab.php

Par contre dans ta modification dans le toolbar.php tu as mis l'include du PS_ADMIN_DIR avant celui du module. Je pense qu'il serait bien d'inverser ton if / elseif pour que l'on puisse écraser au besoin un onglet de l'admin sans toucher au core.

Cédric nous avons un problème similaire pour un de nos projets. La gestion des tags est trop réduite. Nous pensions développer une extension avec la possibilité de faire des groupes de mot clés, attributions à des produits multiples etc... Ca manque cruellement quand on veut faire des exceptions sur des listes de produits sans créer de catégorie... @Damien, quelque chose de prévu pour la 1.2 ?

Fonctionnalité intégré dans le core cf : http://www.prestashop.com/forums/viewthread/12949/#58391