Heureux fan de XBMC, anciennement Xbox Media Center, désormais porté sur windows/mac os et linux, j’ai fini par décider d’utiliser XBMC Live, le Live CD / installeur automatique pour ce merveilleux Media Center Opensource.

Micro rappel sur les fonctionnalités de la bête:

• Lecture audio/video sans paramétrage, HD comprise
• Gestion sortie numérique/analogique en audio/video parfaite
• Librairie de media avec gestion très avancée des films & séries TV. Scrappers automatiques de recherche de films & séries, y compris en français.
• Look très professionnel
• Configuration minimale
• etc…

Bref, XBMC propose donc entre autres XBMC Live, un Live CD qui peut aussi installer automatiquement XBMC, sur un périphérique USB bootable ou un disque dur. L’installation prend 10 minutes montre en main, et livre un PC de salon avec la résolution de la TV, le son numérique directement accessible, et un ubuntu aux petits oignons.

Je ne pensais sincèrement pas que ce niveau de convivialité à l’installation avait été atteint. Bravo !

Yesterday, I stumbled on twitter upon a link to a list of the 20 most popular plugins for wordpress, drupal and joomla (the original website doesn’t respond at the moment). I decided to build a quick comparison of each of these plugins to eZ Publish.

It’s not a great list, of course, but it will say if that feature is natively available, can be implemented using simple configuration & templating, is available using existing extensions, or doesn’t exist at all.

http://spreadsheets.google.com/pub?key=tUJEPE1NzQrC3O0xUpQLSDg&output=html 

I hope this table can show at least a little that eZ Publish really is feature rich, and will maybe encourage our community (including me !) to  help promote our favourite CMS by developing amazing new features ;)

Lors de l’écriture de tests unitaires pour eZ Publish, je me suis retrouvé confronté à un besoin spécifique: charger des templates sans passer par le système de design. Les tests n’utilisant pas d’extension, et cette situation étant voulue, il n’était pas possible d’utiliser les templates accessibles via la ressource “design:”.

Et il s’avère _ bien évidemment, sinon je n’aurais rien écrit _ que c’est parfaitement possible, et même assez bête: tout comme la ressource design ( $tpl->fetch(’design:foo.tpl’)) permet de charger un template résidant dans un design, une autre ressource existe:
file. Celle-ci permet de référencer un template via son chemin, relatif à la racine de eZ, ou absolu:

$tpl->fetch( ‘file:/tmp/mytemplate.tpl’ )

Des fois que ça serait utile à quelqu’un…

Nouvelle extension intéressante sur projects.ez.no: Acces Keys. Elle implémente une série d’opérateurs de templates permettant d’intégrer dans les designs des accélérateurs permettant d’accéder rapidement aux sections standard ou à des sections personnalisées (par exemple S pour “recherche”, présent dans les recommandations des sites gouvernementaux anglais).bbc.co.uk ou vbulletin.com les implémentent effectivement.Bien pratique pour l’accessibilité, et sans doute un sacré gain de temps lors d’une navigation via un terminal mobile.

While working on my ezgoogleanalytics eZ publish extension, I ended up having to merge two MySQL tables, and implemented this with a SQL query I think is worth mentioning.The situation is as follows: two tables with a similar structure, ezgoogleanalytics_pagedata_total and ezgoogleanalytics_pagedata_incremental. They’re used to store statistics, the total one being used for long term data, while the incremental one is updated several times a day. At the end of a day, data from the incremental table have to be added to the total table.

The tables structure:

