Jump to content

J. Danse

Members
  • Posts

    2,563
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by J. Danse

  1. Merci ; je voulais plutôt parler de toi, niveau études. Je ne sais pas comment appeler cela, chez nous c'est Bachelier/Master en Web, par exemple. C'est juste de la curiosité, =)
  2. Tiens, Waschou, une question un peu en aparté: dans quel contexte de TFE vous réalisez votre module ? Plus précisément, dans quel secteur d'étude êtes-vous ?
  3. Allez, pour ceux qui veulent connaitre le pourquoi de la 1.6.0.13: https://github.com/PrestaShop/PrestaShop/commit/c1a79bfdd4254e0cf1865778073a713ed12afbee
  4. Il souhaite faire du refresh à la volée, en fait ;-)
  5. "que le php n'est pas actualisé" ; ça veut dire quoi, ça ? Comment ça, un "PHP actualisé" ?
  6. Et, pour t'aider encore plus: Tools::getValue('input_name') te permettra, dans le PHP, de récupérer la valeur du champ envoyé.
  7. Pour l'info, en effet, la 0.13 remplace la 0.12. Il semblerait qu'un soucis (surement majeur) soit à l'origine de ce changement. Pour appel, on reproche fort bien souvent à PrestaShop que d'un ZIP à l'autre d'une même version, il existe des différences. Ceci étant pour faire des correctifs importants mais ne nécessitant pas une version à part entière (selon la procédure que suivait PrestaShop). Désormais, ils ont suivi les remarques de certains et ont donc très bien faire de remplacer cette version (entre nous, je préfère une version rapidement corrigée que de la laissée traînée avec ce bug). Il est d'ailleurs pas plus mal que cette version ne soit plus en libre accès sur le site de PrestaShop. Pour SourceForge, je ne peux m'avancer. Désormais, également, chaque Pull Request effectué via GitHub sera traité avec Travis, j'ai pu voir que des tests sous deux versions de PHP et sous Linux étaient automatisés. Bien sur, cela n'exempt pas les erreurs mais vous pourrez aussi remarquer que de nombreux tests d'utilisation "classique" sont réalisés ; ainsi on évite pas mal de surprises, je pense bien.
  8. N'est-ce pas ? =) Encore une raison de faire ce petit module, vous allez voir c'est très utile, relativement aisé et très simple en même temps. Il faudra passer par jQuery.ajax, pour vous mettre sur la voie. D'ici samedi, en étant à temps "plein" dessus ? Vous pouvez le faire ! Vous allez tenir votre objectif, sans soucis ! Pas de soucis ; ma satisfaction résidera dans votre fierté d'accomplissement de vos objectifs et de votre module, =)
  9. C'est déjà bien plus clair, pour moi, en tout cas ! Raison de plus que pour apprendre à faire un module cohérent et correct, niveau PrestaShop, si il s'agit d'une volonté de présentation en TFE ! =) Donc, dans l'idée on à une structuration suivante: Une page unique de présentation des données dans laquelle se trouve: Un formulaire avec liste de sélection (basée sur la table "machines"). Un formulaire avec liste de sélection (basée sur la table "machines/composants") filtrée sur base de la machine sélectionnée. Un formulaire avec liste de sélection (basée sur la table "composants") filtrée sur base du couple machine/composant sélectionné. Une table de donnée (basée sur le composant choisi). Voilà pour le résumé, ce sera plus "simple" pour la suite, Bon, autant dire que vu le nombre d'enregistrements par sélection que vous pouvez avoir, il va être préférable de fonctionner par une méthode AJAX pour la récupération des données des étapes suivant la première sélection, pour bien faire. Dans votre cas, vous pouvez utilisez la méthode getContent() pour réaliser votre besoin. Il n'y a pas forcément lieu d'utiliser un ModuleAdminController. Vous pourrez, chez votre client, configurer un accès rapide voir même un léger ModuleAdminController qui n'aura qu'une intention: redirigé vers la page où se situe le getContent(). Donc, concentrez vous sur cette méthode. Ce sera plus judicieux !
  10. Tout dépend de beaucoup, et en premier de votre ré-utilisabilité du module, de vos souhaits et de ce que vous voulez faire au final. Disons qu'on peut toujours "contourner" les standards et les pratiques de programmation PrestaShop. Seulement, ce serait dommage de ne pas profiter des outils fournis (tels que des Helpers) et cela vous permettrait d'en apprendre plus sur le fonctionnement interne et d'en tirer avantage. Si le module est destiné à un seul et unique compte marchand, via une diffusion en direct, vous êtes - je dirais - libre de faire un peu comme vous le sentez. Si l'idée est une diffusion massive, autant vous dire que le respect des standards est très important, sur le coup. Pour le getContent(), il n'y a pas de conventions directes pour le nommage du fichier. Dans l'idée, je l'appelle configure.tpl car il est le template lié à la configuration mais vous pouvez l'appeller comme bon vous semble, du moment que c'est ce nom qui est renseigné dans le module, bien entendu =) La méthode getContent() à pour objectif de fournir un espace de configuration au module. Mais elle ne se limite pas à cela. A ce niveau, tout dépend de la fréquence de vision de votre formulaire et de l'impact que cela peut avoir sur un choix délibéré qui est l'utilisation d'un contrôleur à part (accessible via le menu) ou de la méthode getContent() (accessible via la page modules ou via un accès rapide configuré). A l'heure actuelle, seul vous pouvez en décidez. Je n'ai pas assez d'informations sur l'objectif du module et sur ce que représente son utilisation, je ne peux donc pas vous aiguiller là-dessus. Si jamais vous le pouvez, n'hésitez pas à détaillé un peu plus l'objet et l'objectif du module, afin que je puisse vous aider plus amplement et, peut-être même, vous fournir une structure et des éléments de base pour avancer là-dessus, ce sera surement plus "simple" pour vous,
  11. Hi, It's all I like: converting a module of a version in another version ! I can do it. ;-) Best regards, J. Danse
  12. Bonjour, N'hésitez pas à me communiquer votre document afin de voir pour vous proposer mes services, si jamais Je vous laisse mes coordonnées dans un message privé, par facilité. Bien à vous, J. Danse.
  13. Bonjour, En effet. Les Helper ne sont pas prévu pour être utilisé en Front, nativement. Ils nécessite une modification de leur modèle et une copie des fichiers templates. L'idée étant d'avoir le modèle dans votre module et les templates associés. (Tant que cela n'est pas rendu possible, bien entendu).
  14. Pour la méthode getContent() ce n'est pas tant une question de "pratique", par contre. En fait, la méthode getContent() permet de configurer un module. La présence de celle-ci a pour effet de bord de créer un bouton "Configurer" au niveau de la liste des modules, pour le module donné. Dès lors que l'on arrive sur la page de configuration, c'est le contenu retourné par la méthode getContent() qui sera affiché. Ainsi, on peut y afficher un code html, du simple texte ou alors un HelperForm plus poussé. Il s'agit surtout d'y mettre des éléments de configurations/des paramètres. Prenons l'exemple du module blockcategories (https://github.com/PrestaShop/blockcategories/blob/master/blockcategories.php#L97): le formulaire permet deux/trois petites configurations utiles au module mais ne nécessitant pas un contrôleur particulier. Concernant cette ligne de code: $EXAMPLE_CONF = Tools::getValue('EXAMPLE_CONF'); Attention, il n'est pas question de table "tools" (qui n'existe d'ailleurs pas). Il s'agit d'utiliser une méthode de la classe Tools permettant de récupérer la valeur de $_POST['EXAMPLE_CONF'] et/ou de $_GET['EXAMPLE_CONF']. On pourrait très bien l'écrire comme en PHP classique, mais c'est un standard de PrestaShop. EXAMPLE_CONF est le name de l'input retourné via le formulaire (cfr https://github.com/PrestaEdit/Canvas-Module-Prestashop-15/blob/master/views/templates/admin/configure.tpl#L16). Ici, pour le formulaire, on a fait simple en utilisant un fichier de template dans lequel le formulaire est inscrit en "dur". (https://github.com/PrestaEdit/Canvas-Module-Prestashop-15/blob/master/example.php#L208) La variable $output est utilisée à cette ligne, https://github.com/PrestaEdit/Canvas-Module-Prestashop-15/blob/master/example.php#L192. Elle permet de faire un "echo" de son contenu et d'afficher ensuite le formulaire. Pour le HelperForm, c'est un rien plus "complexe". Je vous conseille vivement d'analyser vite fait ce fichier: https://github.com/PrestaShop/PrestaShop/blob/1.6/controllers/admin/AdminPatternsController.php ; celui-ci en particulier car il a l'avantage de vous exposer un ensemble des champs différents, Pour le ModuleAdminController, voici dans l'exemple comment on crée un onglet dans le menu du Back Office: https://github.com/PrestaEdit/Canvas-Module-Prestashop-15/blob/master/example.php#L124 Et voici donc le fichier utilisé: https://github.com/PrestaEdit/Canvas-Module-Prestashop-15/blob/master/controllers/admin/AdminExampleController.php Des commentaires à son sujet feront bientôt leurs apparitions, je pense.
  15. Pas de soucis ! N'hésitez surtout pas à poser vos questions, même les plus simples et celles que vous pensez "idiotes". Nous sommes tous passés par là ;-) (Je le sortirai, mais je ne sais pas encore quand ni comment donc n'hésitez pas ç poser vos questions au préalable ;-))
  16. Voici le genre de sujet qui me fait dire qu'il est temps que je finalise mon bouquin, moi ! Alors, je pense que le plus simple est en effet d'agir comme vous le faites: posez question petit à petit, tenter de comprendre la mécanique au fur et à mesure. En effet, un module s'articule sur deux plans: des hooks (points d'accroches) et des contrôleurs. Les contrôleurs peuvent êtres front ou back office. La méthode getContent() est utile pour une configuration propre au module, ne nécessitant souvent qu'un simple formulaire (sauf exception). Je vous balance du code... Mes excuses, il est que très peu commenté: https://github.com/PrestaEdit/Canvas-Module-Prestashop-15 ; mais il va vous permettre de vous inspirer et d'éventuellement poser des questions en y faisant référence, selon moi. Dans votre cas, je pense que je partirais sur une utilisation d'un ModuleAdminController, par facilité. De même que j'utiliserais un Helperform pour le formulaire/les inputs. Bien entendu, il est possible de faire cela assez simplement et en dénaturant un rien les outils natifs de PrestaShop, mais je pense que cela vous permettra d'en apprendre plus sur la mécanique et de profiter des outils natifs, justement,
  17. Permettez moi de réagir, mais la question n'est pas forcément hors sujet. D'une part, la question fait référence à des fonctionnalités que vous proposez dans vos hébergements et un client potentiel souhaite voir si le changement d’hébergeur (en l’occurrence, vous !) serait bénéfique ou non pour lui. De plus, entre nous, cela permet de voir si les réponses données peuvent être cohérentes et compréhensibles. Cela ne semble pas être significatif pour vous, mais pour un marchand/client n'ayant pas de connaissances techniques en termes d'hébergement à besoin de cela. Le ton est donné, en tout cas. Pour ma part, si j'avais pu avoir une attirance quelconque pour vos services, il est certain que ce n'est nullement pas/plus le cas désormais. Vous pouvez demander la censure et la suppression de l'ensemble des messages de ce sujet, si vous le souhaitez. Mais, ainsi, j'aurais pris le temps de... Il faut donc être client chez vous pour obtenir un premier contact/support "bien meilleur", si j'ai bien compris. Le message privé aurait bien pu être utilisé par vos soins, en notifiant l'utilisateur que vous allez lui répondre en privé et lui mentionner le fait que sa question reste hors sujet, ceci dit. A bon entendeur, donc.
  18. La table existe belle et bien, et ce depuis la version 1.1.0.1 de PrestaShop. Elle a bien entendu changée au fil du temps, mais elle est toujours la même. En 1.5.0.1, elle est renommée en cart_rule_product_rule_value.
  19. Pour en revenir au sujet initial, en effet, il est tout à fait possible de "migrer" de PrestaBox vers une offre PrestaShop, que cela soit en Cloud ou en auto-hébergé, ceci dit. Par contre, en effet, il nécessite un dump/back-up facturé à 150€ HT par PrestaShop. Pour le reste, c'est un sujet transversal à d'autres et je ne vais donc pas forcément alimenter les débats/propos.
  20. De fait. Voici, sinon, un accès: http://demo.vinummaster.com/admindemo/index.php?controller=AdminModules&configure=vm_advancedconfigurator&tab_module=front_office_features&module_name=vm_advancedconfigurator
  21. Bon... Forfait annuel à minimum +/- 4€ / mois. Donc, +/- 48€ / an. En version mensuelle, ce serait +/- 70€. Cette première souscription comporte des publicités. A ce tarif là, un module à 60€ voire un thème variant entre 30€ et 90€ (pour certains, j'exclus d'office ceux au-dessus) est... finalement, un coût quasi semblable (si pas moins cher) et offre une plus grande liberté. Personnellement, l'argumentation est vite trouvée. Après, c'est une question de volonté, aussi. Un souhait de travailler avec tel ou tel outil. Ni plus ni moins, je pense.
  22. Bonjour, Ceci a été corrigé dans les versions plus récentes. Voici la surcharge du controller pour vous permettre d'en profiter en 1.6.0.9. Ce fichier est à placer dans /override/controllers/admin/ et vous devez régénérer le fichier /cache/class_index AdminReturnController.php
  23. Exact, doekia, pour la partie Cloud. Pour avoir pu faire une migration PrestaBox vers PrestaShop, le backup (coûtant 150€ HT) est complet. C'est sur cette base qu'il faut partir, quoiqu'il arrive !
  24. Voilà, exactement. Des erreurs, ils en subsistent à coup sur. Et pour répondre à la question, ce genre de correctif sera vite pris en compte, une refonte plus "grosse" le sera moins vite, sinon. Un execute() avec DELETE n'est pas anormal, par contre. PS: Voici la proposition GitHub que j'ai effectué: https://github.com/PrestaShop/PrestaShop/pull/2459/files
  25. Bonjour, Majoritairement, oui et non. Cette réponse vous aide, n'est-ce pas ? Pas du tout, je le conçois bien ! Plus sérieusement... Pour avoir fait une légère transposition des requêtes pour qu'elles soient compatibles SQL Server, je peux vous répondre sur plusieurs détails: Tout d'abord, la seule méthode pour que la mise à jour n'écrase pas tout est d'utiliser les surcharges. Si surchage il y a, la mise à jour ne sert d'ailleurs plus à rien, finalement. Ensuite, le gros du gros repose également sur les modules: et là, aucunes surcharges possibles (directement, nativement du moins). Finalement, une "bonne" idée/méthode serait de vous proposer de faire vos propositions modifiées sur GitHub, ainsi l'ensemble de la communauté profiterait des améliorations de performances ET vous aurez le tout intégré nativement. Mais, entre nous, c'est un boulot dingue et qui prends pas mal de temps.
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More