Jump to content

J. Danse

Members
  • Posts

    2,563
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by J. Danse

  1. Tellement de reliquats sont présents, Atch... Entre le CSS, les rétro-compatibilités avec des versions jusque la 1.4 et j'en passe... Des fichiers qui devaient être supprimés en 1.6 (depuis la 1.5 !) sont toujours présent. L'URL se construit sur une certaine base, l'option n'a pas été totalement retirée, en gros :-/ (un simple rechercher me permet de te dire d'où vient ce reliquat, je ne comprends donc pas comment il a été oublié, en fait).
  2. Cool ça ! Ce serait dans Paramètres avancés > Email. Il faut cocher Utiliser mes propres paramètres SMTP (pour les experts uniquement). Les données sont mentionnées au niveau du compte MailJet, dans une section "SMTP" (quelque chose du genre).
  3. Ce ne serait pas impossible. L'idée serait peut-être d'envisager l'ouverture d'un compte gratuit chez MailJet afin de pouvoir paramétrer temporairement la sortie des emails via leur serveur SMTP, ce serait une piste pour savoir si le soucis surviendrait à ce moment là
  4. Bête question, mais c'est bien le bon ? Car dans la source, il y a un tas de trucs qui ne se retrouvent pas ici. Et je suis pas sur que c'est logique ? C'est bien celui du thème utilisé et à jour, là ?!
  5. C'est en effet pas très logique qu'il se retrouve là, lui. Très bizarre, en effet. Rien qui fait appel à prices.tpl ou autre à cet endroit dans le product-list ? :-/
  6. Vu qu'il ne s'agit plus d'un champ lié à la langue, il n'est pas associé à la table "product_lang" mais "product", simplement. Il faut donc altérer la structure de product pour correspondre, et ça devrait être bon.
  7. C'est donc bon signe. Le champ est en multilangue. Il faudrait surement modifier ça (il change en fonction de la langue ?). Product::$definition['fields']['pointsforts'] = array('type' => self::TYPE_HTML, 'lang' => false, 'validate' => 'isString');
  8. Si seulement j'avais du temps pour commencer tout les modules auxquels j'ai pensé, ;-)
  9. Il ne manquerait pas un paramètre value ? <input maxlength="5" id="pointsforts" name="pointsforts" type="text" value="{$product->pointsforts}" />
  10. Très honnêtement, je n'ai pas perdu mon temps à essayer, sur le coup. Ceci dit, je ne sais même pas trop pourquoi ça faisait ce truc... ... de souvenirs, c'était également lié à la surcharge de la variable $definition. Que je ne recommande donc pas (je recommande plus vite l'ajout des nouveaux champs éventuels au moment du constructeur).
  11. Exact. Par ailleurs, et c'est le plus fou [comprendre qui veut pourquoi], il faut éviter les commentaires d'en-tête des méthodes. J'ai cru remarqué que - sauf si c'est corrigé depuis - lors de la suppression de la surcharge, ils n'étaient pas complément supprimés et donc le fichier devient inutilisable. Il provoque même une erreur de syntaxe, qui plus est !
  12. L'utilisation de Tools::redirect($this->context->link->getModuleLink(...)) ne serait-elle pas judicieuse ?
  13. C'est en effet le même module. Avec, simplement, un affichage refait et... (voici toute la richesse de ce menu, ...) les images catégories affichées en bas de chaque onglet. En gros, vous l'avez. Mais ce n'est pas du tout ce à quoi vous (et tant d'autres) vous attendiez,
  14. Il est tout à fait possible de faire des surcharges et de les embarquer dans un module pour qu'elles soient installées lors de l'installation du module, oui,
  15. Dans ce cas, et si c'est particulier à la boutique en place (ou utilisé couramment ainsi), je propose de pencher sur l'idée d'un module propre à la boutique. Un contrôleur en Front Office (sécurisé via un éventuel paramètre) serait appelé par tâche cron tout les x temps. C'est finalement ce dernier qui récupérerait le fichier et qui le traiterait. Cette manière d'agir permet notamment un traitement en objet via les classes directes de PrestaShop. Je ne sais pas si ça collerait à votre besoin, mais c'est une piste.
  16. Aucunes questions idiotes, au contraire. Oui. D'autant que si on utilise un script PHP externe, on peut tout à fait récupérer le flux XML de l'entité souhaité (par exemple Product, Category, ...) et le convertir assez simplement en objet (XMLQuelqueChose). En C#, par exemple, j'ai pris soin de faire un cache pour chaque objet récupéré (attention, je ne fais que de la lecture et c'est donc tout naturel et sans problèmes pour autant, actuellement). Après, selon la nature du script et l'idée souhaitée, il est possible également d'avoir un module maison qui réalise le traitement. Mais c'est au cas par cas, je pense.
  17. J'ai, en effet, la même version. Mais je ne l'utilise pas. En voyant vite fait le code, je ne vois rien qui pourrait provoquer ça là ainsi. Par contre, si tu as encore des erreurs et que tu sais comment les reproduire, n'hésite pas à me contacter. On pourrait voir ensemble au pire pour essayer de forcer un peu la main pour connaitre la nature du fichier qui génère l'erreur, ça aiderait pas mal je pense!
  18. Relance client ? Le module natif ? Qui est à jour ? (Oui, mes posts sont des questions et très brèves, désolé ^^)
  19. Bonjour, Je vous confirme que la réception des données (d'ailleurs, l'envoi également) se fait via XML seulement. Des éléments de réponses se trouvent dans les classes du WebService quant à la sortie en JSON, par exemple, mais ce n'est pas implémenté. Tout dépend du contexte global et comme se déroule le processus, mais il est possible pour votre application de concevoir un interpréteur entre votre XML et l'objet. Ceci permettant par exemple de récupérer les données souhaitées en XML et puis de traiter cela via un objet. Ou bien, finalement, d'avoir une classe de type Product et que, au moment de la soumission au WebSevice, vous utilisez un "build" XML. Tout dépend donc un peu votre point de départ, votre point d'arrivée et l'outil de liaison utilisé entre les deux, je dirais.
  20. Heu ? Je doutes que ce soit le même problème, par contre. Vraiment.
  21. Vous avez également la possibilité de créer des pages CMS voire même des pages très spécifiques (avec un léger développement module) permettant d'agir comme des pages CMS pour les pages "vitrines". Personnellement, je ne vous conseille pas d'avoir deux sites distincts si la charte graphique est pareille,
  22. Bonjour, Scanner un billet (via QRCode ou éventuellement code barre) n'est pas une réelle difficulté. Tout dépend évidemment de quand et comment les billets doivent être scannés (via un smartphone ? De quel type ? Une douchette ? Les deux ? En mode connecté/déconnecté ? Pour comptabiliser ? Pour vérifier ? ;-))
×
×
  • Create New...

Important Information

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