Few weeks ago, I participipated to the eZConference & Open Nordic 2008 in Skien in Norway. There's some things you must now about Norway :

• It's difficult to get there, even by plane, or car or camel...
• It's absurdly expensive (150€ to do 40km in cab)
• There's no night
• Most of Norvegian is speaking english, hopefully !
• They eat caviar for breakfast
• Salmon is absurdly cheap

By the way, as you can imagine, Norway is a big country with few persons in it. So there's a lot of space and they are very concerned by the quality of their life : cities are clean and services are perfect.

Open Nordic 2008

The conference stood in the Skien Ibsenhuset, a very large conference hall, where both conferences, eZConference and Open Nordic, happened.

The main subject on eZ were :

• Multiple file upload in 4.1 : it has been made in complement of the webdav feature which does not work on all platforms (Did I say Windows ???).
• OE 5 : integrating Tiny MCE, this WYSIWG editor rocks ! After having worked with HTMLArea, FCKEditor and the former OE, it seems to be the more powerfull and intuitive work ever done. At least, it is a very visible work.
• Support for OpenOffice.org and Microsoft Office document import and export in eZ via a nested toolbar in the editor : you can open content directly on an eZ instance via a Java connector and modify it as you want. When you save it, it will send the data to the eZ instance and update your website. Very powerfull and I guess very similar to the Sharepoint feature.
• Site factory and CSS Editor : two features which are made to ease the deployment and configuration of eZ websites. The first is a console tool allowing to deploy in one command an entire site with a specified configuration (it uses REST). The second one is a kind of webmaster gadget in full java which will allow people to modify their design in few clicks : you activate a design mode on your frontend and then you can select each element of the page and then change some defined css values, like background-color or what you want.
• ezComponents integration : eZGuys are close to completely lighten the kernel libs by integrating the eZComponents. The most important change will happen when the integration of the ezcTemplate will be effective. It's a big step for the eZCommunity because we will have to deal with a strict template engine (at last !).
• And some new components like Document and Search.

By the way, it was a great time, sharing our knowledge and drinking beers at the at the pub...

Oslo

And then I travelled a bit to reach Oslo... Country, sea and half-light :

Conclusion

It was a great trip, lot of emotions, lot of exchanges between people from different countries, and one pledge : next year I will be there, Monseigneur.

:-D

PHP 5.3 will have a new cool feature: phar. A phar is to PHP what a jar is to Java. I spent a little time to see how easy it would be to make our latest eZ Components release into a workable phar.

First of all, a phar can be build from a directory structure with a few functions only:

<?php 
$phar = new Phar(
    'ezcomponents-2008.1.phar', 0,
    'ezcomponents-2008.1.phar' );
$phar->buildFromDirectory(
    dirname(__FILE__) . '/ezcomponents-2008.1',
    '/\.php$/');
$phar->compressFiles( Phar::GZ );
$phar->stopBuffering();
?>

