Jovicyr

Bonjour Fanny, Regarde ma solution de février 2023. C'est sûrement dû à un module qui cause une régression. Dans la fiche produit en BO? dans son onglet Modules, tu verras les modules qui sont chargés pour les fiches produit. Tente de désactiver ces modules pour tester si l'affichage des champs de description fonctionnent à nouveau. Dans mon cas, c'était un module qui causait ce souci et en le mettant à jour, ça l'a réglé. Si le module en question n'a pas de mise à jour, il faudra le désinstaller et trouver un module alternatif si la fonctionnalité était nécessaire. Tiens-nous au courant,

Hello, Le message est affiché dans l'onglet "Transporteurs" dans une commande. Pas très visible, mais il y est... caché 😉

En fait, je viens de découvrir une piste sérieuse : j'ai un module intitulé "Champs supplémentaires produit" et lorsque je le désactive, il semblerait que les champs s'affichent correctement en BO. N'auriez-vous pas ce même module ou un autre module qui engendre ce comportement ? Je ne sais pas exactement quel hook est concerné, mais pour isoler ce module, j'ai recherché dans PERSONNALISER > Apparence > Position les hook commençants par "adminproduct" en cochant la case "Afficher les points d'accroche invisibles". ça permet de voir quels sont les modules appelés en BO sur la page d'édition de la fiche produit. J'ai une version ancienne de ce module (1.7.38), je vais tenter avec une mise à jour du module, voir si ça permet son usage sans régression sur les champs.

Hello, je rencontre moi aussi ce souci sur différentes versions de Prestashop, notamment après mise à jour en 1.7.8 : 1.7.8.5 / php 7.4 1.7.8.8 / php 7.3 L'affichage semble capricieux : lorsqu'on recharge la page, parfois ça s'affiche à nouveau correctement mais le plus souvent, c'est le non affichage de l'élément TinyMCE incluant le contenu qui n'apparait même pas dans le code HTML si on fait l'inspecteur du navigateur, ni l'iframe qui est censée être affichée par l'éditeur TinyMCE. ça impacte : les pages produit (champs récapitulatif et description) les pages CMS (champ "Contenu de la page") Mais j'ai testé sur le champ Description de la page Catégorie (BO) et ça s'affiche toujours bien dans mon cas. Sur la page produit en BO, j'ai l'erreur suivante dans la console de l'inspecteur dans Chrome : ncaught TypeError: Cannot read properties of null (reading 'textContent') at handleCounterTinyExtraField (8?_token=xx:5781:47) Aussi, l'éditeur TinyMCE semble ne pas correctement se charger et cela, de manière intermittente puisque parfois ça fonctionne et d'autres fois, en majorité, non. Cela se produit aussi bien sur mon poste, sur Chrome/FireFox que sur les postes des marchands, donc des configurations très différentes. Pour ceux qui ont déjà rencontré par le passé ce souci, vous avez pu le solutionner ? Et pour ceux qui verraient par hasard ce post, une idée ? Uns piste de recherche à explorer ? Merci pour vos retour !

Je viens de contourner sur une boutique le gros souci de changement de nom de domaine en BO des multiboutiques PS 1.7 en ajoutant 2 simples lignes dans le fichier htaccess présent dans le dossier "adminxxx" : /adminxxx/.htaccess <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_HOST} ^(www.)?second-site.fr RewriteRule ^(.*)$ https://www.site-maitre.fr/adminxxx/$1 [R=301,L] (trouvez les 2 premières lignes et ajoutez les 2 suivantes en dessous) Ainsi, la navigation dans le BO ne se fera uniquement que sur le nom de domaine (ndd) du site maitre et donc on ne basculera plus sur les autres ndd.

Bonjour Marion, As-tu finalement trouvé une solution ? Je rencontre le même souci sur un PS 1.7.6.3. Merci pour ton retour !

Ok donc déjà si tu "utilises" phpMyAdmin, c'est un bon début 😉 Ben justement, une fois dans l'interface, sélectionne la base de données de ton Prestashop dans la colonne de gauche. Puis à droite, tu dois avoir tout en haut un onglet intitulé SQL. Clique dessus, ça t'ouvre une page avec un grand champ texte. Dedans, colles-y les 2 requêtes de mon précédent message. Vérifie que les tables de ta base de données commencent bien par "ps_", sinon il te faudra adapter mes requêtes avec le bon préfixe. Puis exécute les requête en cliquant sur le bouton de validation normalement présent en bas à droite de la page. Voilà, j'espère que ça te sera utile.

