Frédéric David
Gestion des sites multilingues - host_uri
Au Luxembourg, 99% des sites sont multilingues ( Français, Allemand, Anglais ). L'utilisateur doit pouvoir y accéder via différentes urls propres, à la fois en mode host, comme en mode uri. eZ publish fournit plusieurs fonctionnalités pour gérer les redirections de façon propre, à savoir le module switchlanguage, et le mode "host_uri" apparu à la 4.4.
Module switchlanguage
Le module switchlanguage possède une unique vue "to". Cette vue permet de gérer toutes les redirections selon la configuration d'eZ publish et par siteaccess. Elle prend comme paramètre 2 variables :
- siteaccess : cette variable est obligatoire. C'est le nom du siteaccess vers lequel vous voulez être redirigé ( ex : website_en pour voir la version anglaise ).
- url : cette variable est optionnelle. C'est l'url de votre objet courant. ( ex : contact ). Par défaut, si cette valeur n'est pas fournie, la page d'accueil sera affichée.
switchlanguage fonctionne de manière différente selon le paramètre MatchOrder, défini dans le site.ini Selon la valeur de MathOrder, on aura les fonctionnements suivants :
- uri : MatchOrder est définit à uri. switchlanguage va faire une simple redirection, avec l'adresse du serveur et le nom du siteaccess à la suite ( ex : www.example.com/website_en )
- les autres : Si MatchOrder est définit avec n'importe quelle autre valeur possible ( host, port, host_uri ), switchlanguage va récupérer la valeur de SiteSettings/SiteURL définit dans site.ini pour le siteaccess demandé. ( ex : redirection vers en.example.com )
Cela permet d'avoir des redirections propres, sans avoir à définir un tableau des noms de domaine à côté. Il suffit d'écrire dans son template 1 à N liens selon le nombre de langue :
{concat( 'switchlanguage/to/website_en/', $requested_uri_string)|ezurl}>English
Mode host_uri
eZ publish permet de gérer la redirection des siteaccess via différents modes tel que uri,host,port. Dans le cas ou pour un site, on doit avoir les 2 tel que uri, et host. Le module switchlanguge va prendre par défaut le mode uri, ce qui convient pas trop. Depuis eZ publish 4.4, on trouve un nouveau mode qui est host_uri.
Le mapping du mode host_uri se fait via le tableau HostUriMatchMapItems qu'on retrouve dans Site.ini/SiteAccessSettings
Le mode host_uri prend 3 paramètres par ligne :
- hostname : le nom de domaine ( ex : en.example.com )
- uri : la partie à prendre en compte après le / final
- siteaccess : le nom du siteaccess à prendre
- method : cette parti permet de spécifier le type à prendre ( start/end/part/strict ) Par défaut, c'est strict qui est pris. La valeur par défaut peut être modifiable via SiteAccessSettings/HostUriMatchMethodDefault dans le fichier site.ini
On retrouvera dans site.ini des valeurs de type :
# SiteAccessSettings MatchOrder=host_uri HostUriMatchMapItems[]=en.example.com;;website_en
Il permet de traiter tous les cas de figure qu'on peut retrouver pour un site ( multilingue, multi-site, etc. )
Exemple de configuration
Pour fournir un exemple concret, on va prendre un site qui a comme caractéristiques :
- site multilingue ( Français, Anglais )
- multi site ( site institutionnel, site événementiel )
- splash page permettant de renvoyer vers le site institutionnel, ou le site événementiel
Par rapport à ces conditions, on peut déterminer l'obligation d'avoir comme siteaccess www_fr et www_en ( pour gérer la splash page ), web_fr et web_en ( pour gérer le site institutionnel ), event_fr et event_en ( pour gérer le site évenementiel )
Pour gérer ce genre de cas , on retrouvera dans le fichier de surcharge site.ini :
# SiteAccessSettings MatchOrder=host_uri HostUriMatchMapItems[]=example.com;fr;www_fr;end HostUriMatchMapItems[]=example.com;en;www_en;end HostUriMatchMapItems[]=fr.example.com;;web_fr HostUriMatchMapItems[]=en.example.com;;web_en HostUriMatchMapItems[]=fr.news.example.com;;news_fr HostUriMatchMapItems[]=en.news.example.com;;news_en
On retrouvera les urls des sites que l'on veut dans les fichiers ini des siteaccess. Par exemple, on retrouve dans le site.ini du siteaccess web_fr
# SiteSettings SiteURL=fr.example.com
En utilisant le module switchlanguage, l'utilisateur sera renvoyer correctement vers le bon site., à savoir switchlanguage/to/web_fr renverra automatiquement vers fr.example.com
Cela permet d'avoir différentes configurations selon l'environnement ( développement, recette, production ).
eZ publish et Git
Lors de la journée eZ du 21 septembre, eZ Systems a décidé de scinder eZ publish en 2 versions, une version communautaire et une version enterprise. Pour plus d'informations sur cette journée, je vous conseille d'aller voir Retour sur la journée eZ parisienne du mardi 21 septembre 2010 sur llaumgui.com. Voici un tutorial sur comment contribuer à la version communautaire d'eZ publish .
Préparation de sa copie de travail
La première étape pour aider la communauté eZ publish , et de contribuer est de récupérer la version d'eZ publish disponible sur GitHub.com. Pour cela différentes trucs sont nécessaire.
Configuration de Git Hub
Pour commencer, Il faut s'inscrire sur Git Hub. Une fois identifié, il faut compléter son compte, en cliquant sur Account Settings.
Dans le menu à gauche, nous retrouvons le lien "SSH Public Keys". En ajoutant une nouvelle clé publique, on peut choisir un nom ( j'ai mis le lieu perso ), et sa clé SSH publique. Cette clé va nous permettre d'avoir nos accès à notre répertoire Git.
Récupération d'eZ publish
Dans la fenêtre de recherche, on recherche ezpublish , et on accède au projet. Le lien direct au projet est http://github.com/ezsystems/ezpublish .
En face du titre "ezsystems/ezpublish", différents liens sont disponibles tel que "Watch", "Fork" ou "Download Source". En cliquant sur "fork", cela va copier les différentes branches/tags et compagnie dans notre répertoire Git. Une fois l'opération de copie fini, nous êtes renvoyés vers votre fork, avec une adresse de type "git@github.com:votre_login/ezpublish.git".
Ouvrez un terminal, et rendez vous dans l'endroit qui va contenir votre instance d'eZ publish. Pour récupérer toutes les informations, il faut taper :
Cette commande va prendre quelques minutes selon votre connexion. Il récupère le répertoire principal, ainsi que les branches et tags.
Une fois l'opération faite, vous pouvez commencer à éditer votre version d'eZ publish.
Utiliser sa copie de travail
Travailler avec Git
Git ressemble énormément à SVN, avec pas mal de commande commune. Je vais décrire les différentes commandes les plus utilisées lors d'un développement.
- git status : équivalent à svn status
- git add : équivalent à svn add. A noter, qu'un répertoire ne peut pas s'ajouter seul. Il faut un fichier dedans
- git commit ;: équivalent à svn commit.Cela permet de versionner les différents changements en local.
- git reset : permet après un ajout de fichier non désiré, de l'enlever des fichiers à commiter
Mettre à jour ses changements locaux en ligne
Une fois les différents changements faits, et tests effectués, il faut mettre notre dépot central sur git hub à jour. Pour cela, on utilise la fonction push de git.
- git push origin branche_de_git
Si on est sur la branche master de notre répertoire git, on écrira :
git push origin masterA chercher
Pour le moment, je n'ai pas encore trouvé de solution pour :
- annuler un "Pull Request"
- récupérer les modifications fait sur le dépot principal ezsystems/ezpublish ( pull ? )
Cet article est le premier, et d'autres articles vont suivre, une fois que mes connaissances Git vont s'améliorer.
Classes et attributs non traduisibles
Sur les sites eZ publish multi langues, nous pouvons définir pour une classe qu'un attribut ne soit pas traduisible. L'attribut ne sera modifiable que via la langue principale de l'objet.
Une fois que tous les contenus sont importants, il est relativement compliqué de modifier une classe, et que les modifications soient prises en compte.
Si vous avez déjà du contenu traduit, et que vous modifiez vos classes en modifiant des attributs en attribute non traduisible, eZpublish vous fournit une méthode simple pour mettre à jour vos attributs.
Dans cet exemple, j'ai limité mon fetch sur la classe "Folder". Voici le script PHP qui permet de gérer le problème :
<?php require 'autoload.php'; $cli = eZCLI::instance(); $script = eZScript::instance( array( 'description' => 'test', 'use-session' => false, 'use-modules' => false, 'use-extensions' => true ) ); $script->startup(); $script->initialize(); $params = array( 'ClassFilterType' => 'include', 'ClassFilterArray' => array( 'folder' ) ); $nodeList = eZContentObjectTreeNode::subTreeByNodeID( $params, 2 ); foreach( $nodeList as $contentNode ) { $contentObjectID = $contentNode->attribute( 'contentobject_id' ); $currentVersion = $contentNode->attribute( 'contentobject_version' ); eZContentOperationCollection::updateNontranslatableAttributes( $contentObjectID, $currentVersion ); } $script->shutdown( 1 );
Billets liés
eZ Role
eZ Role est une extension eZpublish . Elle permet d'exporter/importer les rôles via des fichiers formatés en YAML. Cette extension est encore en alpha, mais vous pouvez déjà d'or et déjà la trouver à l'adresse suivante : http://projects.ez.no/ezinstall
Comme petite histoire pour le dépot, l'extension se nommait à la base eZ Install. L'objectif de l'extension était de pouvoir créer/modifier les classes et les rôles. Comme eZ publish implémente l'utilisation des packages, les différentes fonctionnalités sur les classes étaient redondantes. Je me suis exclusivement porté sur l'import/export des rôles et droits. Je l'ai donc renommée en eZ Role.
Je vais expliquer brievement les quelques points que je juge intéressant, au cas où ca vous donne des idées.
Pour avoir une idée des différents choix techniques, voici une petite idée des différents objectifs de mon extension :
- bonne intégration à eZ publish : histoire de faciliter le plus possible l'utilisation de cette extension, j'ai intégré le plus possible les différentes fonctions au sein des templates déjà existants d'eZ publish.
- format des fichiers simples : l'idée est qu'on peut les lire facilement, ou les créer aussi facilement à la main, histoire de ne pas avoir à passer par l'interface de création de droits. Le format YAML a été choisit pour ça.
Lire/écrire les fichiers YAML
Pour manier les fichiers YAML, j'utilise la classe Spyc . Cette classe fournit des fonctions simples à utiliser.
require_once "spyc.php"; // Charge un fichier YAML dans une variable $data = Spyc::YAMLLoad('spyc.yaml'); // Transforme le contenu d'une variable PHP au format YAML $content = Spyc::YAMLDump( $data );
eZ publish - Téléchargement d'un fichier
Lors de l'exportation, je récupère les droits dans une variable php, avant de la transformer au format YAML. Au lieu d'écrire le résultat de l'exportation sur le serveur en lui même, j'ai fouillé un peu la classe eZFile. Gràce à cette classe, j'ai trouvé une petite méthode me permettant de proposer directement en téléchargement le fichier. Voici les différentes lignes que j'ai utilisé :
eZFile::create( $fileName , false, $content ); eZFile::download( $fileName );
Ces 2 fonctions permettent de créer le fichier, et de le proposer directement en téléchargement, sans écrire sur le disque.
eZSiteInstaller - updateRoles
La classe eZSiteInstaller fournit de nombreuses méthodes assez sympas, tel que updateRoles, addClassAttributes. Elle vaut le détour cette petite classe.
La méthode updateRoles prend en paramètre un tableau, et permet de créer/modifier les différents rôles qu'elle trouve dans le tableau fournit.
Méthode très simple à faire, et qui m'a permis d'écrire qu'une dizaine de ligne pour importer les rôles.
TODO
L'extension va encore subir quelques modifications, tel que l'utilisation des remote_id pour faire la correspondance entre diverses instances eZpublish .
J'hésite dans la possibilité de mettre en place une interface permettant de choisir quelles polices mettre à jour.
eZ publish, Google et le référencement
Après l'installation de mon site sous eZ publish, je me suis mit à étudier le référencement de mon site pour Google. Même si le référencement d'un site est facilité grâce à la gestion simplifiée des urls par eZ publish, j'ai quand même cherché à améliorer le référencement.
Google étant ma principale cible de référencement pour l'instant, je me suis mit à regarder les outils mis à notre disposition par Google. Google Sitemap m'avait l'air d'être très intéréssant. Google étant quand même une référence, je me suis dit qu'il devait bien avoir une extension déjà créer pour générer un fichier comme Google Sitemap le demande.
Et j'avais raison, vous pouvez télécharger ici cette extension Google Sitemaps . La suite est pas des plus compliquée, et bien expliqué sur le fichier install.txt. Après l'avoir uploader et activer, il suffit juste de rajouter un googlesitemaps.ini.append pour rajouter les classes que l'on veut que l'extension prenne en charge.
L'extension mit en place , et bien configuré, on peut y accéder, en allant sur
http://votre_site/layout/set/googlesitemap/content/view/googlesitemaps/2 tel que ce Google Sitemap .
Malheuresement, quand on essaie d'y rajouter ce google sitemaps, Google nous dit que le site web ne correspond pas , qu'il faut qu'on enregistre le site http://votre_site/layout/set/googlesitemap/content/view/googlesitemaps avant de pouvoir enregistrer ce fameux sitemap.xml . eZ publish étant super powerfull :), et grâce au traducteur d'url, on peut faire en sorte pour que notre sitemap soit bien prit en compte.
Pour cela il faut rajouter un nouveau système de redirection d'URL. Il ne faut pas oublier de bien rajouter les / au début. Voici ce que j'ai mit :
Nouvelle URL virtuelle : /sitemap.xml
URL système : /layout/set/googlesitemap/content/view/googlesitemaps/2
Après l'avoir ajouter , on peut enfin accéder au google sitemap gràce à l'url http://votre_site/sitemap.xml, tel que le Google Sitemap de Frefred.
Une petite astuce après avoir ajouter un billet, ou un noeud, tapez dans un shell :
curl -s http://google.fr/webmasters/sitemaps/ping?sitemap=http://www.frefred.fr/sitemap_xml > /dev/null
eZ Publish Certified developer
Migration sous eZ 4.0
Ayant migrer frefred sur ez publish 4.0. Tout s'est à peu prêt bien passé, sauf quelques soucis.
Après ma migration, les flux rss n'étaient plus fonctionnels. La solution a été de les recréer. La version 4.0 ne gère plus les flux rss de la même manière que eZ 3, d'où mon problème de flux rss. eZ Rss va être modifié en conséquence.
Le petit soucis, plus délicat est l'impossibilité de créer de nouveaux noeuds. Je suis à l'heure actuelle obligé de faire une copie d'un billet, et de le modifier.
Voici ce maginifique message d'erreur.
Fatal error: Call to undefined method eZDOMDocument::saveXML() in /.../kernel/classes/datatypes/ezxmltext/ezxmltexttype.php on line 307 Fatal error: eZ Publish did not finish its request The execution of eZ Publish was abruptly ended, the debug output is present below.
PHP5 & eZ publish 4
eZ publish 4.0 est sorti hier. Comme déjà mentionné, eZ 4 est en php5, cela rend donc relativement inutile xampp.
Xampp me fournit php4 et php5 , et me permettait de changer de version de php assez facilement, selon si je désirais travailler sur ez publish, ou ez component.
J'ai donc profité de cette sortie pour passer directement par php5 sur mon ordi , en fesant un petit apt-get
sudo apt-get install php5 php5-cli imagemagick php5-imagick mysql-server-4.1 php5-mysql
Une fois tout installé, j'ai du reconfigurer les virtuals hosts d'apache. Je vais pouvoir finir de migrer frefred en ez4. Frefred devrait passer en ez 4 dans pas très longtemps.
Une fois frefred en eZ 4, je vais pouvoir me mettre à tester eZ FLow, package que j'avais déjà vu à l'oeuvre lors de la conférence eZ Developer
Conférence eZ Developer
Hier après midi, eZ Systems a organisé une conférence autour du développement. Cette conférence a attiré pas mal de développeurs, tel que tigrou , ou Nabil .
Ayant eut l'estomac dans les talons, je suis arrivé en retard, et j'ai malheureusement loupé la présentation de Roland Benedetti pendant que j'engloutissais mon sandwitch.
Paul Borgermans nous a décrit eZ Labs et leur objectifs. C'est un projet très intérréssant, qui devrait permettre à eZ publish de se perfectionner sur différents points bloquants. Bonne nouvelle pour les développeurs, projects.ez.no devraient réouvrir, mais je n'ai pas demandé quand est ce que les inscriptions allaient réouvrir :'(
Il nous a aussi exposé la roadmap pour eZ publish 4, et la fabuleuse extension eZ Find qui tourne autour de solr. Le principal changement pour les développeurs sera à partir de la version 4.x qui aménera un changement dans la syntaxe des templates. Il y aura aussi une augmentation des performances, supérieures à ce que l'on pouvait conclure avec le test de performances qu'on peut retrouver sur ez.no. Pas mal de composants d'eZ Components vont être intégrer, tel que les workflows.
Paul a expliqué rapidement les différents concepts, et les façons de faire pour migrer les extensions de PHP4 vers PHP5. Nous avons eut le droit à une démonstration de la nouvelle extension eZ publish nommée eZ Flow, qui d'après moi a de belles années devant elle.
Damien Pobel, du blog pwet.fr a parlé des sites à gros traffic. Il nous a expliqué les différents systèmes possibles, tel que le cache statique, ou le clustering, avec leur avantage, ainsi que leur inconvénients. Il nous a expliqué l'architecture et les différents concepts qu'il avait utilisé sur un site à très grosse audience, avec des obligations de performance supérieures à ce qu'eZ publish peut fournir. Ce passage fut très intérréssant, même si je doute que j'en aurais un jour besoin pour frefred.fr ...
Cette conférence était très instructive, et intéressante. A quand la prochaine ?

