Jump to content

J. Danse

Members
  • Posts

    2,563
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by J. Danse

  1. Désormais, tu peux tout à fait appeler un "Hook" (et donc ses modules greffer) via le template lui-même. Le tout via: {hook h="Top2"} Ce qui devrait peut-être t'aider.
  2. Bonsoir, Cette limitation se trouve dans le fichier /<admin>/ajaxfilemanager/inc/config.tinymce.php en L69. //UPLOAD OPTIONS CONFIG define('CONFIG_UPLOAD_MAXSIZE', 5000 * 1024 ); //by byte
  3. En fait, non. A savoir qu'un des modules que je crée instaure quelques éléments dont des AdminController qui se base sur des controllers existant (j'étends juste le controller et je modifier ce dont j'ai besoin). Rien ne vous empêche de créer un controller étendu et, dans le fichier principal du module, de faire l'inclusion du modèle nouvellement crée. Autant dire que c'est possible mais pas forcément conseiller, non plus. Si tout les modules font de même, on risque un gros soucis. Mais possible, ça l'est.
  4. Pas de soucis, et je pense que c'est justement ce qui m'induisait en erreur... Les nouveaux hooks ne sont pas forcément référencé en base de données, mais bien dans le template. Le tout est de voir comment exploiter le tout, même si j'ai mon idée là dessus
  5. Merci. Mais, entre nous, ils en manquent quelques un, non ? Tel que "displayAdminHomeQuickLinks" ? A savoir, au final, les hooks qui sont dans les templates ?
  6. Titre du hook: beforeSendMail Description: Le but de ce hook serait de permettre à des modules d’interagir avant l'envoi d'un email, pour par exemple permettre d'afficher des informations sur d'éventuels produits ou autre...
  7. Bonjour à tous, Bonjour la team, Je sais que le sujet existe déjà sur la version anglaise du forum mais il ne semble pas exister en français. Ce sujet a pour but de donner le nom et description des hooks que l'on souhaiterait voir apparaitre...
  8. Je viens de réaliser ma requête en overridant la méthode dispatch classe Dispatcher et en créant une nouvelle classe se basant purement et simplement sur la classe PrestaShopExeption Le tout fonctionne nickel mais, bémol, il me faut modifier le fichier /tools/smarty/Smarty.class.php afin de retirer la classe existante dans le package de Smarty. De plus, il ne semble pas possible de faire un override de la classe Dispatcher sans la copier/coller entièrement et y effectuer les modifications. Juste ? En voici le résultat:
  9. Bonjour à tous, Bonjour la Team, Adorant la gestion des exceptions nouvelles dans la 1.5 et trouvant ça bien plus clair voir plus "pro" (une exception ne l'étant pas vraiment ! ), j'ai souhaité rajouter une exception pour Smarty mais je n'y arrive pas en override et je vois que la classe Smarty en a une (vide). Pensez-vous qu'il est possible de suivre la même mécanique pour les SmartyException ? Cordialement, J. Danse
  10. Bon. Je dois surement me focaliser sur un détail (et ça me perturbe). Je vais essayer de contacter Raphaël en direct, voir ce qu'il en est de ces hooks mystères ! =) Merci, en tout cas.
  11. D'accord ! Je vais essayer de voir ça ! Merci bien. Je laisse un peu ce sujet ouvert, je vais venir dire que c'est [Résolu] d'ici peu (quand j'aurais fait mes tests, )
  12. C'est à dire que, par exemple, il me semble que de nouveaux hooks sont existant (mentionnés par Raphael) mais je ne les vois pas dans ma table correspondante et je souhaiterais en profiter,
  13. Oui, j'en utilise trois, il me semble... Je vais voir. Mais, au final, comment synchroniser la base de données ? Avec l'outil dev dans l'install ?
  14. Edit: J'ai rien dit, j'avais pas vu le lien au dessus !
  15. Bonjour à tous, Il semblerait qu'un bug existe au sein de la RC1: lorsque je désactive le multi-boutique, je n'ai aucun accès à un bouton "Désactiver la boutique" (comme en 1.4) et lorsque j'active le multi-boutique et que je veux désactiver la (seule et unique) boutique par défaut, elle n'est pas désactivée. Est-ce bien juste ou ce n'est que moi ? Edit: J'ai rien dit concernant le bouton d'activation de boutique (unique) qui est dans l'onglet "Maintenance". Le reste, je maintiens.
  16. Bonjour tout le monde, Afin d'être bien sur, pouvez-vous me dire comment être à jour avec le SVN de la 1.5 ? Je remarque que ma version n'a pas tout ce qui est censé existé (dont le menu "Comptabilité" et "Stocks" ainsi que quelques hooks) mais je ne suis pas sur de comment exploiter le SVN... Merci d'avance !
  17. Oui, tout à fait ! C'est d'ailleurs pour ça que tu peux en supprimer / ajouter. En fait, dans le template correspondant, il y a une boucle sur les titres de civilités. Maintenant, si tu en ajoutes, il est évident qu'il faut éventuellement modifier le thème actif pour que ce soit joli,
  18. Les civilités se trouvent dans la table gender (et gender_lang, pour les traductions). Et, de fait, il n'y en a que trois ! En fait, il n'y a pas de traductions (accessibles via l'onglet traductions) mais une gestion propre des civilités. Elles sont accessibles dans l'onglet Contacts > Titre de civilités.
  19. Hi, where are these hooks ? I don't find them... :-/
  20. Vous pensez qu'une doc pour les hooks (dont les nouveaux que je ne trouve pas) sera possible d'ici peu ?
  21. Bonjour à tous, Développant un module sous la version 1.5 et ayant besoin d'envoyer un email lors de la soumission d'un formulaire, j'utilise la méthode statique Send de la classe Mail (Mail::Send()) J'ai pris soin de passer un paramètre (le 11ème, $templatePath = _PS_MAIL_DIR_) en indiquant le chemin du module. Voici le code, pour faciliter la vue: return Mail::Send( $this->context->language->id, 'account', Mail::l('Welcome!'), array( '{merchant_name}' => $merchant->merchant_name, '{email}' => $merchant->email, '{passwd}' => Tools::getValue('passwd')), $merchant->email, $merchant->merchant_name, null, null, null, null, $this->module->getPathUri().'mails/' ); Cependant, j'ai une erreur: Je peux vous affirmer que le dossier mails ainsi que les dossiers mails/de, mails/en, mails/es, mails/fr, mails/it sont présent et contiennent chacun le fichier account.html et account.txt. A y regarder de plus près au niveau de la méthode elle-même, je peux voir que la variable $moduleName reprend bien le nom du module (ici "blockmerchant") mais voici mon problème... ... en réalité, si je veux que mon module envoie un émail en particulier sans altérer les autres ou en rajouter dans le dossier principal mails, je dois mettre mon fichier dans le répertoire de mon thème , dans le dossier modules/blockmerchant/mails/ Or, voici ce que je pensais: si je développe un module qui désire envoyer un email, n'est-il pas plus intéressant (au niveau développement et facilité d'utilisation/installation) d'avoir un dossier mails au sein même du module et que la classe Mail me "permette le choix" entre un override via le thème ou directement via le module ? Bien entendu, la question se pose de comment réaliser un mail qui correspond au thème actif à travers le module, mais il est tout aussi possible d'avoir une structure du type: - /modules/<module_name>/mails/defaut/ (correspond aux mails envoyés par défaut si aucun thème ne correspond) - /modules/<module_name>/mails/<nom_du_theme_actif>/ (correspond aux mails envoyés car ce thème est actif). Pensez-vous que j'en demande trop ou que ce n'est pas du tout utile ou autre ? Je voudrais votre avis avant de soumettre cette idée (ou du moins, je soumets mon idée et je vois vos avis). Me concernant, je pense override la méthode pour faire ce traitement... EDIT: Et, bizarrement, lorsque je vois les traductions des modèles emails, on me présente bien le dossier /modules/<module_name>/mails/ et je vois repris ceux de mon module... :-/
  22. Bonjour à tous, Avant de soumettre un bug dans la forge, je préfère m'en assurer auprès des utilisateurs ici-même. Voici ce qui m'est arrivé deux fois déjà... Lors de la création d'un nouvel onglet via le back-office et voulant le placé en accueil, voici le message d'erreur que j'obtiens: Le soucis est que le controller AdminTabsController.php a pour code ceci: public function postProcess() { [...] elseif (Tools::isSubmit('submitAddtab') && Tools::getValue('id_tab') == Tools::getValue('id_parent')) { $this->errors[] = Tools::displayError('You can\'t put this tab in itself'); } else { [...] parent::postProcess(); } } Lors de l'édition, le problème ne se pose pas car id_tab a une valeur et elle est positive. En revanche, lors de l'ajout id_tab n'a aucune valeur et est, en gros, nulle. Ce qui pousse à l'erreur. Pour contrer le bug, voici le code que j'ai mis: elseif (Tools::isSubmit('submitAddtab') && Tools::getIsset('id_tab') && Tools::getValue('id_tab') == Tools::getValue('id_parent')) { $this->errors[] = Tools::displayError('You can\'t put this tab in itself'); } Ca vous semble juste, tout ça ?
×
×
  • Create New...

Important Information

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