Bonjour, Il faut exécuter la requête dans ton outil de gestion de base de données, par exemple phpMyAdmin s'il est installé sur ton environnement serveur. Cependant si tu poses cette question, j'ai bien peur que ma réponse ne soit pas si aidante. J'en profite pour ceux qui passeraient par là, que j'ai depuis une bien meilleure requête et pas qu'une seule d'ailleurs, ces 2 sont complémentaires : INSERT IGNORE INTO ps_access (id_profile, id_authorization_role) SELECT 1, id_authorization_role FROM ps_authorization_role; INSERT IGNORE INTO ps_module_access (id_profile, id_authorization_role) SELECT DISTINCT 1, (ar.id_authorization_role) FROM ps_authorization_role ar ; La première remplace la longue précédente requête pour les pages du BO de Prestashop. La seconde permet l'affectation des droits aux différents modules.

Bonjour, Pourrais-tu partager la solution trouvée ? Merci !

Hello, Avez-vous trouvé une solution ? Merci pour le partage !

Bonjour, Je rencontre le même souci. Avez-vous trouvé une solution ? Merci pour le partage !

Ce souci arrive généralement après une mise à jour de Prestashop 1.6. Il faut ajouter, si ces lignes n'existent pas, dans le fichier tpl contact-form.tpl de votre thème, juste au dessus du bouton submit : <input type="text" name="url" value="" class="hidden" /> <input type="hidden" name="contactKey" value="{$contactKey}" /> ça donne (peut différer légèrement selon votre thème) : <div class="submit"> <input type="text" name="url" value="" class="hidden" /> <input type="hidden" name="contactKey" value="{$contactKey}" /> <button type="submit" name="submitMessage" id="submitMessage" class="button btn btn-default button-medium"><span>{l s='Send'}<i class="icon-chevron-right right"></i></span></button> </div>

