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 ;)
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:
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
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 node ID of the normal content tree
# The node ID of the user tree
# The node ID for the media tree
# The node ID for the setup tree
# The node ID for the design tree
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:
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:
static function nodeAliasID( $nodeName )
if ( is_numeric( $nodeName ) )
$browseINI = eZINI::instance( 'browse.ini' );
$aliasList = $browseINI->variable( 'BrowseSettings', 'AliasList' );
if ( isset( $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' );
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: