Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : Développement web

Après le blog, le Trac et après le Trac, le Twitter...

Guillaume Kulakowski

Après avoir changé le thème du blog, je me suis attaqué à celui du Trac que j'ai renommé en "Plateforme de développement" et passé sous le sous-domaine dev.llaumgui.com. En effet, je voulais une certaine cohérence entre le design du blog et celui de la plateforme de développement. J'ai donc entrepris de porter Emplode sous Trac, et là, force est d'avouer que le truc est assez déconcertant.

Le moteur de template de Trac est basé sur un système d'XSLT qui me fait comprendre la charge serveur d'un Trac ;-). En plus pour appliquer le nouveau thème, bien sûr, il faut redémarrer le serveur apache, normal quoi...

Bon, au final, ça surprend mais ça ne casse pas 3 pattes à un canard. Histoire d'aider ceux qui voudraient appréhender la customisation de Trac, je vous donne mon site.html commenté :

<html xmlns="http://www.w3.org/1999/xhtml"
     xmlns:py="http://genshi.edgewall.org/"
     py:strip="">

  <!--! Add site-specific style sheet -->
  <head py:match="head" py:attrs="select('@*')">
    ${select('*|comment()|text()')}
    <!-- Là, je rajoute ma CSS perso (dans htdocs) en plus des autres champs de head -->
    <link rel="stylesheet" type="text/css" href="${href.chrome('site/style.css')}" />
  </head>
<body py:match="body">
  <div id="page">
    <div id="top">
      <div class="wrapped">

        <!-- Login et préférences... -->
        ${navigation('metanav')}

        <!-- Formulaire de recherche... -->
        <form id="search" action="${href.search}" method="get">
          <div py:if="'SEARCH_VIEW' in perm">
            <label for="q">Search:</label>
            <input type="text" id="q" name="q" size="10" accesskey="f" value="Rechercher" />
          </div>
        </form>

        <!-- Là on va se servire dans trac.ini -->
        <h1><span><a href="${chrome.logo.link}">${project.name}</a></span></h1>
        <p id="blogdesc">${project.descr}</p>
      </div>
    </div>
    <div id="navigation">

      <!-- Le menu principale -->
      <div class="wrapped">
        <ul>
          <li py:for="idx, item in enumerate(chrome.nav['mainnav'])" class="${classes(first_last(idx, chrome.nav['mainnav']), active=item.active)}">
            ${item.label}
          </li>
        </ul>
        <br class="clear"/>
      </div>
    </div>

    <!-- Contenu -->
    <div id="inner">
      <div id="wrapper">
        ${select('*[@id="main"]|text()')}
      </div>
    </div>

    <!-- Pied de page -->
    <div id="footer" xml:lang="en">
      <div class="wrapped">
        <p class="left">
          Powered by <a href="${href.about()}"><strong>Trac ${trac.version}</strong></a> by <a href="http://www.edgewall.org/">Edgewall Software</a><br />
          Basé sur le thème Emplode par <a href="http://arcsin.se/">Arcsin</a>
        </p>
        <p class="right">${chrome.footer}</p>
      </div>
    </div>

  </div>
</body>
</html>

Maintenant il y a plus qu'à faire pareil sur le Trac de Fedora-Fr...

Comme j'étais parti sur ma lancée, j'ai aussi refait le design de mon profils Twitter.

dotclearRemember 2.0

Guillaume Kulakowski

C'est un peu plus de 3 mois après la sortie de la version 1.2 du framework javascript MooTools; que j'ai enfin pris le temps de migrer le thème de mon blog sous cette version.

J'en ai donc profité pour mettre à jour dotclearRemember. Pour ceux qui avaient loupé la version 1.0 de dotclearRemember, rappelons juste qu'Olivier Meunier, lead developper du projet Dotclear, a fait le choix de confier quelques actions du thème de base de Dotclear à la librairie jQuery. Affictionnados de MooTools, j'ai donc entrepris le portage de ces fonctionnalités vers cet outil et c'est ainsi que la fonctionnalité "Se souvenir de moi" (post.js) de Dotclear est devenu dotcleaRemember sous MooTools.

Au programme des réjouissances de cette version 2.0 :

  • Passage de MooTools 1.1.x vers MooTools 1.2
  • Utilisation de la class Class et nouvelle façon de passer les paramètres ainsi que d'initialiser le script
  • Fonction de débug

dotclearRemember 2.0 pour MooTools 1.2.
dotclearRemember 1.0 pour MooTools 1.1.x.

