yorigami (Créer un compte)

Toutes mes réponses sur les forums

4 sujets de 166 à 169 (sur un total de 169)
  • Auteur
    Messages
  • en réponse à : Cannot modify header & Compatibilité WP 2.7 -> résumé #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.

    en réponse à : Cannot modify header & Compatibilité WP 2.7 -> résumé #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 ?

    en réponse à : Cannot modify header & Compatibilité WP 2.7 -> résumé #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 ?

    en réponse à : Cannot modify header & Compatibilité WP 2.7 -> résumé #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.

4 sujets de 166 à 169 (sur un total de 169)