Extensions: hacks, datatypes, cronjobs, exchange, integrations, solutions, 3rd party, workflows

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)

Extendable cache definition list for easy extension cache management

Tuesday, 22 April 2008, 15:13
Categories: Extensions
Tags: extensions, clear cache, cache, extendable list, extend, fine-grained cache control

Back after a longer while... wasn't on holiday, though ;)

About a week ago, while developing my fifth or tenth extension with its own, custom caching layer, I caught myself trying to clear that cache with eZ standard "Clear cache" button. To none of my surprise, it never worked, but after few attempts I decided to see why ;)

The Fine-grained cache control in the administration interface turned out to be a definition-type of array - easy enough to be made extensible with some effort. Why should a developer be in need of creating custom tools then? Let's hope the team picks up the idea soon:

Comments (0)

Brainstorm: *.ini priority vs. extension settings

Tuesday, 19 February 2008, 21:14
Categories: Extensions
Tags: extension, settings, ini, priority, siteaccess, override, brainstorm, ini files, security, convenience, flexibility

Just looking at the priority that the settings files follow:

Gunnstein wrote at http://ez.no/doc/ez_pub...site_management

1. Default configuration settings (/settings/*.ini)
2. Active extension siteaccesses (/extension/*/settings/siteaccess/[name_of_siteaccess]/*.ini.append.php)
3. Siteaccesses (/settings/siteaccess/[name_of_siteaccess]/*.ini.append.php)
4. Active extensions (/extension/*/settings/*.ini.append.php)
5. Global overrides (/settings/override/*.ini.append.php)

It seems like the main/siteaccess/override model for settings files and its advantages weren't introduced to extensions' engine. Here's some issues I see:

1) Let's call it convenience and flexibility: One great feature of the three-step system (and - as far as I understand - one of its key functions) is that we have untouched original *.ini files with all/default settings present, the rest are siteaccess-dedicated or global overrides. This is a great in case of any upgrades, modifications, or simply for reference. I don't see this possibility for extension settings (unless we move the overrides of custom *ini files to the global overrides, but that isn't that convenient we have 10 or 20 extensions...).

2) Security: This actually results from the above. If there is no general override, all your general custom settings will most probably be kept in the main *.ini file. That may include project-dedicated values, passwords, options, etc. The file should then always be called *.ini.append.php, which is easy to forget about.

3) Rules: While with the general settings siteaccesses overrule general files and global overrides overrule all of them, the rules seem less clear with extension settings... that includes both the priorities and the names (look at the security point).

Here's what it could look like (just a quick idea):

  1. Default settings [/settings/*.ini]
  2. Default extension settings [/extension/EXT/settings/*.ini] (only for custom *.ini files)
  3. Extension siteaccesses [/extension/EXT/settings/siteaccess/SITEACCESS/*.ini.append.php]
  4. Siteaccesses [/settings/siteaccess/SITEACCESS/*.ini.append.php]
  5. Extension overrides [/extension/EXT/settings/override/*.ini.append.php] (for custom *.ini files as well as other *.ini files)
  6. Global overrides [/settings/override/*.ini.append.php]

Of course, that would require little changes to directory structure, might be difficult.

I put this on the forum, haven't given this as much thought as I would like to, so... let's see what happens ;)

Comments (2)

eZ My Collected Info - manage your objects' collections

Wednesday, 6 February 2008, 23:32
Categories: Extensions
Tags: informaction collection, collected info, collections

eZ My Collected Info extension gives front-end access to one's collected info. The ownership of the collections is determined based on the ownership of the content object that collected the information. In other words, it is not who sent the information, but whose object it was sent to, that is considered the owner, and thus can browse/read, and optionally delete.

The extension makes it possible to browse though the collections by class and then by object (a tree-like menu is provided for easy access). A detailed class-level configuration is possible to allow/disallow collection deletion, custom identifiers, and custom/default templates.

The extension comes with two module views and two access functions for a flexible management. The standard browsing view can be accessed through: /index.php/siteaccess/mycollectedinfo/browse

Read the settings/mycollectedinfo.ini file's comments for more information.

You can download the extension from: http://ez.no/developer/contribs/hacks/ez_my_collected_info

Comments (0)

eZ User Create Limit

Thursday, 31 January 2008, 03:28
Categories: Extensions
Tags: extension, class, administration

Some time ago I started to develop a simple extension that would provide some sort of control over what users can do in terms of creating objects of given classes. This is mostly due to the fact that eZ Publish access control system only provides qualitative rules (and no quantitative ones).

The extension introduces a datatype that doesn't validate if user is trying to go beyond one's defined limits, and couple of template operators that can help produce functional templates (for example hide a NewButton if it should not be visible in the first place).

This is the first extension I wrote that actually extends into administration interface tabs and has it's administrative views. This way two levels of limit assignments were possible to introduce. First, a detailed configuration in the ini file for defining default limit values for particular classes or users. Second, advanced filtered operations on the actual limits. For example, it is possible to stop particular user from creating any more objects (for example comments) at any point in time, without affecting any other users or this particular user's other create capabilities.

You can download it form:

Comments (0)