Le blog de llaumgui - Développement web

Charger des javascripts distants dans le "domready" de Mootools

llaumgui — Thu, 15 May 2008 20:22:00 +0200

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

llaumgui — Tue, 22 Apr 2008 20:42:00 +0200

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.

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.

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 :

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 ;-)

llaumgui — Mon, 21 Apr 2008 22:35:00 +0200

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

llaumgui — Thu, 17 Apr 2008 19:04:00 +0200

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 ?

Une page accessible devrait faire moins de 70Ko
La réduction du poids des javascripts et des CSS fait partie des préconisations Yahoo
Économie de bande passante
Certains ne réalisent pas qu'en France avec nos superbes connections on est des privilégiés (pensez y lorsque vous collez une signature de plus de 1Mo attachée à vos postes dans des forums...)

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

llaumgui — Wed, 16 Apr 2008 19:17:00 +0200

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 attaché à ce billet.

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.

Bug MySQL 5.0.51a

llaumgui — Mon, 18 Feb 2008 23:04:00 +0100

Depuis quelques jours on me rapporte des comportements étranges sur les forums de fedora-fr. Les messages récents ne seraient plus triés dans le bon ordre (ni dans aucun autre d'ailleurs)... Étonnant, car je n'ai rien touché au code de notre PunBB depuis un bon petit moment...

Bref un petit vim include/common.php pour passer le PUN_SHOW_QUERIES à 1 et ainsi tracer les requêtes MySQL et m'apercevoir que la requête fait bien un ORDER BY t.last_post DESC:

SELECT t.id AS tid, t.poster, t.subject, t.last_post, t.last_post_id, t.last_poster, t.num_replies, t.closed, t.forum_id

FROM punbb_topics AS t

WHERE t.id

IN ( 14524, 29504, 29192, 29526, 29426, 29358, 29381, 29507, 29512, 29534, 29523, 29531, 29532, 29514, 29469, 28791, 29308, 29141, 20353, 29449, 29505, 28867, 29500, 29495, 29535, 29321, 29478, 29480, 29486, 29499, 29506, 29528, 29529, 29457, 29496, 29533, 28380, 29510, 28969, 29142, 29416, 29454, 29511, 29513, 26116, 29333, 29267, 29455, 29493, 29524, 28420, 29258, 29410, 29418, 29452, 29509, 29491, 29477, 29487, 29492, 29501, 29508, 29515, 29517, 29519, 29520, 29525, 29530, 29527, 27926, 28938, 29231, 29265, 29371, 29440, 29485, 29497, 29502, 29518, 29522, 29521 )

GROUP BY t.id, t.poster, t.subject, t.last_post, t.last_post_id, t.last_poster, t.num_replies, t.closed, t.forum_id

ORDER BY t.last_post DESC

LIMIT 0 , 30

Un café plus tard, je lance directement la requête dans l'interface de phpMyAdmin et je m'aperçois que les résultats ne sont effectivement pas triés dans l'ordre... Mais qu'ai je fais ?! Je trace le log de yum et je constate que je suis récemment passé de mysql-server 5.0.45 à la version 5.0.51a...

root@borsalino ~> cat /var/log/yum.log | grep mysql

Oct 15 20:05:57 Installed: mysql.i386 5.0.27-1.fc6

Oct 15 20:08:09 Installed: mysql-server.i386 5.0.27-1.fc6

Oct 15 20:08:10 Installed: php-mysql.i386 5.1.6-3.7.fc6

Jan 20 18:56:44 Installed: mysql-libs.i386 5.0.45-1.fc6.remi

Jan 20 18:56:47 Updated: mysql.i386 5.0.45-1.fc6.remi

Jan 20 18:56:54 Updated: mysql-server.i386 5.0.45-1.fc6.remi

Jan 20 18:56:54 Updated: php-mysql.i386 5.2.5-1.fc6.remi

Feb 17 13:06:18 Updated: mysql-libs.i386 5.0.51a-1.fc6.remi

Feb 17 13:06:22 Updated: mysql.i386 5.0.51a-1.fc6.remi

Feb 17 13:06:29 Updated: mysql-server.i386 5.0.51a-1.fc6.remi

Dans le doute je contact l'ami Remi qui m'aide et me trouve ce bug : #30596 : GROUP BY optimization gives wrong result order.

Effectivement en virant les GROUP BY la requête se retrouve ordonnée comme il faut...
5 minutes plus tard Remi lance un build de MySQL comportant le correctif que j'installe dans la foulée et tout ce remet à marcher dans l'ordre ;-).

