#HELP : Cherche utilitaire pour récupérer mes accents sur blogs #WordPress suite upgrade MySQL 4 => 5
Articles proches :
- Aïe Ouille mise à jour Debian lenny : θ^dA&d ?
- Des extensions WordPress.com non recommandables
- Thèmes WordPress gratuits en Français
- J’attendrai l’élue ^^ RT @wpchannel: WordPress 3.0 Release Candidate à télécharger http://goo.gl/fb/yn1YT #actualités #wordpress
- Vous connaissez un utilitaire qui permet d’imprimer un web « comme à l’écran » sans mauvaises surprises ?
- Firefox rame-t-il ?
- Un annuaire 2010 des acteurs du réseau je suis pas dedans mais y a un blog sans billet depuis mai 2009 c’est un #fail vous croyez ?
@chessman2212 Merci pour ton lien http://tinyurl.com/yh23k96, l’idée semble intéressante je regarde #accents #WordPress #mysql5
#HELP : Mon problème étant que je n’ai pas d’Ancien et Nouveau : Tout est déjà dans le nouveau MySQL5 (uprade serveur dédié) #Wordpress
Une approche de solution pour ceux qui disposent encore de leurs anciennes bases de données ET de leur ancien serveur :
Et oui lors des opérations de modifications majeures d’un serveur il est toujours intéressant de réaliser des backups (pour modifications versions de PHP, mysql, …). Pour ton problème, nous pourrons bien entendu en discuter un peu plus ensemble et voir ce qui se passe exactement au niveau de ta base.
Dans ce cas précis faire une sauvegarde n’aide en rien.
D’ailleurs mon prestataire a toutes les sauvegardes sous le coude
Marco
Une sauvegarde aide TOUJOURS. En cas de boulette elle évite de devoir tout recommencer depuis le départ, dans le cas d’essais cela permet de travailler sans avoir peur de la boulette citée précédemment. Dans le cas actuel effectivement ca n’aide pas car tu ne l’as pas mais si tu l’avais eu tu aurais pu effectuer différents tests d’export de mysql4 pour un nouvel import dans mysql5 de façon « propre » ou du moins fonctionnelle.
Chris,
En effet il faut toujours faire plein de sauvegardes.
J’y ajouterais volontiers d’autres bonnes pratiques mais ce n’est pas le souci dans le cas présent ^^
1. j’ai des sauvegardes
2. mon prestataire d’hébergement a des sauvegardes et dumps faits comme il se doit dans le process, juste avant l’upgrade
LE problème est que les nainformaticiens (communauté WordPress et rien trouvé ailleurs pour l’instant) ne semblent pas avoir créé le « patch » pourtant évident pour un tel cas.
Il existe une méthode pour faire les choses avec la sauvegarde en MySQL4 :
1. trouver un serveur en MySQL4
2. installer vos bases de données concernées une à une sur ce serveur en MySQL4
3. exporter vos bases de données concernées une à une avec des paramétrages précis (ANSI) à partir du serveur MySQL4
4. importer vos bases de données concernées une à une avec des paramétrages précis (ANSI) dans votre serveur MySQL5
Mais c’est bourrin, bien comme ils aiment les nainformaticiens…
Cheers,
Marc
Bonjour,
Après analyse des résultats apportés par un ex stagiaire que j’ai sollicité pour l’occasion et des suites de mes analyses, mes recommandations :
— VEILLEZ À CONVERTIR VOS COLONNES DANS VOS TABLES DANS VOS BASES DE DONNÉES WORDPRESS EN UTF-8 DÈS QUE POSSIBLE même si vous n’avez pas encore décidé de migrer en MySQL 5.xxx (pourtant indispensable pour la dernière version de WordPress)
— VEILLEZ À VALIDER L’INTERCLASSEMENT DANS VOS BASES AVANT de commencer à travailler.
La commande SQL pour convertir interclassements (codage des caractères) dans les bases de données :
ALTER TABLE ... CONVERT TO CHARACTER SET ...(à partir de MySQL 4.1.2) ou encoreALTER DATABASE base_de_donnees CHARACTER SET jeu_de_caracteres COLLATE interclassementCela ne vous empêchera pas de rencontrer quelques problèmes car la commande convertit les éléments déjà présents dans le tables.
Ce qui revient à dire que « le patch » que je recherche reste utile et nécessaire : Un script SQL adaptable facilement pour récupérer des caractères accentués et spéciaux dans des bases de données rapidement.
Quelques ressources bien utiles (même si elles datent comme vous pourrez le constater) :
http://www.developpez.net/forums/d141040/bases-donnees/mysql/requetes/changer-dinterclassement/
http://www.siteduzero.com/tutoriel-3-36943-comprendre-les-jeux-de-caracteres-et-interclassements.html
Bonjour,
*** BONNES NOUVELLES ***
1. J’ai un gars sympa qui m’a fait des scripts MySQL pour remplacer les caractères considérés (mais pour l’instant c’est fastidieux car colonne par colonne table par table).
Ça reste exploitable en l’état mais j’ai prooposé des pistes pour l’améliorer (MySQL étant un langage extrêment intéressant pour qui veut bien l’étudier avec des commandes hyper pertinentes et efficaces).
2. J’y vois un peu plus clair dans tout ceci.
*** QUESTIONS IDIOTES ***
J’achope sur un point qui m’interpelle :
Qu’est-ce qui fait que dans MySQL toutes mes bases créées sous Wordpress sont actuellement en interclassement latin-1 (ISO-8859-1) alors que j’ai précisé le paramétrage UTF-8 dans Wordpress ?
*** Sous questions ***
a. Est-ce que c’était déjà le cas avant ?
b. Est-ce que Wordpress est trop bête et pas suffisamment « fini » pour vérifier et changer ça si nécessaire ? (quand on sait à quel point c’est important)
c. Existe-t-il des moyens simples finalement issus de la communauté Wordpress pour arranger ça ?
Et surtout : AVANT DE FAIRE QUOIQUE CE SOIT (remplacements de caractères), SACHANT QUE JE SUIS EN UTF-8 (et souhaite le rester) DANS WORDPRESS, DOIS-JE CHANGER LES INTERCLASSEMENTS DANS LES BASES MYSQL EN UTF-8 AVANT TOUTE CHOSE ?
Bien à vous,
Marc
Quelques réponses :
1. Vous pouvez (et devez) spécifier UTF-8 en de nombreux endroits :
— lors de la création de votre base de données
— dans le fichier wp-config.php
— dans les réglages / options de lecture de Wordpress (mais ça c’est moins critique)
2. Wordpress 2.8.6 crée bien sa base en UTF-8 dans MySQL (si vous avez laissé les paramètres par défaut, tout va bien)
un petit guide intéressant de MySQL à l’époque de la migration en MySQL 4.1 : Unicode and Other Funny Characters
La page d’informations officielle de MySQL sur Jeux de caractères et Unicode en Français.
Pour information / mémoire, WordPress crée des tables en « utf8_general_ci ».
Ce petit détail pourra en aider quelques uns, une fois plongés dans leurs paramètres MySQL / phpMyAdmin car — il faut le savoir —, il y a pas moins de 21 « utf8_xxxx » proposés dans mon MySQL 5.0.51a
Petites notes de travail :
Test sur un blog / une base :
J’ai effectué la mise à jour « manuelle » des catégories, mots-clefs, articles et pages.
D’autant plus fastidieux que le thème utilisé duplique les titres d’articles dans 4 champs complémentaires.
La mise à jour des articles est « simplifiée » par la mise à jour d’un fichier de correspondances et l’utilisation d’édition / remplacer dans un bon éditeur du code HTML
Opération de sauvegarde de la base puis :
ALTER DATABASE `xxxx` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ciTout va bien.
Continuons : Il faut maintenant faire la même opération pour chaque table et pour chaque colonne de chaque table.
Après quelques tâches commerciales (qui font la raison pour laquelle je préfèrerais avoir les moyens d’avoir une personne qui bosse pour moi, bien concentrée, sur l’informatique), c’est parti pour les
ALTER TABLE `table` CHANGE `colonne` `colonne` VARCHAR( 100 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULLAh non ça ce n’était pas la bonne chose à faire !!!
Pas plus que d’imaginer pouvoir restaurer la sauvegarde SQL faîtes en démarrage de session de travail et restaurer le blog. Pour des raisons que j’ignore totalement, les liens ne fonctionnent plus après restauration et renvoient une erreur 404…
(à suivre…)
Marc
Bon, c’est décidé, on arrête les frais des conneries liées à la fainéantise des nainformaticiens :
Je vais rebâtir mes blogs 1 à 1
Avec l’aide de scripts et de petites astuces pour limiter le travail au maximum.
CQFD
Marc
Un scénario de conversion d’encodages :
Dans phpmyadmin :
1. Opérations => valider utf8_general_ci pour la base ==> convertit le format par défaut pour la base
2. SQL, pour chaque table : ALTER TABLE {table} CHARACTER SET utf8 COLLATE utf8_general_ci ==> convertit le format par défaut de la table
3. SQL, pour chaque table : ALTER TABLE {table} CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci ==> convertit toutes les colonnes de la table
4. Utilitaire de remplacement de caractères spéciaux en fonction de vos besoins