Mysql : champs tronqués après apostrophes ou tirets

Des données de type nom ou adresse entrées dans une table mysql comportent souvent des apostrophes ou des tirets.

Même si elles ont été entrées correctement dans la table, elles apparaissent tronquées lorsqu’on les rappelle à l’intérieur d’un champ input (pour modifier l’ensemble des données par exemple).

Exemple : <form method=’post’ action=’modifier.php’><input type=’text’ size=’10′ name=’Adresse’ value=’”.$row[3].”‘>
<input type=’submit’ value=’Mettre a jour’></form>

Solution trouvée (en faisant abstraction des divers commentaires lus sur les forums qui nous font nous perdre entre problème de sécurité et commandes obsolètes).

La solution, tout convertir en html que ce soit lors de la première entrée dans la table :
$Adresse=htmlentities($Adresse, ENT_QUOTES);
Cela implique de prévoir des champs bien plus grands dans la table car le code html d’un caractère comporte bien plus de caractères que le caractère lui-même (ex : é=&eacute; prend 8 fois plus de place !)

ou au moment de la modification des données :

$query=”UPDATE $Table SET
Adresse=’”.htmlentities($Adresse, ENT_QUOTES).”‘, etc…

En plus, il semble que ce soit une bonne chose pour la sécurité informatique !
Remarque : les 3 guillemets c’est un guillemet simple suivi d’un guillemet double (l’inverse pour fermer).
Remarque encore : le ENT_QUOTES permet de convertir également les guillemets (simples ou doubles en leur code html).

Simple utilisation de Simplepie

Je voudrais simplement afficher quelques flux RSS sur un blog WordPress, en français, anglais, arabe et hébreux.

Simplepie, qui traite les problèmes d’encodage, est donc la solution de choix.

Pour pouvoir modifier le code de mon blog wordpress, il faut bien évidemment qu’il soit installé chez mon hébergeur, et non pas chez WordPress.com.

J’ai donc téléchargé la toute dernière version de WordPress : 2.3.2. qui, me semble-t-il, n’est pas encore traduite en français, et je l’ai installée en 5 minutes.

J’ai téléchargé la toute dernière version de Simplepie : Simplepie 1.1 (attention, il semble qu’elle utilise PHP 5 uniquement).

J’ai pas mal tâtonné pour savoir où placer simplepie.inc, parce que j’allais devoir l’utiliser dans un template wordpress qui est enfoui dans l’arborescence des fichiers. Finalement, je l’ai mis dans la racine du site, avec l’index.php de mon WordPress, qui ne fait qu’appeler les différents éléments du template.

Du coup, j’ai dû créer le dossier cache directement à la racine de mon WordPress également. J’ai fixé les droits d’écriture (chmod à 777). Il restait à mettre les fichiers de simplepie au bon endroit, et j’ai donc transféré tout le dossier idn à la racine de WordPress. Je conseille vraiment de ne pas modifier l’emplacement du cache, car il est appelé de très nombreuses fois par simplepie.inc. Les dossiers cache et idn doivent donc être dans le même répertoire que simplepie.inc.

Ensuite, pour lancer simplepie, j’ai pas mal bataillé avec les tutoriaux du site (problèmes de fonctions non définies, de noms d’objets incorrects…). J’ai fini par m’en sortir en prenant le code dans le dossier de demo qui est dans le package Simplepie (au moins ce code est cohérent avec lui-même).

J’ai donc copié de grands passages de multifeeds.php et ça a fini par marché…

Juste une remarque, il faut modifier le chemin de simplepie.inc :

require_once(’simplepie.inc’);
require_once(‘./idn/idna_convert.class.php’);

Sauf que, avec tout ce temps perdu, je n’ai pas réussi à définir le nombre d’éléments de chaque flux à agréger. J’adopte temporairement la solution de traiter chaque flux séparément.

foreach($feed->get_items(0,1) as $item):

(modifier les paramètres entre parenthèses, c’est tout ce que j’ai trouvé pour l’instant pour ne faire afficher qu’un seul item par flux)

et je ne sais toujours pas non plus comment limiter la longueur du texte agrégé.
Il me vient à l’esprit que le plugin SimplepieWP, permettait de faire tout cela avec le sourire.
A suivre… (la semaine prochaine, ça se fera peut-être en 5 minutes…).

Ah oui, pour voir le résultat (pour l’instant un seul flux agrégé), c’est ici.

Smart RSS

Après vérification Smart RSS permet bien d’importer un flux RSS par article dans un blog WordPress.

J’ai un peu bataillé vu la maigreur des instructions sur la page destinée à ce plugin : http://www.devplug.net/smartrss-plugin/

Encore une fois je ne remercie pas le commentateur (Night Angel) bien intentionné qui m’a montré que ce que je cherche à faire est disponible depuis juillet 2006 déjà !

J’ai donc téléchargé le plugin, je l’ai activé dans la page Plugins de mon wordpress, et j’ai déplacé le fichier wp_smartrss.php à la racine de WordPress comme il était prescrit. J’ai ensuite essayé de lancer wp_smartrss.php, et j’ai obtenu une page blanche.

C’est tout à fait par hasard que aujourd’hui, j’ai découvert que SmartRSS était passé dans le menu options de mon wordpress, et que c’est là qu’on entre les flux RSS que l’on veut importer. Et lorsqu’il y a des flux à importer, miracle, il suffit de lancer wp-smartrss.php pour commencer l’importation. La page n’est plus blanche.

Jusque là l’encodage a l’air parfait. Une table est créée dans la base de données avec la liste des flux, j’ai donc pu insérer les 140 flux grâce à l’importation d’un fichier excel (csv) dans la table.