Merci de ton retour. Après investigation, effectivement il manque non pas des colonnes (le modèle de données a changé), mais des lignes. Cette requête a permis de réaffecter l'ensemble des persmission au profil administrateur (id = 1) : INSERT IGNORE INTO `ps_access` (`id_profile`, `id_authorization_role`) VALUES (1, 1), (1, 2), (1, 3), (1, 4), (1, 5), (1, 6), (1, 7), (1, 8), (1, 9), (1, 10), (1, 11), (1, 12), (1, 13), (1, 14), (1, 15), (1, 16), (1, 17), (1, 18), (1, 19), (1, 20), (1, 21), (1, 22), (1, 23), (1, 24), (1, 25), (1, 26), (1, 27), (1, 28), (1, 29), (1, 30), (1, 31), (1, 32), (1, 33), (1, 34), (1, 35), (1, 36), (1, 37), (1, 38), (1, 39), (1, 40), (1, 41), (1, 42), (1, 43), (1, 44), (1, 45), (1, 46), (1, 47), (1, 48), (1, 49), (1, 50), (1, 51), (1, 52), (1, 53), (1, 54), (1, 55), (1, 56), (1, 57), (1, 58), (1, 59), (1, 60), (1, 61), (1, 62), (1, 63), (1, 64), (1, 65), (1, 66), (1, 67), (1, 68), (1, 69), (1, 70), (1, 71), (1, 72), (1, 73), (1, 74), (1, 75), (1, 76), (1, 77), (1, 78), (1, 79), (1, 80), (1, 81), (1, 82), (1, 83), (1, 84), (1, 85), (1, 86), (1, 87), (1, 88), (1, 89), (1, 90), (1, 91), (1, 92), (1, 93), (1, 94), (1, 95), (1, 96), (1, 97), (1, 98), (1, 99), (1, 100), (1, 101), (1, 102), (1, 103), (1, 104), (1, 105), (1, 106), (1, 107), (1, 108), (1, 109), (1, 110), (1, 111), (1, 112), (1, 113), (1, 114), (1, 115), (1, 116), (1, 117), (1, 118), (1, 119), (1, 120), (1, 121), (1, 122), (1, 123), (1, 124), (1, 125), (1, 126), (1, 127), (1, 128), (1, 129), (1, 130), (1, 131), (1, 132), (1, 133), (1, 134), (1, 135), (1, 136), (1, 137), (1, 138), (1, 139), (1, 140), (1, 141), (1, 142), (1, 143), (1, 144), (1, 145), (1, 146), (1, 147), (1, 148), (1, 149), (1, 150), (1, 151), (1, 152), (1, 153), (1, 154), (1, 155), (1, 156), (1, 157), (1, 158), (1, 159), (1, 160), (1, 161), (1, 162), (1, 163), (1, 164), (1, 165), (1, 166), (1, 167), (1, 168), (1, 169), (1, 170), (1, 171), (1, 172), (1, 173), (1, 174), (1, 175), (1, 176), (1, 177), (1, 178), (1, 179), (1, 180), (1, 181), (1, 182), (1, 183), (1, 184), (1, 185), (1, 186), (1, 187), (1, 188), (1, 189), (1, 190), (1, 191), (1, 192), (1, 193), (1, 194), (1, 195), (1, 196), (1, 197), (1, 198), (1, 199), (1, 200), (1, 201), (1, 202), (1, 203), (1, 204), (1, 205), (1, 206), (1, 207), (1, 208), (1, 209), (1, 210), (1, 211), (1, 212), (1, 213), (1, 214), (1, 215), (1, 216), (1, 217), (1, 218), (1, 219), (1, 220), (1, 221), (1, 222), (1, 223), (1, 224), (1, 225), (1, 226), (1, 227), (1, 228), (1, 229), (1, 230), (1, 231), (1, 232), (1, 233), (1, 234), (1, 235), (1, 236), (1, 237), (1, 238), (1, 239), (1, 240), (1, 241), (1, 242), (1, 243), (1, 244), (1, 245), (1, 246), (1, 247), (1, 248), (1, 249), (1, 250), (1, 251), (1, 252), (1, 253), (1, 254), (1, 255), (1, 256), (1, 257), (1, 258), (1, 259), (1, 260), (1, 261), (1, 262), (1, 263), (1, 264), (1, 265), (1, 266), (1, 267), (1, 268), (1, 269), (1, 270), (1, 271), (1, 272), (1, 273), (1, 274), (1, 275), (1, 276), (1, 277), (1, 278), (1, 279), (1, 280), (1, 281), (1, 282), (1, 283), (1, 284), (1, 285), (1, 286), (1, 287), (1, 288), (1, 289), (1, 290), (1, 291), (1, 292), (1, 293), (1, 294), (1, 295), (1, 296), (1, 297), (1, 298), (1, 299), (1, 300), (1, 301), (1, 302), (1, 303), (1, 304), (1, 305), (1, 306), (1, 307), (1, 308), (1, 309), (1, 310), (1, 311), (1, 312), (1, 313), (1, 314), (1, 315), (1, 316), (1, 317), (1, 318), (1, 319), (1, 320), (1, 321), (1, 322), (1, 323), (1, 324), (1, 325), (1, 326), (1, 327), (1, 328), (1, 329), (1, 330), (1, 331), (1, 332), (1, 333), (1, 334), (1, 335), (1, 336), (1, 337), (1, 338), (1, 339), (1, 340), (1, 341), (1, 342), (1, 343), (1, 344), (1, 345), (1, 346), (1, 347), (1, 348), (1, 349), (1, 350), (1, 351), (1, 352), (1, 353), (1, 354), (1, 355), (1, 356), (1, 357), (1, 358), (1, 359), (1, 360), (1, 361), (1, 362), (1, 363), (1, 364), (1, 365), (1, 366), (1, 367), (1, 368), (1, 369), (1, 370), (1, 371), (1, 372), (1, 373), (1, 374), (1, 375), (1, 376), (1, 377), (1, 378), (1, 379), (1, 380), (1, 381), (1, 382), (1, 383), (1, 384), (1, 385), (1, 386), (1, 387), (1, 388), (1, 389), (1, 390), (1, 391), (1, 392), (1, 393), (1, 394), (1, 395), (1, 396), (1, 397), (1, 398), (1, 399), (1, 400), (1, 401), (1, 402), (1, 403), (1, 404), (1, 405), (1, 406), (1, 407), (1, 408), (1, 409), (1, 410), (1, 411), (1, 412), (1, 413), (1, 414), (1, 415), (1, 416), (1, 417), (1, 418), (1, 419), (1, 420), (1, 421), (1, 422), (1, 423), (1, 424), (1, 425), (1, 426), (1, 427), (1, 428), (1, 429), (1, 430), (1, 431), (1, 432), (1, 433), (1, 434), (1, 435), (1, 436), (1, 437), (1, 438), (1, 439), (1, 440), (1, 441), (1, 442), (1, 443), (1, 444), (1, 445), (1, 446), (1, 447), (1, 448), (1, 449), (1, 450);

Bonjour pumpvive, as-tu trouvé une solution ou l'origine du souci ? Je viens en effet de mettre à jour un Prestashop 1.6 vers 1.7.4.4 et j'ai exactement ce souci : les pages Commandes, Clients sont en accès interdit pour un SuperAdmin. Merci pour ton retour,

Hello Prestashopconector, I am face to this issue and trying to execute the procedure you indicated. The procedure is executed, I can see tmp table being field up but there is an infinite loop: numbers in nleft and nright can't stop growing. My category table contains 570 lines. It's a multishop prestashop. What do I have to fix before executing this procedure in order to avoid the loop and getting success? Gracias for your precious answer,