besky Posted March 21, 2013 Share Posted March 21, 2013 (edited) Bonjour, J'ai migré ma boutique en local sur une version 1.5.3.1 depuis une 1.3.7 par une mise à jour progressive donc en passant de version en version jusqu’à arriver à la 1.5.3.1. Je suis en train de peaufiner tout cela en réadaptant le thème, en installant les modules dont j'ai besoin (à jour bien entendu) et en récupérant quelques erreurs sur mes produits. Hors j'ai rencontré un bug plutôt gênant par deux fois en modifiant mes produits. Le fichier "config/settings.inc.php" est totalement vidé et bien entendu quand je recharge la page ou enregistre mes modifications, la base de données n'est plus accessible. La deuxième fois que cela m'est arrivé c'était en modifiant les déclinaisons de produit. J'ai donc récupéré une sauvegarde de mon fichier "setting.inc.php" (la première fois j'ai été obligé de refaire le processus de mise à jour) et tout rentre dans l'ordre. Le plus étonnant c'est qu'en refaisant les même modifications de mes produits le bug ne se reproduit pas. Je ne comprend donc pas comment ce fichier peut se vider de son contenu inopinément. Quelqu'un a t'il rencontré ce problème ? Avez vous une solution ? Merci ! Edited March 21, 2013 by besky (see edit history) Link to comment Share on other sites More sharing options...
besky Posted March 22, 2013 Author Share Posted March 22, 2013 Je suis le seul à qui cette mésaventure arrive ? Une idée sur les causes possibles ? Peut-être que cela découle de la mise à jour ? Link to comment Share on other sites More sharing options...
Johann Posted May 4, 2013 Share Posted May 4, 2013 Je viens d'avoir ce meme problème aussi, après une migration 1.4.7 -> 1.5.4.1, lors de laquelle j'ai désactivé tous les modules non-natifs, et j'ai ensuité installé un thème de chez ThemeForest Ca marche très bien, mais à un moment donné, hop, settings.inc.php vidé aussi, à deux reprises, sans que je ne comprenne pour l'instant la cause. Je vais essayer de le mettre en lecture seule pour l'instant... Link to comment Share on other sites More sharing options...
Matthieu B Posted May 21, 2013 Share Posted May 21, 2013 Même problème rencontré le lendemain d'une mise à jour en 1.4.9 vers 1.5.4.1 qui s'est pourtant très bien déroulé. Link to comment Share on other sites More sharing options...
Oron Posted May 22, 2013 Share Posted May 22, 2013 Bonjour Est-ce que vous pouvez donner des précisions sur vos hébergeurs ? Si vous avez un hébergeur différent ou le même hébergeur. Détailler aussi à partir de quel moment + de quel action que le setting.inc.php s'est vider et comment vous en êtes aperçu. Avez-vous des messages d'erreur ? Merci Link to comment Share on other sites More sharing options...
besky Posted May 22, 2013 Author Share Posted May 22, 2013 (edited) Bonjour, Je suis personnellement hébergé en local avec Wamp car heureusement la migration de mon site n'est pas encore terminée vu tout le boulot de modifications à faire en passant de 1.3.7 à 1.5.x Ça vient à l'instant de me le refaire (je me suis remis sur la migration aujourd'hui après un mois d’arrêt) c'est d’ailleurs pour cela que je reviens par ici. Je suis tout d'abord allé sur les modules puis j'ai recherché le module "block catégorie" via le champ de recherche jquery, puis j'ai cliqué sur "configurer" de ce fameux module et la, plus d'accès à la BDD et en vérifiant le fichier "setting.inc.php" je me suis rendu compte qu'il avait encore été vidé de son contenu. Pour info j'ai fait une mise à jour de 1.5.4.0 à 1.5.4.1 quelques heures plus tôt. La mise à jour s'est parfaitement déroulée. Je n'ose même pas imaginer que cela puisse arriver en prod, ce serait un peu catastrophique, d'autant plus si tu ne passe pas tous les jours sur le site pour vérifier qu'il fonctionne. J'espère que vous trouverez une solution à ce fâcheux problème car j'ai bien peur de ne pas pouvoir le mettre en prod avant cela... Cordialement, Besky. Edited May 22, 2013 by besky (see edit history) Link to comment Share on other sites More sharing options...
Oron Posted May 22, 2013 Share Posted May 22, 2013 Bon si je comprends bien c'est ce recherche jquery, est-ce qu'il est d'origine développer par prestashop ou un autre développeur ? Est-ce que vous avez une version antérieur de ce jquery ? Est-ce que vous avez vérifiez votre poste totalement avec un antivirus mis à jour de tous vos disques durs ? Avez-vous un logiciel pour détecter les chevaux de troyes ou autre malware ? Vous utilisez quel navigateur ? quel thème utilisez vous ? Link to comment Share on other sites More sharing options...
Broceliande Posted May 22, 2013 Share Posted May 22, 2013 (edited) Salut Besky, Oron a eu la bonne idée de me titiller en cette soirée (trop?) calme et me pointer sur ton topic. Il y a à mon sens 3 possibilités - un script d'upgrade tourne toujours , et en boucle , dans une fenêtre de navigateur. - une fenetre de navigateur est ouverte sur adminPerformances et tourne en boucle - un virus La plus probable est pour moi la première Edited May 22, 2013 by Broceliande (see edit history) Link to comment Share on other sites More sharing options...
Johann Posted May 22, 2013 Share Posted May 22, 2013 Dans mon cas, c'est donc arrivé quelques minutes après la migration 1.4.7 -> 1.5.4.1 sur le site en prod d'un client (boutique en maintenance) sur un kimsufi chez ovh. Comment on s'en aperçoit ? Ben... dans ce fichier il y a les infos de connexion à la BDD, avec un fichier vide, PS se gaufre très rapidement Heureusement, j'avais fait une migration de test sur un clone du site de ce client sur mon serveur dédié perso (pas chez OVH, chez Sivit), j'ai donc pu recopier le contenu de ce fichier au format 1.5.4.1 sur le serveur du client, et corriger le user/pw qui n'étaient évidemment pas les mêmes que sur mon serveur, en les récupérant de la version 1.4.7 (merci SVN). C'est arrivé deux fois en quelques minutes, en manipulant le backoffice. Depuis, j'ai changé les droits linux sur ce fichier, il n'est plus en écriture, et je n'ai plus le pb (un peu bourrin, mais dans la précipitation...) Link to comment Share on other sites More sharing options...
besky Posted May 22, 2013 Author Share Posted May 22, 2013 (edited) Petit problème de manip. Ne tenez pas compte de ce post et passez au suivant. Merci ! Edited May 22, 2013 by besky (see edit history) Link to comment Share on other sites More sharing options...
besky Posted May 22, 2013 Author Share Posted May 22, 2013 Bonsoir Oron, Broceliande et Johann et merci de votre intervention. @Oron : - Je parle de barre de recherche dans la page des modules. - Il est peu probable qu'il s'agisse d'un virus étant donné que je suis loin d'être novice en informatique et que mon Pc est correctement protégé. - J'utilise Firefox dans sa dernière version et je doute que cela puisse avoir une influence quelconque. @Broceliande : - Ce qui m'étonne dans la première solution c'est que la mise à jour était terminée depuis pas loin de 15 minutes voir plus, que j'ai changé plusieurs fois de page avant que le problème ne survienne et que seuls deux onglets étaient ouverts sur PS: L'un sur le BO que j'utilisais et le second sur le front auquel je n'ai pas touché entre temps. - Pour la seconde solution aucune autre fenêtre n'était ouverte. - Pour la troisième la réponse est au début de ce post. @Johann : - En changeant les droits en écriture c'est certain que ça règle le problème temporairement mais à la prochaine mise à jour cela risque de créer des problèmes. Ce n'est donc qu'une solution provisoire. Ce qui m'intrigue c'est qu'il m'est arrivé en ayant le fichier "setting.inc.php" ouvert sur mon éditeur (notepad++) que le logiciel m'informe que "le fichier a été modifié par un autre programme" (Ps je présume) et me demande donc si je veux le recharger. Il y a donc probablement un processus quelconque qui intervient au fonctionnement du BO pour modifier ce fichier et c'est à mon avis la que le problème survient. Reste à définir quoi, quand et pourquoi ? Lors de la mise à jour, le thème mobile est désactivé semble-t-il et il me semble avoir vu une fois une ligne concernant ce fameux thème mobile dans le fichier de config. Ce pourrait-il que le thème mobile en se réactivant puisse essayer de modifier le fichier de config et planter ? Merci de votre aide ! Cordialement, Besky. Link to comment Share on other sites More sharing options...
Oron Posted May 22, 2013 Share Posted May 22, 2013 On 5/22/2013 at 10:00 PM, besky said: Ce qui m'intrigue c'est qu'il m'est arrivé en ayant le fichier "setting.inc.php" ouvert sur mon éditeur (notepad++) que le logiciel m'informe que "le fichier a été modifié par un autre programme" (Ps je présume) et me demande donc si je veux le recharger. Normalement quand on fait une mise à jour ou une manipulation faut pas laisser ouvert un fichier que le programme utilise. Il faut l'ouvrir dans notepad++ puis enregistrer et fermer, après s'il est nécessaire de le rouvrir vaut mieux ouvrir )à nouveau que de recharger. Normalement Windows n'accepte pas que deux programme travail sur un même fichier en écriture. Donc u a surplanté l'autre d'où le setting.inc.php qui s'est vider. Link to comment Share on other sites More sharing options...
besky Posted May 22, 2013 Author Share Posted May 22, 2013 Je te rassure tout de suite, lors de la mise à jours aucun fichier n'était ouvert dans mon éditeur. Cependant a ma connaissance cela ne doit pas poser de problème lorsqu'il s'agit de notepad++ qui ne bloque pas l'édition des fichiers lorsqu'il est ouvert, mais cela aurait tout de même pu être une bonne piste. Je vais essayer de fouiller un peu demain voir si je peux reproduire le même comportement. Link to comment Share on other sites More sharing options...
Broceliande Posted May 23, 2013 Share Posted May 23, 2013 @Besky , la variable concernant le thème mobile est stockée dans la table de configuration , sur la 1.5.4.1 en tout cas. Il faut s'intéresser je pense aux seuls processus qui accèdent au fichier de settings, et ceux-ci sont très peu nombreux : - Script d'installation - Script de mise à jour - Admin des performances en back office (au travers de la méthode rewriteSettingsFile ) Il n'existe pas d'autres cas dans une 1.5.4.1 pour lesquels le fichier est réécrit, on peut facilement le vérifier en effectuant une recherche sur la totalité des scripts. Mon avis reste le même sur la cause la plus probable, puisqu'il ne s'agissait pas là d'une installation mais d'une maj : Comme le script d'upgrade est appelé depuis une boucle javascript , et exécute des commandes en ajax , c'est bien un javascript lancé dans une fenêtre de navigateur qui exécute les scripts php de maj. Supposons que tu aies cliqué plus d'une fois sur le bouton de maj , (a supposer également que ce soit possible , en principe il devrait être désactivé dès le premier click) , alors il est fort possible que la maj se soit lancée plus d'une fois , sans pour autant que tu puisses t'en apercevoir. Il pourrait tout aussi bien être possible que le script js qui contrôle l'upgrade se soit relancé tout seul, dans ce cas ce serait un bug bien sûr. Mais dans un cas comme dans l'autre , la deuxième maj peut facilement être fatale et pourrait expliquer l'échec de la réécriture du settings.inc. Tu dis Besky que le fichier a disparu 15 mn environ après l'upgrade. Est-ce que ça ne correspondrait pas approximativement au temps qu'aurait pris ce premier upgrade ? La seule autre chose que tu peux facilement tester , c'est de modifier un paramètre dans les performances et enregistrer au cas ou ce serait à ce niveau que l'enregistrement échoue. Mais à nouveau , je penche pour une boucle ou une exécution multiple du controller d'upgrade (partie js). Link to comment Share on other sites More sharing options...
besky Posted May 23, 2013 Author Share Posted May 23, 2013 (edited) La mise à jour a été très rapide en local, pas plus d'une minute Broceliande. Je vais essayer de modifier quelque chose dans les performances voir si cela reproduit le problème. Quand au bouton de mise à jour je suis certain de n'avoir cliqué qu'une seule fois dessus. Après comme tu dis ça pourrait être un bug qui relance la MAJ sans raison. Edit: J'ai modifié le paramètre de compilation des fichiers dans la page "performances" aucun problème n'est apparut. Edited May 23, 2013 by besky (see edit history) Link to comment Share on other sites More sharing options...
besky Posted May 27, 2013 Author Share Posted May 27, 2013 (edited) Cela vient de se reproduire. Cette fois-ci c'est en désinstallant des modules et en les supprimant. J'ai voulu supprimer (en cliquant sur "supprimer") un caroussel après l'avoir désinstallé proprement. Et hop : Link to database cannot be established: SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Hôte inconnu. Et le fichier setting.inc.php est vide... Et pourtant je n'ai fais aucune mise à jour de Prestashop récemment, ce qui écarte définitivement le processus de mise à jours du problème. Ceci dit j'ai fais une mise à jour de Paypal qui me le demandais, est-ce le même processus ? Petite chose étonnante: J'avais mise le fichier en lecture seule sur Windows en me disant que peut-être cela règlerait temporairement le problème en empêchant l'édition du fichier. Malgré tout le fichier est revenu à la normale. Pourtant après quelques tests, de moi même il m'est impossible de modifier ou de remplacer un fichier en lecture seule sur Windows. Est-ce que Prestashop pourrait passer outre ? C'est tout de même étrange ce problème. Merci de votre aide ! Cordialement, Besky. Edited May 27, 2013 by besky (see edit history) Link to comment Share on other sites More sharing options...
Oron Posted May 27, 2013 Share Posted May 27, 2013 Bonjour Normalement en désinstallant un module et même en supprimant son dossier il touche pas au setting.inc.php qui est juste un fichier de configuration. Link to comment Share on other sites More sharing options...
besky Posted May 27, 2013 Author Share Posted May 27, 2013 Bonsoir Oron, Je veux bien te croire mais c'est pourtant bien à ce moment précis que le fichier s'est vidé. Je ne comprend pas non plus... Link to comment Share on other sites More sharing options...
Broceliande Posted May 27, 2013 Share Posted May 27, 2013 On 5/27/2013 at 8:04 PM, besky said: Bonsoir Oron, Je veux bien te croire mais c'est pourtant bien à ce moment précis que le fichier s'est vidé. Je ne comprend pas non plus... Besky, On dit que l'explication la plus évidente est toujours la meilleure, mais dans ton cas l'évidence fait place au doute... L'onglet d'administration des modules ne fait aucunement appel à la méthode de reconstructions de settings.inc.php. Rien dans le code même ne lie au fichier. J'ai posté au sujet des maj de modules, car à mon sens il existe un bug latent dans ce processus , mais rien qui puisse détruire ou réinitialiser settings. Je ne peux que me référer à mes posts précédents dans lesquels je liste les processus à même de modifier ce fichier. Alors la seule idée nouvelle qui me vient est qu'un module non natif prestashop ou qu'une modif de ton presta cause ce bug. Au delà c'est juste inexpliquable :s Link to comment Share on other sites More sharing options...
Oron Posted May 27, 2013 Share Posted May 27, 2013 Suggestion : Faites un test avec une installation neuve dans un autre dossier et avec une base de donnée à part. Sans les produits sauf ceux de la présentation par défaut. Par contre vous mettez tous les modules que vous avez installer actuellement. Si ce test fonctionne bien que le setting.inc.php ne se vide pas, faites un export des tables nécessaire client produist employee adresse cleint etc.. et utilisez cette nouvelle installation. Link to comment Share on other sites More sharing options...
besky Posted May 28, 2013 Author Share Posted May 28, 2013 Je n'ai malheureusement pas le temps pour faire ce genre de test qui me prendrait un certain temps, mais pourquoi pas à l'avenir. Dans un premier temps je pense que je vais simplement mettre le fichier en lecture seule. Je modifierais les droits lors des mises à jours. Ce n'est pas la solution idéale mais en attendant d'avoir le temps de mener des investigations plus profondes j'ai bien peur que ce soit la seule solution. De toute manière je réfléchis grandement à migrer vers d'autres CMS. Malheureusement Prestashop, bien que génial du point de vue du concept, fini par prendre beaucoup trop de temps en correction de bugs et en mise à jour. Peut-être y reviendrais-je plus tard... Qui sait ? En tous cas merci de votre aide à tous les deux, si jamais quelqu'un d'autre à une solution ou ne serais-ce qu'un début de piste n'hésitez pas à participer. Cordialement, Besky. Link to comment Share on other sites More sharing options...
shoppingnet Posted February 20, 2014 Share Posted February 20, 2014 Bonjour, J'ai assi le même probleme le fichier setting est vide et biensur un message d'erreur quand je veux ouvrir la boutique " Link to database cannot be established " Je suis sur Ps 1.4.4 Hébergé chez Online. C'est une mauvaise manipulation de ma part. En BO j'ai eut un message comme quoi l'url n'était pas la même et que si ce n'etait pas la même il fallait en changer donc j'ai ajouté : " www." devant et la paff !!!!!!! Les soucis ont débarqués. Si vous avez une idée de la solution, je suis preneur. Merci bien Link to comment Share on other sites More sharing options...
shoppingnet Posted February 20, 2014 Share Posted February 20, 2014 Personne ? Link to comment Share on other sites More sharing options...
Broceliande Posted February 20, 2014 Share Posted February 20, 2014 On 2/20/2014 at 5:53 PM, shoppingnet said: Personne ? J'ose espérer que tu as une sauvegarde de ce settings.inc.php ou que ton site n'est pas en production ? Dans le cas contraire il n'est pas impossible de relancer ton site mais chacun de tes clients devra regénérer un mot de passe car tu auras perdu la clef magique : _COOKIE_KEY_ , qui sert à crypter les mots de passes dans la bdd , entre autres. En français dans le texte , on stocke le mdp client / employé etc dans un cryptage non reversible. Le cryptage n'est pas réversible donc, mais dans tous les cas de figure, le même mot de passe, qu'on ajoute derrière cette fameuse clef, passé à la fonction MD5 (c'est elle qui crypte à sens unique) donnera toujours le même résultat. SI tu as perdu définitivement cette clef, jamais plus un de tes clients ne pourra s'identifier sans regénérer un mot de passe avec la nouvelle clef. Bien évidemment si tu as changé l'url du bo durant le processus de mise à jour et ce sur la même page ou s'exécutait l'upgrade, tu as rechargé cette dernière et interrompu la mise à jour. Mais tu auras également créé un second cookie avec les www devant, ce qui peut facilement faire perdre les pédales à toute action en cours utilsant les cookies... Une des première choses que fait l'upgrade est de modifier le settings.inc. Pour des tests etc j'ai parfois eu à interrompre et relancer ce processus, la version de prestashop était déja inscrite dans settings. Jamais en revanche je ne l'ai trouvé vide. Tourne toi dans un premier temps vers ton hébergeur pour savoir s'il n'existe pas de sauvegarde automatique de ton site. Ce serait salvateur de revenir en arrière , quitte à risquer de perdre les quelques dernières commandes , que tu pourras toujours récupérer si avant de restaurer , tu fais et conserver une sauvegarde de la base actuelle. Link to comment Share on other sites More sharing options...
shoppingnet Posted February 20, 2014 Share Posted February 20, 2014 Bonsoir et merci de ta réponse, Pour commencer, mon site était encore en test, donc déjà moindre mal. Au sujet des save, j'ai effectué une sauvegarde depuis la BO. Le fichier se trouve dans backup, se sera suffissant pour une restauration. J'ai aussi une save de ma base de donnée au besoin. J'aimerai remettre tout en ordre car ma boutique était déjà pas mal configurée. Merci Link to comment Share on other sites More sharing options...
Broceliande Posted February 20, 2014 Share Posted February 20, 2014 Il faudrait surtout savoir si presta a commencé la conversion de ton site côté BDD Mais pour que ton settings soit vide je pense que non . Donc remettre simplement un backup de settings.inc.php devrait suffire reprendre la main sur le BO. Ensuite puisque ton arbo a probablement été écrasée par la nouvelle version , tu peux retenter une upgrade pour que la bdd soit en corrélation avec la version de presta présente dans l'arborescence. Mais attention : Comme l'auto-upgrade fonctionne en ajax je me pose une question : Si tu édites ton ficher /config/defines.inc.php , n'aurais tu pas par hasard activé dedans le mode debug ? SI tu as define('_PS_MODE_DEV_', true); au lieu de define('_PS_MODE_DEV_', false);, alors c'est le cas et il est plus que logique que l'ajax plante au premier notice php. Je ne sais pas si l'auto-upgrade ne réalise pas ce test toutefois avant de se lancer. Une dernière chose que tu peux tenter est de lancer une upgrade "manuelle" si tant est que cette mise à jour n'est pas une maj majeure (genre si tu passes d'une 1.5.6.x à une 1.5.6.2 c'est sans danger) , pour cela tu ajoutes ceci derriere l'url de base de ton site : /install/upgrade/upgrade.php Là pour le coup le debug peut être activé et c'est même préférable, car de mémoire j'ai rencontré un bug dans le script de la 1.5.6.2 qui cherche à include des noms de classe avec casse alors que ces mêmes classes ont été toutes renommées en lower case, enfin un truc dans le genre ... Link to comment Share on other sites More sharing options...
shoppingnet Posted February 20, 2014 Share Posted February 20, 2014 Pour info, j'avais aucune mise à jour en cours. J'ai simplement fait une mauvaise manip dans le BO. J'ai renommer URL de mon site en mettant www devant . Link to comment Share on other sites More sharing options...
shoppingnet Posted February 20, 2014 Share Posted February 20, 2014 Si tu pouvais aussi me donner la marche à suivre pour lancer une restauration via ce fichier en backup. Merci Link to comment Share on other sites More sharing options...
.png.022b5452a8f28f552bc9430097a16da2.png)
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now