Le blog de llaumgui - php

ezoescript et ezoecss : 2 bonnes surprises dans ezoe

llaumgui — Fri, 13 Jun 2008 21:08:00 +0200

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.

Du changment dans ma vie

llaumgui — Wed, 30 Apr 2008 08:43:00 +0200

Hier était pour moi un jour particulier puisqu'il s'agissait de mon dernier jour au sein de la société Kaliop. Une société et des collaborateurs avec qui j'ai pris plaisir à travailler pendant près de 2 ans & demi, et où je pense avoir beaucoup appris.

Lundi commencera pour moi un nouveau défi puisque j'intègre la société Logica, la 7^e société de conseil, de services informatiques et outsourcing en Europe (sources Wikipédia) qui est plus connu en France sous son ancien nom : Unilog (Mais où est passé Unilog). Mon titre y est décrit comme "Ingénieur en technologies de l'information" et j'y ferais principalement du php5/MySQL/eZ Publish; bref, je m'aventure en terrain connu ;-).

Autre changement en prévision : un nouveau déménagement ! Ce coup si je n'emménage pas seul vu que je déménage pour habiter avec ma copine ;-).

Petit message à mes anciens collaborateurs : Vengeance : Dark Tyranus | Kakia la coquine | Touche les tétous

Remi + Borsalino = php5.2 + MySQL 5 mis à jour

llaumgui — Sun, 20 Jan 2008 18:02:00 +0100

Devant la coupure de service, surement due à une monté en charge de Borsalino, et devant les failles récentes révélées pour php : j'ai décidé de basculer Borsalino sur le dépôt de l'ami Remi Collet qui maintient toujours les packages php et MySQL pour Fedora 6 alias Zod !

On install le dépôt :

root@borsalino ~> wget http://remi.collet.free.fr/rpms/remi-release-6.rpm

root@borsalino ~> rpm -Uvh remi-release-6.rpm

On active le dépôt en passant enabled à 1 :

root@borsalino ~> vim /etc/yum.repos.d/remi.repo

Et on mets à jour :

root@borsalino ~> yum clean all; yum update

[...]

Dependencies Resolved



=============================================================================

 Package                 Arch       Version          Repository        Size 

=============================================================================

Updating:

 mysql                   i386       5.0.45-1.fc6.remi  remi              2.1 M

 mysql-server            i386       5.0.45-1.fc6.remi  remi               10 M

 php                     i386       5.2.5-1.fc6.remi  remi              1.3 M

 php-cli                 i386       5.2.5-1.fc6.remi  remi              2.5 M

 php-common              i386       5.2.5-1.fc6.remi  remi              226 k

 php-eaccelerator        i386       1:0.9.5.2-1.fc6.remi  remi              136 k

 php-gd                  i386       5.2.5-1.fc6.remi  remi              115 k

 php-ldap                i386       5.2.5-1.fc6.remi  remi               33 k

 php-mbstring            i386       5.2.5-1.fc6.remi  remi              1.1 M

 php-mcrypt              i386       5.2.5-1.fc6.remi  remi               28 k

 php-mysql               i386       5.2.5-1.fc6.remi  remi               83 k

 php-pdo                 i386       5.2.5-1.fc6.remi  remi               89 k

 php-pear                noarch     1:1.6.2-1.fc6.remi  remi              400 k

 php-xml                 i386       5.2.5-1.fc6.remi  remi               97 k

Installing for dependencies:

 mysql-libs              i386       5.0.45-1.fc6.remi  remi              1.5 M

 sqlite2                 i386       2.8.17-1.fc6     extras            170 k



Transaction Summary

=============================================================================

Install      2 Package(s)         

Update      14 Package(s)         

Remove       0 Package(s)         



Total download size: 20 M

Pour finir, on peut utiliser mon script pour notifier des mises à jour via yum...

eZ Publish 4, php 5.2, CentOS 5, Remi et la spb-box

llaumgui — Sat, 06 Oct 2007 10:31:00 +0200

Que du beau monde dans un seul billet...

A la lecture du très instructif commentaire de Paul Borgermans laissé à la suite de mon billet sur la première alpha d'eZ Publish 4.0; et l'annonce qu'eZ 4.0 ainsi qu'eZ Components iraient plus vers un compatibilité php 5.2 que 5.1 : j'ai décidé de mettre à jour la version de php de la spb-box.

Pour cela, j'ai fait confiance à l'ami Remi (Attention prononcer Remi et surtout pas Rémi) et à son dépôt. Pour ceux qui ne connaisse pas Remi, surnommé dans le milieu "Serial Builder", il propose les dernières versions php/MySQL pour Fedora mais aussi pour les RHEL 4 & 5.

Une petite ligne de commande :

root@spb-box ~> wget http://remi.collet.free.fr/rpms/el5.i386/remi-release-5-2.el5.remi.noarch.rpm \

