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

One of my primary postulates towards the new MCE Online Editor is that it supports different button sets, depending on explicit call or preset settings. Actually, presets would stand a much better approach, so let's forget about template declaration for a while. I decided to find out how much work it would require to make the preset approach run.

Ini structure modification

First of all, we have to store the settings we will be using later on. Current button declaration in ezoe.ini looks as follows:

We would need multi-dimentional array with multiple preset-like named blocks instead:

XMLBlock datatype modification

Once we're done with our preset configuration, we have to make the XML Block datatype actually display and store the preset values. First of all, we need to modify the datatype itself (kernel/classes/datatypes/ezxmltext/ezxmltexttype.php):

The example above is not complete, there are other methods to modify, like initialization or (un)serialization ones. This should be enough to run the test, though.

We still have to modify the datatype templates. Again, we'll do the minimum: modify the datatype's class attribute template (design/standard/templates/class/datatype/edit/ezxmltext.tpl) by adding the following code:

Now, all pieces are in their place for the final cuts.

MCE Online Editor modification

First of all, we have to modify the method responsible for collecting the button settings from the configuration files. We locate the eZOEXMLInput handler class and extend the proper method:

All this modification does is choose a proper button preset instead of a general one. It could be more warning-secured, this is the minimum.

This seems to be all, but it is not. The main MCE init template uses run-once operator to make sure that OE init is only run once. This is going to be a problem since OE button configuration is part of the init. We have to remove the run-once operator and allow multiple initializations. Now, I'm not sure at the moment if this is JavaScript-safe, but seems to work fine at first glance. Edit ezxmltext_ezoe.tpl template file and comment out run-once operators:

This should be it.

Summary

As this example shows, a number of kernel-located files have to be modified in order to achieve this functionality. This takes just a couple of minutes once you know what you're doing, but kernel modification won't likely be accepted for premium support, for example. This is why I really hope this modification makes it to the eZ Publish 4.1.0 release, with some 4.0.x backward compatibility mode.

Also, note that this is hardly a substitute for server-side validation of what user is allowed to do within the OE (which ideally should automatically control what a user can do and I hope for that in eZ 4.2+), but stands a great transitional presentation-layer functionality that can be backed up with proper access control. Many projects will suffer if this is not in place...

Last Thursday, during the Open Nordic Conference 2008 eZ Systems handed out its annual awards again. For the eZ Components award, there were four nominees, which are all recognised for their support of the eZ Components project.

The nominees were Stefan Marr and Falko Menge: for the work on the upcoming Extended Reflection component, James Pic: for the work on the upcoming MVC additions, Andreas Schamberger: for contributions to the Template and Translation tie-in functionality, and Freddie Witherden: for the contribution of SVG font support in the Graph component.

This year's eZ Components award has been awarded to James Pic , congratulations!