eZ blog...

SELF OverLib - eZ Publish JavaScript overLIB library integration

Tuesday, 24 June 2008, 11:44
Categories: Extensions
Tags: OverLib, JavaScript, integration, template operator

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.


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/


{* This is an adhoc declaration, it has no pre-configured settings, *}
{* all the paramters that are not declared will have default OverLib values. *}
'html_value', 'THIS IS THE ANCHOR',
'width', '225',
{* This is a preset-based declaration. You do not have to define anything *}
{* except for the preset and the content. *}
'preset', 'admindefault',
'caption', 'Help: how to use it?',
'content', 'It order to use this functionality, you must...',

Read doc/readme.txt for further details.

This extension is available at:

Comments (4)

Class-attribute-based button sets in new MCE Online Editor

Tuesday, 24 June 2008, 02:58
Categories: Lab
Tags: eZ MCE Online Editor, class attribute, eZOE, XML editor, hack

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):

// Class constants declaration
const BUTTONS_FIELD = 'data_text2';
const BUTTONS_VARIABLE = '_ezxmltext_buttons_';
// Fetch and store post data - method modification
function fetchClassAttributeHTTPInput( $http, $base, $classAttribute )
$column = $base . self::COLS_VARIABLE . $classAttribute->attribute( 'id' );
$buttons = $base . self::BUTTONS_VARIABLE . $classAttribute->attribute( 'id' );
if ( $http->hasPostVariable( $column ) )
$columnValue = $http->postVariable( $column );
$classAttribute->setAttribute( self::COLS_FIELD, $columnValue );
$buttonsValue = $http->postVariable( $buttons );
$classAttribute->setAttribute( self::BUTTONS_FIELD, $buttonsValue );
return true;
return false;

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:

<div class="block">
<label>{'Button preset'|i18n( 'design/standard/class/datatype' )}:</label>
<select name="ContentClass_ezxmltext_buttons_{$class_attribute.id}">
{def $preset_list=ezini( 'EditorSettings', 'ButtonPresets', 'ezoe.ini' )}
{foreach $preset_list as $preset}
<option value="{$preset|wash()}"{if eq( $preset, $class_attribute.data_text2 )} selected="selected"{/if}>{$preset|wash()}</option>

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:

function getEditorButtonList()
if ( $this->editorButtonList === null )
$contentClassAttributeID = $this->ContentObjectAttribute->ContentClassAttributeID;
$contentClassAttribute = eZContentClassAttribute::fetch( $contentClassAttributeID );
$buttonPreset = $contentClassAttribute->DataText2;

$oeini = eZINI::instance( 'ezoe.ini' );
$buttonPresets = $oeini->variable( 'EditorSettings', 'ButtonPresets' );

if( !in_array( $buttonPreset, $buttonPresets ) )
$buttonPreset = $buttonPresets[0];
$buttonList = $oeini->variable( 'ButtonPreset-' . $buttonPreset , 'Buttons' );

$contentini = eZINI::instance( 'content.ini' );
$tags = $contentini->variable('CustomTagSettings', 'AvailableCustomTags' );
$hideButtons = array();
$showButtons = array();

// filter out underline if custom underline tag is not enabled
if ( !in_array('underline', $tags ) )
$hideButtons[] = 'underline';

// filter out pagebreak if custom pagebreak tag is not enabled
if ( !in_array('pagebreak', $tags ) )
$hideButtons[] = 'pagebreak';

// filter out relations buttons if user dosn't have access to relations
if ( !eZOEXMLInput::currentUserHasAccess( 'relations' ) )
$hideButtons[] = 'image';
$hideButtons[] = 'objects';
foreach( $buttonList as $button )
if ( !in_array( $button, $hideButtons ) )
$showButtons[] = $button;
$this->editorButtonList = $showButtons;
return $this->editorButtonList;

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.


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...

Comments (2)

Blue screen of death & eZ Publish

Wednesday, 28 May 2008, 19:41
Categories: eZ Publish
Tags: blue screen of death, ez publish, bsof, site.ini, global override

Does eZ Publish have its own blue screen of death? Yes, it does! It is the setup wizard on a production site. And how do you make go off? Well, it's quite enough to have anything about site.ini global override messed up: transmission error, solid syntax error, etc... Over thirty eZ installations and deployments, I was calm enough to figure it out just in seconds, but it still made me sweat... And imagine a beginner... ;)

Comments (4)

Themes for eZ Publish - discussion