rpm -Uvh remi-release-5*.rpm \

yum --enablerepo=remi update php

Et me voila en php 5.

root@spb-box ~> rpm -qa php

php-5.2.4-1.el5.remi

Tenant à activer le dépôt de Remi par défaut (il est très réactif au niveau des mises à jour) mais ne tenant pas à mettre à jour mon serveur MySQL, j'ai configuré le dépôt de la sorte.

[remi]

name=Les RPM de remi pour Enterprise Linux 5 - $basearch

baseurl=http://remi.collet.free.fr/rpms/el5.$basearch/

    http://iut-info.univ-reims.fr/remirpms/el5.$basearch/

enabled=1

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi

exclude=mysql mysql-server mysql-libs

A force de mettre des clauses exclude dans mes fichiers repo, j'en fini par croire qu'il faudrait inventer un clause include...

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 :-).

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...

Version finale du script de migration de Xoops vers punBB

llaumgui — Sun, 17 Sep 2006 22:34:00 +0200

Quelques semaines après le lancement du débat et le début du projet, je viens de terminer mon script de migration de Xoops vers punBB. Ce script migre les données d'un site sous Xoops muni d'un forum CBB pour les transférer dans l'interface de punBB.

Pré requis :

php4 ou supérieur.
php-cli pour lancer le script en ligne de commande.
Je n'ai pas testé avec un navigateur mais ça doit marcher quand même ;).
Quelques connaissances en php.

Licence :

Gnu/GPL, vous pouvez donc l'adapter au besoin, il est fait pour ça.

Concrètement ce script convertie :

Les groupes de membres : Les permissions seront les mêmes pour tous les groupes.
Elles seront donc à modifier par la suite.
Les membres :
- Xoops autorisant plusieurs groupes pour un seul membre, ce que punBB ne fais pas, les membres sont tous mis dans le même groupe, membres (id=4).
- Autre petites subtilité de punBB, le membre à l'identifiant 1 est l'invité, il faut donc ne pas avoir de membre avec un uid=1 sous Xoops. Si c'est votre cas, vous devrez faire une petite moulinette en modifiant mon script.
- Les avatars, il faut tous les mettre dans le bon dossiers (img/avatars).
Les catégories.
Les forums.
Les topics
Les postes : Ca c'est le gros morceau, il y a un traitement par lots pour les grosse bases.

Réflexion sur Fedora-France, Xoops et l'hébergement.

llaumgui — Sat, 02 Sep 2006 19:00:00 +0200

Depuis plusieurs années, Fedora-Fr tourne sous Xoops, un CMS ultra complet mais qui nous enferme dans son univers. Depuis que j'ai pris en charge la partie technique du site, je n'ai pas eu le courage de changer et, je l'avoue, j'ai même freiné ce changement.

A présent je m'interroge...
De par mon travail, j'ai énormément progressé et je suis capable de réaliser une migration de CBB (forum de Xoops) vers punBB sans problème (en fait, j'en étais capable avant, mais comme je n'avais rien fais de tel, j'avais un peu la flemme ;)).
Et, récemment, la réflexion de Damien Durant sur la liste de diffusion des ambassadeurs francophone m'a réconforté dans mon idée qu'il faut envisager le changement.

L'hébergement :

Avant tout, le vrai problème de Fedora France demeure l'hébergement. De plus en plus une solution dédiée s'impose ! Elle permettrait de souffler et de mettre fin au erreur 500 et autre petit problème de l'hébergement communautaire. Mais surtout, elle permettrait au site de prendre son envol.

La question est quel hébergement pour Fedora-France ?