root@borsalino ~> yum --enable remi-test update mysql\*

Montée en charge et compression Gzip des pages servies

llaumgui — Fri, 07 Dec 2007 19:57:00 +0100

Depuis quelque temps, je trouve que Scenario-Paintball et llaumgui.com (tous deux hébergés sur la spb-box) mettent du temps à servir les pages.

J'ai mis à jour le système de CentOS 5.0 vers la 5.1 avec le dernier kernel pensant que ça pourrait améliorer les perfs (qui a dit naïf ?) de mon kernel datant du temps où CentOS 5.0 était encore en phase de bêta testes chez Dedibox (mais CentOS était bel est bien en version finale).

Rien à faire, j'observais encore des montées en charge et des montées de CPU. J'ai donc entrepris de m'orienter du côté d'Invision Power Board et de mieux régler la bête pour ne plus servir de pages compressées en gzip (Disable GZIP encoding?). Depuis, beaucoup moins de problème de montée en charge et même lorsque le serveur charge il arrive encore à servir les pages en un temps tout à fait respectable.
J'ai profité de cette occasion pour affiner les réglages d'IPB et configurer une charge limite (Server Load Limit ?) de 15 à laquelle Scénario-PaintBall affiche un message d'erreur invitant à patienter...

Bref, la version 2.1 n'étant pas connu pour sa légèreté, je pense que la migration vers la version 2.3 d'IPB se fait de plus ne plus pressante...

eZ publish 4.0 alpha 1, support du php5

llaumgui — Thu, 04 Oct 2007 23:03:00 +0200

Aujourd'hui, a été publiée la première version alpha d'eZ publish 4.0.
Je dois dire que j'attendais cette version avec impatience car elle introduit une nouveauté majeure : le support de php 5 (et php 6) et... Et... Et bien, malheureusement c'est à peu près tout.
Pas de gros changement, une certaine continuité qui va surement faciliter les migrations d'eZ 3.x vers eZ 4.0 mais qui laisse quand même un petit goût de déception...

Support php 5

Selon moi, eZ 4.0 marche bien mieux sous php 5 que le port communautaire que j'utilisais jusqu'alors. Ça ce ressent aux erreurs et warning remontés ainsi qu'aux performances, surtout lors de l'installation de la bête. Cependant les attributs private et autres protected sont encore bien présent en commentaires mais peu dans le code.

Arrivée d'eZ Components

Une de mes autres déceptions est l'implémentation d'eZC qui n'est pas très visible. En fait il faut lire entre les lignes et comprendre qu'eZ 4 ouvre la voie de l'intégration d'eZC mais n'est pas 100% développée sous eZC comme beaucoup (dont moi) l'auraient pensé.

Les bonnes surprises

Qui dit peu de modifications dit grosse compatibilité avec eZ 3.9.x que j'utilisais jusqu'alors. J'ai donc passé mon labo sous eZ 4 et mes extensions ezipb et ezipb-shoutbox tournent parfaitement jusqu'à présent.
Le débug est enfin valide xHTML, ce qui permet de contrôler la validité de son code plus facilement et évitera les problèmes sous IE.

Php 5.2 minimum ?

Bien que je n'ai rien vu passer là dessus et qu'eZC demande php 5.1.1 minimum, lors de mon installation sur ma CentOS qui tourne en php 5.1.6, j'ai eu la surprise de tomber sur le message suivant :

Unsupported PHP version 5.1

eZ Publish 3.x does not run with PHP 4.
For more information about supported software please visit eZ Publish download page

Après analyse du code :


if ( version_compare( phpversion(), '5.2' ) < 0 )
{
	print( "<h1>Unsupported PHP version " . phpversion() . "</h1>" );
	print( "<p>eZ Publish 3.x does not run with PHP 4.</p>".
           "<p>For more information about supported software please visit ".
           "<a href=\"http://ez.no/download/ez_publish\" >eZ Publish download page</a></p>" );
    exit;
}

Au final, vu le flou du discourt, j'ai commenté le tout et ça marche très bien jusque là...

En résumé :

Vivement la version final !

Ètat d'avancement d'ezipb, Le connecteur ipb pour eZ publish

llaumgui — Sun, 30 Sep 2007 20:20:00 +0200

