Bug dans le BO pour la modification et l’enregistrement des fiches produits et autres textes, icones qui tournent en permanence (icone du pingouin Prestashop et boutons enregistrer)

[@Jo]

Bonjour,

J’ai des problèmes sur mon site/ 1.6.1.5, constatés depuis le 9 mars 2018 alors que je n’ai pas fait de modifications. Je n’ai pas procédé à un upgrade prestashop et ce n’est pas un problème de navigateurs. Je n’ai pas fait de modification de fichiers depuis très longtemps. Tout tournait bien, mis à part des lenteurs par moment.
Je n’avais quasiment que des modules Prestashop (sauf un ecaptcha) et je viens de ne laisser activés que les presta.

Je précise que j’ai fait de nombreuses recherches et procédé à de nombreux essais de corrections, qui ont marché pour d’autres, sans effet. (A chaque fois, je remets ensuite en l’état initial).

Certaines fonctionnalités ne s’affichent plus en BO et quand je suis sur une fiche produit l’enregistrement ne fonctionne plus, les boutons tournent en permanence. Au début je pouvais afficher les pages annexes en cliquant sur les onglets (prix, SEO, Associations, etc.) où l’enregistrement ne fonctionnait pas non plus, puis ensuite il n’y avait plus possibilité de les afficher. Je reviens toujours sur la page « informations » de la fiche produit.

En premier j’avais constaté que c’était l'affichage des messages prédéfinis du SAV, dans le suivi de chaque commande qui ne fonctionnait pas. Les titres des messages s’affichent bien dans la liste déroulante pour envoyer un message au client, mais pas le contenu. Celui-ci est bien présent et je peux aller le copier pour le coller dans le message (son expédition fonctionne).

Mais encore, l’icône du pingouin (en haut à gauche du BO) tourne aussi en permanence. Le système pédale dans le yaourt…

J’ai aussi constaté en Front que le formulaire de contact ne fonctionne plus. Après avoir entré le texte et cliqué sur envoyé, rien ne se passe.

Voici les solutions que j'ai tentées (à chaque fois je vide bien sur le cache avant de voir si cela marche, et ensuite je remets en l’état initial) :

-        .  J’avais installé le fameux patch avec les 9 fichiers à remplacer (2 tentatives), mais rien ne se passait,

-        .   J’ai vidé manuellement le cache smarty,

-        .   J’ai ensuite installé les mêmes 9 fichiers extraits de la version 1.6.1.9., même non-résultat,

-          . J’ai appliqué (pour voir) la modification (qui a marché pour certains) du fichier /js/admin/products.js, en ajoutant (ligne 202) : var mod_evasive = false;  et toujours pas d’effet,

-   .        Ensuite j’ai remis le répertoire initial de ma sauvegarde (aout 2016) : js/tiny_mce pour être sure qu’il n’ait pas été impacté par quoi que ce soit.

Donc je n’arrive pas à cerner le bug, et en même temps je pense qu’il est probable qu’il n’y ait pas grand-chose à modifier pour que tout revienne dans l’ordre. Mon hébergeur LWS m’affirme que le problème ne vient pas d’eux (ils ont procédé à des vérifications), bien que je pensais à un problème de serveur, d’autant que ce problème à l’air de tomber du ciel.

Quelqu’un aurait-il une piste ?

[P i l o u]

Salut,

 

je crois que le problème était connu et avait été corrigé dans une version plus récente que la tienne.

[@Jo]

Merci pour ta réponse Pilou.
Il y a un certain nombre de posts un peu partout sur les fiches produits qui moulinent, mais pas avec tous les autres problèmes apparemment. Et dans leur cas, le problème a été résolu en appliquant le patch (les 9 fichiers à modifier) ou une des autres solutions que j'ai essayées.

Je pense que les développeurs de Prestashop doivent avoir une idée d'où il faut intervenir.
Si je pouvais avoir ne serait-ce qu'un bout de piste parmi les solutions possibles que je n'ai pas encore essayées...
 