Apparemment le Projet Fedora est hébergé par Red Hat qui n'héberge que du statique ou du Python pour raisons de sécurité.
Avec le trafic actuel et de la publicité nous pourrions nous payer une Dedibox (solution dédiée de Free) sans trop de problème. Mais l'idée de la pub ne va-t-elle pas contre nos idées de liberté ?
La solution serait alors de se monter en association (c'est prévu), de démarcher des fournisseurs (Dedibox en premier) et de leurs faire profiter de notre image de libre en nous soutenant.

La structure de Fedora France et le choix d'un CMS

Damien propose de suivre le projet Fedora dans ses choix et de passer vers une solution Python, mais je pense que l'architecture php/MySQL offrirait beaucoup plus de souplesse, et en plus c'est ma spécialité.

Voici ma réflexion :

Forum : punBB (scripts CBB -> punBB par moi même).
Wiki : DokuWiki, intégré à punBB (étude de la faisabilité d'un script wiwimod -> DokuWiki qui soit correct).
Planet : DotClear 2 et son plugin planet visible ici.
Page d'accueil : Faites maison.

Je sais, certain dirons que cette structure ressemble pas mal à un autre site... Mais à problématique proche, solution proche.

Bref, le travail que j'aurais à faire pourrait être découpé en plusieurs étapes :

Migration de Fedora France.
Installation du planet.
Migration du forum.
Migration de la home page.
Migration du wiki.

Cette réflexion n'engage que moi et nullement Fedora-francce. Elle est juste là pour aider un éventuel webmaster/administrateur qui se retrouverait face à une solution historique et serait effrayé par l'obstacle d'une migration.

MySQL 5.0 et la cohabitation de scripts php

llaumgui — Fri, 28 Oct 2005 19:27:00 +0000

Le bridge (appellations tout ce qui a de moins officielle) est un pont permettant à 2 scripts php de communiquer entre eux. Le meilleur exemple est, à mon sens, Coppermine qui est une galerie en php avec son propre espace membre mais qui sait utiliser une autre table membres que la sienne afin d'être parfaitement intégrée à une structure déjà existante.

Un exemple concret peut être donné via Scenario-PaintBall qui utilise IPB et Coppermine avec le bridge adéquate pour n'avoir qu'un seul compte membre pour les 2 scripts.

Auparavant, soit ce système de bridge été incorporé en natif, soit il fallait toucher au code d'un voir des 2 systèmes en places.
Par exemple, faire en sorte que l'inscription à IPB soit couplée avec celle de Coppermine (Modification des source d'IPB) et utiliser le système d'identification d'IPB sous Coppermine (Modification des source de Coppermine).
Bref le travail était fastidieux, mais les mise à jour était pires.

MySQL 5.0 introduit un point très intéressant, que les utilisateurs de solutions telles que SQL Server ou Oracle connaissent : Les triggers. En vulgarisant, ce sont des réactions à des actions bien spécifiques.
Un exemple pourrait être une requête d'insertion dans la table membre de Coppermine suite à une requête d'insertion dans celle d'IPB et vice versa... On a donc automatisé l'inscription aux 2 scripts sans modifier une seul ligne de code...

Malheureusement, et oui, il y a toujours un "mais", MySQL 5.0 n'est officiellement stable que depuis quelques jours et des incompatibilités apparaissent déjà avec certain scripts très utilisés (IPB pour ne citer que lui). A mon avis, et les copains de Celeo sont d'accord avec moi, une réelle utilisation en production de MySQL 5.0 ne se fera pas avant 1 an, mais on peut s'y préparer.

NB : Comme me le fais remarquer Dash sur IRC au moment de la rédaction de ce billet : cette vision est simpliste et ne pourrait bien entendu pas fonctionner avec n'importe quel script. Par exemple, le cryptage d'un champs via un algorithmes compliqué ne pourrait être exécuté via le serveur MySQL mais seulement récupéré à partir de la première requête... Les systèmes utilisant un cryptage de mots de passe différents pourraient donc poser problèmes.

Liste de mes mods IPB

llaumgui — Wed, 28 Sep 2005 18:43:00 +0000

Je commence à me faire une petite collection de mods persos pour IPB. Ce billet servira à tous les lister et savoir où les trouver.

IPB 1.3.x :
- RSS IPB News 1.6 (Chez Invisionize), (médaille du meilleur mod catégorie "Mid-scale" Juin 2005) : Ce mod vous permet d'exporter vos news issues de votre forum IPB au format RSS.
IPB 2.0.x :
- RSS IPB News 1.6 (Chez Invisionize): Ce mod vous permet d'exporter vos news issues de votre forum IPB au format RSS.
- [Task] goTrash 1.0 (Chez Invisionize): (médaille du meilleur mod catégorie "Mid-scale" Septembre 2005) Certaines multi-modération peuvent ajouter un préfixe dans le titre du topic. Par exemple, sur mon site, j'utilise le préfixe [Périssable] pour signaler que le topic rejoindra bientôt la corbeille. Cette task automatise juste ce déplacement dans la corbeille...
IPB 2.x :
- [SDK] Tchat Xpress (Chez Invisionize) : ShoutBox basée sur le SDK 1.5 pour IPB 2.x. Il faut donc l'avoir préalablement installé pour utiliser le Tchat XPress.
- Show Queued : Ce mod est un auto-module : donc pas de fichier d'IPB à modifier smile.gif. Il sert a afficher la liste des topics demandant un travail de modération (Posts invisibles ou sujets non approuvés).
IPB 2.1.x :
- [Task] goTrash 1.1 : Certaines multi-modération peuvent ajouter un préfixe dans le titre du topic. Par exemple, sur mon site, j'utilise le préfixe [Périssable] pour signaler que le topic rejoindra bientôt la corbeille. Cette task automatise juste ce déplacement dans la corbeille...
IPB 2.1.x (En cours de développement, mais disponible en pré-version):
- imode and Wap for IPB 1.1 : Une version iMode de votre site.
- JS export news 1.0 : Exporter vos news au format JavaScript.

Mon profil sur IPBR-Fr.
Mon profil sur Invisionize.

Mis à jour le 28/09/05