One variable to handle the namespaces

[tormec]

Now we can talk with some lines of code on hand. Some important notes.

1. The page with the menu can have any name.
2. If you specify the path of particular page containing the menu (i.e n0:n1:page), then all the namespcaes under that given namespace (i.e n0:n1:n2:..) will load the specified page.
3. If you specify a parent and a child namespace (i.en0:n1:page1 and n0:n1:n2:page2), first we check if we are in the child namespace and then in its parent. This is necessary because it's used a foreach loop, over the namespaces, and, above all, the function strpos. In fact, this means that the parent namespace is always found even if you are in its child.
4. I used a regex to split the list of paths because the function getNS($ID) always removes the last sequence of : and, so, it was difficult to distinguish 'page' from ':page'.

I know it could be a little bit confused, so take your time if you want to make some tests. In the meanwhile, I'm at your disposal for any other explanation.

[tormec]

Basically, a typical scenario would be: pageA, n0:n1:page1, n0:n1:n2:page2, which means (in the following order):

1. if you are in n0:n1:n2 then load page2;
2. if you are in n0:n1 then load page1;
3. if you are neither in n0:n1:n2 nor in n0:n1 then look for pageA in the current namespace or in its parents.

But you can also say (but this is a rare occurrence): pageA, pageB, n0:n1:page1, n0:n1:n2:page2 which means:

1. ditto
2. ditto
3. ditto
4. if there isn't pageA then look for pageB

Therefore, to repeat:

1. first try to load the page containing the menu from a specific namespace beginning from the most deeper level all the way up;
2. then try to load the page containing the menu from the current namespace or, if there isn't, from its parents;
3. (rare occurrence) if were specified more then one page, to be load from the current namespace, the list of pages is read from left to right.

[turnermm]

If I understand you correctly you would like a setup where the parent namespace governs children unless there is a specific namespace overlay specified for a child. Your suggestions would stray too far from the original and so wouldn't be backwardly compatible. I've made a somewhat simpler effort to do the same: https://github.com/turnermm/Dokuwiki-Nav-Overlay/archive/namespace.zip In this version, the only difference from the original is that if you want a parent:overlay to be inserted into the overlay DIV, then you specify the nsoverlays name of that parent as parent* (this could be parent:child*). If there is no specific overlay for the current namespace, then the parent is used, if it exists; otherwise the default page overlay is used. Try it; I've only briefly tested it.

[tormec]

If I understand you correctly you would like a setup where the parent namespace governs children unless there is a specific namespace overlay specified for a child.

Right.

Your suggestions would stray too far from the original and so wouldn't be backwardly compatible.

Well, you may be right.

I think your idea to use the syntax parent* it's a good compromise solution and it seems to work.

There is only one problem: a user, without read permission, con view the overlay page even if it is in a "private" namespace. You can reproduce this behaviour when you navigate to a "private" page, log out and then try to open the menu. A solution could be to use:

        if (auth_quickaclcheck($ID) >= AUTH_READ) {
            $insert = p_wiki_xhtml($overlay);
        }

[turnermm]

ACL checks could be useful But it seems to me more useful to check the ACL for the overlay pages and to suppress the action link where the user does not have rights. I've made these changes in the namespace branch: https://github.com/turnermm/Dokuwiki-Nav-Overlay/tree/namespace

[tormec]

Tested and the result is even better because now, if the user doesn't have a read permission isn't even shown the link to the menu, so he won't think "oh! a broken link" :)