A propos du thème de ce blog, Nodoka, on remarquera que j'en ai profité pour laisser tomber mon script verif_form (qui ne sera pas porté vers la 1.2) pour passer sous Form.Check qui est tout bonnement génial. J'ai également profité de l'occasion pour céder à la mode des lightbox et pour installer Milkbox...

eZFluxBB 1.0 final

Guillaume Kulakowski

C'est avec beaucoup de plaisir que je viens de libérer le code d'eZFluxBB. Pour ceux qui auraient loupé les épisodes précédents, eZFluxBB est l'extension qui permet à Fedora-Fr d'utiliser conjointement le CMS eZ Publish avec le forum FluxBB.

Dès le début du projet, le code source était disponible sur mon trac et téléchargeable via SVN mais je n'avais pas encore pris le temps de faire un beau petit package avec documentation et tout le toutim.

Fedora-Fr utilise que du libre pour sa plateforme web et c'est avec satisfaction que nous libérons les développements internes. Je tiens aussi à remercier Emma, ma copine, qui ma bien aidé pour la documentation anglaise.

eZ Publish : activation vs forgotpassword

Guillaume Kulakowski

Il y a quelque chose d'étrange dans la façon dont eZ Publish gère l'activation de compte. En effet, si je crée un compte mais ne le valide pas, je ne peux pas faire une demande de renvoi du mail d'activation. Je peux cependant demander une re-génération de mon mot de passe via la fonction forgotpassword. Cette procédure demande, au préalable, une validation par mail, ce qui permet alors de vérifier le mail de l'utilisateur.
Me voila donc l'heureux propriétaire d'un compte dont l'email est validé, le mot de passe re-généré, mais qui est toujours inactif…

En annexe, je joins un petit patch pour remédier à cela. Je l'ai proposé sur les forums d'eZ publish, mais il ne semble pas déchaîner les foules…

Bien sur, le fait que l'utilisateur puisse réactiver son compte après une désactivation de ce dernier par l'administrateur, implique que la désactivation de compte ne soit pas une mesure de modération mais bien de (re)validation d'email. Pour modérer un bouletutilisateur, on créera alors un groupe à part avec des droits adéquats.

Fedora-Fr v4.1, étude de cas d'un site sous eZ Publish

Guillaume Kulakowski

Cela fera bientôt 3 ans que je travaille avec le CMS open-source eZ Publish édité par la société eZ Systems. J'ai débuté cette expérience dans la société Kaliop, et je la poursuis aujourd'hui, chez Logica.

Que ce soit en temps qu'expert, consultant ou développeur (« simple » ou référent), j'ai eu la chance de collaborer sur un grand nombre de projets différents utilisant cet outil. Des projets tels que des sites institutionnels (WWF, UM1), des (extra|intra)nets, des usines à sites, ou encore, dernièrement, un portail immobilier avec plus de 150.000 objets eZ (prévoyez 2 jours pour l'import sur un octo proc' ;-)).

Cependant, jusqu'à présent, mon utilisation d'eZ Publish s'était cantonnée au monde professionnel et je n'avais pas de site « personnel » (je mets entre guillemets car Fedora-Fr n'est pas un site perso, mais un site que je gère personnellement...) utilisant cette technologie. J'avais bien commencé le portage de Scénario-Paintball sous eZ, mais je suis toujours en attente d'une charte graphique (Rad' si tu me lis...).
Bref, la refonte de Fedora-Fr sous eZ arrivait à point nommé pour m'offrir un petit bac à sable pour toucher d'encore plus près l'outil, développer autour et reverser du code à la communauté.

Cette migration s'est faite en 2 temps; le premier, la bascule du Planet de Dotclear (+plugin planet) vers eZ; suivie dans un deuxième temps par le passage du site www.fedora-fr.org (le portail) sous eZ.

Le choix d'eZ

Comment s'est fait le choix d'eZ Publish ? Le premier choix qui a été fait à été celui de changer la structure d'avant qui souffrait de 2 problèmes majeurs :

  • Le premier venait du planet qui avait tendance à sauter des blogs voir même à arrêter l'indexation de ces derniers... Dotclear montrant ses limites, il fallait le changer.
  • Le deuxième problème venait de la structure même du portail de Fedora-Fr. C'était un portail 100% maison développé par mes soins, mais utilisant un grand nombre de fonctions PunBB. Je craignais que le passage à la 1.3 de PunBB (qui sera en fait la 1.3 de FluxBB) ne cause pas mal de problèmes et demande beaucoup de réécriture de code.

