Jump to content

Broceliande

Members
  • Posts

    1,735
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Broceliande

  1. Voici un retour qui vaut son pesant d'or ! Je gage que tous les utilisateurs de la 1.5.1 utilisant des déclinaisons vont te bénir. A ce que j'en ai vu le post sur la forge est fermé et le bug corrigé sur le svn , mais pour le coup il faudra attendre la 1.5.2 pour en bénéficier a moins de suivre tes consignes.
  2. L'adresse de livraison fait partie intégrante du processus de commande de prestashop. Pour ne pas l'afficher et ne pas avoir à réinventer la roue, il suffit peut être de mettre dans le css un display:none sur le bloc correspondant. Certes cela ne modifiera en rien l'affichage de cette adresse sur la facture ... mais c'est un autre pb ...
  3. La réponse de Matt75 est la bonne, Selon le thème choisi vous pouvez avoir par exemple la colonne de gauche occultée , ou bien la colonne de droite... Les modules s'installent par défaut sur une de ces colonnes. Un thème qui n'appelle pas ces modules puisque la colonne par défaut n'est pas affichée implique que l'on tente de greffer à la m ain les modules sur la colonne visible. Cela nécessite que le module soit greffable (hookable) sur cette colonne , ce qui est le cas des modules natifs , mais pas forcément de tous les modules. Ceux qui ne le sont pas devront être modifiés pour accepter le hook voulu. Je m'étendrais pas beaucoup plus sur le sujet parce que ça me prendrait une bonne heure au moins pour donner des exemples et des cas de figure. Mais en substance tout dépend du thème et conquerante81 tu ne nous donne pas de lien ni d'infos qui nous permette de te répondre plus en détail.
  4. Bonjour, Bien évidemment les noms de fichiers sont cryptés, c'est ce qui rend ce module sécure... Pour récupérer les fichiers liés à une commande et consulter les messages joints à ces fichiers il suffit d'éditer la commande en back office. Les fichiers joints y sont listés et il suffit de cliquer sur le lien fourni pour télécharger le fichier (avec le bon nom). Si cela ne fonctionne pas, il est possible que les headers aient été corrompus par l'affichage des erreurs (voir si display_errors est bien à off dans config.inc.php) Possible également que ton hébergement n'autorise pas suffisamment de mémoire aux scripts php pour que le fichier soit envoyé par cette methode (il est chargé en mémoire) , c'est dans la liste des prérequis si je ne me trompe pas. Pour info il est certes précisé dans la fiche que je n'assure plus de support , le module étant gratuit , mais je ne suis pas non plus borné et je veux bien jeter un oeil à ta configuration si tu le souhaites.
  5. Well this strongly depends on the context you need to use this function. $id_image is the id of the image you wanna display... while link_rewrite is the corresponding field in (ps_)image_lang table. If you use it in a tpl file, you'll get theses vars in assigned lists like $products ... eg : in product-list.tpl , $product in the foreach loop contains them , then you'll get the link using: {$link->getImageLink($product.link_rewrite, $product.id_image, 'home')} In some cases , $product is not an array but an object so you'll have to use -> rather than . {$link->getImageLink($product->link_rewrite, $product->id_image, 'home')} Depending on the controller wich assigns smarty vars , these all var names can differ. You'd better put a {debug} tag in the tpl to get a full dump of available data. If you plan to assign the vars yourself in a self written php file (module or controller) , then you'll have to get those vars by yourself. However you should know that the most of native classes contain static methods (or obj ones) wich return full arrays of arrays or objects with any data you need. Just var_dump them to get the full structure. there are too many cases or samples to give ... :s Let's say you are using an instance of a Product object : $product = new Product($idproduct); You'll be able to get images data using : $images=$product->getImages($id_lang); wich will return an array of any images linked to the product, containing all needed data. Now if you only need the default image , you can use $result= Product::getCover($idproduct); But as this only returns an id of the cover image, you'll need to instanciate the image object to get other fields: $cover = new Image($result['id_image'], $idlang); notice that if you don't specify $idlang , then link_rewrite will be an array containing the rewrite for any language. Then you must use it this way : $rewrite=$cover->link_rewrite[$idlang] , to get the right field. As you see there are really too different way to proceed and too many cases depending on what you really want to do. So i heavily recommend you to have a look on existing classes (mainly Product , Image) , and existing controllers or modules wich use product data + images. Hope this helps a bit.
  6. What do do exactly mean by doing it "completely" ?
  7. Non mais aussi bien c'est toi qui a raison et moi qui ai lu de travers, faut avouer que c'est pas du tout clair... Mais le prends pas mal , je faisais justement de l'ironie
  8. En même temps à la décharge d'Hedrad, ta question manque de clarté. En gros pour une boutique en ligne gratuite , il suffit d'installer prestashop , qui lui est 100% free. Il faut néanmoins un minimum vital : - un hébergement + nom de domaine comprenant les prérequis à l'installation de prestashop (à partir de 60€ par an je dirais) - un compte paypal ou un contrat tpe avec ta banque pour le paiement par CB. Comme le souligne Hedrad , ces outils ont un cout et effectivement prélève un %age allant de 1.8% en moyenne pour les contrats tpe , à + ou - 4% pour paypal ... Si effectivement c'est à celà que tu veux échapper , alors je pense que tu peux renoncer au e-commerce... Dans le cas contraire, si tu ne souhaite rien payer de plus , la combinaison paypal + prestashop + hebergement suffit à commencer à vendre. De manière générale , les modules liés aux tpe bancaires sont payant (mais c'est du one shot) , les thèmes de qualité le sont aussi... Enfin si tu ne te débrouille pas seul , les prestataires ne sont pas gratuits non plus , même si tu peux trouver pas mal d'aide ici ou sur irc (epicknet #prestashop) J'espère que ça répondra un peu plus à ta question , mais ça serait bien que tu la précises ...
  9. Houla, houla ...! C'est un conseil ou de l'ironie ça ? Clairement les paiements par chèque et virement sur un e-commerce usuel ne représentent pas 1% des commandes.... Je crois que notre ami ne faisait pas référence aux frais annexes mais à des sites qui proposent des solutions gratuites clef en main avec hébergement etc mais prélèvent 10 à 15% du CA ... (eg: prestabox) C'est pas une réponse ça Hedrad, faut se réveiller !
  10. Evidemment je plussoie autant que faire se peu !!! J'expliquais plus haut que justement , cette suppression n'allait supprimer les enregistrements que dans une seule table , et les effets de bord .... incorrigibles je vous dis !!!
  11. la par contre pour une autre application bien sur mais tu dois avoir ça dans le contexte : $this->context->shop->id un truc comme ça ...
  12. bon je vais développer un tout petit peu plus quand même : Les tests que tu veux occulter permettent d'une part de vérifier si l'adresse mail existe avant d'essayer de la créer. L'adresse mail est une clé unique dans la table ps_customers ... De plus , sur la 1.5 , les formulaire chargé est chargé en ajax et l'adresse mail est bien sûr attendue dans ces données , donc tu ne peux te satisfaire de cette override , et tu devra aller plus loin , ne serait-ce que modifier le javascript qui récupère et affiche ces données, ou au pire les données elles mêmes . Supposons que tu y parviennes : alors le client devra finalement entrer son adresse mail dans le formulaire complet , qui retournera les mêmes erreurs lui, s'il entre une mauvaise adresse ou une adresse existante , sauf que cette fois le client aura rempli un formulaire complet pour arriver au même résultat. Le jeu en vaut-il la chandelle ?
  13. En fait tu ne valides rien du tout puisque tu fais un return , d'une part , qui n'est pas nécessaire, et que d'autre part tu assignes une chaine vide à la donnée POST 'email' : return $_POST['email'] = $email; A ce stade $email est vide puisque tu as supprimé purement et simplement ce qui renseignait $email .
  14. salut, là ce que tu donnes c'est le contenu du tpl , or les fancybox se gère depuis le javascript (cf product.js) C'est du jquery. L'idée est de sélectionner les élements du dom que tu veux "fancyboxer" , un exemple de code : $('#idmonbloc").fancybox(); ou idmonbloc est l'id de ton div ou de ton img Faut regarder les sélecteurs jquery, si tu veux fancyboxer toutes les images de classe toto ça va être : $('.toto').fancybox(); évidemment il y a des paramètres à transmettre dans les parenthèses si tu veux personnaliser la box ... de plus il faut que la page soit chargée avant d'appeler ce code , donc on met ça dans l'évenement domready : $(document).ready(function() { $('.toto').fancybox(); }); bref c'est du javascript , particulièrement du jquery ... c'est simple mais ça demande pas mal de notions, je sais pas si ça t'aide.
  15. En principe ton site aurait du reprendre , bien sûr il faut mettre à jour le mot de passe bdd que tu viens de changer dans cette ligne là : define('_DB_PASSWD_', '[info sensible supprimé - Modéré par Patric]'); Mais à moins que tu n'aies bricolé dans tous les sens , je pense que ça devrait coller , sauf si le pb vient vraiment d'ovh ... D'autant que ton settings semblait parfaitement correct pour un passage sur mutualisé.
  16. D'après ce que me dit un collègue , kaylabs pour ne pas le citer ... un bug cet après midi a fait sauté les liens sql à partir des mutualisés . En revanche , cher ami , tu es bon pour renouveler ton mot de passe sql , car afficher ton settings.inc.php nous donne purement et simplement le moyen de faire ce qu'on veut sur ta boutique. Imagine que nous ne sommes pas tous si bien attentionnés ... Je plaisante pas il y a urgence !
  17. Dans smarty.config.inc.php , ligne 42 : $smarty->debugging = false; essaye $smarty->debugging = true;
  18. Si tu n'as pas d'erreur en activant l'affichage des erreurs, alors c'est qu'elle est dans un tpl , faut aussi l'activer pour smarty , c'est je crois dans smarty.inc.php
  19. C'est un sujet récurrent et j'ai déja dis ça , mais je veux préciser que hormis purger le site des commandes test avant mise en production , celà n'a aucun sens de supprimer une commande du BO. Cette fameuse manip est connue mais ne purge pas tout ce qui se rattache à la commande lors de la suppression : en réalité elle ne supprime que la ligne dans ps_orders. On s'expose donc à des effets de bord inattendus...et je ne parle pas en l'air. Une commande peut être annulée , mais ne doit jamais être supprimée dans un site en production. J'ajoute qu'en cas de contrôle... l'absence de certains numéros dans l'incrémentation fera tiquer de suite et on vous demandera des explications... dans le meilleur des cas... Je dis ça , je dis rien. Libre à vous.
  20. Salut, Tu n'as pas précisé ta version de prestashop ... je présume 1.5 mais 1.5. combien ? L'erreur et ta capture ne suffisent pas pour t'orienter. Si tu veux que l'on se fasse une idée, il va falloir editer le fichier config.inc.php , éditer la ligne : @ini_set('display_errors', 'off'); pour la passer en : @ini_set('display_errors', 'on'); A la place de l'erreur 500 tu auras un joli message d'erreur qui nous aidera peut être, à t'aider
  21. Pour info une nouvelle version du module corrige le phénomène bloquant : en cas d'indisponibilité du serveur le module ne s'affichera tout simplement pas, et votre page de paiement sera convenablement chargée avec les modes de paiement restant. Pour le coup je salue la réactivité des développeurs : la solution au problème d'hier était dans les bacs ce matin... Pour mettre à jour votre module, suivez bien les instructions de maj , en gros : - Ajoutez la nouvelle version depuis votre BO ou via ftp - Désinstallez le module - Réinstallez le - Rendez vous dans la configuration , vous devriez y retrouver vos paramètres pré-entrés : ré-enregistrez les !
  22. Clairement, non : la page plante complètement et donc les autres modes de paiement ne chargent pas. L'erreur est bloquante....
  23. Je vais essayer d'être le plus concis possible afin de ne pas m'attirer les foudres de fianet... Les faits : Kwixo subit ces derniers temps des problèmes avec la solution de paiement à crédit via leur interface. D'après un technicien kwixo contacté ce matin par une de mes clientes le problème ne viendrait pas d'eux mais de sofinco. Ceci étant dit, nous venons de constater que le module kwixo (nous utilisons la dernière version connue v4.4.14) est suceptible dans certains cas de planter purement et simplement la page de paiement a cause d'un appel distant qui échoue si j'en crois le message. Nous avons du désactiver le module pour que les clients puissent à nouveau commander sur le site via les autres modes de paiement. En d'autres termes, si quelque chose foire dans le système de cette solution , alors le module plante votre page paiement et personne ne peut plus commander. Je remonte l'info afin que les utilisateurs soient avertis et puissent agir si ils découvrent qu'étrangement plus de commandes n'arrivent dans leur back office. Pour le coup dans le cas présent, le module semble attendre une réponse de tel ou tel serveur mais parait pas gèrer et intercepter les exceptions ou timeouts, ce qui plante prestashop tout court.
×
×
  • Create New...

Important Information

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