[doekia]

Il faut attendre de mémoire la 1.6.1.13 pour que prestashop n'utilise plus l'ajax synchrone (interdit par chrome depuis plus d'un an)

Après vu le nombre de glitch que tu cites un peu partout, j'ai plus l'impression qu'en mettant ton eicaptcha, tu ais vidé tes caches qui n'avaient pas été mis a jour depuis longtemps et font apparaitre des erreur qui étaient latentes depuis des lustres.

 

Sans même une url front nous allons avoir du mal a te conseiller. Coté BO je te conseille ce patch qui peut-etre fera apparaitre un problème coté BO: https://aide.prestashop.click/topic/1034/1-6-bo-ajax-error-dans-la-page-produit-pas-d-autre-explication-de-l-erreur

 

[@Jo]

Merci pour ta réponse Doekia.
Je ne pense pas que ce soit un problème de navigateur car j'ai testé avec plusieurs.

Ceci dit j'essaie le patch que tu m'as indiqué. Par contre je n'ai pas tout compris.
J'ai bien modifié et publié les fichiers :
js/admin/products.js
js/jquery/plugins/alerts/jquery.alerts.css

Mais comment les problèmes sont censé apparaître ensuite ?

 

[@Jo]

suite...
J'ai fait un clic droit "examiner l'élément" sur l’icône prestashop (le pingouin) et voici le code qui mentionne des erreurs :
#ajax_running i {
    font-size: 20px;
    color: rgba(255,255,255,0.6);
    line-height: 35px;
}
[class^="icon-"] {
    font-size: 14px;
}
.bootstrap * {
    -webkit-box-sizing: border-box;
    -moz-box-sizing: border-box;
    box-sizing: border-box;
}
.icon-spin, #content .process-icon-loading, .bootstrap #dashboard .loading .data_value::before, .bootstrap

#employee-thumbnail::before {
    -webkit-animation: fa-spin 2s infinite linear;
    animation: fa-spin 2s infinite linear;
}
.icon-fw, [class^="icon-Admin"], [class^="process-icon-"] {
    width: 1.28571em;
    text-align: center;
}
.icon, .page-sidebar-closed:not(.nav-topbar):not(.mobile-nav) .searchtab::before, [class^="icon-"],

[class^="process-icon-"], .bootstrap .alert.alert-warning::before, .bootstrap .alert.alert-danger::before,

.bootstrap #carrier_wizard .wizard_error::before, .bootstrap .alert.alert-success::before, .bootstrap

.alert.alert-info::before, .bootstrap .alert.alert-addons::before, .bootstrap .alert.alert-onboarding::before,

.bootstrap .alert.alert-message::before, .bootstrap .table td.dragHandle .dragGroup::before, .bootstrap

#dashboard .loading .data_value::before, .bootstrap #employee-thumbnail::before, .mce-ico, .chosen-container-

single .chosen-single div b, .chosen-container-single .chosen-search::before {
    display: inline-block;
    font: normal normal normal 14px/1 FontAwesome;
        font-size: 14px;
        line-height: 1;
    font-size: inherit;
    text-rendering: auto;
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
    transform: translate(0, 0);
}
#ajax_running {
    text-align: center;
}
body {
    font: 400 12px/1.42857 "Open Sans",Helvetica,Arial,sans-serif;
    color: #555;
}
html {
    font-family: sans-serif;
    -webkit-text-size-adjust: 100%;
}
0% {
    -webkit-transform: rotate(0deg);
    transform: rotate(0deg);
}
100% {
    -webkit-transform: rotate(359deg);
    transform: rotate(359deg);
}
0% {
    -webkit-transform: rotate(0deg);
    transform: rotate(0deg);
}
100% {
    -webkit-transform: rotate(359deg);
    transform: rotate(359deg);
}


Après il faut savoir interpréter et quoi faire ...

[doekia]

Le patch permet de transformer une erreur en message d'erreur - avant ça plantait c'est tout.

