Si pendant un moment j’ai fait l’erreur de ne pas le tenir trop à jour (j’ai du commencer avec une 1.0.7 ou 8), depuis que la mise à jour en 1.1 a été faite les mises à jour sont un plaisir, avec un simple click tout bête. J’espère que la version 2 passera vite l’étape de la release candidate, et que l’upgrade sera aussi aisée ! Un choix de forum à recommander en tous cas, une équipe de développement super active, un beau produit, certes pas une licence libre mais gratuit quand même, et une API intéressante pour la gestion des utilisateurs mais j’en recauserai j’espère.

Problème résolu en deux requêtes au lien d’une avec un UPDATE IGNORE suivi d’un DELETE sur le ida remplacé dans ab.

en résumé :

a:

+------------+
+ id | value |
+----+-------|
| 1  | abc   |
| 2  | def   |
| 3  | ghi   |
+----+-------+
b:
+------------+
+ id | value |
+----+-------|
| 1  | pip   |
| 2  | xzu   |
| 3  | mni   |
+----+-------+

et l’association ab

+---+---+---+
|id |ida|idb|
+---+---+---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 2 | 1 |
| 4 | 2 | 3 |
| 5 | 3 | 2 |
| 6 | 3 | 3 |
+---+---+---+ UNIQUE(ida,idb)

Si je veux remplacer les ida 2 de ab par 1, je fais

UPDATE ab SET ida=’1′ WHERE ida=’2′

mais MySQL va me renvoyer à la gueule que j’ai la clause unique rapport par exemple à la ligne 3. Ce que je voudrais faire c’est

UPDATE ab SET ida=’1′ WHERE ida=’2′ ON DUPLICATE DELETE

qui n’existe pas donc

UPDATE IGNORE ab SET ida=’1′ WHERE ida=’2′

bon ignore c’est pas du tout clean ok… suivi de

DELETE FROM ab WHERE ida=’2′

car les ida=’2′ qui restent sont forcément des duplicata.

Trivial, oui sans doute, mais bon ça fera peut-être gagner 10 mn à quelqu’un !

Pour ceux qui comme moi ne connaissaient pas : supposons que j’ai

A:

+------------+
+ id | value |
+----+-------|
| 1  | abc   |
| 2  | def   |
| 3  | ghi   |
+----+-------+

B:
+------------+
+ id | value |
+----+-------|
| 1  | pip   |
| 2  | xzu   |
| 3  | mni   |
+----+-------+

et l’association AB

+---+---+---+
|id | ia| ib|
+---+---+---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 2 | 1 |
| 4 | 2 | 3 |
| 5 | 3 | 2 |
| 6 | 3 | 3 |
+---+---+---+
SELECT *,GROUP_CONCAT(ib) FROM A,AB WHERE A.id=AB.ia GROUP BY A.id

et direct on peut récupérer des lignes façons

1,"abc","1,2"
2,"def","1,3"
3,"ghi","2,3"

en schématisant un peu pour le résultat parcequ’en vrai ce sont des blobs donc pas de taille infinie mais bon dans le contexte où je bosse là ça colle.

Le lien vers la doc

Le site ukulele.fr doit évoluer sous peu. Au programme, plus de pages, plus de rubriques, mais toujours les actualités.

Dotclear 1.2 qui y est en place depuis 5 ans n’est plus tellement adapté.

J’exclus toutes les usines à gaz façon Drupal ou joomla, disproportionnées et mal adaptées. Par contre WordPress me semble assez bien – pas des plus légers mais complet et pratique justement pour ajouter des pages etc…

Avez-vous des expériences pour le skinner ? pour migrer un dotclear 1.2 vers WP ? Des suggestions d’alternatives ? Est-il possible d’intégrer simplement des modules php externes qui peuvent aussi tourner indépendamment ? Ou alors plutôt faire un CMS simplifié qui affiche juste un moteur de blog pour les actus (lequel ?) et les autres modules ? Ça existe ?