Ma partie de paintball ayant était annulée pour cause de pluie (et oui, ça arrive 1 à 2 fois par an, même à Montpellier ;-)), j'en ai profité pour m'avancer dans le développement d'ezipb, le connecteur Invision Power Board pour eZ publish.

Comme le montre la feuille de route, la version 1.0 RC1 devrait même être livrée en avance et la RC2 est déjà bien avancée.

Trouvant ma démo hideuse, j'ai arrangé le tout et développé les quelques templates que j'avais initialement prévu pour la RC2.
Mon labo s'en retrouve un peu plus montrable ;-). J'ai également fait une tâche cron pour synchroniser la démo avec la version SVN tout les soirs.

Comme une bonne nouvelle n'arrive jamais seule, j'ai bien avancé dans la documentation en ligne de l'extension.
Le maintien d'une documentation utilisant le wiki de Trac étant très facil; j'ai décidé de ne pas fournir la documentation dans l'archive mais de faire une simple fichier LISEZMOI.txt avec un lien vers la documentation en ligne.

Bref l'intégration d'IPB dans eZ publish arrive en grand pas ;-).

Un labo pour tester ezipb, le connecteur IPB pour eZ publish

llaumgui — Wed, 26 Sep 2007 00:03:00 +0200

Comme je viens tout juste de finir un petit script permettant de configurer automatiquement un site web sur un serveur (création de la base de données MySQL, des répertoires, configuration des stats Awstats, du vhost, etc...), j'en ai profité pour mettre en place un petit labo afin de pouvoir vous monter ezipb.

Pour le moment, ça fait pas grand chose mais ça peut vous donner une idée de ce que sera mon intégration d'Invision Power Board (IPB pour les intimes) avec eZ publish (eZ pour les intimes).

URL : labo
Login : ezipb
Mot de passe : ezipb

Remarque : Pour ce qui est de mon script, il fera l'objet d'un prochain billet lors que j'aurais un peu mieux testé le truc.

jQuery 1.2 est dans les bacs

llaumgui — Tue, 11 Sep 2007 13:53:00 +0200

C'est juste au moment où je suis en train de réfléchir aux côtés dynamiques, 2.0 & funky de Scénario-PaintBall v3; que mon framework JavaScript / AJAX préféré voit publier sa version 1.2.
Pour ceux qui ne le connaissent pas (encore), jQuery est une bibliothèque permettant de « Write less, do more » (Traduction partisane : « Faire un max de choses en n'en foutant le moins possible » ; j'adore ce slogan !) et qui surtout est compatible tous navigateurs. Dépassé (enfin presque) le temps où l'on perdait du temps à déboguer ses JS sous Internet Explorer !

Je vais donc explorer, pour SPB, les nouvelles pistes offertes par jQuery 1.2.
Comme certaines librairies peuvent être incompatibles entre elles et que je ne veux pas forcer à l'utilisation d'un framework en particulier : je ne pense pas utiliser jQuery dans ezipb-shoutbox.
Cependant, comme eZ publish le permet, dans le cadre de mon site (qui est dans une extension), je vais surcharger le JS d'ezipb-shoutbox et utiliser jQuery.

ezipb-shoutbox, une shoutbox pour ezipb

llaumgui — Sun, 09 Sep 2007 23:26:00 +0200

Je viens d'importer, sur mon serveur Subversion, la première version d'ezipb-shoutbox : la shoutbox AJAX pour l'extension ezipb permettant de coupler eZ publish et IPB.

J'en ai aussi profité pour mettre à jour la documentation sur mon wiki, ainsi que le roadmap.

eZ publish et eZ find 1.0 bêta 1

llaumgui — Sun, 09 Sep 2007 14:36:00 +0200

