Cannot modify header & Compatibilité WP 2.7 -> résumé

  • Statut : non résolu
15 sujets de 1 à 15 (sur un total de 31)
  • Auteur
    Messages
  • #466529
    Supporter
    Membre
    Padawan WordPress
    50 contributions

    Bonjour,

    Je me permet de faire un résumé des modifications a faire sur WordPress 2.7 pour que tout ou presque fonctionne le mieux possible. Si jamais les modérateurs veulent supprimer certains sujets en double… Le but ici est de tout rassembler et d’épingler 😉

    Donc:
    Edition du fichier wp-config.php et mettre 4 clés personnalisés:

    /**#@+
    * Clefs uniques d’authentification.
    *
    * Remplacez les valeurs par défaut par des phrases uniques !
    * Vous pouvez générer des phrases aléatoires en utilisant
    * {@link http://api.wordpress.org/secret-key/1.1/ Le service de clefs secrètes de WordPress.org}.
    *
    * @since 2.6.0
    */
    define(‘AUTH_KEY’, ‘put your unique phrase here’);
    define(‘SECURE_AUTH_KEY’, ‘put your unique phrase here’);
    define(‘LOGGED_IN_KEY’, ‘put your unique phrase here’);
    define(‘NONCE_KEY’, ‘put your unique phrase here’);
    /**#@-*/

    Exemple: (Ceci est un exemple, mettre des clés différentes en allant ici : Liens Secret key Personalisées )

    define(‘AUTH_KEY’, ‘=}jPU|aBxn^Vx:06!0HCuaCobm4_b|y;?rwy-[!IUTyMJOvI+< *o%f(;}U-wK569');
    define(‘SECURE_AUTH_KEY’, ‘_~,Bp]I.W&*r92j.NA7Y|Aq.?$5rSr;3nXV=rwaX_@ KCSD$6
    define(‘LOGGED_IN_KEY’, ‘@9;BV.mY]-j|7~U~GQt73
    define(‘NONCE_KEY’, ‘g~AX2/<9UP-)DebND,B[w/#W[E#b}yQ-95w#=[l~tp9?z,rNhc|Cnh+|Y >2b5;b’);

    ==================================================

    Ensuite:Edition du fichier fr_FR.php et remplacer:

    < ?php
    $wp_default_secret_key = ‘mettez ici une phrase unique’;
    ?>

    Par exactement ceci ( donc sans aucune modification):

    < ?php
    $wp_default_secret_key = ‘put your unique phrase here’;
    ?>

    =============================================================

    Ensuite les BOMS:
    BOM Définiton

    Erreur spécifique à un problème de BOM: Warning: Cannot modify header information
    ( Cette erreur peut aussi avoir d’autres causes )
    A noter que plusieurs fichiers du theme Défaut de WordPress 2.7 contiennent des BOMS.

    Enlever les BOM:
    Comment?
    En utilisant le programme: delete-tag-utf8-bom
    Téléchargeable ici: Delete Tag
    Ensuite le dezipper sur le bureau.
    Ensuite lancer l’exécutable: delete-tag-utf8-bom-win.exe dans le dossier binDebug
    Cliquer sur choisir la cible, parcourir, et aller chercher le dossier WordPress version 2.7
    Ensuite lancer le scan: le programme va corriger les fichiers

    Ou:

    Lumière de Lune wrote:
    Enormément de messages suite à l’affichage de cette erreur.

    Dans la plupart des cas, cela provient du fichier wp-config.php

    Pour fonctionner correctement celui ci doit être enregistré en UTF-8 sans BOM , ou sans identification.

    Car le caractère d’identification est mal compris, et génère l’erreur en question.

    Le mode d’enregistrement dépend de l’éditeur de texte utilisé.

    Sous Notepad : enregistrer sous, codage UTF 8
    Sous Notepad +, dans le menu fichier, choisir “Codage” et UTF-8 (et pas UTF-8 avec signature)
    Sous Notepad ++ ,cliquer sur “encodage” et choisir “Encoder en UTF-8 (sans BOM) “
    Sous Word (si, si) : c’est pas possible (le fichier est en TXT, mais il n’y a pas moyen à ma connaissance de spécifier l’encodage)
    Sous Dreamweaver : Menu modifier, Propriétés de la Page, Titre / encodage

    Si le fichier wp-config.php est correctement enregistré en UTF-8 sans signature, alors il peut y avoir un autre problème.

    ===================================================

    Pour la compatibilté des themes avec WordPress 2.7
    De nouvelles fonctions avec les commentaires avec WordPress 2.7

    Une astuce intéressante:
    Le fichier comments.php du theme default est parfaitement compatible, avec les nouvelles fonctionnalités de WordPress 2.7
    Donc simplement remplacer le fichier comments.php de votre theme par celui du theme default 😉
    PS: ne pas oublier d’enlever les BOM ( voir plus haut)

    =====================================================

    Forum BBpress
    La version stable de bbpress actuelle:0.9.0.4 n’est pas compatible avec WordPress 2.7
    La prochaine version stable sera compatible

    Pour le moment donc seule la version Alpha de bbpress est compatible avec WordPress 2.7.
    Actuellement c’est la version: 1.0 alpha6.
    Téléchargeable ici:
    Télécharger le forum bbpress

    =====================================================

    Dans certains cas exceptionnels: Solution de secours mais radicale:
    1- Faire une sauvegarde de la BD.
    2- Sauvegarder le dossier contenant les fichiers de votre Thème (présent dans le dossier wp-content/themes/) sur votre Disque Dur.
    3- Sauvegarder le fichier config.php ( Pour reinstaller WordPress avec les mêmes paramètres ! )
    4- Vider la BD
    5- Reinstaller WordPress 2.7 ( En utilisant les même paramètres et donc les mêmes clés d’authentifications)
    6- Mettre la sauvegarde de la BD.
    7- Mette le dossier contenant les fichiers de votre thème dans le dossier wp-content/themes/ si necessaire !
    8- Activer le Thème

    ======================================================

    PS: Pour les problèmes d’encodage de BD, voir la suite…

    MISE A JOUR: LE 05/02/2009

    #658267
    krysttof
    Participant
    Chevalier WordPress
    219 contributions

    Le logiciel cité pour supprimer les BOM fonctionne que sous Windows. Existe-t-il des équivalents pour Mac et Linux ?

    #658269
    yorigami
    Membre
    Chevalier WordPress
    198 contributions

    Bonjours à tous,
    Tout d’abord, bravo pour le formidable travail accompli et pour l’ai que vous apportez par vos interventions.

    Je suis confronté au même problème que krysttof. J’utilise WordPress depuis plus d’un an, je bosse sur Mac (Intel et G4) et la mise en place de la nouvelle page config.php avec l’activation des nouveaux paramètres comme les clefs uniques d’authentification provoque inexorablement un mauvais affichage de la table des caractères de mes sites.
    J’ai naturellement essayé de mettre en pratique toutes les préconisations proposées dans cette discussion (et sur d’autres discussions), mais pour l’instant j’ai fait chou blanc à chaque tentative. J’ai dû me résigner à conserver la page config.php initiale pour conserver un affichage correcte.

    Questions
    Ces nouvelles clefs uniques d’authentification sont-elles la condition sine qua non à l’évolution pérenne de mon CMS préféré (qui pour l’instant fonctionne très bien)? Qu’apportes-t-elles concrètement ?

    Très curieusement, quand je supprime la ligne « define(‘DB_CHARSET’, ‘utf8’); » de la nouvelle page config.php mon affichage redevient normal (c’est la solution que j’ai adoptée pour l’un de mes sites pour voir dans le temps si tout fonctionner normalement).

    Y a-t-il une solution ou un programme efficace testé par Mac-user ?

    Merci pour vos réponses.

    #658268
    Supporter
    Membre
    Padawan WordPress
    50 contributions

    C’est simple:
    Si tu as mis à jour ta WordPress en 2.7, il faut évidemment utiliser tous les nouveaux fichiers de WordPress 2.7 et donc bien sur le nouveau fichier config.php qui utilise des nouvelles clefs uniques d’authentification.
    Si tu n’as pas mis a jour ta WordPress ou installé WordPress 2.7, les modifications dans cet article ne sont pas à prendre en compte….

    ============================================================
    Sinon:
    define(‘DB_CHARSET’, ‘utf8’); = Définit uniquement l’encodage de ta BD ( Base de données) et non l’encodage de tes pages html et/ou php.

    Le problème vient surement du fait que ta base de données n’est pas encodée en UTF8.

    Tu as deux solutions:
    Important: faire une sauvegarde de la base de donnée avant toute modification !

    Première solution: Accéder a ta base de données avec PhpMyAdmin ou autre… et changer l’encodage de ta BD en UTF8 ( tu trouveras des tutoriaux et aides sur le net) et donc laisser: define(‘DB_CHARSET’, ‘utf8’);

    Deuxième solution: tester en mettant: define(‘DB_CHARSET’, ‘latin1’);

    ==============================================================
    Sinon:
    Pour l’encodage UTF8 sans Bom sous Mac:
    Je ne sais pas sous Mac, mais il existe des Editeurs sous Mac aussi:
    Donc voir si ces logiciels existent sous Mac et utiliser cette methode ou trouver un Editeur sous Mac et utiliser une methode equivalente:
    Sous Notepad +, dans le menu fichier, choisir “Codage” et UTF-8 (et pas UTF-8 avec signature)

    #658270
    yorigami
    Membre
    Chevalier WordPress
    198 contributions

    Merci pour ta réponse Supporter.
    Oui je suis bien sous 2.7, et c’est pour cette raison que je cherche à placer cette nouvelle page config.php.
    J’ai fait des tests en local et sur MAMP (un émulateur de base PHP MySQL pour Mac) et si j’applique le nouveau fichier config.php de la version 2.7, je n’ai pas de problème d’affichage si toutes mes tables et leurs interclassements sont bien en UTF8.

    Après vérification mes sites qui étaient tous sous l’encodage UTF8 à leurs mises en service sont passés en latin-swedish-ci sur certaines tables. Je pense que c’est suite au changement d’hébergeur et à la migration de la base de données que le problème est apparu.
    Et je pense que c’est cet encodage qui est responsable des problème d’affichage et que les BOM n’ont rien à voir avec cela. Sous TextEdit (l’équivalent de NotePad) il n’y a qu’un version d’UTF8 proposé et aucune information sur la spécificité du codage.
    Petite question :
    Si je passe du « latin-swedish-ci » à UTF-8 par ma base de données, cela risque-t-il pas de provoquer des problèmes ?

    #658271
    Supporter
    Membre
    Padawan WordPress
    50 contributions

    A mon avis non, avec une sauvegarde de ta base de données, tu n’as rien a perdre a essayer de toute façon.

    Perso, c’est ce que je ferais, pour que tout soit au même encodage, et aussi car à la base WordPress utilise l’encodage UTF8

    PS: Quand on voie les caractères des nouvelles clefs uniques d’authentification…, en effet l’encodage doit jouer un role à ce niveau…

    #658272
    yorigami
    Membre
    Chevalier WordPress
    198 contributions

    Merci beaucoup pour ton aide précieuse,
    Je viens de faire la correction de toutes mes tables et interclassement en UTF-8, tout à bien fonctionné, mais, dès que je dépose la nouvelle page config.php (version2.7) avec les clefs authentification le même problème d’affichage de caractères accentués intervient. :(

    Je ne comprends pas, car en local ça semble bien marcher.

    Question :
    Si je conserve l’intégralité du code de la page config.php sauf cette ligne :
    define (‘DB_CHARSET’, ‘utf8’); qui semble poser le problème d’affichage, est-ce que je risque de gros problèmes dans les mises à jour ou de fonctionnement dans le futur, est-ce un bon compromis en attendant que je trouve une solution ?

    #658273
    Supporter
    Membre
    Padawan WordPress
    50 contributions

    Dirige toi sur ton blog, ensuite affiche la source de la page à partir de ton navigateur:

    Dans les premières lignes de la source tu devrais trouver cette ligne:
    <meta http-equiv="Content-Type" content="text/html; charset=

    Il faut que cette ligne soit comme ceci:
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8” />

    Ensuite:
    Connecte toi en tant qu’admin et va sur cette page:
    http://www.ton-blog.com/wp-admin/options.php

    Et verifie la clé: blog_charset
    la valeur en face doit être: UTF-8

    Il se peut que ton hébergeur est configuré l’encodage Php autre qu’en UTF8.
    Tu peux donc tester en mettant un autre encodage que UTF8 devant la clé: blog_charset comme: iso-8859-1

    Tout en laissant UTF8 dans le ficher config.php: define(‘DB_CHARSET’, ‘utf8’);

    Assure toi aussi que le fichier config.php ne contient pas de Boms.
    Exemple: edit le fichier config.php présent sur ton serveur à partir de ton logiciel FTP, tu devrais visionner les caractères BOMS de cette façon, et supprime les, il ne faut aucun caractères avant le <?php

    Fait tous ces tests et dit moi…

    PS: je voudrais signaler aussi le fait que la mise à jour de WordPress ne se fait pas seulement en remplaçant les anciens fichiers manuellement par les nouveaux…
    Il existe une procèdure pour la mise à jour de WordPress…
    J’espere qu’à la base tu as suivis la procédure de mise à jour officielle… Et donc qu’ensuite tu as remis ton ancien fichier config.php à cause de ce bug d’affichage…

    #658274
    yorigami
    Membre
    Chevalier WordPress
    198 contributions

    Tous les points cités ci-dessus sont corrects chez moi (bien UTF-8 de partout).
    Si je passe mon blog_charset: iso-8859-1, les caractères partent en live dès qu’il y a un accent ou autre, dès que je reviens en UTF-8 tout s’affiche normalement.

    Je vais essayer de trouver un PC avec FileZila pour voir si je peux localiser les Boms depuis le fichier config.php en ligne, sur Mac les deux gratuiciels que j’utilise n’ont pas cette option de correction en ligne.

    Pour chaque mise à jour, j’ai suivi la procédure du document html joint avec chaque version supérieure (ainsi que la désactivation puis réactivation de mes plugins avant et après chaque mise à jour).

    Merci une fois de plus pour ton aide.

    #658275
    Supporter
    Membre
    Padawan WordPress
    50 contributions

    J’ai vue plusieurs posts au sujet de bugs à la suite d’un changement d’hébergeur ou d’un changement de serveur et à la migration de la base de données…

    Certains ont finalement résolus le problème de cette façon:

    Solution de secours mais radicale:

    1- Faire une sauvegarde de la BD.
    2- Sauvegarder le dossier contenant les fichiers de votre Thème (présent dans le dossier wp-content/themes/) sur votre Disque Dur.
    3- Sauvegarder le fichier config.php ( Pour reinstaller WordPress avec les mêmes paramètres ! )
    4- Vider la BD
    5- Reinstaller WordPress 2.7 ( En utilisant les même paramètres et donc les mêmes clés d’authentifications)
    6- Mettre la sauvegarde de la BD.
    7- Mette le dossier contenant les fichiers de votre thème dans le dossier wp-content/themes/ si necessaire !
    8- Activer le Thème

    #658276
    yorigami
    Membre
    Chevalier WordPress
    198 contributions

    C’est un peu ce que je craignais, je vais donc essayer cela ce week-end en espérant que tout fonctionne aussi bien après la remise en place de la base de données.
    Je vous tiens informé de la suite des évènements.

    #658277
    yorigami
    Membre
    Chevalier WordPress
    198 contributions

    Après re-vérification, je suis complètement désappointé, sur les 3 CMS WP deux sont restés intègres au code UTF8 et le troisième (bien entendu le plus important) lui est passé partiellement dans un autre codage.
    Ce matin, j’ai donc refait une tentative de mise en place du nouveau fichier config.php (version 2,7) sur les deux WP qui avait conservé l’UTF-8 (quelques tables étaient passées en latin-swedish-ci, mais visiblement cela n’a pas provoqué de dégâts) et le nouveau fichier config.php s’est cette fois intégré sans générer de problème d’accent.
    Par contre pour le troisième site le fichier SQL est, je pense, inexploitable pour une restauration de base de donnée du fait de la modification partielle du code.
    Donc a priori les problèmes d’affichage ne sont pas provoqués par la présence de Boms dans le fichier config.php, mais bien à un problème de codage ou de configuration de table UTF-8 de la base SQL.

    Si quelqu’un a une suggestion pour la reconstruction de ma base de données, je suis preneur.

    #658278
    Supporter
    Membre
    Padawan WordPress
    50 contributions

    Soit plus précis stp, modification partielle de quel code exactement?
    Le code php? Si oui quels fichiers?
    Le code en rapport avec la base de données? Si oui, plus de détails…

    Sinon effectivement, voila la raison du bug…

    PS: tu aurais du le spécifier dès le départ, cela nous aurait fait gagner du temps 😉

    #658279
    yorigami
    Membre
    Chevalier WordPress
    198 contributions

    Désolé, je ne suis pas très clair…
    C’est bien ma base de donnée SQL qui est partiellement mal codée.

    Quand je l’exporte depuis phpMyAdmin depuis le serveur de mon hébergeur, je récupère une base moitié UTF-8, moitié latin-swedish-ci (je pense que c’est le code [les accents sont comme ceci : é pour é ; è pour è, ç pour ç…).
    Mais c’est très curieux, car certain mots ont une graphie juste. Si j’ouvre le fichier SQL sur un éditeur de texte, ce dernier perçoit soit le fichier en partie UTF8 et Latin-swedish-ci soit uniquement en latin-swedish-ci, ce qui me fait alors disparaître tous les accents (cela dépend de l’éditeur).

    À force de me prendre la tête sur le fichier SQL, je pense avoir trouvé une solution.

    J’ai trouvé (après de nombreux tests de petits programmes freeware pour mac) ce petit gratuiciel ConvertEncoding
    Il voit le fichier SQL avec les mêmes défauts d’affichage, mais si je place ses deux boutons d’encodage de UTF-8 vers UTF-8, il corrige toutes les fautes d’accents. Mais cela provoque un autre problème, le fichier enregistré n’est plus lui-même en UTF-8. Je suis donc obligé de l’ouvrir depuis DreamWeaver et par les propriétés de page le re-coder en UTF-8 (sans Boms).
    Là, mon fichier peut enfin être renvoyé sur le serveur de base SQL de mon hébergeur.
    J’ai alors créé une nouvelle base, j’ai importé mon fichier SQL corrigé sur cette nouvelle base, réinstallé WordPress 2.7 dans un nouveau répertoire renommé du nom du répertoire de mon site à problème (lui même renommé) pour que ce dernier indique le bon chemin.
    A priori à la connexion tout est rentré dans l’ordre et le fichier config.php ne pose plus de problème d’affichage.
    Il faut que je vérifie l’intégrité de tous les fichiers, mais pour l’instant tout fonctionne bien.
    La méthode est sans doute pas très claire et certainement empirique mais elle semble marcher.

    PS. Je l’aurai bien fait, mais le problème d’encodage n’est pas visible immédiatement, car il est situé en plein milieu du fichier, et comme à chaque fois je regardais les premières lignes du fichier SQL, je n’ai rien détecté.
    j’ai cherché le problème du côté des Boms, car cela me semble le plus cohérent compte tenu de ce que je voyais.

    #658280
    Supporter
    Membre
    Padawan WordPress
    50 contributions

    Essaye de tout réinstaller avec la base SQL sans correction de ta part…
    Il arrive que certaines bases de données soient comme la tienne et cela fonctionne tout de même…
    Si jamais cela bug toujours, alors oui la solution que tu viens d’enoncer sera peut-être suffisante… 😉

15 sujets de 1 à 15 (sur un total de 31)
  • Vous devez être connecté pour répondre à ce sujet.