Dans les choses que j’aimerais bien faire par exemple – que je n’ai pas pris le temps de faire avec dotclear mais à peine esquissé – il y aurait l’idée d’utiliser la base d’utilisateur de SMF (que je compte garder comme forum) pour les commentaires du blog, et pour d’autres parties à venir du site (parceque la gestion des utilisateurs de SMF est vraiment pas dégueu et a une API sympa). Si ça vour parle suggestions bienvenues en commentaires ou par mail.

Bien sûr j’aurais pu faire un système d’indexation imitant les tags mais je trouve ça fastidieux et puis les tags sont là. Donc il faut la recherche sur le texte via mysql. Du coup le texte entrée doit être débarrassé des balises html, et puis tant qu’on y est de la ponctuation et de tous les signes non alphanumériques et des chiffres (sans garder non plus tous les nombres au sens large unicode du terme mais ce serait éventuellement modifiable pour un portage en chinois ? maybe).

bref ça donne ce bout de code il est vrai carrément trivial mais qui dépannera peut-être quelqu’un de pressé :

function bareText($text) {
	// les majuscules/minuscules ne serviront pas :
	// > tout en bas de casse
	$newtext = strtolower($text);
	// on se débarrasse aussi des retours à la ligne éventuels
	// en les remplaçants d'abord par du html
	$newtext = nl2br($newtext);
	// puis on dégage tout ce qui est balise html
	// noter qu'on remplace par un espace pas par rien
	$newtext = preg_replace('/<([^<>]*)?>/uims',' ', $newtext);
	// ceci fait on retraduit les entités en texte régulier
	$newtext = html_entity_decode($newtext,ENT_QUOTES,"UTF-8");
	// avant de supprimer tous les caractères non alphanumériques
	// c'est à dire pas des lettres (p{L}) ni des chiffres ([0-9])
	$newtext = preg_replace('/[^\pL0-9]/uims',' ',$newtext);
	// comme on a rajouté plein d'espaces
	// on les condense :
	$newtext = preg_replace('/\s+/uims',' ', $newtext);
	// du blanc au début ou à la fin ? à dégager
	$newtext = trim($newtext);
	// c'est prêt !
	return $newtext;
}

Pourquoi remplacer par des espaces quand on pourrait remplacer par rien en supprimant ? Hé bien par exemple si on a :

<p>Paragraphe 1</p><p>Paragraphe 2<br />peut-être</p>

qui devrait s’afficher :

Paragraphe 1

Paragraphe 2
peut-être

il serait « nettoyé » en : Paragraphe 1Paragraphe2peutêtre

Ce qui serait loin de l’objectif ! Alors que avec la fonction ci-dessus on obtient bien :

paragraphe 1 paragraphe 2 peut être

bien plus approprié pour le futur

Nettoyage de code en route !

bonnes notes à prendre : la DB est déjà UTF8, la partie client aussi, juste quelques précautions à prendre côté php, ne pas oublier l’option u  dans les regexp !

Comme je ne peux pas demander à mes corédacteurs d’apprendre le HTML et que j’utilisais moi même le mode wiki, j’ai dû leur faire un peu de rapide formation. Bilan : la syntaxe wiki est facile, c’est passé bien même avec des utilisateurs carrément pas tech-savy, mais néanmoins ça laisse un arrière goût de « je ne comprends pas trop ce que je fais ça passe quand même », avec des ajouts involontaires (double retour chariot qui deviennent un <p> html etc). Rien de grave mais pas satisfaisant.

Donc pour le back office de éphémérid, je veux un bel éditeur HTML. Tour rapide de l’existant : FCKEditor (bientôt CKEditor), TinyMCE, WYMEditor. Pour le reste, trop fancy, pas assez mature, pas assez documenté.