Si aucun message alors le problème n'est pas lié à un crash du coeur .

Pour ce qui ai de "tous les navigateurs", j'ai signalé que chrome avait bloqué le synchrone il y a une an, et tous les navigateur lui ont emboité le pas depuis lors

Ton clique droit nous affiche la css de l'élément, ce n'est pas une erreur ça

[@Jo]

Ok Doekia, je ne voyais pas bien où trouver le message d'erreur....

Donc me revoilà au point de départ.
Quelqu'un d'autre à une idée ?

[Johann]

J'ai eu ça récemment sur un site en PS 1.6.1.17 qui avait un module qui ajoutait un onglet dans la fiche produit dans le backoffice. Et ça faisait en effet le même effet que le bug ajax asynchrone d'avant PS 1.6.1.10. Il n'y a que sur certains onglets que le bouton "enregistrer" ne merdait pas. Par exemple, pour changer un prix, il fallait le changer dans l'onglet "prix" puis retourner sur "informations" pour sauvegarder, car "enregistrer" dans l'onglet "prix" tournait... Ca peut être une piste...

[@Jo]

Bonjour Johann et merci pur cette information.
Pour ma part, je n'ai plus que la page "informations" qui s'affiche, plus aucun onglet ne fonctionne.
Quel était le module qui a provoqué ce bug, sa fonctionnalité ? Je vais creuser un peu par là.

 

[Johann]

Je ne me rappelle plus du module

Tu peux aussi essayer en désactivant les overrides et/ou les modules non natifs, histoire de voir si ça déconne toujours autant, le but étant de trouver le module incriminé si ça vient bien d'un module

[@Jo]

Je ne suis pas sure d'avoir installé des modules non-natifs à part l'ecaptcha que j'ai désactivé depuis (qui fonctionnait bien et qui n'avait pas provoqué de dysfonctionnements  quand je l'ai instaallé).

Les modules Paypal et MondialRelay sont considérés comme natifs ou pas ? Jusque là ils ne posaient pas de problème, juste Paypal au début ou lors d'une mise à jour où j'avais du faire une modification quelque part (je ne sais plus où), mais il y a longtemps.

[@Jo]

Je crois qu'il y a un autre axe de recherche au niveau de la position des modules.
Est-ce qu'il a des modules qui doivent être impérativement greffés ici ou là, à commencer dans le header ?

[@Jo]

Je suis toujours dans les recherches et les vérifications de fichiers. Vu que le patch des 9 fichiers n'avaient pas fonctionné et que j'avais remis mes fichiers d'origine en ligne, là je vois quelque chose de curieux dans le fichier :

.../themes/default/template/controllers/products/helpers/tree/tree_associated_categories.tpl
 

Pour rappel mon site est en 1.6.1.5. Les dernières lignes de code sont :
</script>
{/if}
Il est vrai que cela correspond à l'ordre du début du script, mais cela ne me semble pas cohérent. Quelqu'un sait-il ?

[doekia]

??

Quand tu observes un patch, il faut remplacer les sections en rouge de gauche par les sections en vert de droite.

 

[@Jo]

Merci Doekia.
Dans l'intervalle voici ce que je viens de faire :
J'ai fait la comparaison entre le patch de 9 fichiers que j'avais appliqué en le trouvant sur un blog (qui avait marché pour certains) et celui qui se trouve dans github. J'ai vu que finalement il y avait des différences.
J'ai donc recommencé et cette foi en copiant et collant l'intégralité du code de chaque fichier pour remplacer les miens, pas seulement la modification, pour être sure de ne rien louper. J'ai tout publié... et pas de changement.
Je fatigue là ...
 

[@Jo]

Je viens de faire un contrôle à partir de mon mobile et j'ai le message dune erreur 500 qui s'affiche à nouveau sur le chargement des onglets. Mon hébergeur m'a assurée à plusieurs reprises que cela ne venait pas de l'hébergement (mutualisé).

Voici le dernier log erreur pour le cas où cela parle à quelqu'un :