This build script will create a phar from the directory contents in "ezcomponents-2008.1", but only include the PHP files (See http://php.net/phar.buildfromdirectory). We compress all the files and with stopBufferingwe write the file to disk. With the following code, we can now use the phar in our application:

require 'ezcomponents-2008.1.phar';

It is also possible to run a bit of code when including the phar. You do this, by adding a stub to the phar. To do so, we include the following code just before the compressFiles() call:

$stub = <<<ENDSTUB
<?php
Phar::mapPhar( 'ezcomponents-2008.1.phar' );
require 'phar://ezcomponents-2008.1.phar/Base/src/base.php';
spl_autoload_register( array( 'ezcBase', 'autoload' ) );
__HALT_COMPILER();
ENDSTUB;
$phar->setStub( $stub );

After we re-create the phar with "php -dphar.readonly=0 build.php". The new phar once required will now setup the autoload mechanism of the eZ Components. The following script demonstrates that it actually works:

<?php
require 'ezcomponents-2008.1.phar';
$f = ezcFeed::parse( 'http://derickrethans.nl/rss.xml' );
foreach ( $f->item as $item )
{
    echo $item->title, "\n";
}
?>

Conclusion: phar is cool!

I released the first package of eZFTP (release 0.0.1). But take care, this is a testing release which is not 100% reliable and which can be bug prone !

For now you will be only able to browse your contents in a FTP client...

Download it now

I released the first package of eZFTP. But take care, this is a testing release which is not 100% reliable and which can be bug prone !

For now you will be only able to browse your contents in a FTP client...

Download it now

This is just reminder for me which SQL queries execute on eZ Publish database when switching for example from eng-GB to nor-NO language.

Its been a while and after chatting with gabriele and roberto at the eZ conference i've started to look at this again.

We've created a roadmap for the upcoming eZ Components (2008.2) release. In this release our main focus is to add MVC support. Where most frameworks dedicate a specific router, controller and view, the MVC implementation in eZ Components will only consist of very loosely based parts. For each of the specific parts of MVC we will provide one or more default implementations, as well as detailed information on how to write your own implementations of a Model, View and Controller. Of course most of those implementations will be done through Tie-in components. At the moment we're creating a requirements and design specification. If you're interested in participating in this discussion, please drop by on our mailinglist.

Besides this main focus, we will also enhance some of the critical components that the upcoming version of eZ Publish will require. Please see the full roadmap.

As someone who spends most of the day testing and developing eZ Publish, I always have multiple instances of eZ Publish checked out. Different versions, customer installations, etc. Previously I’ve created a new virtual host in Apache for each installation — very painful indeed.

I went searching for a better solution — one that wouldn’t need reconfiguring of Apache. I could have used rewrite rules to map part of the URL to a directory, however rewrite rules will get messy fast. I want my configuration to be as clean and simple as possible. Some researching later and I stumbled upon the VirtualDocumentRoot directive. From the VirtualDocumentRoot documentation:

The VirtualDocumentRoot directive allows you to determine where Apache will find your documents based on the value of the server name. The result of expanding interpolated-directory is used as the root of the document tree in a similar manner to the DocumentRoot directive’s argument.

Sounded perfect. Here’s my new and improved virtual host configuration I came up with using VirtualDocumentRoot:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<VirtualHost *:80>
    <Directory /www>
        Options FollowSymLinks
        AllowOverride None
        Order allow,deny 
        Allow from all 
    </Directory>

    VirtualDocumentRoot /www/%1

    RewriteEngine On
    RewriteRule content/treemenu/?$ /index_treemenu.php [L]
    Rewriterule ^/var/storage/.* - [L]
    Rewriterule ^/var/[^/]+/storage/.* - [L]
    RewriteRule ^/var/cache/texttoimage/.* - [L]
    RewriteRule ^/var/[^/]+/cache/texttoimage/.* - [L]
    Rewriterule ^/design/[^/]+/(stylesheets|images|javascript)/.* - [L]
    Rewriterule ^/share/icons/.* - [L]
    Rewriterule ^/extension/[^/]+/design/[^/]+/(stylesheets|images|javascripts?)/.* - [L]
    Rewriterule ^/packages/styles/.+/(stylesheets|images|javascript)/[^/]+/.* - [L]
    RewriteRule ^/packages/styles/.+/thumbnail/.* - [L]
    RewriteRule ^/favicon\.ico - [L]
    RewriteRule ^/robots\.txt - [L]

    RewriteRule .* /index.php [PT]        

</VirtualHost>

How it works

This is the same virtual host setup as explained in the eZ Publish installation documentation, except for 2 new directives.

1. VirtualDocumentRoot /www/%1

   Instead of DocumentRoot, we use VirtualDocumentRoot to dynamically set the document root depending on the Host HTTP header. The %1 specifies that we only want the first part of the host name. For more information about VirtualDocumentRoot, check out the mod_vhost_alias documentation.

2. RewriteRule .* /index.php [PT]

   [PT] (pass through to next handler) was added to make sure the document root is set using VirtualDocumentRoot. If omitted the default DocumentRoot setting will be used, resulting in paths looking like /www/index.php, instead of /www/trunk/index.php.

Examples

To illustrate how the mapping between the host header and directories on your file system, here are some examples:

This extension integrates a popular OverLib JavaScript library with eZ Publish. Beside providing a simple template operator for automated generation of OverLib instances, it introduces a fallback configuration architecture for even easier and flexible use. It is possible to use pre-configurable presets, ad-hoc configurated calls as well as any combination of the two approaches.

Description

For each OverLib instance, a JavaScript code must be generated within HTML document that requires a number of paramter variables to be passed. Those variables control what text/content will be displayed, how the window will behave, what it will look like, will it be sticky, and so on. There are several problems with literally defining this JavaScript code in the templates:
- It is not easy to deal with special characters and escape strings, especially in the eZ template language,
- Static JavaScript code is not flexible in case of any future changes, especially across big projects.

To cope with those problems, a simple template operator is introduced. The operator automatically deals with any special chars that could destroy JavaScript code. It is also configurable by means of presets. Any number of presets can be defined and each preset can define any combination of OverLib settings.

To ensure that overlib gets always generated properly and the JavaScript has every variable required, a setting fallback system is introduced. The following priority is used to determine the values of OverLib parameters:
1) Ad-hoc declarations (within the template itself, when using the operator),
2) Preset declarations (if a preset was declared and used)
3) Default system values.
Any combination and order of parameters can be used.

Note: Please read the selfoverlib.ini configuration file for further details.
Note: Find out more about OverLib library at http://www.bosrup.com/web/overlib/

Examples

Read doc/readme.txt for further details.

This extension is available at:
http://ez.no/developer/contribs/template_plugins/self_overlib