J'ai donc fait le choix de revoir ma copie et de ne plus faire un portail autour de PunBB mais de prendre un CMS déjà existant et de lui permettre de communiquer avec PunBB/FluxBB.

Mon bagage en eZ, ainsi que le fait qu'il correspondait parfaitement à nos besoins (notamment la fonction d'import/export de contenu via RSS), ont fait que c'est naturellement que je me suis tourné vers cette solution et que j'ai commencé le développement d'eZFluxBB.

eZFluxBB

A l'heure où j'écris ces quelques lignes (dans un Starbucks Parisien, la classe ;-)), eZFluxBB est disponible en version 1.O RC1 sur mon Trac. Il est parfaitement fonctionnel et il ne me reste qu'à faire la documentation : exportation de la doc francophone en PDF via Trac et traduction de cette dernière en anglais. Une fois que cela sera fait, eZFluxBB sera packagé et reversé à la communauté.

Bien définir le rôle de chaque outil

Lorsque j'ai commencé le développement de la nouvelle version de Fedora-Fr (v4.1) sous eZ Publish, j'ai délimité le rôle de chaque outil : FluxBB pour les forums et la gestion des membres; eZ Publish pour la partie publication.

Il n'est aucunement prévu de faire une synchronisation des membres eZ/FluxBB ni même de permettre au visiteur de Fedora-Fr de se connecter sur le CMS. Cependant, comme eZFluxBB est sous GPL, si la demande est là et si des volontaires sont motivés, pourquoi ne pas ajouter cette fonctionnalité à eZFluxBB : login handler / loginhandler ] + cronjobs côté eZ, hook côté FluxBB. Cependant, je ne pense pas l'activer sur Fedora-Fr.

Structure eZ mise en place sur Fedora-Fr

Les extensions

On est dans une architecture classique en eZ, à savoir : 1 site = 1 extension.
A cela, j'ai ajouté une extension dite socle permettant de regrouper certains design, les traductions et certains paramètres propres à tous les sites de Fedora-Fr en eZ.

Au extension typées sites, s'ajoute:

  • eZFluxBB : Communication FluxBB / eZ
  • MyUtils : Contient des fonctionnalités que je peux récupérer sur d'autres projets
  • ezrssfeed : Pratique pour afficher du contenu extrait de fils RSS sans avoir à le mettre en base
  • eZOE 5 : Pour finir, notons que j'ai fait le choix de partir sur la version 5.0 beta d'eZ Online Editor, l'éditeur de contenu d'eZ à la place du traditionnel ezdhtml (v4)

Les classes

Je ne vais pas décrire toutes les classes utilisées sur les différents sites. Je vais simplement dire que plutôt que de créer des classes spécifiques par typologie de contenu, j'ai fait le choix que toutes les pages soient de la classe page (ou website pour les pages d'accueil). Ensuite, j'inclus les différents blocs (qui eux sont des contenus spécifiques) via l'éditeur eZOE.

Edition de la page d'accueil du site

Je me suis même amusé à personnaliser le contentstructuremenu.ini.

Utilisation d'eZFlux dans l'administration d'eZ Publish

Les différents sites de l'instance eZ Publish

L'une des forces d'eZ est de pouvoir créer plusieurs sites à partir d'une seule instance de l'outil. Voila ce que ça donne sur Fedora-Fr (je fais un peu de teasing sur les prochains projets....).

Les différents site eZ Publish de Fedora-Fr

Concrètement, pour un professionnel, avec une bonne configuration des vhost apache, cela permet de confier tout son système d'information à eZ : site institutionnel, extranet et intranet , etc...

Planet

Comme écrit plus haut, le planet a été le premier sous-domaine à migrer sous eZ. Bien que la fonction d'importation des flux RSS d'eZ a l'air taillé sur mesure pour un planet, il souffre d'un manque de souplesse et elle m'aurait obligé à renseigner les flux RSS de chaque blog moi-même...