Les moteurs de recherche, quel cruel dilemme ! Soit on a un moteur basique et léger soit un moteur super pertinent mais consommant un max de ressources. Certains même en arrivent à utiliser Google en guise de moteur de recherche sur leur site (je propose d'ailleurs cette solution alternative en plus des moteurs de recherche de fedora-fr).

eZ publish n'échappe pas à la règle et de base son moteur de recherche est pour le moins... pas terrible. Heureusement qu'eZ est bien fait et permet le remplacement du moteur de recherche par d'autres via le système d'extensions. Avec la Community Newsletter #11 et l'annonce de la version 1.0 beta 1 d'ezfind, j'ai donc entrepris de tester la bête.

Quelques petits problèmes à l'installation

Comme je l'ai déjà dis plusieurs fois, j'utilise la version 3.9 communautaire compatible php5 d'eZ publish. eZ find semble cependant tourner parfaitement en php5. Par contre, dès le début, je me suis heurté à une fatal error :

Fatal error: Class 'ezsolr' not found in /mnt/divers1/public_html/scenario-paintball/kernel/classes/ezsearch.php on line 104
Fatal error: eZ publish did not finish its request

The execution of eZ publish was abruptly ended, the debug output is present below.

Comme ma version d'eZ n'est ni conventionnel ni la dernière, j'ai pas cherché plus loin et j'ai fait un petit lien relatif (pas le temps de passer plus de temps à faire plus propre sur une bêta 1 de test).

llaumgui@enterprise /mnt/divers1/public_html/scenario-paintball/kernel/search/plugins> ln -s ../../../extension/ezfind/search/plugins/ezsolr/ ./

Ensuite, ma version semble ne pas posséder d'updatesearchindex.php, je l'ai donc pris sur le serveur SVN.

Spécificités d'eZ find

eZ find requière le JRE (Java Runtime Environment) 5.0 ou supérieur. Les améliorations apportées par rapport à la recherche standard sont notamment :

Classement par pertinence !
Support natif des droits dans eZ publish.
Soulignement des mots clef.
Recherche par langue, basée sur la configuration du siteaccesses courant.
Possibilité de rechercher sur de multiples siteaccesses.
Intégration dans l'administration d'eZ publish ainsi que dans ezwebin.

Premières impressions

Une fois le tout configuré, l'exécutable Java lancé et le cache de recherche mis à jour, voici ce que ça donne.

J'aimerais bien utiliser ce moteur de recherche sur scenario-paintball voir court-circuiter le moteur de recherche d'IPB pour centraliser toutes les recherches à partir d'eZ find, c'est une piste que je dois explorer pour ezipb. En effet, le moteur d'IPB n'est pas réputé pour sa faible consommation en ressources.

Par contre, pour une utilisation sur un serveur possédant plusieurs instances d'eZ (comme c'est le cas à mon boulot), une seule instance de l'exécutable suffit ~~je suis septique sur un point : doit-on lancer 1 instance de l'exécutable Java par site ou une seul par serveur~~...
J'aimerais aussi benchmarker la consommation de ce moteur de recherche par rapport à celui livré en standard dans eZ publish ainsi que la montée en charge de l'appli Java lors de l'indexation (qui a fait monter mon CPU à 100% quand même !). Une chose est sûre l'appli Java à besoin de tourner en permanence et ne sert pas uniquement lors de l'indexation.

~~Par contre j'avoue avoir été déçu par le fait qu'eZ find ne semble pas indexer les pdf, enfin selon mes tests~~.

ezipb : eZ publish et IPB réunis

llaumgui — Sun, 02 Sep 2007 17:01:00 +0200

eLors d'un précédent billet, j'avais parlé de la refonte de SPB et de mon projet d'extension ezipb pour permettre à eZ Publish et IPB de communiquer. J'ai bien avancé, voila ce que fait mon extension pour le moment :

Initialise les classes d'IPB strictement nécessaires (j'ai pompé et allégé l'index.php d'IPB).
Initialise des drivers MySQL modifiés à la place des drivers d'IPB.
Ces derniers utilisent la connections ouverte par eZ. Comme eZ est orienté php4, mon extension force MySQL à la place de MySQLi qui est normalement automatiquement déclenché par la présence de php5. Cette fonctionnalité est désactivable si vous n'avez pas vos données eZ et IPB sur la même base.
Divers opérateurs eZ publish afin de récupérer les informations sur les membres.
Divers templates (1 pour le moment) afin d'avoir les éléments principaux d'IPB dans eZ publish.

Bref actuellement, le cout de mon extension est de 3 requêtes et j'ai pas encore entamé la chasse aux requêtes inutiles !

Comme je veux proposer cette extension ainsi que le portage vers IPB 2.3.x de la plupart de mes mods et task IPB, j'ai monté un Trac et un SVN afin d'assurer le support et de proposer un téléchargement via Subversion... IPB, je suis de retours !

Plus d'infos, documentation et téléchargment sur le Trac.

