December 2007

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:

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:

1. ezuser_role - role configuration, 43 was there because of default editor role's limitations, I can skip this one
2. 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'
3. 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')
4. ezsearch_object_word_link - search engine, can be reindexed, so let's skip this one...
5. 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
6. 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:

But that's for another round...

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

This is a collection of common datatypes whose validation has been extended so to verify their uniqueness within given content object attribute. Otherwise, these datatypes behave exactly as their prototypes.

Currently there are two datatypes provided:
- Unique string (based on Text line system datatype),
- Unique URL (based on URL system datatype).

Use these if you want to make sure that a given attribute of a given class never accepts/stores two identical values.

Note: uniqueness is validated globally, which means it will not skip content objects that are drafts, in trash, or unpublished versions! However, multiple versions of the same content object may store the same value (in fact, it would not work otherwise).

Note: uniqueness is validated within the same attribute only, which means that if you use the datatype in two different classes, it will become two independent attributes resulting in two independent uniqueness sets! This may be changed/enhanced in the future.

You can download it form:
http://ez.no/developer/contribs/datatypes/ez_unique_datatypes

I've just noticed that my tag cloud (on the right) changes itself from time to time, even if no new content has been published... This is weird, I'll have to log it ;)

So it's time to touch what I've been sleeping with over last few weeks. Ever since I begun to understand what's under the hood of eZ, I've seen so many possibilities and also... so many things that still have to be done ;)

At this point eZ Publish 4.0 is I'm focusing at, and that's for a number of reasons. First, upcoming hosting problems. Second, lack of extensions ready for this version out there yet. Third, luckily I have the comfort of not having to stick with PHP4 for much longer (at least with current and upcoming projects), and can choose PHP5 instead.

eZ Vote Collector

This is my first extension ever. It hasn't been used in a production environment so far, but is a candidate for a number of projects already.

eZ Vote Collector is an eZ Publish extension which provides a collection of tools that can facilitate collecting and accessing simple one-dimensional user input. It is mostly appropriate for polls, grading, checklists, single question answers.

In some ways it resembles eZ Publish information collection tools. Although it is considerably less complex and universal, it provides some useful and flexible options, that eZ mechanisms seem to lack. Above all, it makes it possible to define valid value range and user timeouts based on object class.

eZ Vote Collector is not an out-of-the-box poll or grading solution, although some templates and packages are planned to be delivered in the following versions. Nevertheless, it should be very easy to implement and use.

And yes, this is for eZ Publish 4.0+, not exactly backward compatible.

You can download this extension from here:
http://ez.no/developer/contribs/hacks/ez_vote_collector