Comme je suis fainéant (c'est un avantage en informatique il parait), j'ai fait le choix d'étendre la classe utilisateur et de modifier le cronjobs rssimport.php en planet.php pour que ce dernier aille chercher les informations directement dans le profil des utilisateurs du groupe blogeur.

Edition de son profil Fedora-Fr

Le contenu de chaque billet est stocké dans un datatype Bloc-text, directement en HTML. Comme certaines versions de Dotclear utilisent des liens relatifs pour leurs smileys (ce qui invalide un flux, soit dit au passage) et que tous les blogs ne respectent pas les normes du W3C (je ne citerai pas de nom), cela m'a contraint à nettoyer les contenus avec quelques expressions régulières et à utiliser php-Tidy (yum install php-tidy, merci Remi).

Pour ceux qui seraient intéressés par mon, cronjob planet, il est disponible dans mon extension MyUtils téléchargeable sur mon Trac ou par svn.

WWW

Le portail est plus classique dans son développement, il s'agit en effet d'un site de présentation. Sa seule particularité est l'utilisation d'eZFluxBB pour récupérer les informations à partir de PunBB.

Démo d'eZFluxBB 1.0 RC1

Choix technologiques

Cache statique

Passer un site de la recette à la production est toujours cause de stress. En effet, il est toujours difficile d'apprécier la charge que va provoquer une nouvelle application avec 3.000 à 4.000 utilisateurs quotidiens (quoi qu'il existe des logiciels pour ça). Les développeurs d'UbuntuUser.de en ont récemment fait les frais.

En terme de performance, la référence était pour moi le site précédent. Basé sur PunBB, pas complètement POO ce qu'il faut le dire lui confère des pages servies en moins de 0,05s. Malheureusement, malgré tous les caches possibles et toutes les optimisations de développement envisageables, eZ, de par sa richesse fonctionnelle, n'arrivait pas à de tels scores. J'ai donc entrepris des tests de cache statique sur le planet. Les tests m'ont convaincu et j'ai mis en œuvre cette technique également sur le portail.

Concrètement qu'est-ce que le cache statique ?

Avant de servir la page, Apache va aller vérifier si elle existe dans un répertoire de cache. Si c'est le cas, il servira une simple page HTM, sinon, il servira une page issues d'eZ Publish. Le gain de performance est conséquent puisqu'on ne sert plus des pages php mais de simples pages HTML sans aucun calcul.

## Cache static
RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$
RewriteCond /path/to/ez/static/fedora_portail/index.html -f
RewriteRule ^/$ /static/fedora_portail/index.html [L]

RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$
RewriteCond /path/to/ez/static/fedora_portail/index.html -f
RewriteRule ^$ /static/fedora_portail/index.html [L]

RewriteCond %{REQUEST_METHOD}      !^POST$
RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$
RewriteCond /path/to/ez/static/fedora_portail$1/index.html -f
RewriteRule ^(.*)$ /static/fedora_portail$1/index.html [L]
RewriteRule !\.(gif|css|jpg|png|jar|ico|js)$ /index.php

Limitation

Comme il n'y a plus d'opérations php, la page est la même pour tous. Ça ne dérange pas sur le planet, mais sur le portail, la barre d'utilisateur de PunBB est confiée à une requête AJAX (voir plus bas).

Le bug #9126 faisant que le cache d'eZ se regénérait à partir de la version déjà en cache, cela m'a contraint à mettre quelques fichiers d'eZ 4.0 à jour par rapport à la version 4.0.1.

L'utilisation du cache statique sur Fedora-Fr

Fedora-Fr ne confie pas la régénération du cache statique à eZ Publish. En effet, la page d'accueil possède des contenu indépendants d'eZ et le planet également. J'ai donc fait le choix via cronjobs de mettre à jour le planet toutes les heures et la page d'accueil toutes les 5 minutes.

# Planet
0 * * * * cd $EZPUBLISHROOT && $PHP runcronjobs.php planet -q 2>&1 /dev/null; $PHP bin/php/makestaticcache.php -s $PLANET -f 2>&1 /dev/null

# Portail
*/5 * * * * cd $EZPUBLISHROOT && $PHP bin/php/makestaticcache.php -s $WWW -f 2>&1 /dev/null

MooTools

