When no path is specified, root namespace appears to be selected

[sinkva]

Desired behavior is as stated in docs: "no path is specified, the current namespace is selected" But current behavior seems to be when no path is specified, root namespace is selected

Release 2023-04-04 "Jack Jackrum" nspages plugin Installed version: 2023-04-20 Your last update: Wed, 03 May 2023 02:50:41 -0400

[gturri]

Thanks for this bug report.

I am not able to reproduce it.

Here is what I did to try to reproduce it:

• I created the pages: sandbox:start, sandbox:test
• on the page sandbox:start I put the content <nspages>
• what I observe is a TOC with pages start and test (which is what is expected)

Could you please give me more context in order to reproduce that issue? For instance some precise steps I could take in order to reproduce that issue? Or perhaps a link to a page of your wiki which shows that issue?

[sinkva]

On 5/3/23 2:32 PM, Guillaume Turri wrote:

Could you please give me more context in order to reproduce that issue? For instance some precise steps I could take in order to reproduce that issue? Or perhaps a link to a page of your wiki which shows that issue?

Here's a link to an example page in the website: http://kuo1.com/mem/doku.php?id=2023-05-03_nspages_test:start

username: test password: test781

---

If you look in the sidebar, you can see that nspages is showing everything that the "test" user can see at the root level, not the "2023-05-03_nspages_test" namespace level.

The simplenavi plugin returns the correct list of pages in the namespace.

Hope this helps!

• Tim

[gturri]

Ah, so the issue appears in the sidebar, ok.

I may have a fix, it would be awesome if you can test it on your side. In the file lib/plugins/nspages/namespaceFinder.php please turn the function

private function getCurrentNamespace(){
    return '.';
}

into

private function getCurrentNamespace(){
    global $INFO;
    return isset($INFO) ? $INFO['namespace'] : '.';
 }

(if you prefer applying a patch directly, here it is:

diff --git i/namespaceFinder.php w/namespaceFinder.php
index d730dde..94a80e0 100644
--- i/namespaceFinder.php
+++ w/namespaceFinder.php
@@ -33,7 +33,8 @@ class namespaceFinder {
     }

     private function getCurrentNamespace(){
-        return '.';
+        global $INFO;
+        return isset($INFO) ? $INFO['namespace'] : '.';
     }

     private function isRelativePath($path){

)

In order to test it you should:

• empty the cache of your browser and the cache of your dokuwiki
• test it from different pages (because this fix may be too simple as far as dokuwiki cache is concerned)
• if your sidebar is displayed when you edit a page then please also check while editing

If you can test it and if it fixes your issue then I'll merge it (but, to be honest, it may require a bit more work once I get feedback from you)

[sinkva]

It's getting closer, but not quite fixed.

Using nspages in the sidebar, if I switch to another namespace, then nspages still reports the list of pages in the previous namespace. If I purge the page cache, nspages (in the sidebar) reports the current namespace.

But if I go to another namespace, then come back, the "another namespace" gets listed by nspages in the sidebar.

Again, purging the page cache fixes the nspages list (in the sidebar).

You can see this behavior by going 1) to the "test" namespace, then 2) click on the "home" icon: http://kuo1.com/mem/doku.php?id=2023-05-03_nspages_test:day_1

[sinkva]

Perhaps see what the "simplenavi" code does? The output isn't as nicely formatted as nspages, but it gets the current namespace (listed in the sidebar) without any cache/purge issues...

[gturri]

Thanks for this feedback. I think I understand the current issue: the namespace is computed in the handle method but the output of this method is cached by dokuwiki. The simplenavi plugin resolves the namespace in the render method, where it's always evaluated. However the resolution of the namespace is a bit more complex in nspages than in simplenavi (because it can handle more cases, with several possible syntax, because it makes sure that the user input cannot be used to create a security breach), so it's interesting to be able to cache it rather than re-doing the exact same checks and computation every time a page with nspages is displayed. Except in the case of a sidebar. I'll try to come up with a way to handle this properly while still handling correctly the existing usages

[gturri]

I tried something: I added an option -sidebar which leads to evaluate dynamically the current namespace.