Mon besoin est simple : un éditeur de texte avec des options très basiques, gras, italique, souligné, strikethrough, bullet list, listes à nombres, hyperliens, et éventuellement je garde la possibilité de lier des images (même si je pense plutôt gérer les médias séparément et les lier aux textes par ailleurs afin de contrôler la vue finale).

Constat : la plupart (tous) les éditeurs de texte choisis sont des usines à gaz qui gèrent trop de choses par rapport à mon besoin. Partant de l’idée que qui peut le plus devrait pouvoir le moins je me lance – en sachant d’avance que je serai déçu sur le chemin.

J’opte pour TinyMCE, utilisé par pas mal de CMS, développement sérieux, API claire, customisation apparemment facile, intégration qui ne parasite pas le framework choisi, bonne documentation. Il existe une application non libre des mêmes développeurs pour éventuellement la gestion des images et une autre open source. Hélàs, je déchante. Très lourd (le temps de chargement est ignoble), sa très bonne API ne suffit pas à me le faire garder. Très chargé, manque de souplesse, les contrôle de son apparence ne sont pas clairs.

Ensuite WYMEditor : à priori une philosophie parfaite pour ce genre d’outil. Il est par nature limité (pas de choix de polices ou autres aberrations pour un back office possible), propose quand même de gérer éventuellement des images, etc… Première grosse déception, il utilise Jquery qui est sans doute très bien mais qui n’est pas le framework que j’ai choisi. Pas très grave (hormis la lourdeur) puisqu’il peut cohabiter sans souci avec Prototype. Ça fait un peu râler quand même. Installation et déploiement : premier essai ça va – j’en profite pour nettoyer un peu ma CSS que j’ai faite par dessus la jambe en évitant que mes div se chevauchent etc… Et j’essaie de customiser la chose. Là c’est la débacle : la doc est indigente et toutes les modifications sont d’ignobles bidouilles indignes ! Il faut taper dans les styles pour désactiver des options, pas de méthodes intégrées, du bricolage qui mélange le HTML, les CSS et les scripts pour les mises en page – c’est ce que préconisent les développeurs eux-même (qui répondent essentiellement par « regarder les exemples – le code source hein, il n’y a rien de bien détaillé). Une horreur d’autant plus décevante qu’elle est à l’opposée du module lui même ! Exit donc les infâmes bidouilles de WYMEditor qui n’est utilisable que si on le prend out of the box (ce qui ne me va pas). Exit aussi tout ce qui ne sera pas correctement documenté.

CKEditor je tente rapidement, mais version RC (utilisable et fonctionnelle quand même), absence de doc (normal le produit n’étant pas en version production), alors que l’API semble très chouette elle n’est pas du tout documentée. Dommage.

FCKEditor la version précédente : je prends, il a un peu des défauts et des qualités des précédents. La doc est bien comme TinyMCE. Il n’est pas d’une souplesse terrible et il faut un peu bricoler – la config ici, le lien là -mais ça marche. Il n’a pas la beauté de la simplicité de WYMEditor (en utilisateur s’entend) mais on peut le brider. Pour le moment ce sera donc FCKEditor. Reste à voir comment il s’intégrera dans la suite du dév.

Bilan de ces essais : si quelqu’un est dans le développement de ce genre d’outil, qu’il pense simplicité et pérennité ! Il faut un outil qui marche sur tous les browsers, qui ne cassent pas avec les changement de version, qui reprenne les bonnes idées de WYMEditor avec la possibilité de contrôler simplement l’aspect, avec une API riche et efficace surtout,où une ligne de code permette d’ajouter ou d’enlever des boutons ou de rajouter des fonctionnalités ! Il ne faut pas des machines à tout faire qui imitent des traitements de textes, c’est le défaut de tous ces éditeurs à l’exception de WYMEditor, ce sont de mauvais clônes de Word – donc ils n’ont rien à faire dans les back offices des CMS ou des blogs.

Et ceux qui veulent faire un traitement de texte en AJAX n’ont qu’à aller voir chez GoogleDocs !

