Ryba's eZ developer's blog

SELF OverLib - eZ Publish JavaScript overLIB library integration

Tue, 24 Jun 2008 09:44:39 GMT

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

{* This is an adhoc declaration, it has no pre-configured settings, *}
{* all the paramters that are not declared will have default OverLib values. *}
{selfoverlib_display(
hash(
'content', 'THIS IS MY OVERLIB TEXT',
'caption', 'THIS IS MY OVERLIB CAPTION',
'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. *}
{selfoverlib_display(
hash(
'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:
http://ez.no/developer/contribs/template_plugins/self_overlib

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

Tue, 24 Jun 2008 00:58:37 GMT

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:

[EditorSettings]
Buttons[]
Buttons[]=formatselect
Buttons[]=bold
Buttons[]=italic
Buttons[]=underline
...

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

[EditorSettings]
ButtonPresets[]
ButtonPresets[]=full
ButtonPresets[]=mini
#...
[ButtonPreset-full]
Buttons[]
Buttons[]=formatselect
Buttons[]=bold
Buttons[]=italic
Buttons[]=underline
Buttons[]=|
Buttons[]=bullist
Buttons[]=numlist
Buttons[]=indent
Buttons[]=outdent
Buttons[]=|
Buttons[]=undo
Buttons[]=redo
#...
[ButtonPreset-mini]
Buttons[]
Buttons[]=formatselect
Buttons[]=bold
Buttons[]=italic
Buttons[]=underline
Buttons[]=|
Buttons[]=bullist
Buttons[]=numlist
Buttons[]=indent
Buttons[]=outdent

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:

{'Button preset'|i18n( 'design/standard/class/datatype' )}:

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:

{*run-once*}
...
{*/run-once*}

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

Blue screen of death

Wed, 28 May 2008 17:41:35 GMT

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

Themes for eZ Publish - discussion

Thu, 22 May 2008 08:10:07 GMT

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:
http://ez.no/developer/forum/suggestions/provide_new_themes

Persistent variables - checked out

Wed, 21 May 2008 16:50:38 GMT

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?

Control

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?

Availability

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.

Cost

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.

Upcomming Summer 2008 eZ

Wed, 21 May 2008 16:36:05 GMT

A busy week expected in the fourth week of June this year:

eZ Publish Community Developer Day, June 18th, 2008

Tutorials, break-out sessions, talks and presentations, barcamp... some topics announced till now include: performance and testing, improving usability & accessibility in eZ publish, web 2.0, OpenID, integration between ez publish and Ajax frameworks, Open office integration, eZ Components, eZ Find, TinyERP integration, microformats...

http://ez.no/developer/news/ez_publish_community_developer_day_june_18th_2008

eZ Conference & Awards, June 19-20th, 2008

The annual eZ Conference & Awards is the largest Open Source CMS event in Europe. This year marks the 6th annual eZ Conference and new this year is that it will be run together with the Open Nordic Conference and the Open Nordic Mobile event. This is without doubt, the biggest event ever held in Europe with main focus on Free Software.

All together more than 1000 people are expected to join during these days. The program will include keynote sessions, panel discussions and valuable exhibiting.

http://conference.ez.no/

PHP Vikinger, June 21st, 2008

PHP Vikinger is an unconference directed towards everyone who wants to learn more about PHP and likes to discuss and meet with new people. Unlike normal conferences, the talks at conferences are determined by the attendees, and not a program committee.

http://phpvikinger.org/

Can't wait!

This year will be my first time to join eZ Community during this series of events.

User-readable cache-block identifiers

Sat, 10 May 2008 12:18:34 GMT

Just as I'm struggling with cache optimization for one of the current projects, I discovered that it would be great if cache-block functionality had one more parameter - a user-defined and user-readable identifier. Being able to clear all the cache by calling this identifier would be a great enhancement. It would be enough if it was implemented at eZ API level, so that users were able to create their own actions (views) to handle it. This would be especially benefitial for caching of custom modules and views, outside content and content tree itself.

Life example: Imagine expensive custom views that require couple of hundreds of SQL queries per view or view/param combination, and can be accessed/managed by a) the owner (of something), b) all other users. Now, leaving these views uncached would be suicidal, and cache-blocks would be quite handy, and there would be only two cache blocks per view (since you either are the owner or not). Now, the additional expectation is that the owner will always have his view up-to-date, which means we can't really cache it for him. Wouldn't it be great to be able to create a button named "Refresh my view", which would cause one particular cache-block (or cache block group) be cleared? In that way, we could cache the owner's view as well, making it possible to let a manual clear only when needed ;)

Variable cache layer... Var-block - wouldn't that be something?

Tue, 22 Apr 2008 17:49:57 GMT

It took me fairly long time to figure out what particular tool available from PHP in my custom software and website implementations was missing from eZ Publish... but I finally got it. It's the ability to dynamically, flexibly cache variables, understood as operation or logic results, stored in a reusable form. Naturally, there is no significant need of caching simple variables defined directly within the pagelayout, just like these:

{def $my_var=345}
{def $my_other_var=hash( 'a', '4023' )}

However, it gets worse not being able to cheaply store an array of ten values, whose fetching/generating cost was over fifty or one hundred SQL queries, several files accessed in the file system, etc.

Problem

The problem seems quite straightforward - out of many caching techniques and layers in eZ Publish, only two are universally useful: the viewcache and the cache-blocks. Unfortunately, both of them store presentation layer results rather than data, and both are quite independent. As a result:

Whenever you crave for variables that will be used by several cache-blocks in the pagelayout, they must be placed outside of cache-blocks themselves. Don't get fooled by the top cache-block apparently holding the variables used further on - it's a coincidence. This may only work if all expiry times are equal for all the blocks and no subtree expiry is ever used (or you've used bugged eZ 4.0.0 for half-a-year, where subtree expiry is simply broken and it's easy to take it as the default behavior), provided that the blocks never got desynchronized. The point is: variables must be kept outside cache-blocks and they will not be cached.
The module result gets generated before the pagelayout, so there's little reusability between their vars.

So what's missing?

My idea is a cache layer halfway between logic/data and the presentation layer. It could be a variable-dedicated cache-block equivalent (maybe a var-block?).

Example: Imagine a website that for each of its node views should be able to access both current node data (data map) as well as root node data in order to make some decisions, calculations, etc. Further, the data could be required by at least three of its cache blocks (with different expiry times, expiry rules and "uncomfortable" locations within the pagelayout). Today that sort of combination requires a substantial...

The var-block as I imagine it would have expiry settings similar to cache-blocks: subtree expiry, expiry ignore, expiry time and a flexible key management. In order to prevent frequent file system access, var-block could serialize variable collections rather than just singles. An additional "collection name" parameter could help organize the blocks within the pagelayout.

Please let me know what you think.

Here's the prototype:
http://ez.no/developer/contribs/template_plugins/self_var_cache

Extendable cache definition list for easy extension cache management

Tue, 22 Apr 2008 13:13:58 GMT

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:
http://issues.ez.no/IssueView.php?Id=12860&activeItem=3

eZ Developer Day - first one in Poland (Warsaw, 15th April 2008)

Thu, 17 Apr 2008 05:17:30 GMT

Polish eZ community has met during the first official eZ Developer Day held in the country. Up to thirty people showed up, representing eZ partners, independent developers as well as users, both experienced and potential. Many of the participants were active Polish eZ Community members. eZ Systems was represented by Bård Farstad, co-funder and CTO (Chief Technical Officer) and our native system developer Łukasz Serwatka.

The meeting, which was held in the heart of capital city of Poland, included the introduction to eZ Systems and their flag products, including eZ Flow (both functional and technical demos), the discussion on eZ Publish roadmap and its future releases.

The community had a chance to present their recent implementations as well as share and discuss their problems or requests (I hope we didn't kill Łukasz during this part, as we tried to clear up issues that had been awaiting "closure" for quite some time).

Bård attempted to provoke some community commitment, so that it grows stronger and bigger, but I'm not sure how much response that would get. It got little while there, but there might be some follow-up. Seems like the active will remain active in their ways anyways.

Personally, I am very glad that we had this meeting. Maybe there was too little technical/developer detail, but everyone had an opportunity to bring things up... Maybe it lacked some social part, during which the community would get to know each other little better and discuss things in a more informal, open way. One suggestion though: make that a weekend event because socializing for most people in Poland hardly ever works during the weekdays! ;)

Installing eZ Publish 4.0 on home.pl servers

Sun, 24 Feb 2008 18:49:57 GMT

Home.pl is Poland's largest hosting provider. Despite the fact that they do not have eZ Publish-dedicated services and their machines do not exactly match its standard requirements (FreeBSD, PHP in CGI mode), it is possible to successfully deploy eZ 4.0 installation in their shared hosting environment. Since many people seem to have problems getting through the installation wizard, here's some tips.

Organization

Put the files in a subdirectory and use the subserver functionality (in other words: point the domain to that subdirectory). This is not only because of some possible namespace conflicts (0:/bin is reserved by the system), but also for good organization and easy management. Since a subserver cannot reach above its own root, remember to create a /tmp dir for any temporary files.

Wizard problems

If you try to install version 4.0 from scratch, you may encounter some early problems. This is due to the fact that some systems functions are called during setup tests that cannot handle an error in this environment (which is FreeBSD-like by the way). You can easily cope with that by simply commenting out a line in /kernel/setup/ezsetuptests.php:

$ginfo = posix_getgrgid( posix_getgid() ); // around line 593

This is practically never used again, so don't worry, you may revert the changes after installation, or even leave it like that.

Limitations

For a number of reasons, this hosting will only serve a number of use scenarios. The major problem is a script-like CRON, which works on PHP rights, which means it has the same limitations. It will be impossible to safely run large, exhausting notifications or maintenance scripts... Lack of CLI makes it even harder, and can only be partially compensated by enabled system() PHP function. Still, with a little practice it is possible to tame it, especially with servers' above-average efficiency.

Brainstorm: *.ini priority vs. extension settings

Tue, 19 Feb 2008 20:14:10 GMT

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

Default settings [/settings/*.ini]
Default extension settings [/extension/EXT/settings/*.ini] (only for custom *.ini files)
Extension siteaccesses [/extension/EXT/settings/siteaccess/SITEACCESS/*.ini.append.php]
Siteaccesses [/settings/siteaccess/SITEACCESS/*.ini.append.php]
Extension overrides [/extension/EXT/settings/override/*.ini.append.php] (for custom *.ini files as well as other *.ini files)
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 ;)
http://ez.no/developer/forum/suggestions/ini_priority_vs_extension_settings

Re: Is eZ Publish 4.0 like Microsoft Vista?

Sun, 17 Feb 2008 05:23:55 GMT

Inspired by Bruce Morrison's post in his blog: http://suffandnonsense.blogspot.com/2008/02/is...

eZ Publish 4.0

I kind of understand the disappointment with minor revolution of the current big version 4.0, although I had known (more or less) what to expect when I was awaiting it few months back. You can ask yourself: was PHP5 more of an improvement, or maybe a necessity? If the latter, the smaller was the step ahead, indeed. Nevertheless, I am very glad this step was made, no matter what the version is called, for reasons that must be obvious. Back to the expectations, I can only imagine how 3.x introduction was different (greater) to 4.x, because I've only known eZ Publish since 3.8.x or so (BTW: have to admit I gave up after several attempts with 3.5... it beat me!).

eZ Publish 4.0 maintenance mode, 5.0 eZ Components-based rebuild

Bruce's suggestion is to put eZ Publish 4.0 at its rather stable state into feature freeze mode, while concentrating efforts on taking full advantage of the maturing eZ Components to produce the next big version (5.0) from scratch. I have to say that I like this idea for similar reasons:

There's always a risk of ending up with Vista-like model,
It will probably take equally long (or even longer) to incorporate majority of eZ Components into eZ Publish (with compromises possible/necessary on the way), than it would have taken to build a completely fresh thing,
Past limitations and problems will probably become even more concreted,
I believe that eZ Components with all their features would prolong the application's lifespan, secure its potential and make future port to PHP6 easier (I'm not sure if another platform "rewriting" would be a good idea).

There's another thing, but it deserves to be covered in its own paragraph.

Solid content model vs. feature richness

In my comparatively short experience with eZ Publish, I have already dug deep enough to see its few weaknesses, especially regarding the content and storage models. Don't get me wrong, by no means would I call eZ Publish weak, it's just that it has its limitations defined and there are only so many things you can do with it without hacking or severely extending.

Now, I do understand how big part various "rich" features play in the eZ business model and in those of many eZ partners. For example, extensions such as eZ Flow or Web interfaces that make it possible to have an advanced out-of-the-box product with time required for implementation significantly reduced. Having seen how business-oriented eZ people are, I do not expect this direction to be given up at any stage (and I like that).

However, I hope that that direction does not prevent from improving the application at its core, that is the foundation for all eZ business after all. Unlike presentation layer or even more advanced extensions, which can be developed independently, core upgrades would be rather difficult to be introduced by means of hacking the kernel. I'd like to be optimistic, but don't see alternative storage models or advanced class features coming any time soon. New rebuild could be an ideal opportunity to make eZ Publish even more versatile and fit to solve even more advanced content management tasks (and not only!).

Summing up

It doesn't seem like this issue is up for a discussion, but I haven't heard anything official on eZ Publish 5.0, yet. So, maybe it is not too late ;)

If you ask me, I think I could live in this 4.0 feature freeze mode... if what I was waiting for was a completely new eZ Publish 5.0 in a year or two, with even greater core features and as few compromises as possible.

"Require flag" on the object attribute level

Sun, 10 Feb 2008 19:02:55 GMT

Lately we've been having this discussion with André about different suggestions regarding ways to improve eZ content model:
http://ez.no/developer/forum/suggestions/in...

It was started by my own suggestion to introduce an additional flag that would sort of require objects attributes to be present (or, in other words, impossible to remove from the presentation/XHTML layer). And that actually resulted from my early eZ days questions on how does eZ Publish actually deal with missing attributes...

Back to the additional "require attribute flag"

"Required" flag, that we have today, suggests by semantics that the attribute is required, however, that is not so. I hope I was the only user not to go in depth with this issue, however I expect otherwise. Today's "required" should in my opinion be called "Value required" or "Require value", because that's what the checked flag actually causes.
Why isn't the default behavior of attribute validation such that all attributes are required to be present?
Doesn't lack of all/any of the solution ideas mentioned above (or other) make the editing process vulnerable to any manipulation of the presentation layer? Isn't that comparatively easy to simply omit all uncomfortable attributes, for example datatype-based CAPTCHA, limits, identifiers, etc.?
"Require all required" as a class attribute/flag actually doesn't make much sense with current "Required" meaning. What would it mean? Require all required values? This is why I suggest that there should be a separation of "required flags". We could leave today's required as "Require value" flag, as I suggested above. Then, there should be an additional flag that would decide whether the attribute itself is required to be present in the editing process. This would be much more flexible than earlier "require all required" and at the same time seems to make that idea useless.

Discovery

Well, I finally found some time to look at it again, especially into the eZ Publish kernel. I followed the path that an attribute takes from the edit view all the way to the datatype itself. Actually, I found out that no matter what you do, no matter how you manipulate the presentation layer, the attributes of a content class always reach input validation function in their datatype. So it is up to the given datatype to take further steps, but it's already a good news: it is possible to force attributes without any kernel/lib modifications! Here's an example (ezstring datatype):

function validateObjectAttributeHTTPInput( $http, $base, $contentObjectAttribute )
{
if ( $http->hasPostVariable( $base . '_ezstring_data_text_' . $contentObjectAttribute->attribute( 'id' ) ) )
{
// THE REST OF THE CODE
}
$contentObjectAttribute->setValidationError( ezi18n( 'kernel/classes/datatypes', 'Attribute missing in the presentation layer!' ) );
return eZInputValidator::STATE_INVALID;
}

A quick update on my four points above: I still believe the new flag would be a useful solution. I still believe there's space for both "required flags". I'm still not sure why checking an attributes presence is not default behavior in most (or all) out-of-the-box datatypes. But at least now I have it under control! ;)

And here's how the new flag could work:

function validateObjectAttributeHTTPInput( $http, $base, $contentObjectAttribute )
{
if ( $http->hasPostVariable( $base . '_ezstring_data_text_' . $contentObjectAttribute->attribute( 'id' ) ) )
{
// THE REST OF THE CODE
// Including use of: $contentObjectAttribute->validateIsRequired()...
}
elseif( $contentObjectAttribute->attributeIsRequired() )
{
$contentObjectAttribute->setValidationError( ezi18n( 'kernel/classes/datatypes', 'Attribute missing in the presentation layer!' ) );
return eZInputValidator::STATE_INVALID;
}
}

What do you think?

eZ My Collected Info - manage your objects' collections

Wed, 06 Feb 2008 22:32:47 GMT

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

Busy 2008...

Thu, 31 Jan 2008 02:35:28 GMT

Didn't get much time to write this month... Projects, international partner meeting, certification... Seems like 2008 is even more busy. Some big projects running, some more and bigger coming up, our little team is growing. It's good that February will at least be a bit longer this year ;)

eZ User Create Limit

Thu, 31 Jan 2008 02:28:28 GMT

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:
http://ez.no/developer/contribs/datatypes/ez_user_create_limit

Finally a certified eZ Publish developer...

Wed, 23 Jan 2008 06:19:01 GMT

Back after a while of silence... lot's of projects, meetings, trips in the meantime...

But I am happy to share the good news - I have finally passed an eZ Publish developer certification with 80% correct answers (including a broken one!). Not that I have tried before, first take - first passed. Not as big challenge as I had expected, still requires proficiency in pretty much every single area that a developer should be aware of, so I was glad I had reviewed some general topics the day before ;) Few ambiguous or debatable questions, but I can't actually say if I've got them right or not - maybe they were not that ambiguous after all. Majority of questions - straightforward and clear.

And the link: http://ez.no/certification/verify/222415

Custom top level nodes - is that possible? Round I - exploration...

Sat, 29 Dec 2007 22:39:12 GMT

Are custom top level nodes possible? It is especially thrilling when one has encountered top level node problems ;) I forgot about this issue for quite some time, but now it's back. As I'm typing this post, I know that it won't provide an ultimate answer tonight, and some quick NO answers are within reach. Still, I want to give it a try. Round I - no particular goals, just exploration.

I run a fresh installation of eZ Publish 4.0.0 with just English language, URL addressing. When ready, I manually clean all the cache, just in case.

So what top level nodes do we have? Out of five available, there are three that seem to have much in common (all deal with content in a similar fashion), and just one of them - the media tree root - has a two-digit node ID (43) that will be easier to look for, than content's '2' ;)

Let's look for some clues in the application. I start with /settings directory as I know that it is where the top level nodes are actually declared. But just in case, I search through all the *.ini files. Only two files contain relevant 43 string: menu.ini in this context is only used for navigation part and tab configuration, no key information there, so let's skip it for now; content.ini contains the very declaration:

[NodeSettings]
# The node ID of the normal content tree
RootNode=2
# The node ID of the user tree
UserRootNode=5
# The node ID for the media tree
MediaRootNode=43
# The node ID for the setup tree
SetupRootNode=48
# The node ID for the design tree
DesignRootNode=58

The above code doesn't seem to suggest that extending top level was ever planned, but let's move on.

I log into the administration interface and create a folder called 'Custom', just under eZ Publish content tree root node. I memorize the new IDs: 59 as node ID and 57 as content object ID (the IDs you get may be different). I will need those as soon as I figure out what to destroy in the database ;) Basically, what I will try to do is to move this #59 node folder to the top level.

Let's look for some clues in the database now. I run a database search for any 43-like values in the entire table set (assuming that 43 will be the only way of referencing parts of the database that have something in common with the media root node). I get around 15 table hits, 6 of which seem to be relevant. Now, by analysing the tables, I come up with the following decisions:

ezuser_role - role configuration, 43 was there because of default editor role's limitations, I can skip this one
ezurlalias_ml - URL aliases (multilanguage?), I update my 59 node just in case, md5 has to be calculated for lowercase 'custom' (probably a more complex rule behind this, but lowercase will do in this case):
UPDATE ezurlalias_ml SET text='Custom', text_md5='8b9035807842a4e4dbe009f3f1478127' WHERE action='eznode:59'
ezurlalias - URL aliases, I add a missing record, same md5 hash:
INSERT INTO ezurlalias VALUES ('content/view/full/59', 0, NULL, 1, 1, 0, '8b9035807842a4e4dbe009f3f1478127', 'custom')
ezsearch_object_word_link - search engine, can be reindexed, so let's skip this one...
eznode_assignment - I have absolutely no idea what this table's for, so I just take a guess and change depth:
UPDATE eznode_assignment SET parent_node=1 WHERE id=36
ezcontentobject_tree - actual tree, I modify path string, parent node, identification string and depth - all for my folder:
UPDATE ezcontentobject_tree SET path_string='/1/59/', parent_node_id=1, path_identification_string='custom', depth=1 WHERE path_string='/1/2/59/'

Just before I touch my eZ Publish interfaces, I clear all the cache, just in case again...

And here we go. From this moment on I have a sixth top level folder node. I don't have a tab and navigation part for it, yet, but I can access it by system URL: /content/view/full/59... Not only that... it seems to properly hold newly created child nodes. I can navigate through this new, hidden structure without visible problems, but...

...something must be missing, it's obvious when you search the kernel and libraries for 'MediaRootNode', 'RootNode', or 'UserRootNode', and see this:

// /kernel/classes/ezcontentbrowse.php
static function nodeAliasID( $nodeName )
{
if ( is_numeric( $nodeName ) )
return $nodeName;
$browseINI = eZINI::instance( 'browse.ini' );
$aliasList = $browseINI->variable( 'BrowseSettings', 'AliasList' );
if ( isset( $aliasList[$nodeName] ) )
return $aliasList[$nodeName];
$contentINI = eZINI::instance( 'content.ini' );
if ( $nodeName == 'content' )
return $contentINI->variable( 'NodeSettings', 'RootNode' );
else if ( $nodeName == 'users' )
return $contentINI->variable( 'NodeSettings', 'UserRootNode' );
else if ( $nodeName == 'media' )
return $contentINI->variable( 'NodeSettings', 'MediaRootNode' );
else if ( $nodeName == 'setup' )
return $contentINI->variable( 'NodeSettings', 'SetupRootNode' );
else
return false;
}

But that's for another round...

eZ Human CAPTCHA - preventing bots from submitting spam in your eZ website

Mon, 24 Dec 2007 09:39:44 GMT

eZ Human CAPTCHA is a simple eZ Publish extension which provides a collection of tools that make it easier to use session-based CAPTCHA techniques for preventing bots from submitting any unwanted data to your website.

The default way to use it is to add Human CAPTCHA-datatype-based attribute to your content class. From that moment on any edit action taken on objects representing that class will require CAPTCHA code to be provided. This will secure both editing as well as collecing info. This method is completely automatic and does not require any development whatsoever.

The other method is meant for developers, who want their own modules and/or templates secured. There are two template operators responsible for initiating/displaying a token and validating the code respectively. Optionally, it is possible to directly call a method responsible for token validation in PHP.

Since the quality of the CAPTCHA token image is of critical importance, this extension can be further extended by applying custom image filters. An image filter is simply a set of PHP instructions to generate a token image.

Search the Web if you need further information on CATPCHA itself.

You can download this extension from:
http://ez.no/developer/contribs/applications/ez_human_captcha