You can test it by downloading this tarball https://github.com/gturri/nspages/zipball/fix147 and configuring your sidebar with <nspages -sidebar [and potentially other options]>

If that works for you I'll merge it.

[sinkva]

Sorry, the "fix147" tarball goes back to always displaying the root namespace in the sidebar. Even with the -sidebar option :-(

But nspages in the start page of the namespace works correctly.

[sinkva]

Good observation about the simplenavi plugin being less secure.

simplenavi exposes the existence of a namespace that the "test" user doesn't have permission to read.

nspages does not even show that namespace. Gold star!

[gturri]

Thanks for this feedback. It seems there is indeed something I did not completely understood with how Dokuwiki handles some global variables. I've made a new version and took the time to setup a locally a wiki with a sidebar so I could test it locally, so I'm pretty confident it should work fine this time. You can download the new version at the same url as before (ie: https://github.com/gturri/nspages/zipball/fix147 ). I'll merge it once you confirm that it works for you with the -sidebar option.

[sinkva]

Success! Woo-hoo!

Now, some questions/tweaks for the sidebar...

And I'm using the vanilla Bootstrap3 theme.

1) Can the list of pages be compressed vertically? Where/what in the css should I modify things, if that's the right place? 2) The current page is highlighted in bright solid blue. Where/what in the css should I modify things, if that's the right place? 3) The with the "-h1" option selected, the namespace itself gets listed as itself. Is there a way to have nspages use (perhaps?) the first h1 title in the start page of the namespace (similar to the -h1 behavior of pages)?

See here: http://kuo1.com/mem/doku.php?id=2023-05-03_nspages_test:day_0

[gturri]

Thanks for testing it. I'll try to find a moment merge it and update the doc today or tomorrow.

About your questions. First of all: I'm not familiar at all with the bootstrap3 theme, so I can only give generic answers.

1. Last time I checked it seemed impossible to deliver css built dynamically (ie: to change the css a plugin provide based on some user input). (Except with css directive directly in the html, but that's such a bad practice that I don't want to go there). So, if you want to have some custom css directive you should either change locally the css file provided by the plugin (but that would be overriden next time you update it), or, according to https://www.dokuwiki.org/faq:css , through a template. But I'm afraid I don't have more clues about the good practices here. That being said, FTR: nspages displays its content in an enclosing div with class plugin_nspages (then it depends on the printer you select), so it could be a starting point to configure some css directives.

2. I'm not too sure. It seems related to the class active set on the li which encloses the link. I'm not too sure where it comes from. I can try to take a closer look in the next few days. 3: I'm not too sure right now, I'll try to take some time to look into in the next few days

[gturri]

More information:

2. I had a closer look and I'm pretty sure that it's some Dokuwiki API which adds the css class which result in highlithing the active page, so if you want to get rid of this you should adapt your css (to be honest I'm a bit puzzled because the html isn't exactly the same between your wiki and mine, but still, thats not in the hands of nspages)

3. About the the title of the main page of a namespace: I agree, that would be nice. Unfortunately I don't think it's possible (or at least, it's completely not trivial). That's because, as far as I understand Dokuwiki does not provide a way to get metadata for a namespace, so we would need to detect the main page of the namespace first. But getting the main page of a namespace is not trivial because there are a lot of cases to handle. For instance the main page of namespace :ns: could be any of those pages depending on which exist: :ns:start, :ns:ns, :ns.

FTR: I just merged the patch with the -sidebar option, so you can update your plugin through the plugin manager to get it. And I'm subsequently going to close that issue.

[sinkva]

For #3: Perhaps you're trying to be too flexible? If you simply say that 1) if (say) the -ns_start_h1 option is "on", then the first h1/title (if one exists) in the "start" page (only) will be displayed (or the default namespace page name, if it's not "start"). Otherwise the raw namespace will be displayed. That would be the default page defined here: https://www.dokuwiki.org/config:startpage

[gturri]

That's an interesting idea indeed. I would suggest you open a new ticket on this bug report in order to track that. (however I will likely be busy with other stuff in the near future and will likely not be able to spend too much time on nspages for now)