[Thu Mar 22 15:41:26 2018] [error] [client XXXXXX] FastCGI: server "/var/www/minsite/cgi-bin/php5.6.external" stderr:   thrown in /htdocs/tools/smarty/sysplugins/smarty_internal_write_file.php on line 46, referer: http://monsite/adminXXXXX/index.php?controller=AdminProducts&id_product=101&updateproduct&token=befc46d71c037aef92b2422d50e702ca

Je continue de ramer...
                     

[doekia]

à priori cette fois, ton serveur ne peux pas créer les cache liés au mobile, c'est donc bien un problème d'hébergement, mais bon... gérer le BO depuis un mobile, autant construire le Taj Mahal avec un pince à sucre

[@Jo]

Doekia,
Je ne pense pas que ce soit lié uniquement au mobile, j'ai déjà vu passer ce type de log d'erreur à partir de mon ordi.
J'en ai d'autres aussi, par exemple celui-là :
[Sun Mar 18 18:08:18 2018] [error] [client 180.153.236.51] FastCGI: server "/var/www/monsite/cgi-bin/php5.6.external" stderr: PHP message: PHP Fatal error:  Uncaught  --> Smarty: unable to write file /htdocs/cache/smarty/cache/blockpermanentlinks_header/1/1/5/dd/8f/27/wrt5aae9d02517404_91113120 <-- , referer: http://monsite/vestes-14?p=2

[@Jo]

Pour ce qui est du problème pour le formulaire de contact en Front, il est solutionné, après avoir désactivé les surcharges. Il était évident qu'il s'agissait d'un problème différent à ceux du BO qui demeurent.
Je cherche encore.

 

[doekia]

Le message est clair. Impossible d'écrire d'une version compilé ou cache d'un template.

Ceci survient lorsque l'hébergement est mou et supprime tellement lentement les fichiers qu'il est encore en suppression quand on cherche à l'écrire, lorsque les permissions sont invalide, ou encore lorsque l'hébergeur limite le nombre de fichier et que cette limite est atteinte.

 

[@Jo]

Merci Doekia,

Cela correspond à peu près à ce que j'avais compris et à ce que j'ai rabâché au contact du ticket ouvert chez mon hébergeur qui me soutient le contraire, à savoir que l'erreur (503) : "est retournée suite à une erreur php exécutée sur votre site" .
Moi je ne vois pas bien comment elle pourrait apparaître du jour au lendemain.
Je viens de lui faire un copier-coller de ton analyse. A voir s'il va en sortir quelque chose.

[doekia]

une erreur 503 est retourné pour cause de boutique en maintenance

lorsqu'un php crash c'est une erreur 500 ou pas d'erreur http du tout

 

Mais là nous partons probablement sur un autre problème. Si tu as Preston qui se titille l’uropygienne, cela vient probablement d'autre chose

[@Jo]

Mon hébergeur me demande de lui indiquer comment réaliser sur mon site un test de suppression et de réécriture de cache afin de pouvoir analyser en direct sur le serveur ce qu'il se passe lors de cette action.
J'ai un doute sur quoi lui indiquer, si quelqu'un peut m'éclairer ?

[@Jo]

EURÊKA j'ai résolu le problème et les fonctionnalités sont revenues.

J'ai trouvé 3 fichiers manquants qui étaient listés dans "paramètres avancés" "liste des fichiers manquants". Par contre il me semblait avoir déjà vérifié et je ne me souviens pas qu'ils manquaient. Il est vrai que la dernière fois que j'ai voulu contrôler, Presta n'arrivait pas à afficher cette liste, là aussi il moulinait.
Les 3 fichiers sont :

AdminXXX/drawer.php
Config/xml/.htaccess
js/admnin.js

Je ne sais pas comment ils ont pu disparaître et si quelqu'un a la réponse, je veux bien en profiter, car j'aime bien comprendre. Je suis sure à 100% de ne pas les avoir touchés.
J'avais laissé aussi la dernière modification que j'ai faite des 9 fichiers comme préconisé dans github.
Merci encore à ceux qui ont répondu.
 