Bon, il y a quelques petites imperfections, l’affichage ne comprend pas le nom du blog d’origine ce qui est un peu génant. Et puis, je n’ai pas encore compris comment programmer une “tâche en cron” (ouais j’apprends des langues) pour que l’importation soit automatique, et on va voir aussi comment se passent les importations successives.

Et enfin mon hébergeur n’accepte pas les contenus politiques !

Et finalement, oui il y a encore moyen de s’amuser avec Simplepie pour me faire mon Smart RSS à moi.

Comment utiliser Simplepie ?

C’est simple, Simplepie, il suffit d’y croire. J’ai dû pêcher par manque de foi.

Voici les erreurs que j’ai commises :

1- J’ai téléchargé le package et j’ai créé sur le serveur un dossier php et un dossier cache, mais j’avais mal lu, le dossier cache doit être dans le dossier php. (d’où j’avais des erreurs du type cannot write cache). J’ai fixé les droits d’écriture de mon dossier cache (chmod à 777) et ça marche. Pour d’autres c’est chmod à 755.

2- J’ai longtemps cherché un fichier exemple pour lancer simplepie. Finalement je l’ai trouvé dans le dossier demo, c’est multifeeds.php. Il est bien documenté et il suffit d’y changer quelques paramètres, comme par exemple y entrer la liste des flux RSS que l’on veut agréger.

3- Il faut faire hyper attention au chemin des fichiers qui sont appelés par le script. Par exemple require_once(‘./simplepie.inc’); Dans le même registre, je n’avais pas d’affichage d’images tant que je n’ai pas modifié ce chemin dans le fichier handler_image.php.

4- L’encodage: j’avais de méga problèmes d’encodage car j’essayais de lire les fluxRSS à partir d’une base de données mysql. Les textes m’apparaissaient en hiéroglyphes d’une langue encore inconnue de moi. C’est là que je me suis aperçue que ma bdd était en latin_swedish, mais même si je la passe en UTF-8, le problème persiste. C’est un grand mystère.

5- Pour l’instant, je suis tellement content de voir un agrégateur aussi beau, que je vais lui donner les flux de la liste freemen à la main.

6- L’étape suivante est l’import dans WordPress, il existe un plugin mais ça demande tout de même de mettre les mains dans le camboui.

7- Pour avoir un aperçu du résultat qui m’a pris 15 jours au lieu de 30 minutes, c’est ici.

8- Ah oui, j’oubliais, merci Christophe.

Problèmes d’encodage

Après avoir cherché un bon moment comment examiner la déclaration XML des flux RSS qui comporte l’indication de l’encodage (ISO-8859-1 ou UTF-8), je me suis penchée sur le code de MagpieRSS et je me suis aperçue qu’il n’était pas besoin de réinventer le fil à couper le beurre, MagpieRSS s’est déjà penché sur le problème. J’ai conclu qu’il renvoie du ISO-8859-1 (mais le logiciel date de 2005) et j’ai essayé de changer pour UTF-8 sans améliorer le rendu de l’agrégateur.

Il ressort que WordPress et Dotclear sont encodés en UTF-8 et qu’ils sont pour l’instant minoritaires dans la liste des blogs que je veux agréger. Donc pour le meilleur rendu, il faut afficher la page php de l’agrégateur en ISO-8859-1, ce qui laisse les textes UTF-8 avec des ? à la place des apostrophes. Bah, c’est presque lisible.

Prochaines étapes, regarder à nouveau le code de MagpieRSS pour voir ce qui cloche, et chercher un autre agrégateur qui serait plus adapté à notre langue accentuée…

Ouliblog semble avoir résolu le problème, l’affichage est impeccable. Mais l’agrégation est distante, or je voudrais sur les traces d’Antoine ramener le flux vers un blog pour pouvoir commenter les articles. Coup de chapeau à Antoine en passant.

PHP permet d’écrire du XML

Dès lors qu’on dispose d’une liste dans une base de données, on peut utiliser PHP pour générer le fichier OPML de la liste.

On peut l’écrire dans une page web en utilisant des encodages pour les guillemets et les signes > et < < > & etc… Une liste fort utile des codes est présente ici.

Mais on peut aussi l’écrire dans un fichier, et ça c’est super-fort.

Pour cela, on va utiliser son logiciel ftp, par exemple Filezilla.

On va créer un fichier que l’on transfère sur le serveur par Filezilla et auquel on donne des droits d’écriture (chmod à 777, ça fait super-pro). Cela veut dire qu’on va (dans attributs du fichier, en cliquant droit sur le fichier) cocher toutes les cases permettant à tous d’éditer, de voir et de modifier le fichier.

Ensuite il suffira dans le fichier php d’ouvrir le fichier, d’écrire dedans, puis de le fermer.

Fabuleux, non ?

On commence à entrevoir ce que peuvent bien faire les hackers…

Encodage UTF-8 et ISO

Erreur principale : le problème d’encodage. Chaque fois que vous voyez des hyéroglyphes dans un email, dans une page web ou sur un blog, c’est un problème d’encodage. Les anglo-saxons ont sans doute moins de problèmes car ils n’ont pas de caractères accentués. L’encodage, c’est la galère, et je n’ai pas encore trouvé de bonne solution.

Le fichier XML comporte toujours une déclaration avec l’encodage charset= (soit UTF-8 soit ISO-8859-1). J’ai encore beaucoup à lire sur ces histoires d’encodage, notamment sur Wikipedia. Si les données proviennent d’une base de données, il faut s’assurer que l’encodage est le même pour la page Web et pour la base de données. Les caractères accentués font planter le fichier OPML à tous les coups.

Donc on peut les supprimer en les passant à travers un filtre :

exemple : $title=strtr(“$title”,”éèêàùôiœ”,”eeeauoioe”);