person:mathias bynens

J’ai essayé de faire :
update spip_meta set valeur='utf8bm4' where nom='charset_sql_connexion';

ceci afin que SPIP envoie la commande
set names 'utf8mb4';

mais si on fait ça il faut d’abord convertir toute la base de données en utf8mb4. C’est pas gagné !

Emoji deserves it :) <— smiley tout pourri du millénaire dernier

avant d’écrire quoi que ce soit il faudrait que je comprenne pourquoi ça ne marche pas… :)

À proposer et expliquer pour la doc d’installation de #SPIP ? (et éventuellement pour convertir un site existant)

évidement, ça vaut pour n’importe quelle application qui utilise MySQL (ou MariaDB ?)

(en local) j’ai tenté une approche utf8mb4 sur seenthis, et je suis parvenu à la recette suivante, qui a fonctionné mais me paraît un peu complexe…

# Comment utiliser utf8mb4 avec SPIP

background :
►https://mathiasbynens.be/notes/mysql-utf8mb4
►http://seenthis.net/messages/350136

Voici une liste d’opérations qui semble fonctionner chez moi (en local) :

0. Vérifier

– que le contenu est en utf8 (dans l’espace privé de SPIP) ;
– que les tables sont bien en utf8 (dans le dump mysql)
– que MySQL est en version > 5.5.3

1. Exporter la base sous deux fichiers, d’un côté la structure, de l’autre, les données (dans notre exemple, on travaille sur la base seenthis) :

mysqldump --opt --no-data seenthis > seenthis_structure.sql
mysqldump --opt --no-create-info seenthis > seenthis_contents.sql

cet export est notre backup ; en cas de souci, le réimporter tel quel

2. Réimporter la structure, en prenant soin de remplacer utf8 par utf8mb4, et de remplacer 255 par 249 (car une clé primaire doit obligatoirement faire moins de 1000 octets) :

cat seenthis_structure.sql | perl -pi -e's/utf8/utf8mb4/g;' | perl -pi -e's/\(255/(249/g;' | mysql seenthis

3. Réimporter les données :

cat seenthis_contents.sql | mysql seenthis

les données étant déjà en utf8 elles se chargent telles quelles

3. Indiquer à SPIP qu’il doit se connecter à MySQL en invoquant SET NAMES utf8mb4 :

echo "update spip_meta set valeur='utf8mb4' where nom='charset_sql_connexion'" | mysql seenthis

je ne sais pas encore s’il faut éditer
– charset_collation_sql_base (valeur : utf8_general_ci)
– charset_sql_base (valeur : utf8)

4. tester

5. Si on utilise mysql en ligne de commande, l’invoquer avec

mysql --default-character-set=utf8mb4

ou ajouter ceci dans .my.conf :

default-character-set=utf8mb4

Remarque importante : il faut absolument traiter toutes les tables.

Deuxième remarque : un SPIP mal configuré (créé il y a plusieurs années en utf8, mais sur une base en latin1) accepte parfaitement les emoji !

 ?

ben j’ai fait comme indiqué ci-dessus, en profitant que j’étais réveillé à une heure tardive :)

@speciale note bien qu’avec les tout derniers commits sur le trunk, les prochaines versions de SPIP sauront contourner le problème
▻http://core.spip.org/projects/spip/repository/revisions/21939
▻http://core.spip.org/projects/spip/repository/revisions/21940
(reporté également en branche SPIP 2.1)

pour activer ce fonctionnement, il faut pour l’instant ajouter dans mes_options la ligne suivante :
define('_MYSQL_NOPLANES', true);

 ?

 ?

à noter, les gens de wordpress en arrivent aux mêmes conclusions que nous, avec :
▻http://wptavern.com/wordpress-4-2-on-track-to-expand-core-support-for-emoji
▻https://make.wordpress.org/core/2015/02/13/emoji-chat-meeting-notes-february-12-2015
et
▻https://github.com/twitter/twemoji

(pour ma part je m’arrête là)

est ce que ça fonctionne avec le moteur de recherche ? ;-)

#spip_blog

Le truc qui m’intéresse particulièrement là-dedans, c’est normalise.css (pour ma pratique, je trouve que reset.css est une véritable plaie).

necolas/normalize.css - GitHub
►https://github.com/necolas/normalize.css

Normalize.css is a customisable CSS file that makes browsers render all elements more consistently and in line with modern standards. We researched the differences between default browser styles in order to precisely target only the styles that need normalizing.