[doekia]

Sauf qu'ils auraient été infecté et donc supprimé par l'hébergeur, il ne reste que la thèse du bug chaise-clavier

[@Jo]

Le "bug chaise-clavier" c'est un peu facile ;-)
Supprimer accidentellement un fichier, admettons, mais 3 en 3 emplacements aussi différents, non !
Je pense qu'il s'agit très probablement d'effets en chaîne liés à un fonctionnement de Prestashop (dysfonctionnement ?) et à ses nombreuses instabilités.

J'ai déjà solutionné des bugs vraiment surprenants, dont certains qui y était en natif et que j'avais du combattre au moment du développement.
Ce n'est pas en les dissimulant que l'on fait avancer le sujet.
 

[doekia]

Je n'ai jamais vu de Prestashop supprimer de fichier dans ces endroits là. Jamais en 10 ans. Mais des glisser/déposer raté dans l'utilisation de filezilla c'est plusieurs fois par mois. Mais puisque cela t'offusques d'imaginer que tu puisse être faillible alors inventes toi un explication qui te satisfasse.

Je constate que tu es infaillible au point d'écrire js/admnin.js au lieu de js/admin.js et Config/xml/.htaccess au lieu de config/xml/.htaccess

Le problème des ordinateurs c'est d'être extrêmement pointilleux sur des "détails".

D'ailleurs, le .htacces n'avait aucun impact sur ton problème

[@Jo]

Quelle susceptibilité !
Tu viens de relever 2 fautes de frappes que j'ai faites, mais je ne vais pas relever les tiennes dans tes messages ...

Bien sur que non je ne pense pas infaillible. Et si les glissés de fichiers arrivent, et ça m'est arrivé aussi, là je sais que ce n'est pas le cas, je n'étais pas allée dans ces répertoires, avant que ces fonctionnalités disparaissent. Cela faisait un bout de temps que je n'avais pas accéder à mes fichiers en dehors de la mise en ligne de fichiers .csv dans le répertoire "import".
Et ensuite je n'y ai pas touché non plus, et encore moins le fichier drawer.php que je n'ai jamais ouvert et dont je n'avais même pas remarqué l'existence.
Ceci dit, quand on pointe un dysfonctionnement, ou une zone de non-connaissance, on reçoit souvent de l'agressivité en retour, alors que c'est la meilleure façon de faire évoluer un sujet.
Je vais donc stopper ce sujet, puisqu'il n'est plus constructif.

[doekia]

Je n'ai jamais prétendu ne pas me tromper et si mon français contient des fautes d'orthographe ou de grammaire, lorsque je mentionne un point technique j'ai à coeur de le relire 3x pour être sûr - et je m'y trompe aussi des fois hélas.

 

Le fichier adminxxx/drawer.php existe dans toutes les version de Prestashop depuis au moins la 1.2

Et le fichier js/admin.js également depuis au moins les 1.2

Soyons clair, je suis 100% sûr que les fichiers disparus ne sont pas la cause de PrestaShop. Il ne reste plus que toi ou la suppression pour cause d'infection par un automate de l'hébergeur comme cause possible

 

[kokoon]

Salut, j'up le sujet pour d'autres qui fouineraient à la recherche d'une solution.

J'ai eu le problème après MAJ de 1.6.1.15 vers la dernière mouture 1.6.1.18. Pour moi le problème est causé par le module blockyoutubevideo (module officiel acheté en plus) , çà ajoute un onglet afin d'insérer un lien youtube sur la page produit.

Le contenu de cet onglet ne s'affiche plus, un joli gris à la place.

Le problème a été réglé en désactivant le module qui est en version 2.1.9. Maintenant je dois régler ce problème avec le module mais çà c'est une autre histoire.

Voilà, si çà peut aider quelqu'un ... si vous avez un module qui ajoute un onglet çà vaut le coup de vérifier cette piste