Thursday, 22 May 2008, 10:10
Categories: Random thoughts
Tags: blog, CMS, themes, GUI, UI, theme, skin, templates, tpl, ezwebin, forum, CRM, shop, webshop, design, eZ Publish themes, eZ Publish skins, eZ Publish templates

An interesting topic emerged among suggestions in the ez.no forum, regarding themes for eZ Publish. I thought it was an interesting theme, so here's the link: http://ez.no/developer/forum/suggestions/provide_new_themes

And here's what I think:

I have to agree that easier theme management and exchange would help to widespread eZ Publish. Personalization seems like the big thing right now and even if it's not about that, ability to implement selected themes easily might be one of the key factors when deciding on a particular CMS.

However, we need to realize what theme engines we're talking about when trying to incorporate that idea into eZ Publish. Most themes that I know of are prepared for systems that have a very isolated and precise functionality due to the kind of system they are (CMS blogs, forums, shops, web galleries, CRMs, or CMSs with preexisting module sets, etc..), and whose content model, internal structure etc. do not change.

Meanwhile, with eZ Publish we have a content engine that makes it possible to handle most of the above functionalities and nearly everything can be customized. With the system we don't have preset roles for a forum, for a blog etc - we have to arrange that ourselves, minding all the implementation details. There's entire list of other dimensions that have to be taken under consideration (sections, access rules, caching, custom overrides, class modifications, structure...). Many of those things are handled or reach to the presentation layer (*.tpl), many of them in a customized way, again.

If some of the themes available for those other, isolated systems, have to be versioned along with the core (for example: theme for version 2.0, theme for version 2.1, etc..), how do we want to handle the change with eZ Publish and its complexity? Would that be possible without limiting of what's one of eZ's key features - extensibility? Wouldn't that concrete the development of the core in some ways?

If I look at ezwebin, I see an intelligent GUI, not a skin. This interface is crucial for developers to ease the learning curve and also pick up some good practices, but with around 40 eZ Publish implementations, we haven't yet had a customer who would fit into ezwebin precisely (or sometimes - at all).

Yet, another perspective.

Much as I appreciate the marketing goals, I don't think they are that important for this level of CMS (and ezwebin versions do just fine for that matter), and nowhere near as important as the core of the system. And there's only so much time eZ people have. I believe we're all much better off getting solutions such as eZ toolbar or eZ Flow (or bug-free stability and security) rather than color variations of backgrounds...

To be continued... here:

Comments (1)

Persistent variables - checked out

Wednesday, 21 May 2008, 18:50
Categories: Lab
Tags: node, cache, cache-block, persistent variables, persistent var, var, full view, objects, serialize, hash, array

Well, I gave up my variable caching ideas, even if just for a while. I wanted to master the standard caching techniques (there had always been an excuse, some extension to write...). And I am very glad now because it starts to feel like having real control over my eZ implementations ;)

Among things that I've discovered were persistent variables, recommended by Gaetano in response to my var cache struggling, and completely unknown to me before. Even if not a complete substitute, still a very nice solution, one of those that you ask yourself how you could have lived without...

So what's so great about persistent variables without going into much detail?


They don't require any additional control. Persistent variables are compiled as part of viewcache, which means that they only expire when the viewcache expires, and they naturally follow the smart viewcache clear rules as well. What more control needed than that?


They seem to be available at all times, if not cached before, calculated upon request for the full view that stores them.

This also means that expiry times of cache-blocks that depend on that data do not have to be synchronized in any way (not that it is even possible...). Gaetano mentioned the relationship between viewcache and cache-block clear being an important issue, but I haven't been able to spot any unwanted or problematic link, yet.


Persistent variables can indeed store a variety of data useful for further generating parts of the pagelayout. Even if the singular cost of viewcache generation goes slightly up, this is usually benefitial: once generated, the variables are simply there as long as needed. And in most cases all I need is some $node-related operations.

Even if some more expensive data is to be fetched, once you're through the effort of composing you persistent hash, it's there!

Some minor disadvantages.

Since the variables are physically serialized, it is impossible to pass complex objects, such as $node directly. You have to precisely choose which simple data you want (numbers, strings, arrays, hashes...). Luckily, arrays do just fine in most cases, so that's probably as much as one may need before going straight to a fetch outside of a full view.

Then, some includes seem to be able to damage a persistent var that had been generated few lines before, so you have to carefully test if the persistent var set is available in all the full views required. Haven't found an exact rule, yet.

If you're interested if a very nice use example, look here in the comments.

Comments (0)