Remarque : J'utilise la version 3.9 communautaire compatible php5 d'eZ publish. Mon extension est donc en php5. Elle est donc incompatible avec la plupart des versions d'eZ publish... C'est ballot :-).

Mise à jour automatique de Dotclear 2.0 et de ses plugins, à partir du SVN (update)

llaumgui — Fri, 31 Aug 2007 20:01:00 +0200

Je mets très souvent mon blog à jour à partir de la dernière version SVN de Dotclear 2.0. Jusqu'à présent, je faisais un svn co sur ma machine locale, puis je virais les répertoires inutiles (rm -rf `find ./ -name .svn`) et enfin j'envoyais le tout sur mon ftp. On obtient alors une version de Dotclear à jour et sans fichiers .svn. Le revers de la médaille étant le temps passé à faire la manip'. Je me suis donc fais un petit script pour automatiser tout ça :

Mise à jours des sources de Dotclear à partir du SVN.
Mise à jour et téléchargement de nouveaux plugins à partir du SVN de Dotclear.
Mise à jour de la base de données (visite de la page d'admin).
Vidage le cache.

Comme je suis un Geek très flémard et qui n'a peur de rien : j'ai mis le tout en tâche cron.

#!/bin/bash

###############################################################################

#

# dc-svn-co :

# Mise à jour d'une installation Dotclear 2.0 à partir des sources du SVN.

#

# Dépendances requises :

#       - subversion

#       - curl

#

# Attention : L'utilisation de ce script permet de mettre à jour votre instance

# de Dotclear à partir d'une version dite instable !

# Utiliser à vos risques et périls !

#

# Licence Dotclear : http://www.dotclear.net/license.html

#

# by Guillaume Kulakowski a.k.a LLaumgui <guillaume at llaumgui dot com>

# Version 2.0

#

###############################################################################

# This program is free software; you can redistribute it and/or

# modify it under the terms of the GNU General Public License

# as published by the Free Software Foundation; either version 2

# of the License, or (at your option) any later version.

#

# This program is distributed in the hope that it will be useful,

# but WITHOUT ANY WARRANTY; without even the implied warranty of

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

# GNU General Public License for more details.

#

# You should have received a copy of the GNU General Public License

# along with this program; if not, 

#  - write to the Free Software

#       Foundation, Inc., 51 Franklin Street, Fifth Floor,

#       Boston, MA  02110-1301, USA.

#   - See http://www.gnu.org/licenses/gpl.html

###############################################################################





######################################

# Variables :



# Chemin vers l'installation de Dotclear :

DC_CORE_PATH="/home/www.xxx.com/www"



# Chemin vers les plugins de Dotclear :

DC_PLUGIN_PATH="$DC_CORE_PATH/plugins"



# Chemin vers le cache :

DC_CACHE_PATH="$DC_CORE_PATH/cache"



# Liste des plugins à récupérer à partir du svn :

DC_PLUGIN_LIST="antiflood commentsWikibar dayMode emailNotification gallery related sitemaps spamplemousse2"



# Chemin vers votre administration (pour la requête de mise à jour) :

DC_URL="http://www.xxx.com/admin/"





SVN_DC_URL="https://svn.dotclear.net/2.0/trunk"

SVN_DC_PLUGIN_URL="https://svn.dotclear.net/2.0/plugins"











######################################

# # #                            # # # 

# # #   /!\ On touche plus /!\   # # #

# # #                            # # #

######################################



###

# Mise à jour à partir du SVN :

function svnCo() {



    cd "$1"

    svn co "$2" ./

}







###

# Mise à jour de la liste des plugins à partir du svn :

function svnPlugin () {



        for plugin in $DC_PLUGIN_LIST; do

                echo -e "\n\n###############  $plugin   ###############"

                

                # Création du répertoire pour les nouveaux plugins :

                if [ ! -d $DC_PLUGIN_PATH/$plugin ]; then

                        echo "Le répertoire $plugin n'existe pas !"

                        echo "Création du répertoire $plugin."

                        mkdir "$DC_PLUGIN_PATH/$plugin"

                fi;

                

                svnCo "$DC_PLUGIN_PATH/$plugin" "$SVN_DC_PLUGIN_URL/$plugin"

        done;

}







###

# Mise à jour de la base par appel de l'url de l'admin :

function updateDB() {



        curl $DC_URL

}







###

# On vide le cache

function cleanCache() {

        

        rm -rf "$DC_CACHE_PATH/cbfeed"

        rm -rf "$DC_CACHE_PATH/cbtpl"

}











echo "################################################################################"

echo "#                                                                              #"

echo "#               Mise à jour de Dotclear à partir des sources SVN               #"

echo "#                                                                              #"

echo "################################################################################"

svnCo "$DC_CORE_PATH" "$SVN_DC_URL"



echo -e "\n\n\n\n\n\n################################################################################"

echo "#                                                                              #"

echo "#                      Mise à jour de la liste des plugins                     #"

echo "#                                                                              #"

echo "################################################################################"

svnPlugin



echo -e "\n\n\n\n\n\n################################################################################"

echo "#                                                                              #"

echo "#                           Opérations de mise à jours                         #"

echo "#                                                                              #"

echo "################################################################################"

echo ""

echo -e "\n### Mise à jour de la base de données ###"

updateDB



echo -e "\n\n###          Vidage du cache          ###"

cleanCache

Je mets à disposition mon script (sous licence GPL) tout en précisant que son utilisation réfléchie ne pose pas de problème (pas plus qu'un checkout) mais qu'une mise à jour automatisée au moment où la révision Subversion plante (ça peut arriver), fait buger le site jusqu'à la mise à jour suivante...

Mise à jour : Métro-sexualisation du code pour un rapport par mail (crontab) plus lisible.

Scénario-PaintBall version 3 en préparation

llaumgui — Thu, 30 Aug 2007 23:05:00 +0200

Après plusieurs années de bons et loyaux services, il est grand temps que la version 2 de Scénario-PaintBall tire sa révérence, pour donner naissance à une v3 ;-).
Pourquoi ?

Le forums : L'une des raisons principales et la version d'IPB, la 2.1.x. Cette dernière n'est plus ou ne sera bientôt plus supportée. Il est donc grand temps de passer à la branche 2.3.x.
Les autre points découlent de cette mise à jour.
Le portail : Il utilise l'ipbSDK qui n'est plus développé depuis la version 2.1 d'IPB (déjà que la 1.6 beta 5 pour IPB 2.1 était « limite »). Si je veux récupérer mon portail il faut donc que je rende compatible la dernier version du sdk avec la version actuel du forum... Or, j'ai la flemme de récupérer du vieux code !
Le design : le passage vers IPB 2.3 oblige à refaire la feuille de style (si on veut pas faire le porc). A remonter une page, autant en remonter une nouvelle.

Des pistes pour l'évolution

Pour la partie graphique, Radinus est en train de voir avec un designer.
Pour la techno, je pense utiliser eZ Publish 4.0 qui ne devrait plus tarder à sortir en version alpha voir peut être même bêta... Je rappel que la version du sdk utilisée actuellement est une bêta 2 ultra modifiée par moi même, donc on est plus à une bêta près.
En attendant la v4 d'eZ, je commence les tests sur la version 3.9 communautaire compatible php5.

Du coup, en utilisant IPB + eZ publish, je n'ai plus qu'une seule chose à développer : une extension eZ pour communiquer avec IPB (connections membres + requêtes de récupération d'informations diverses).

Des non pistes

Pourquoi pas le module forums pour eZ ?

La licence IPB est payée à vie et c'est un excellent forums ultra (trop?) complet.

Pourquoi pas un CMS autour d'IPB ?

Je pense qu'un forum est un forum et qu'un CMS est un CMS ! Vouloir absolument développer un CMS autour d'un forum est, selon moi, une erreur. Erreur que j'ai d'ailleurs commise lors de la v2 de spb ;-).
La solution est donc de coupler différents scripts via des bridges (ma future extension ou les bridges à la Coppermine) ou grâce à des systèmes du type SSO (pour SPB on en est pas encore là).

TODO

Installer Eclipse Europa (3.3) avec les extensions qui vont bien (pdt, Smile eZ plugin). Je commence de loin, mais installer & configurer Eclipse c'est presque aussi long qu'installer un système complet.
~~Configurer mon serveur apache local~~.
~~Installer eZ 3.9 php5~~.
~~Convertir la base IPB 2.1.x vers 2.3.1~~.
Développer le plugins eZipb pour faire communiquer IPB et eZ publish (voir les différentes pistes offertes et voir aussi du côté de Converge).
Découper le design (que j'attends toujours).
Développer, dans la version eZ, les différentes fonctionnalités actuellement disponibles sur spb.
Migrer le forums en UTF-8.
etc...