- Publié le 02 Mars 2007 à 20:37
J'aime bien changer de fond d'écran régulièrement, seulement il n'est pas toujours facile de trouver de jolies photos. Via le Planet Ubuntu Users et un billet sur Motho ke motho ka botho, j'ai découvert qu'on pouvait télécharger automatiquement l'image du jour de Wikimedia Commons et des Wikipedias Anglais et Allemand dans la résolution souhaitée (ou au plus proche).
J'ai écrit le petit script suivant permettant de mettre en fond d'écran l'un de ces clichés, rien de bien compliqué. Si aucun fond disponible ne vous convient, il est possible de définir un fond par défaut sur le disque.
#! /bin/sh
# usage: dlbg.sh [default|commons|enwiki|dewiki-bdk] [scale|tile|center|seamless]
POTD="Documents/Wallpapers/potd-1280x1024.jpg"
# image par défaut
DEFAULT="Documents/Wallpapers/galaxie.png"
wiki="${1:-default}"
type="${2:-scale}"
if [ "$wiki" = "default" ] ; then
feh --bg-$type "$DEFAULT" &
else
[ -f "$POTD" ] && rm -f "$POTD"
wget "http://tools.wikimedia.de/~daniel/potd/potd.php/$wiki/1280x1024" -O "$POTD"
feh --bg-$type "$POTD" &
fi
Il utilise feh, un petit programme permettant d'afficher et de mettre en fond une image. Il a un petite fonctionnalité intéressante lorsqu'on utilise pas GNOME ou KDE : lorsqu'il met une image en fond d'écran, il écrit la ligne de commande nécessaire dans le fichier .fehbg. Ainsi, pour lancer un windows manager alternatif comme openbox avec le même fond d'écran, il suffit d'insèrer la ligne suivante dans le fichier .xsession servant à lancer sa session :
openbox & wmpid=$!
eval `cat $HOME/.fehbg` &
# éventuellement, divers autres trucs lancés au démarrage
wait $wmpid
Aujourd'hui en tapant bin/dbbg.sh commons scale ça donnait un drôle d'effet avec cette chenille :-)
- Publié le 01 Mars 2007 à 23:31
Un sacrée boite à BMX ! Il a pas de bol, ses pneus ont visiblement éclatés, enfin la prochaine fois il mettra peut être au moins un casque ou mieux, il s'abstiendra...
- Publié le 27 Février 2007 à 23:52
Ce billet aurait pu s'appeler RSS and eZ Publish on Steroïd ou bien RSS ou autres exports de contenu avec eZ Publish ou encore Utilisation de différents layouts dans eZ Publish ... La technique présentée dans ce billet a été inspirée par le message de Bertrand Danes sur le forum eZ Publish France et pour certains points techniques par l'extension Google Sitemap de Sergey Shishkin qui utilise aussi ce mécanimse.
Depuis un moment, j'avais envie de gérer plus finement et d'étendre les flux RSS sur pwet.fr (et maintenant sur t-ka.net :-)). Les principaux problèmes étant pour moi l'impossibilité de changer l'URL des items et l'impossibilité d'aggréger plusieurs attributs dans la balise description. Il est à noter aussi qu'eZ Publish n'inclut pas l'élément <guid> dans les flux RSS, ce qui empêche la détection correcte de mises à jour par les lecteurs RSS. J'avais aussi écrit un petit patch pour pouvoir inclure un feuille de style XSLT dans les fils RSS pour eZ Publish 3.8.x, mais l'utilisation d'un layout et du système de template pour créer des fils RSS rend complètement obsolète le patch en question... Et puis j'ai un petit projet personnel en tête qui devrait utiliser assez intensivement cette technique, enfin si il se concrétise un jour...
Pour en revenir, à cette technique, elle est assez simple à mettre en oeuvre ( easy comme toujours ;-)). Il suffit de créer un layout spécifique pour le RSS. Mais qu'est ce qu'un layout ? Il s'agit en fait de spécifier quel fichier est utilisé comme template de pagelayout. On peut aussi le faire avec une règle d' override , mais dans le cas d'un layout, il est également possible de spécifier le "Content-Type" que générera celui-ci. Dans le cas de mes fils RSS, mon layout.ini.append.php contient une section qui ressemble à :
[rss]
PageLayout=rss_pagelayout.tpl
ContentType=text/xml
Ces lignes signifient que les pages appelées via l'URL /layout/set/rss/ utiliseront comme template pagelayout le fichier design/<mon_design>/templates/rss_pagelayout.tpl et tout cela générera du XML. Le fichier en question est très simple et on retrouve le point central des pagelayout traditionnels (si je puis dire...) :
<?xml version="1.0" encoding="iso-8859-1"?>
<rss version="2.0">
<channel>
<language>fr-FR</language>
{$module_result.content}
</channel>
</rss>
Appeler l'URL /layout/set/rss/ revient à appeler le vue full du noeud racine dans ce pagelayout, ce qui donnera probablement des résultats bizarres. Il est par contre tout à fait possible d'appeler une vue personnalisée (au hasard rss_full) sur un noeud quelconque (par exemple 119) via l'URL /layout/set/rss/content/view/rss_full/119. Il reste alors à faire en sorte que design/<mon_design>/templates/node/view/rss_full.tpl et ses éventuels override génèrent du RSS et le tour est joué ! Pour améliorer les performances, il vaut mieux rajouter cette vue dans la liste des vues à mettre en cache dans le paramètre CachedViewModes dans la section ContentSettings dans le site.ini.append.php des siteaccess concernés.
Pour aller encore plus loin, on peut enfin utiliser le traducteur d'URL d'eZ Publish pour donner des adresses plus sympas aux fils voire permettre l'utilisation d'un node_id en paramètre pour avoir des fils RSS "automatiques". Par exemple, le fils RSS des commentaires du billets où je parlais de l'inclusion de vidéo de Dailymotion ou de Youtube dans eZ Publish via un custom tag est disponible à l'adresse : http://pwet.fr/rss/feed/commentaires/64219 qui correspond en fait à http://pwet.fr/layout/set/rss/content/view/rssco/64219. Il ne reste donc plus qu'à adapter les templates pour ajouter les liens vers ces fils RSS pour les rendre disponibles.
- Publié le 25 Février 2007 à 14:04
eZ Publish est fourni avec un certain nombres de scripts à lancer en ligne de commandes. À ma connaissance, il n'y a aucune documentation sur ces outils pourtant très utiles et qui peuvent faciliter la vie du développeur que ce soit en phase de développement ou en maintenance. Tous ces scripts sont à lancer à partir de la racine du site eZ Publish. Pour connaitre les options disponibles de chacun de ces script, il suffit de les lancer avec l'option --help. Les scripts détaillés ici sont dans le répertoire bin/php sauf clearcache.sh et cleanup.php.
Vider les caches : bin/shell/clearcache.sh
clearcache.sh est un script shell qui permet de vider les différents cache. Il est utile lorsque PHP4 version CLI n'est pas installé, puisqu'il utilise uniquement des commandes shell pour effectuer les différentes tâches. Pour la même raison, il est très rapide. Je l'utilise principalement lors du développement pour supprimer tous les caches d'un site en utilisant un alias bash correspondant à :
$ bin/shell/clearcache.sh --clear-all
$ bin/shell/clearcache.sh --clear-all --var-subdir=XXX
où XXX est le répertoire du cache pour le siteaccess visé, par exemple plain.
Vider le cache de contenu d'un noeud ou d'une arborescence : ezcontentcache.php
ezcontentcache.php permet de vider le cache de contenu d'un noeud ou d'une sous arborescence. Il peut être utile par exemple, si dans un site vous n'avez pas configuré les options SmartCacheClear permettant de vider les caches des noeuds dépendants de ceux qui ont été mis à jour.
Vider des caches de manière fine : ezcache.php
ezcache.php permet de vider certains caches assez finement en spécifiant uniquement un cache particulier pour un siteaccess donné. Par exemple, si vous ajouter un Custom tag comme comme dans mon billet sur l'inclusion de vidéos, il est possible de vider uniquement le cache template-override. Pratique sur un site en production, surtout si le site est très visité et si le(s) serveur(s) sont un peu justes...
Manipuler les données : ezsubtreeremove.php et ezsubtreecopy.php
Comme leur nom l'indique, ces scripts permettent de supprimer ou copier (donc déplacer...) des données dans l'arborescence. Ils sont utiles pour manipuler de gros volumes de données, là où l'interface web est limitée par le timeout PHP.
Compiler les templates : eztc.php
La compilation des templates est probablement l'opération la plus gourmande lors de la regénération des caches après un vidage complet. Une utilisation typique de ce script est lors de la mise en production d'un site. On vide tous les caches, mais avant d'activer le site, on compile l'ensemble des templates pour éviter une trop forte montée en charge. Une autre utilisation est la mise à jour des templates, on force la compilation des templates et ensuite, il suffit de vider les caches de contenu pour avoir la nouvelle version sans avoir vider complètement les caches.
Vérifier syntaxiquement les templates : eztemplatecheck.php
Utile lors du développement, celui-ci permet de vérifier simplement la syntaxe des templates sans avoir à parcourir l'ensemble du site avec les options de debug.
Faire le ménage dans la base de données : flatten.php et update/common/scripts/cleanup.php
Ces scripts permettent de faire le ménage dans la base de données en supprimant les données temporaires ou plus utilisées. flatten.php permet de supprimer par exemple toutes les versions non publiées d'objet. À manipuler avec précautions donc. cleanup.php permet de supprimer des données inutilisées. Je l'utilise par exemple pour supprimer les données des sessions expirées qui encombrent la table ezsessions.
