- WordPress :4.9.4
- Statut : non résolu
- Ce sujet contient 6 réponses, 3 participants et a été mis à jour pour la dernière fois par
, le il y a 7 années et 2 mois.
-
Messages
-
Bonjour,
Ma configuration WP actuelle
- WP : 4.9.5
- Version de PHP/MySQL : 7.1 (OVH défaut)
- Thème utilisé : custom depuis twentythirteen
- Extensions en place : … aucune, voir détail du problème
- Nom de l’hébergeur : OVH
- Adresse du site : sans intérêt le problème ne se manifeste que dans les conditions précisées
Problème(s) rencontré(s) :
Bonjour,
La semaine dernière (ceci est survenu le 15/04/2018), mon site avec les conditions définies suivantes est devenu incapable de trouver les thèmes figurant dans le répertoire sauf un seul, probablement le thème par défaut dans 4.9.5 « Twentyseventeen »:
- wp 4.9.5 (ceci semble être apparu avec la mise à jour de 4.9.5 mais je ne suis pas sûr – je ne pouvais pas effectuer de test de descente pour le test jusqu’à maintenant)
- Exécuter le navigateur Chrome canari actuellement Version 68.0.3403.0 (Build officiel) canary (64 bits)
- Exécuter sur mon ordinateur (le serveur est hébergé sur ovh server)
Dans ces conditions WP ne voit que le thème « Twentyseventeen ».
Les conséquences sont:- en mode admin un seul thème est vu alors qu’il y en a 8.
- lors de l’exécution front ou backend le thème défini dans la base de données est ignoré et seul un « Twentyseventeen » nu est utilisé pour afficher le contenu
Mais :
- Sur le même ordinateur mais un autre navigateur (six commun testé) le problème n’existe pas
- Sur un autre ordinateur avec le même navigateur chrome canari tout est OK
- Sur tout autre navigateur pouvant être lancé à partir de n’importe quel autre ordinateur, il n’y a pas de problème (plus de dix testés)
Je n’ai pas trouvé de sujet correspondant ici et qui soit aussi clair que le mien : défaillance de listage des thèmes contenu dans le répertoire adapté (content/themes/) (juste quelques sujets voisins de mon sujet : des difficultés à reconnaître les thèmes mais site français ou US aux causes variées et spécifiques).
Note: J’utilise actuellement un thème personnalisé bien identifié et installé depuis trois ans maintenant et issu de, et largement amélioré à partir de « twentythirteen ».
Est-ce que quelqu’un connaît ce problème?
J’ai déjà passé près de 60 heures à chercher, alors que je ne peux plus développer et maintenir le site et le lancement du site est retardé, le site est arrêté. J’ai découvert une grande partie du code de base autour du processus de sélection de modèle, mais avant de trouver exactement ce qui se passe, je pense qu’il reste encore beaucoup de travail.Quelque chose dans mon contexte définit le comportement fortement associé , mais quoi ?
Exemple de voies explorées (parmi des dizaines) :
- (un mauvais cookie?) qui peut associer le problème au navigateur et à l’ordinateur, mais lequel ? Mais c’est nécessairement faux puisque le problème survient dans l’exécution php sur le serveur avec une même requête https.
- Sans possibilité de trace détaillée (serveur OVH mutualisé) un problème de rewrite du htaccess en fonction du client ?
Meilleures salutations
Trebly
Hello, quelles sont les permissions sur les dossiers ? Est-ce que le bug persiste avec les extensions désactivées ? Quel est l’en-tête du fichier style.css ?
Bonsoir,
Merci.
Comme le problème ne se manifeste que pour un navigateur sur une seule machine (ma machine de développement):
- les permissions ne sont pas concernées
- il n’y a pas d’extensions chargées
- l’en tète fonctionne depuis 3 ans et avec tous les autres navigateurs et systèmes
Il y a un problème lié au navigateur (c’est chrome canari qui est concerné) et son contexte.
Tout semble tourner autour de la gestion de la « santé » et la désactivation de plugins.
Je suis près du but mais c’est extrêmement long.
Il y aurait un ou plusieurs bugs, mais pas principalement dans WP.
Quand je disais :
-
(un mauvais cookie?) qui peut associer le problème au navigateur et à l’ordinateur, mais lequel ? Mais c’est nécessairement faux puisque le problème survient dans l’exécution php sur le serveur avec une même requête https.
c’était une « connerie », j’ai écrit bien trop vite en pensant à autre chose, en effet le traitement de session va interroger le demandeur ( environnement du navigateur) en renseignant l’array superglobale $_COOKIE et en testant $_COOKIE[« … »] utilisé abondamment …
Trebly
Bonsoir,
Eh bien non, ce n’est même pas un bogue.
Il y a de nouvelles fonctions en version 4.9.4, en particulier pour la gestion de sécurité et d’incidents.
Un de leurs effets est ce que j’ai observé.
Pour en sortir j’en ai eu pour huit jours et environ 60 heures de travail.
Pour plus d’informations essayer de voir Health Check (plugin pur et mu-plugins).
La cause est un cookie WP qui s’installe et pour lequel rien n’est décrit. Il faut le détruire manuellement pour que tout rentre dans l’ordre sinon :
- on reste rivé au thème (twentySeventeen) par défaut et avec
- la totalité des plugins désactivés,
- plus de visibilité des themes,
- etc…
Et le vrai problème et unique problème est un problème de documentation.
En effet quand on donne à Google les mots-clés WordPress est le nom du coup qui considéré, Google reste muet tout autant que le codex, ce n’est pas étonnant c’est un plugin …
Cordialement
Trebly
________________________________________________________________________________
Note 1 : on ne peut pas considérer ce sujet comme fermé. Evidemment j’attends les réactions des auteurs qui est l’équipe WordPress.
Note 2 :
En effet c’est une évolution récente, le concept de « plugin complément tiers » évolue vers celle de compléments par opposition au noyau. On est alors dans le problème de l’évolution de l’architecture d’un outil et de l’organisation de son développement. Si le plugin reste l’apanage des développeurs tiers et que l’équipe WordPress s’occupe du cœur dans sa totalité, rien n’interdit à l’équipe WordPress de développer elle-même des plugins (en utilisant ce concept relatif à l’architecture globale du produit pour introduire des développements avec les mêmes outils que ceux introduits par les développeurs tiers, malheureusement avec le même tendon d’Achille : la documentation, ce qui n’est pas pas le cas du remarquable CODEX pour le noyau).Je rebondis sur ta Note 1. Ici tu es sur le forum d’entraide francophone. Pas du tout à l’endoit ou les bugs sont remontés puis traité, patché. (ici pour le Core https://make.wordpress.org/core/)
Quand tu définis « L’équipe WordPress » tu penses a qui ? a quoi? WordPress est un logiciel open Source développé par des milliers de développeurs de par le monde. Tu es développeur, tu peux d’ailleurs faire partie de cette équipe WordPress et ainsi apporter ta pierre a l’édifice.
Si tu penses que ton soucis (que je n’ai toujours pas compris) vient du Coeur de WP, je te conseilles d’ouvrir un ticket sur le lien précédemment donné en anglais. Si tu trouve le « bug » et ben tu proposer un patch qui sera testé et validé … ou non tout dépends :-/
Bonjour,
Désolé, je ne définis pas « L’équipe WordPress », je ne fais qu’utiliser le concept qui définit les auteurs du plugin « Health Check » (mu-plugin).
Par ailleurs j’ai plus de 200 messages laissés sur : https://wordpress.org/support/forum/how-to-and-troubleshooting/
Ton courrier m’a forcé à vérifier et je n’ai pas retrouvé le message sur le forum US.
Je n’avais pourtant pas rêvé l’avoir envoyé et j’en ai retrouvé le texte dans ma pile de copies de messages. D’ailleurs le message d’origine ici est, tu l’as peut-être remarqué, une traduction automatique anglais vers français et à peine corrigée de mon message d’origine rédigée en anglais (voir certaines tournures).Je viens de le renvoyer et je pense d’ailleurs à cette occasion avoir trouvé la cause (une mauvaise balance de tags). J’ai probablement voulu aller trop vite et je n’ai pas du vérifier l’affichage après avoir « soumis »…
J’ai aussi décidé d’envoyer une version modifiée du message sur ce site d’aide français. Sur le site US je pose un problème, ici je disais plutôt « en avez-vous entendu parler ».
Je n’ai pas donné ici de réponses détaillées (voir aussi .https://wpfr.net/support/sujet/une-anomalie-inintelligible/#post-2140175 sur lequel tu m’avais d’ailleurs répondu. En effet je veux éviter sur ce problème qui est finalement assez compliqué de créer « du bruit » sur la question de la solution. Pour cela j’attends la réaction du forum US.
En effet j’ai la cause et presque tout ce qui tourne autour après avoir creusé le code de manière approfondie (ajouter des traces fines sur 20 fichier .php du cœur et du mu-plugin). Par contre je n’ai pas l’origine exacte, il y a un mélange de data et de cookies. Après près de 60 heures passées sur ce problème, j’ai un remède qui permet de se sortir de l’impasse mais qui n’est pas la correction d’un bug.
Cordialement
Trebly
Note :
Pour ce qui est du problème, maintenant qu’il est en partie résolu, et que j’en ai fait le tour des aspects, j’essaye de te l’expliquer en quelques mots :
le dimanche 15 avril en rentrant de promenade, en réveillant ma machine, je découvre pour un onglet de mon site un bandeau d’en-tête occupant toute la page et en dessous le texte de l’article qui était affiché dans un mode (theme) totalement inconnu (Et évidemment plus un seul plug-in ni widgets ni menu).
J’essaye d’accéder en mode administrateur, ce qui réussit, et je découvre un site totalement nu (tout plug-in désactivés). Je lance la fonction thème et n’en trouve qu’un seul «twentyseventeen ».À partir de constantes HTML j’essaye de retrouver l’origine, j’identifie bien que le thème affiché est « twentyseventeen » mais totalement déshabillé. De plus des classes d’éléments sont différents.
À la suite de ça je teste le site à partir de mes autres navigateurs sans constater aucune anomalie. Je teste à partir de mon Smartphone, à partir de l’ordinateur de mon épouse sur lequel j’installe chrome canari, tout fonctionne. Je vérifie l’ensemble du code sur le serveur rien n’a bougé.
Voilà comment a commencé la journée du 16 avril et je n’ai trouvé le pot au roses qu’hier.
- Vous devez être connecté pour répondre à ce sujet.