Fedora-Fr embarque la librairie MooTools dans ça version 1.2. Son utilisation est essentiellement due à 2 points :

  • L'événement domready qui comme le montre la démo, est bien plus rapide que le classique onload. Cet événement permet notamment de gérer les requêtes AJAX avant le chargement total de la page ce qui fait que vous ne voyez presque pas que la page se charge en 2 temps.
  • L'autre raison est une volonté d'aller plus vers le web 2.0 (même si je n'aime pas ce terme) avec l'utilisation d'info-bulles plus riches en informations et bien d'autres évolutions qui seront visibles avec l'arrivée de FluxBB 1.3.
window.addEvent('domready', function(){
       
        /* Récupération du brdwelcome en AJAX */
        if ( $('brdwelcome') && $('brdwelcome').hasClass('ajax')) {
                // Requète AJAX en 1 ligne...
                $('brdwelcome').load( ezroot + 'ajax/brdwelcome.php');
        }
});

Design

La façon dont les designs sont gérés sur Fedora-Fr diffère quelque peu des sites eZ classiques. En effet, après avoir hésité avec une utilisation classique conjointe à l'emploi d'ezoescript et ezoecss, j'ai fait le choix de conserver la structure de Fedora-Fr actuelle. A savoir, utiliser un sous domaine (common) pour les javascripts, les images et les feuilles de styles.

Fedora-Fr sous Firebug

Cela permet, par exemple, de ne télécharger qu'une fois la librairie MooTools (60Ko normalement mais 19Ko une fois compressée) pour le portail et le planet. Ça me permet aussi d'avoir toutes mes feuilles de styles et mes javascript à un seul endroit et de les compresser facilement avec YUICompressor.

Et demain

Les projets futurs en eZ ?

  • Passer la Faq non-officielle sous eZ.
  • eZFluxBB 1.1 compatible FluxBB 1.3. D'ailleurs, je travail actuellement sur la nouvelle version du forum utilisant FluxBB 1.3.

eZFluxBB 1.0 RC1

Guillaume Kulakowski

Je viens à l'instant de compléter la version 1.0 RC1 de eZFluxBB : le connecteur PunBB / FluxBB et eZ Publish. Pour plus d'information sur eZFluxBB vous pouvez vous reporter à mon précédent billet.


eZFluxBB : Quand eZ Publish se connecte à FluxBB / PunBB

Guillaume Kulakowski

Étape n°2 de la migration de Fedora-Fr vers le CMS open source eZ Publish : après le planet, c'est au tour de l'accueil d'amorcer son virage sous eZ...

Pour le moment rien n'est visible en prod', mais j'ai commité ce week-end un début d'extension permettant à eZ Publish de récupérer des informations issues de PunBB / FluxBB.

Actuellement, cette extension eZ ne fait pas grand chose, puisque que la seule action possible et un fetch current_user permettant de récupérer les informations sur l'utilisateur courant.

Première version d'eZFluxBB

Ce qui reste à faire :

  • fetch sur les topics (derniers topics, extraction de news, etc..)
  • fetch sur les stats
  • fetch sur les utilisateurs en ligne
  • Rendre le code de ma classe eZFluxBBDB moins ridicule et lui permettre de connecter un eZ et un FluxBB sur des bases de données et des serveurs différents
  • Documenter !

Ce que l'extension ne fera pas :

  • Synchronisation des utilisateurs eZ / FluxBB.
    Mon choix est clairement de garder eZ pour de la publication et FluxBB pour la partie user input/ gestion de compte.

Utilisation d'eZFlux dans l'administration d'eZ Publish

A suivre...

ezoescript et ezoecss : 2 bonnes surprises dans ezoe

Guillaume Kulakowski

Pour ceux qui ont suivi mon précédent billet sur l'optimisation des javascripts, vous l'aurez compris : je suis sensibilisé à l'optimisation des sites web et notamment (entre autre) à la préconisation Yahoo! Developer Network :"Minify JavaScript and CSS". Cette préconisation suggère de réduire les CSS et les javascript en nombre et en poids. Dans le meilleur des cas, il faudrait donc n'avoir qu'une feuille CSS et qu'un fichier Javascript de poids raisonable.

Pour la migration du planet Fedora-Fr sous eZ Publish, j'avais pour intention de développer une extension eZ Publish intégrant un minifier JS/CSS. J'étais parti pour utiliser JSMin qui, certes est moins puissant que YUI ou packer mais qui offre le double avantage d'être full php (YUI utilise JAVA) et surtout de ne pas trop altérer le source à grands coups d'eval (comme le fait packer).

Mais au final, j'ai fait le choix de ne pas utiliser le système de design d'eZ Publish et de continuer à stocker le design (CSS, images, JS) de chaque sous-domaine (www, planet, forums, doc, etc..) dans un sous domaine commun (common). Au final, que vous soyez sur le planet, l'accueil ou sur les forums de fedora-fr, vous ne téléchargerez qu'une fois les images et les feuilles de styles.

Bref, comme vous l'aurez compris, j'avais laissé tomber la chose... Puis en furetant dans le code source de la future version d'online editor : ezoe pour les intimes; je suis tombé sur la classe ezoepacker. À la lecture du templateautoload j'ai déduit qu'ezoe proposait 2 opérateurs de template forts sympatiques : ezoescript et ezoecss.

Pour faire court, ezoescript et ezoecss remplacent la syntaxe classique d'eZ, qui avait pour résultat de multiplier les CSS et les JS :

{section name=JavaScript loop=ezini( 'JavaScriptSettings', 'JavaScriptList', 'design.ini' ) }
<script language="JavaScript" type="text/javascript" src={concat( 'javascript/',$:item )|ezdesign}></script>
{/section}

<style type="text/css">
{section var=css_file loop=ezini( 'StylesheetSettings', 'CSSFileList', 'design.ini' )}
    @import url({concat( 'stylesheets/',$css_file )|ezdesign});
{/section}
</style>

On notera au passage que contrairement à ce que préconise Yahoo, le JS est chargé avant le CSS...

Bref, tout ça est remplacé par :

{ezoescript(    ezini( 'JavaScriptSettings', 'JavaScriptList', 'design.ini' ),
                        true, 'text/javascript', 'javascript', 3 )}
{ezoecss(       ezini( 'StylesheetSettings', 'CSSFileList', 'design.ini' ),
                        true, 'all', 'text/css', 'stylesheet', 3 )}

ezoecss

ezoecss va récupérer toutes les CSS pour n'en faire qu'une. Cette dernière sera stockée dans le cache et sera de la forme 1 ligne par feuille CSS.

ezoescript

Malheureusement ezoescript n'est pas un vrai minifier JS au sens strict du terme. En effet, point de code sur une seule ligne ni de renommage des variables et fonctions. ezoescript se contente de supprimer les sauts de ligne et les commentaires avant de stocker le fichier en cache. L'avantage c'est qu'il ne présente aucune contrainte de codage pour fonctionner (jusqu'au niveau 2 du moins). J'ai cependant émis sur les forums la suggestion de le coupler à un vrai minifier et André R. ne semble pas fermé à ce genre d'idée...

Déçu de ne pas pouvoir faire joujou avec ces 2 opérateurs sur fedora-fr, je les ai utilisé sur un projet professionnel sur lequel j'avais une problématique forte d'optimisation. Je doit avouer être satisfait du résultat.

Remarque : Si vous utilisez les réécriture d'url, attention à rajouter les lignes qui vont bien dans votre virtualhost.

Charger des javascripts distants dans le "domready" de Mootools

Guillaume Kulakowski

Certains l'avaient peut-être remarqué, depuis quelques jours, le blog ramait grave ! Les symptômes : le bandeau, qui change selon l'heure de la journée, ainsi que différentes couleurs du site mettaient du temps à s'afficher.

La faute au script de Twitter qui ralentissait le chargement de la page et reculait d'autant l'évènement domready de MooTools.

C'est après avoir posé la question sur les forums de MooToos que la solution c'est offerte à moi : construire l'élément <script> qui appelle les javascripts de Twitter dynamiquement et dans le domready, c'est à dire une fois mon design en place.

J'ai pour cela mis en place une petite fonction sur laquelle vous pouvez vous appuyer :

/*
 * Mootools : onDOMReady
 *
 * Remarque : les actions prioritaires en premier.
-------------------------------------------------------- */

window.addEvent('domready', function(){

        var nodoka                      = new Nodoka();
        var scripts             = [     /* twitter */
                                                'http://twitter.com/javascripts/blogger.js',
                                                'http://twitter.com/statuses/user_timeline/llaumgui.json?callback=twitterCallback2&count=5"' ];
        /* [ . . . ] */
        nodoka.loadJS( scripts );
        /* [ . . . ] */
}); // EODR

/* [ . . . ] */

function Nodoka() {
       
        /* [ . . . ] */

        /*
         * Ajout des Javascripts distant
         * @author Guillaume Kulakowski <guillaume_AT_llaumgui_DOT_com>
         * @since 1.0.1
         */

        this.loadJS = function loadJS( scripts ) {
               
                scripts.each(function(src){
                        var loadJS = new Element('script', {
                        'src': src,
                        'type': 'text/javascript'
                        }).injectInside(document.head);
                });
        };

        /* [ . . . ] */
       
}; // EOC

Pimp my Dotclear Acte II

Guillaume Kulakowski

Dotclear 2.0 RC1 arrivant à grands pas, on continue avec les exemples de mise en œuvre de ce gestionnaire de blog simple et efficace.
Après la sécurité et l'optimisation de Dotclear, aujourd'hui : les rétroliens (ou trackbacks) et les plugins pour Dotclear qui vont bien. Vous pouvez, à ce propos, consulter la liste des plugins déployés sur ce blog.

Rétroliens et anti-spam

Les rétroliens sont un super outil permettant à la discussion de dériver et de se poursuivre ailleurs. Le problème est que les trackbacks sont trop souvent victimes du SPAM et les bloggeurs ont alors tendance à les désactiver (ce qui était mon cas jusqu'à il y a peu).

La solution, pour pouvoir utiliser les trackbacks sereinement : le plugin rétrocontrôle configuré pour effacer directement les rétroliens indésirables, sans passer par la case corbeille.

Filtre anti-spam dans Dotclear

Au passage, vous constatez que, pour le moment, ma configuration anti-spam est plutôt légère, j'ai donc encore des armes pour me défendre.

Configuration de rétrocontrôle

Je n'ai pas non plus activé l'option "adresses jetables" car je ne suis pas sûr de sa compatibilité avec le plugin Static Cache.

miniSEO :

Comme le montre ce calculateur (au résultat plus que discutable je vous l'accorde), le SEO du blog frôle la perfection (97%) et ce grâce, entre autres, au plugin miniSEO qui peut être couplé avec MyMeta comme le conseille l'auteur sur le billet de support.

MyMeta

Vous l'aurez peut être remarqué, une image illustre mes billets. Cette image est soit celle associée à la catégorie du billet, soit celle d'un tag. Pour cela j'utilise le plugin MyMeta :

Configuration du plugin MyMeta

Je peux ensuite appliquer à un billet une illustration en fonction d'un tag grâce à ce template :

<tpl:MyMetaIf type="tag-illustration" defined="false">
    <tpl:EntryIf has_category="1">
        <a href="{{tpl:EntryCategoryURL}}" class="category-illustration cat_{{tpl:EntryCategoryID}}" title="{{tpl:EntryCategory}}">&nbsp;</a>
    </tpl:EntryIf>
</tpl:MyMetaIf>
<tpl:MyMetaIf type="tag-illustration" defined="true">
    <a href="{{tpl:BlogURL}}tag/{{tpl:MyMetaValue type="tag-illustration"}}" class="category-illustration" title="{{tpl:MyMetaValue type="tag-illustration"}}" style="background: transparent url(/themes/nodoka/img/tag/{{tpl:MyMetaValue type="tag-illustration"}}.png) 0 0 no-repeat;">&nbsp;</a>
</tpl:MyMetaIf>

Pages

La révision #1729 de Dotclear introduit le plugin Pages remplaçant avantageusement le plugin Related que j'utilisais jusqu'à présent. C'est maintenant "Pages" qui gère les pages suivantes :

Notez au passage qu'avec une petite règle apache, le plugin Pages peut faire correspondre une page du blog à un sous domaine :

RewriteCond %{HTTP_HOST} ^cv.llaumgui.com
RewriteRule ^index.php$ index.php/pages/curriculum [L]

Subscribe to comments

En plus du flux RSS associé aux commentaires d'un billets, natifs dans Dotclear, le plugin Subscribe to comments permet à vos visiteurs de s'abonner par email aux nouveaux commentaires.

Pimp my Dotclear ;-)

Guillaume Kulakowski

Dotclear est un logiciel simple et léger permettant de créer son blog (comme ici) ou de mettre en place une plateforme de blog pouvant héberger plusieurs blogs comme c'est le cas sur la plateforme de blog de fedora-fr.

Optimiser Dotclear

Utilisation de connexions persistantes

Ludovic en parlait sur son Blog, les connexions persistantes sont à présent directement configurables depuis le fichier config.php de Dotclear :

define('DC_DBPERSIST',true);

Cache statique

Toujours en développement, le plugin staticCache est disponible via le dépôt SVN. Il permet de générer non pas du code php comme le fait le cache de template mais de stocker du code HTML qui sera directement rendu aux visiteurs de votre blog.

Pour l'activer, ça se passe encore dans le fichier config.php

define('DC_SC_CACHE_ENABLE', true );

Sécuriser son Dotclear

La première chose à faire pour sécuriser son Dotclear est de le mettre à jour. En effet, des failles de sécurité ont récemment étaient découvertes.

La gestion des uploads

Si vous êtes le seul à utiliser votre blog, la question se pose moins, mais si d'autres personnes utilisent le système d'upload, ils pourraient très bien envoyer des fichier php sur le serveur et les exécuter. Toujours dans le domaine de la supposition, ces fichiers pourraient permettre d'inclure le fichier config.php et d'en parcourir le contenu, dévoilant ainsi les mots de passe de la connexion à la base de données. Sur un serveur très très mal configuré, ces fichiers pourraient aller jusqu'à lire des fichiers du répertoire /etc/ !

Pas de panique : depuis la révision #1714, Dotclear permet d'exclure des extensions de fichier du gestionnaire de médias et ce via la directive media_exclusion du plugin about:config (plus d'infos).

Empêcher l'upload de fichier php c'est bien, mais empêcher l'exécution de fichier php dans le répertoire public, c'est mieux. Pour cela, on configurera apache :

<Location ~ "public/.*\.php$">
     ForceType text/plain
     RemoveHandler php
</Location>

Optimiser ses javascripts : le cas de mootools

Guillaume Kulakowski

Avec le nouveau thème du blog, Nodoka, c'est posé la question de l'optimisation des javascripts. En effet, mootools c'est bien, mais c'est lourd : 87Ko pour la version complète !

J'ai donc essayé les différents moyens de compresser du javascript et j'en ai fait un tableau comparatif.

Comparatif des différentes méthodes de compression du code javascript

Les tests suivants sont effectués à partir de la version complète de mootools 1.11.

Full Sans les commentaires JSMin YUI Compressor packer
180Ko 87Ko 73Ko 65Ko 41Ko

Comme le démontre le tableau, la meilleure méthode de compression semble être packer. Mais après une discussion sur le chan #mootools (serveur freenode.net), il semblerait que packer souffre de 2 problèmes :

  • problème avec les regex (pas tout compris à la démonstration : barrière de la langue ;-) )
  • moins compressible que YUI

C'est pour ça que mootools utilise YUI Compressor et j'ai donc suivi cette préconisation sur mon blog.

Pourquoi compresser du javascript pour gagner quelques malheureux kilo octets ?

Aller plus loin

Mais les 65Ko obtenus avec YUI Compressor ne sont pas une fin en soit. Il est ensuite possible de compresser le JS pour en faire un gzip. Attention : je ne parle pas de faire consommer du CPU pour compresser à la volée, mais de compresser une fois pour toute :

cp moootols.js mootools.jgz
gzip -9 mootools.jgz
mv mootools.jgz.gz mootools.jgz

Ensuite on modifie l'inclusion de la librairie :

<script src="/themes/nodoka/js/mootools.jgz" type="text/javascript">

Et on effectue un petit réglage sur son serveur pour penser à ceux qui ne supportent pas la compression Gzip :

# JGZ (compression JS)
RewriteCond %{HTTP_USER_AGENT} ".*Safari.*" [OR]
RewriteCond %{HTTP:Accept-Encoding} !gzip
RewriteRule (.*)\.jgz$ $1\.js [L]
AddType "text/javascript;charset=UTF-8" .jgz
AddEncoding gzip .jgz

Voila au final mootools complet ramené de 87Ko à 19Ko.

Utiliser mootools dans Dotclear 2.0

Guillaume Kulakowski

Dotclear, le gestionnaire de blog, dans sa version 2.0 (dont la RC1 devrait pointer le bout de son nez le 1er mai) utilise jQuery comme librairie javascript. Notons au passage que l'utilisation d'une telle librairie permet de gagner un temps de développement précieux et d'éviter d'éventuels problèmes de compatibilité entre les différents navigateurs.

Actuellement, l'utilisation du javascript dans le thème par défaut (Blowup) se limite à la gestion du cookie de la case "Se souvenir de moi sur ce blog".

J'aime beaucoup jQuery (je m'en suis servi dans mon précédent thème et sur d'autres projets) mais professionnellement j'utilise beaucoup mootools et j'ai acquis des facilités avec ce framework.
Pour mon dernier thème, Nodoka, c'est donc mootools que j'ai retenu et j'ai donc eu à entreprendre de porter le code de la gestion des cookies de jQuery vers mootools.
Histoire de vous faciliter la vie si vous aussi vous souhaitez utiliser mootools dans vos thèmes Dotclear, je vous mets mon bout de code à disposition ainsi que la documentation.

svn co https://svn.llaumgui.com/javascript/mootools_1.1.x/dc_remember/

On remarquera qu'il y a 2 fichiers : un fichier source avec le code lisible et commenté; et une version compressée avec YUI Compressor. D'ailleur, La compression des javascripts donnera bientôt lieu à un nouveau billet.