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

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