J’ai une vague idée pour le front, mais finalement on s’en branle je sais que ce que je produis sera facilement utilisable, et le cahier des charges étant assez simple je peux me lancer avec cette simple vague idée.

Pour le back office du tout venant, avec pour moi cette nouveauté de finalement utiliser AJAX, donc requête et tutti cuanti… nouveauté toute relative puisque c’est exactement comme ça que je codais en actionscript, en plus simple ! Aujourd’hui avec tous les bons exemples d’applis on line (chez google en particulier) on a de suite les bons réflexes.

Après il faut savoir éviter les mauvais plis. Je n’ai pas besoin d’utiliser une librairie à la scriptaculous pour faire des fondus de transparence, parceque je n’ai pas besoin de transition. Exit donc ces apparitions que mes mauvaises habitudes de flasheur me font toujours regarder (et une heure de dev perdues du coup mais bon). Je la garde sous le coude parcequ’il y a peut-être quelques trucs efficace pour l’usability comme disait le désagréable Jakob Nielsen – qui a toujours fait croire qu’il était révolutionnaire en disant les évidences avec deux trains de retard.

Donc je me perfectionne un peu en CSS toutes carrées, en js, dans la librairie prototype.js, dans les aller retours AJAX style, et l’utilisation du browser comme un environnement d’exécution d’applications.

Et aussi je me débarasse d’un vieux principe qui m’a fait perdre des journées : j’arrête de réinventer la roue, en ne me resservant pas de mes bibliothèques parceque pas assez « dans le vent » et en n’utilisant pas les choses toutes faites – j’arrête l’open source à sens unique du coup et je me sers aussi.

Et les problèmes commencent

Quelques choix déjà pris et pourquoi :

- Pas de flash : parceque j’ai fait ça exclusivement depuis huit ans pour toutes les parties clients des sites, donc lassitude, mais surtout parceque c’est une technologie dans laquelle je n’ai plus confiance. Pas confiance dans l’éditeur qui n’est pas capable de faire des versions utilisables de ses outils, pas confiances dans les bidouillages open source autour – parfois d’un niveau épatant quand même mais bidouillage non par leur fabrication, mais par la nature de la plateforme, qui évolue trop vite au gré des modes et qui se trouve aujourd’hui limitée à lire des videos dans des environnements HTML/JS. Pas confiance non plus dans l’insistance à ne pas suivre les standards. Pas utile car ce qu’on ne pouvait faire qu’avec flash est largement faisable en Ajax dès qu’on ne parle pas d’animation riche et d’eye candies pour lesquels Flash reste insurpassable.

-PHP/MySQL/Apache : forcément incontournable trio, qui a fait ses preuves et dispo chez quantités d’hébergeurs, donc permettant une migration facile. En outre tout ce petit monde étant open source, le développement sera toujours récupérable d’une manière ou d’une autre.

- AJAX : nouveauté pour moi, mais on voit tellement de bonnes choses, et c’est tellement familier, et surtout je peux continuer à coder des choses rapidement pour de petites applications sans rentrer dans des frameworks imbitables.

- En parlant de framework justement : je découvre Prototype.js dont la philosophie m’est assez familière (et que je t’étends allègrement les namespace existants) qui est proche aussi de la philosophie « développement rapide » inhérente à javascript, sans s’empêcher de faire les choses proprement.

- Du coup pour les échanges clients/server ce sera JSON, côté client c’est pris en charge pas le framework Prototype.js, côté serveur ce sera du fait main le temps de me bricoler un parser approprié en PHP (grave manque de ce côté là dans l’open source, rien de facile à utiliser dans un simple include, je ne veux pas entendre parler de PEAR). JSON aussi parceque du XML j’en ai fait plus qu’assez, donc passons à autre chose, que malgré l’aspect un peu dégueu de la spec remplie de guillemets c’est rapide à déployer et plus lisible que du XML, et parceque du XML je m’en fade avec le DOM de toutes façons.