Jump to content

Col&gram

Members
  • Posts

    341
  • Joined

  • Last visited

Everything posted by Col&gram

  1. Si ça peut servir à d'autres : La ligne qui mettait le bazar dans le htaccess : AuthGroupFile /dev/null Par contre je ne sais pas expliquer pourquoi ... si quelqu'un sait je veux bien qu'il éclaire ma loupiotte.
  2. Voilà, plus d'erreurs RINDJAEL 😀 ça c'est fait. L'erreur 500 est également solutionnée : j'ai fini par me souvenir qu'il y a un .htaccess couplé à un .htpassword dans mon dossier d'admin pour faire une sorte de double authentification ... le renommer m'a redonné l'accès. Je soupçonne une modification de chemin lors de la bascule sur la nouvelle plateforme. Merci
  3. Merci, je suis en attente du retour de l'hebergeur pour être sûre que mcrypt est bien installé et activé sur leur plateforme Révolution. En principe oui vu qu'ils proposent d'y mettre du Prestashop mais je préfère avoir confirmation. Edit : j'ai uploadé un phpinfo pour aller plus vite dans mes vérifs, mcrypt est bien activé. C'est déjà ça.
  4. Bonjour, La page de connexion au back office de ma boutique me sert une belle erreur 500 depuis que mon hébergeur à migré mon offre sur sa nouvelle plateforme Révolution (enfin plus si nouvelle que ça). Ce changement a été fait à ma demande car avec l'ancienne plateforme je n'avais pas accès à une version de php plus récente que 5.6, laquelle commence à sentir un peu la sapin. php 7.0 = erreur 500 sur la page de connexion à l'admin. Nota : mes tests en local avec php 7.0 ne posent aucun problème. Retour en php 5.6, toujours l'erreur 500. Le front office lui fonctionne parfaitement. J'ai pu créer un client, passer une commande, envoyer un mail via le formulaire de contact. J'ai vidé le cache de Cache/Smarty∕compile, renommé le fichier .htaccess pour voir si c'est lui qui pouvait poser problème, vidé historique et cookies du navigateur, testé avec un autre navigateur ... rien nada, toujours cette erreur 500. Le mode debug ne m'affiche rien sur le back office. Sur le front office il m'affiche ceci : Il y a un sujet sur ces erreurs, probablement qu'elles sont là depuis le passage en 1.6.1.20 https://www.prestashop.com/forums/topic/866670-message-log-serveur-16120-rijndael_iv_/ Ces dernières peuvent-elles être la cause de mon erreur 500 côté back office ? Hébergement mutualisé, je n'aurais accès aux logs du serveur que demain. J'espère avoir une erreur plus explicite. Il y a un ticket ouvert auprès de Nuxit, sans réponse pour le moment. Y a-t-il une chose que je n'ai pas pensé à vérifier ? Merci pour l'aide Ps : édition pour typo 😉
  5. Bonjour, Ça m'est arrivé de façon assez bizarre et aléatoire genre un coup ça le fait, un coup ça le fait pas et uniquement sur des produits pas mis à jour depuis un bout de temps. Pour ma part, quitter le page du produit et y revenir solutionne le souci même si ce n'est pas une "vraie" solution.
  6. Bonjour, Vous pouvez télécharger la police Open Sans sur Fonts Squirel -> https://www.fontsquirrel.com/fonts/open-sans? (choisir le webfont kit) et suivre les instructions du post juste au-dessus du votre.
  7. C'est super sympa de donner le code qui va bien (testé et adopté). Encore une fois merci Eolia
  8. Merci :-) Ça fonctionne. Trop bien même car je ne reçois plus l'alerte comme quoi on m'a laissé un message. Je ne sais pas si l'envoi des 2 mails peuvent être être dissociés (la confirmation au "client" + la notification au marchand) pour ne garder que la notif au marchand sans rentrer dans des modifications complexes. En attendant ça m'ira comme ça, je me connecterais plus souvent au BO pour vérifier les éventuels contacts.
  9. Bonjour, Lorsque qu'on utilise le formulaire de contact pour me contacter, cela envoie un mail de confirmation à la personne qui me contacte. J'aimerai supprimer l'envoi de cette confirmation. J'ai cherché si une option existe dans le back office (comme pour les statuts de commandes où l'on peut choisir d'envoyer ou non le mail) mais je ne trouve rien. Peut-être que je cherche aux mauvais endroits. Quelqu'un sait où se trouve cette option ou comment faire autrement si ce n'est pas possible depuis le BO ? Merci
  10. Merci BeComWeb, tu as posté pendant que je validais ma réponse. Du coup ça confirme : pas moyen de savoir, c'est la surprise. Du coup je pense que je vais attendre la prochaine, ça mévitera de pester si la 1.6.1.18 arrive demain alors que je maj la 1.1.6.17 aujourd'hui (me semble que ça doit bien faire un mois qu'elle est sortie).
  11. Merci pour ta réponse, je m'attendais un peu à ce qu'il n'y ait pas moyen de savoir, même de l'à peu près. Avant de demander ici, j'ai fouiné un peu partout sur le site et même le github sans rien trouver . Ce serait quand même bien pratique pour pouvoir planifer les maj sereinement avec toutes les vérifs qui vont avec.
  12. Bonjour, Y a-t-il un endroit où l'on peut connaître approximativement la date de la prochaine mise à jour ou son état d'avancement ? C'est dans le but de mieux planifier/préparer mes maj : la dernière fois la 1.6.1.17 est arrivée un jour après que je passe ma boutique en 1.6.1.16 et vu que j'ai traîné un peu pour cette dernière je me demande si il ne serait pas plus sage d'attendre la 1.6.18 pour ne pas faire le travail 2 fois. Merci
  13. Bonjour, Perso je fais ça en utilisant une copie de test de ma boutique (sur un serveur local) pour éviter de devoir régénérer les miniatures sur le serveur de prod car selon la quantité d'image et la puissance du serveur, ça peut être long: J'upload l'image à changer sur une fiche produit bidon, en front office je repère le numéro de l'image avec un clic droit information sur l'image et je vais récupérer tous ses formats dans le dossier correspondant. Exemple ma nouvelle image se nomme 3641.jpg je vais dans /img/p/3/6/4/1 (le numéro de l'image décomposé donne le chemin) Je recopie toutes les tailles de mon image dans un dossier de mon pc pour pouvoir modifier tranquille Je vais sur le front office de ma boutique en prod pour trouver le numéro de l'ancienne image qui est à changer, admettons que ce soit 1252.jpg. Sur ma série d'images "nouvelle" je renomme chacune d'elle avec le bon numéro (3641.jpg devient 1252.jpg ; 3641-small_default.jpg devient 1252-small-default.jpg ; etc ...) Je me connecte via ftp sur le serveur de prod Je vais dans le dossier /img/p/1/2/5/2 et j'écrase les images par les nouvelles. Évidemment c'est fastidieux ... faut pas avoir beaucoup d'images à changer. Mais si c'est une de temps en temps ça se fait
  14. Bonsoir, Perso je ferais ceci en utilisant les outils de base (sur la 1.6 - je ne sais pas si c'est toujours valable pour la 1.7) : Faire 4 déclinaisons comme ceci : couleur 1 couleur 2 couleur 3 RAL personnalisé + expliquer dans la description de l'article que si on choisit un RAL personnalisé il faudra inscrire le numéro du RAL dans le formulaire de message au vendeur qui s'affiche lors de la validation de commande (avant l'étape du paiement). Je fais ça pour quelques-uns de mes articles et ça se passe bien. J'avais essayé d'abord de combiner les déclinaisons + le champ de personnalisation mais certains oubliaient de le valider avant de mettre au panier et du coup la personnalisation n'était pas enregistrée. Sinon il existe peut-être des modules qui répondraient au besoin, faut regarder ... ou en (faire) développer un sur mesure.
  15. Bonsoir, Doekia merci pour ces précisions, ça m'aide à confirmer et finir de comprendre ce que je soupçonnais après avoir pousser les recherches sur ce fichier core. Donc en gros ce fichier à bien été généré par une application du serveur, soit côté hébergeur. Je viens de faire une fouille archéologique dans les informations de maintenances de l'hébergeur et il y en a eu plusieurs qui correspondent avec la date du fichier. Voilà donc le mystère expliqué. Merci à vous deux
  16. Bonsoir, Peut-être en utilisant le champs de personnalisation mais il faut que le client connaisse le code RAL, ou à défaut sache où le trouver pour le recopier.
  17. Fichier supprimé et tout fonctionne normalement Clamav n'a rien trouvé de vérolé et la comparaisons des fichiers par rapport à une fresh install n'a pas fait apparaître d'autres fichiers bizarres ou avec ajout de code. Pour moi il n'y a pas d'infection. Il me semblait avoir lu un topic il y a ... un certain temps où quelqu'un avait aussi une alerte d'un fichier core dans l'admin qui était ignoré pendant la sauvegarde par 1click upgrade mais pas moyen de le retrouver. En tout cas si quelqu'un avait ce même fichier et une explication le concernant, j'aimerais bien connaître le fin mot de l'histoire
  18. La réponse de l'hébergeur : Ma demande dépasse le champ d'intervention du support, l'utilisation de l'espace loué sur le serveur et de tout ce qui s'y trouve étant sous la seule responsabilité du client. Et ... c'est effectivement le cas (abo mutu pro). Par contre on me conseille de vérifier que mon site n'est pas piraté depuis 2014, date de dernière modification du dit fichier d'après mon ftp. Ça me surprendrait quand même car je n'ai jamais remarqué de bizarreries (pas d'envoi de spam, pas d'alertes dans le webmaster Google, pas de dysfonctionnements particuliers, pas vu d'autres fichiers qui ne devraient pas être là) mais je vais passer tout ça au clamav au cas où + comparer avec un presta tout neuf et tester de virer le fichier sur une copie de test. Je tiendrais au courant de ce que je trouve ... et j’appellerais à l'aide si besoin.
  19. Ok, merci beaucoup. Je pose la question à l'hébergeur et je repasse dire ce qu'il en est au cas où ça serve à quelqu'un
  20. Ah oui ça change tout si ce fichier ne vient pas de Prestashop. Merci Eolia. Juste pour être complètement sure avant de poser la question à l’hébergeur : ma boutique était à l'origine en 1.5 et upgradée en 1.6 peu après sa sortie (avec tous les aléas qui ont suivi ). Cela ne pourrait pas être une relique de la 1.5 ?
  21. Bonjour, Je m'interroge sur la fonctionnalité du fichier core qui se trouve dans le dossier admin. Le mien pèse 39,2 Mo et les propriétés affichées sur une des sauvegardes sur mon pc sont : - données de plantage de programme (application/x-core) Cela fait pas mal de temps qu'il a ce volume et ne bouge pas ; le 1click upgrade me l'ignore lors des sauvegardes avant mise à jour. Je prends le temps de m'y intéresser seulement maintenant (pas de bugs et je fais toujours une sauvegarde manuelle). Les recherche sur le web n'ont pas donné grand chose ... Si c'est bien un fichier de type "log d'erreurs", peut-on le supprimer ? Si non, quelqu'un peut-il m'expliquer à quoi il sert et si on peut éventuellement l’alléger ? Merci
  22. Re, Avec Firefox-esr (45) ça fonctionne. Ce que je trouve bizarre, c'est que la maj s'était déroulée correctement avec Firefox 52 sur ma version de test en local. Et l'url de téléchargement chez Prestashop était bien fonctionnelle au même moment des échecs décrits dans le post au-dessus.
  23. Bonjour, Pour info sur la 1.6 ça fait plusieurs versions que les mails standards se mettent à jour malgré un réglage sur non. J'ai même tenté de passer à oui, enregistrer puis repasser à non enregistrer mais rien n'y fait
  24. Bonjour, Quelle est votre version de Firefox ? Je viens de faire 2 essais et j'ai aussi cette erreur de téléchargement avec Firefox 52.0.1.
  25. Bonjour, Même souci. Après mise à jour un message comme quoi le module est désactivé car la maj ne s'est pas faite correctement. J'ai d'abord pensé à un problème suite au passage de la boutique en https et puis en venant par là, j'ai vu ce message donc j'ai réinitialisé le module, ensuite il faut reconnecter son compte Payplug et réactiver le mode Live. Ça semble ok.
×
×
  • Create New...

Important Information

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