CREATE TABLE `ezgoogleanalytics_pagedata_total` (
`node_id` int(10) NOT NULL,
`url` text NOT NULL,
`pageviews` int(10) NOT NULL,
`uniquepageviews` int(10) NOT NULL,
`entrances` int(10) NOT NULL,
`exits` int(10) NOT NULL,
`timeonpage` int(10) NOT NULL,
`bounces` int(10) NOT NULL,
`newvisits` int(10) NOT NULL,
PRIMARY KEY  (`node_id`,`url`(255)),
KEY `url` (`url`(255)),
KEY `node_id` (`node_id`)

I first tried a simple inner join (SELECT … FROM table1, table2 WHERE table1.id = table2.fid), but hit a wall since some elements can be in total without being in incremental, while some can be in incremental without being in total, and others in both. This means that depending on the situation, we could have to either UPDATE or INSERT elements. And I didn’t want to use multiple queries. I consider that when executing such operations, reducing the amount of data transferred from MySQL to PHP always improves performances.

The goal was then to INSERT items from incremental into total, but UPDATE the total items to the sum of total+incremental if the item was already existing in both tables. Two distinct features can be used here: INSERT… SELECT, and INSERT… ON DUPLICATE KEY UPDATE. The first one will insert into one table the result of a select from another, while the later will perform an update on the first table if the insert leads to a DUPLICATE KEY error. In my situation, the update had to perform a sum of statistics colums (all but node_id and url).

Here’s the final result:

INSERT INTO ezgoogleanalytics_pagedata_total
(node_id, url, pageviews, uniquepageviews, entrances, exits, timeonpage, bounces, newvisits)
SELECT * FROM ezgoogleanalytics_pagedata_incremental AS incremental
ON DUPLICATE KEY UPDATE
 pageviews = ezgoogleanalytics_pagedata_total.pageviews + VALUES( pageviews ),
 uniquepageviews = ezgoogleanalytics_pagedata_total.uniquepageviews+VALUES(uniquepageviews),
 entrances = ezgoogleanalytics_pagedata_total.entrances+VALUES(entrances),
 exits =ezgoogleanalytics_pagedata_total. exits+VALUES(exits),
 timeonpage =ezgoogleanalytics_pagedata_total. timeonpage+VALUES(timeonpage),
 bounces = ezgoogleanalytics_pagedata_total.bounces+VALUES(bounces),
 newvisits = ezgoogleanalytics_pagedata_total.newvisits+VALUES(newvisits)

We INSERT to total the result of a SELECT from incremental, and if the row already exists, sum up the stat values from incremental & total: pageviews = total.pageviews + VALUES( incremental.pageviews ). VALUES will use the elements provided in the INSERT call that led to the DUPLICATE KEY UPDATE, in our case the result from the SELECT.

I haven’t really tested the performances of this operation, but it will get the job done !

Following the post I wrote a few days ago ( Late thinking: google analytics & eZ publish ), I started writing the so-called extension, and finally commited a working version today.

Working… yes, working. But the featureset is still a tad limited. I consider that this extension currently has 3 features.

Analytics API

An open API that lets you request data from analytics from within eZ publish. This is an example of how it is used:

<?php
$analytics = new eZGoogleAnalytics();

$request = new GoogleAnalyticsDataRequest();
$request->setDimension( ‘pagepath’ );
$request->setMetric( ‘pageviews’ );
$request->setStartDate( ‘2009-01-01′ );
$request->setEndDate( ‘2009-06-30′ );

$data = $analytics->getData( $request );
?>

This API is extremely generic & open on purpose; the gdata API offers an incredibly flexible request system, and I didn’t want to limit it (even so… nevermind). The extension will gradually implement higher-level function based on this API.

Pagedata

This is the current real world feature of the extension.

In the beggining, I wanted to replace the viewcount feature of eZ publish with data coming from Analytics, instead of having to parse a not-so-reliable apache access log. I actually ended up doing something else, even though I’m still thinking of implementing the viewcount feature as a “consequence” of pagedata.

This feature uses a script (bin/php/pagedata.php) that fetches analytics data for EVERY url ever accessed on your account. It attempts to translate each URL to a node ID, and finally stores page statistics for the node ID or URL in a local table. Incremental updates are handled.

Based on these statistics, you can use the googleanalytics/pagedata fetch function to retrieve statistics about any node or URL of your website. Included: page views, entrances (number of times the page was the first visited), exits (number of times the page was the last visited), timeonpage (total time spend by non exiting visitors on the page), bounces (number of times the page was the only visited in a session)…

Tracker operator

This barely deserves the name of feature, but it’s here anyway: a template operator, googleanalytics_tracker, can be used to integrate the javascript tracking code in your pages based on your INI settings. It supports both the new (ga) tracking code and the legacy (urchin) one.

Feedback is appreciated, either on this post, or in the project’s forum on projects.ez.no.

This is a draft I wrote for myself over the last hour. It summarizes a few ideas for a google analytics integration in eZ publish. I figured it would be worth sharing.

Google analytics integration (ezga)

Idea

Integrate standard analytics data to eZ publish, in order to provide a _ possibly configurable _ dashboard as well as a set of fetch functions.

 

Possible features

Get the 10 most viewed pages (D: ga:pagePath, M: ga:pageViews)

Get number of pages viewed, number of visits for specific URL (D: ga:pagePath, M: ga:pageViews,ga:visits, FILTER: ga:pagePath=/url/alias)

 

These should actually be provided by an open implementation of the GData protocol. This API would be usable:

    - as-is from the template engine

    - from PHP code (custom operators maybe ?)

    - usable from fetch functions using a trick: a dynamic module.php that checks an INI file and builds custom fetch functions using developer input. The referenced function is then implemented in PHP using the referenced classs. Neat eh ?

Technical Analytics API notes

Requests are performed using a 2 dimensions matrix, provided one dimension (for instance a page’s title (content/ga:pagePath) along with a metric (visitor/ga:pageviews).

 

Requesting metrics doc:

http://code.google.com/intl/fr-FR/apis/analytics/docs/gdata/1.0/gdataProtocol.html#requestingMetrics

 

Metrics reference:

http://code.google.com/intl/fr-FR/apis/analytics/docs/gdata/gdataReferenceDimensionsMetrics.html

Je viens de tomber suite à un article parlant du stack GLAMMP sur la documentation de Gearman. Personnellement, jamais entendu parler avant aujourd’hui, et j’ai la nette impression d’être passé à côté de quelque chose de fort.Gearman implémente en quelques mots un dispatcheur (mais non, ce n’est pas un anglicisme) de tâches. Concrètement, un serveur TCP acceptant en entrée des demandes d’exécutions de tâches (calculer ceci, convertir cela…), et se charge de transmettre celle-ci vers le serveur (Worker) le plus approprié, pour enfin retourner le résultat.Sur ce petit schéma innocemment emprunté au site officiel, on peut voir que le langage dans lequel on travaille n’a pas à être homogène entre Client et Worker. On peut envoyer depuis du PHP, et implémenter en C, ou SQL… tout langage supporté. Les API dans les différents langages sont documentées, et sont dans l’ensemble très intuitives. Je note par contre que le client PHP est implémenté sous la forme d’un package PEAR, développé par Brian L. Moon, l’auteur de l’article original (tiens tiens). Petit bémol en ce qui me concerne, surtout au vu de la documentation du package, malheureusement assez proche de ce que l’on voit souvent chez PEAR: une doc d’API acceptable, mais peu de tutoriels permettant de se faire une idée de la librairie en quelques minutes. Dommage.Cependant, Gearman me donne quelques idées pour eZ publish ou tout développement web… pouvoir déléguer, en synchrone ou asynchrone, des traitements lourds à un serveur distant ouvre des perspectives juteuses. A suivre !

Quelques années auparavant, je m’étais demandé comment implémenter une de ces saletés de Payment Gateways eZ publish… et je n’avais rien trouvé. Alors que la documentation existe, et sans doute depuis très longtemps… tout bêtement dans le dossier doc/ du CMS. Ca peut énerver :)Bref, dans le dossier doc/shop de eZpublish, par exemple disponible sur SVN, on trouve pas mal d’infos qui devraient à priori permettre d’implémenter une de ces sales bêtes. Ca peut quand même être utile.

Mieux vaut tard que jamais…  écrans.fr, le site cinéma de liberation, a publié aujourd’hui une lettre ouverte de plusieurs acteurs du monde du cinéma opposés à HADOPI, qu’ils jugent fumeuse, peu efficace et fruit d’un lobbying massif. Depuis le temps qu’on le dit.Ce n’est pas dans tous les cas comme si cela allait servir à quoi que ce soit. Il était certain que la loi allait passer en l’état compte tenu de la parité actuellement en place au sein de notre gouvernement, mais cela montre tout de même que contrairement aux affirmations de Christine Albanel, tous nos artistes ne considèrent pas les français comme des “pirates à l’origine de la mort de la culture en france”.

Mon avis rejoint le leur: la diffusion et l’existence même de la culture est en train de changer, et toute défense becs et ongles que nos acteurs de l’ancien modèle pourront opposer ne feront que repousser l’échéance. Il est certain que des gens vont en pâtir, que des sociétés importantes devront se réorganiser, mais n’est-ce pas le cas de la plupart des changements majeurs d’une société ?

En passant au delà des considérations numériques sur la place du téléchargement _ légal ou illégal _ au sein de la culture, je reste médusé devant la capacité de notre gouvernement à faire passer en force une loi pourtant critiquée par de nombreuses instances, officielles ou non, des artistes, justement attaquée par l’opposition politique au cours de débats. Beaucoup me diront que ça a été le cas de beaucoup de lois votées au cours de ces dernières années, mais… est-ce une justification suffisante ? Notre république ne montre-t-elle pas ses limites, au sein d’un pays censé être un exemple de démocratie ? A méditer…