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