Jump to content

Col&gram

Members
  • Posts

    341
  • Joined

  • Last visited

Profile Information

  • Activity
    User/Merchant

Col&gram's Achievements

Newbie

Newbie (1/14)

26

Reputation

4

Community Answers

  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
×
×
  • Create New...