Symptoms:
Error in ../dokuwiki/lib/exe/js.php?tseed=1276516464 on line 1 position 102237
Error in ../dokuwiki/lib/plugins/indexmenu/indexmenu.js on line 18 position 308

Diagnose:
There is error in plugin TOOLBOX in ../dokuwiki/lib/plugins/toolbox/script.js

Solution:
In ../dokuwiki/lib/plugins/toolbox/script.js change line 40

from: “key”: “”,

to: “key”: “”

Starling

I installed this on a test version of DokuWiki and it looked great. When I installed it on my production wikis, I ran into some problems. I could not get the nice JavaScript version to display.

After much troubleshooting (and fixing two other problems related to session.save_path not pointing anywhere in the php.ini and disabled sessions), I was able to get this working on one of the wikis. When I compared the two (they are virtually identical) I noticed that one had the notes plugin while the other did not (I only planned to use it in one of the wikis). The wiki with it enabled was receiving a JavaScript error in firebug with the indexmenu_findExt() function. I disabled notes on the second wiki, and refreshed and it appeared properly. I then re-enabled notes to test if that was indeed causing the problem, but it still seems to work fine now.

So all in all, I'm not sure if there is a conflict or not, or if the order in which I enabled them made a difference?

Just putting this here in case anyone else has a similar problem or can confirm a conflict. Thomas Hawkins 2008/12/18

Hi, I can't reproduce this bug neither in the stable nor in the development DokuWiki release. For example, this test page seems to work.

What's exactly the firebug error message? Be sure also to have purged correctly cache following steps 4 and 5 from The tree is not displayed. — Samuele Tognini 2008/12/19 10:09

I just happened to have an old browser window opened with the error on it. It reads:

indexmenu_findExt is not defined
dTree("indexmenu_1631928460494ad9797f3e8", "default")
start()()start (line 106)
|-------------------------------------...h.max(this.length-1,0);return lstEl;});}

in file: indexmenu.js (line 18)

I did also follow all of the troubleshooting steps listed. It could have been a combination of it all that finally got things working. I also had indexmenu2 installed for a while, and I didn't know initially that they shared a directory. – Thomas Hawkins 2008/12/19

I have just had this problem. I upgraded my wiki from the version of 2008 to the one of 2009, and my indexmenu and my edit toolbar stopped working. I had the error on line 18 of indexmenu as well as another in lib/exe/js.php. Reloading cache didn't work.I disabled the plugin note, reloaded cache and started working. I have a copy of this wiki on a Windows server and I didn't have this problem, I had it on the server run by Ubuntu.
I have re-enabled note plugin and now it works fine… weird– Adolfo 2009/02/20

As I can understand - indexmenu will replace the main DokuWiki index as I write some thing in page_index setting. But replace doesn't work for me. I try to find out where is the bug. And find that script action.php stops in line 131

if (!file_exists(wikiFN($this->getConf('page_index')))) return;

So scripts thinks that there is no file and return :( Maybe I have to create any file manually? How make this feature work? Maybe I'm wrong, but I managed to work this feature by modifying function _loadindex in action.php this way:

function _loadindex(&$event, $param) {
    if ('index' != $event->data) return;
    //if (!file_exists(wikiFN($this->getConf('page_index')))) return;
    global $lang;
	//print '<h1><a id="index" name="index">'.$lang['btn_index']."</a	></h1>\n";
    //print p_wiki_xhtml($this->getConf('page_index'));
    if ($this->getConf('page_index')) {
        echo p_locale_xhtml('index');
        $instr = $this->getConf('page_index');
    }
    $instr = p_get_instructions($instr);
	$info = '';
 
    $instr = p_render('xhtml', $instr, $info);
    echo $instr;
    $event->preventDefault();
    $event->stopPropagation();

Vychegzhanin Stanislav 2008/12/26

“Replace Index” option in the admin panel has not to contain syntax, but a DokuWiki id page.
For example: Configure it as “mysite:myindex”. Then create this DokuWiki page and put inside it the “{{indexmenu>..#1|navbar}}” code — Samuele Tognini 2008/12/26 10:46.

This is what happens when I click on the small dark horizontal triangle at the end of any page or namespace in the index menu : it says “loading” and then appears this message :

   Fatal error: Call to a member function query() on a non-object in /srv/d_survie/www/forum.survie.org/htdocs/include/functions.php on line 130

Fixed by Samuele by adding

             require_once (DOKU_INC.'inc/common.php');
             //require_once (DOKU_INC.'inc/pageutils.php'); // can lead to disconnection if using [[auth:punbb]]
             require_once (DOKU_INC.'inc/auth.php');

At line 19, just before

           //session_write_close

Fixed in the development release. — Samuele Tognini 2009/02/12 09:31

I am using indexmenu in Monobook to generate a navigation menu. Everything works fine except when I enable userewrite: the tree is not displayed if no start page exist in the namespace. I tried to play with config parameters, flushed caches, etc. but without any success. Any idea?

Jean-Philippe Thierry 2009/04/17

What namespace? the tree root one? Please, try the development release and, if the bug persists, report (or send me via email) more details about your configuration (custom DokuWiki configuration, indexmenu syntax, ACLs or anything else that can be related to this issue) because I'm not able to reproduce it on my testing site. — Samuele Tognini 2009/04/17 15:52

I tried the development release. This time I can see all the levels except that the first one disappears when I click on it. I am using the last DokuWiki stable release without any specific tuning. The syntax of my navigation bar is

{{indexmenu>..#1|navbar context}}

Jean-Philippe Thierry 2009/04/17

With the “context” option, this behaviour could be normal. Check its meaning in the above syntax, this is not for displaying the full tree of your site, but the subtree of your current namespace (and if it has any children node, it'll be empty). For the full tree,

{{indexmenu>..#1|navbar}}

is sufficient (optionally you can add the 'js' JavaScript method). — Samuele Tognini 2009/04/22 21:03

It works with the development release. I should have read the manual more carefully And thanks a lot for answering so quickly. Jean-Philippe Thierry 2009/04/17

I updated to the new DokuWiki release 2008-05-05. I cleared the cache etc. as mentioned above. All config values are standard. The menu tree will not be displayed – just a plain text list will appear.

Could you try the development release and let me know? Samuele

Yes, the development Version works just fine. Thanks and keep up the good work!

Hi

I have a private wiki (root namespace ACL is none), although start and sidebar pages have read permissions for @ALL, so anonymous users can also watch the main page and the sidebar (i have removed the index menu and inserted this page in the left bar). Then when an anonymous user or authenticated user access the main page (i.e http://dokuwiki.aquiline.es or http://dokuwiki.aquiline.es/inicio, start page is called inicio), they can see the content, but the text for the root namespace in the indexmenu has no link. Is this a bug? You can watch this at http://dokuwiki.aquiline.es

Regards

— Juan 2008/04/24 22:44

What are your namespaces_title_and_link, startpage, skip_file and hidepages options? — Samuele Tognini 2008/04/25 00:37

Hi

* headpage (namespaces_title_and_link) → :start:, :same:, :inside:
* start → inicio
* skip_file → /sidebar.txt/
* hidepages → (none)

Regards

— Juan 2008/04/25 02:14

Uhm, those settings are okay and I can't reproduce the bug. When you logged as administrator, is the root link created? What's your ACLs (from conf/acl.auth.php)?.

Hi,

When I login as administrator, the root of the tree is the title of the “inicio” page of the root namespace (correct); when I am not logged in
or logged with an user other than administrator, the root of the tree has the text of the
wiki name, and it is not linked. This is my ACL file:

* @ALL 0
inicio @ALL 1
sidebar @ALL 1
general:* @usuarios 2
publico:* @ALL 1
sistemas:* @sistemas 8

Regards and thanks for your help.

It should be solved in the development release. — Samuele Tognini 2008/04/26 12:49

Hi

The development release fixes this bug, confirmed. Thank you very much for your help and your attention.

— Juan 2008/04/26 15:07

Hi, I would remove the context_menu to give back the standard right-click on link. This is important for me because my users use Firefox and open multiple page on new tab with a right click on link.

Is possible ? how ?
Alessandro Celli

Just empty the menu files (don't delete them) as described in the context menu section — Samuele Tognini 2008/09/16 15:28

I have try to remove the variables definition but the right click of mouse result disable.
I need the default right-click menu of browser (I use Firefox).
Thanks again. Alessandro

Oops, you were right . A fix is now in the development release. Please, let me know if it works.

Hi. We really appriciate all the work and updates related to using the nsort option… it looks like this may really help us more robustly structure our wiki's for the long run.

However, it looks like I may have come across another issue with the nsort option. Basically it seems that there is a problem when combining non-js mode with the nsort option and a specific tree depth.

Perhaps that sounds strange, and I think the only way to really demonstrate it is with examples. I made a page in an active wiki (using indexmenu 4.2) to demonstrate:

http://tools.iscvt.org/advocacy/wiki/indextest

Hope that all makes sense, happy to elaborate and/or try other combinations…

Best — Ryan Jacobs 2008/03/14

Simply the namespaces are not sorted. Could you test the new development release? Please, check also that js namespaces sorting still works correctly. Thanks again for testing and bug reports. — Samuele Tognini 2008/03/22 18:59

Solved in v4.3 — Samuele Tognini 2008/04/12 11:43

I have two problems with the context menu:

1. It does not work correctly when using URLs with slashes, creating a new page gives “newpagename_do_edit” instead of “newpagename”. This can be fixed by editing the context-menu.js, but it would be nice if it could adjust automatically to the kind of URLs used.

2. If I use swedish characters like åäö in context-menu.js, they show as questionmarks. I have no real coding experience, and I'm not familiar with JS, so help would be welcome.

- Erik 2008-03-10

Hi Erick
1. I can't reproduce it. Whats your DW version and userewrite, useslash and sepchar DW settings? What did you changed in the code to make it work?
2. First, when writing your own function, your editor has to support the utf8 chars set. Then the encodeURIComponent or encodeURI function should make the trick.

— Samuele Tognini 2008/03/10 12:02

Thanks for the fast reply!
1. Ok, I'll move it! I use DW 2007-06-26b with internal userewrite, with useslash on and sepchar to “_”. I configured all that trough the interface. What happens is that it tries to access “mystart/namespace/page” with the addition of “&do=edit” to the URL, wich does not work, so I changed it to “?do=edit”. But I think that means the function will breake if I decide to stop using useslash.
2. I'll try that later! Maybe we could have some way of easily translating the context menu instead of editing the script?
— Erik 2008/03/10 14:16

1. Yes it's a bug. It happens when internal userwrite setting is enabled. I'll look for a solution for the next release, in meanwhile your workaround should be ok.
2. I realize now that maybe you were talking about special chars in the menu item description and not in the url (encodeURI is needed for url encoding). A good editor with unicode support should work. Another solution is to encode them yourself: Find your char at http://unicode.coeurlumiere.com, replace the last zero of the left code by the character in the upper row and prepend the result with \u : ie \u00E3 for 'ã'

2: Thanks!

1: Should be solved in v4.3. Feel free to reopen a new bug issue if it's not. — Samuele Tognini 2008/04/12 11:43

It seems to me that the latest dokuwiki rc has somehow broken the js in indexmenu. I am no good at js, so I may be wrong.

What is happening with dokuwiki-rc2008-03-31 and either the latest release of indexmenu or the 2008-03-10 dev version is that the index displays correctly, but the links omit the '?id=' from the url.

Oddly, the page source appears to include correct urls. But the javascript returns the truncated form. This seems like a fatal bug: the menu is totally unusable as all links are broken by it.

— richard at the-place.net

The development release should solve it — Samuele Tognini 2008/04/03 18:05

And it does – but only after deleting the plugins/indexmenu directory, deleting the cache (rm -rf data/cache/* ; rm -rf data/index/* ; rm -rf data/meta/*) and installing the development release (version 2008-03-10) again. Thanks Samuele. — richard at the-place.net

Deleting data/meta/*, and pheraps data/index/*, is dangerous because it contain important information used by dokuwiki. To purge cache, follow the the tree is not displayed instruction, above all steps 4 and 5.

The indexmenu is working fine except one thing: the urls of the folder and files aren't correct. Instead of doku.php?id=page I get doku.phppage. I tried to find the error but I had no luck. Clearing cache or using another browser did not solve the problem. What else can I do ? — Nadir 2008/04/09 22:14

This is a duplicate report. Please read the above bug report (link_parsing_broken_with_latest_dokuwiki_r.c). A stable release will be out in 1-2 day. — Samuele Tognini 2008/04/09 23:29

Solved in v4.3 — Samuele Tognini 2008/04/12 11:43

Dear Samuele, thanks for a wonderful plugin, with lots of very useful features. I am using v. 4.1 on DokuWiki 2007-06-26b. I have a question on context menu. The context menu seems to work differently on namespaces with and without headpages.

• For a namespace without headpage (does not matter which form of headpage is used, i.e. internal, external, etc.) I get “Namespace action” menu, as expected. “New page here” works as expected too.
• However, if a namespace has a headpage, then the “Page action” context menu is displayed. In this case selecting “New page here” creates the new page AND another namespace. For example if I have namespace “ns” with a headpage (“ns” or “start”):

  ns/
    ns

creating new page “page1” actually puts it under an intermediate namespace “ns”:

  ns/
    ns/
      page1

What I'd expect to have is:

  ns/
    ns
    page1

Am I missing anything? I tried clearing cache (browser, server, and set cachetime=0), it did not help. Can you reproduce it? If so, is there any way to fix that so that pages may be added to namespaces which already have a headpage?

Thank you,
Aleksey

Thanks, please confirm that 4.2 release fixes it. — Samuele Tognini 2008/03/10 14:00

Samuele, the latest upgrade (10-03-2008) seems to have resolved all the above issues. Thank you for the great work! Aleksey

Hi there. I have DW 2007-06-26. I'm quite keen to use the new nsort option to re-arrange several indexes on 3 wiki installs (instead of using manual URL title numbering) and have discovered that using the js and nsort switches together seems to cause problems. If I use these together, and do a page preview or save, the page simply will not render, or will render incomplete (just the background and the “you are here” links or similar) or just not load at all… there is no error. Something like

{{indexmenu>:|js msort}}

or

{{indexmenu>:|msort nsort}}

works fine, but

{{indexmenu>:|js msort nsort}}

leads to this strange problem.

This links provides an example: http://wiki.ryanjacobs.name/wiki/test That page contains the following wikicode:

Some text

{{indexmenu>:|js msort nsort}}

Some more text

Hope I'm not missing something obvious with this. The problem seems to show up in v4.0 and v4.1 of the plugin. In the link above, v4.0 is used. — Ryan Jacobs 2008-02-20

I can't reproduced it. It seems a loop bug, but something similar was in v4.0 and fixed in v4.1. Be sure to have purged cache with the above testing release and if it persists you should check apache and php log files for more infos. Try also to test differents wiki tree branches by specifing different main namespaces. This could help to check if it's fault of a specified namespace. i.e:

{{indexmenu>wiki|js msort nsort}} 
{{indexmenu>playground:ns2|js msort nsort}}

— Samuele Tognini 2008-02-21 11:21

Well, I'm quite stumped on this one as after playing more it appears that there are more variables involved. I can't get 100% consistent results. I think that it has something to do with ACLs, as I can typically avoid the problem while being logged in as an admin, or by listing a specific part of the tree (just one subset of namespaces instead of the full tree… the test you suggested). I was also able to toggle the problem on and off by removing my skipped namespaces setting. Anyway, the php error log (on a test local install) USING v4.0 says this just after my test page produces the problem: “PHP Fatal error: Maximum execution time of 30 seconds exceeded in /Users/ryan/Documents/MAMP Data/htdocs/wiki/lib/plugins/indexmenu/syntax/indexmenu.php on line 320”. Then, using v4.1 I get the same php error in the log, but a reference to line 322 instead of 320 (looks like the same “while” loop). I did not see any relevant apache errors. There are specific line references there, so maybe there is a clue. I think I'm over my head on this and I just hope it's not something unique only to my setup. I'm wondering if perhaps I have the right combination of specific ALC/sort settings that trigger a bug… or I may also just be crazy. Hope this turns out to be useful. — Ryan Jacobs 2008-02-22

Check your mail.

It should be solved in the development release. LEt me know — Samuele Tognini 2008-02-25 13:05

I really appreciate all the effort that goes into this plugin, and the many new features and fast updates. I just tried out v4.1 (seems to be full of good stuff), but I'm just not clear on how it now manages empty namespaces. I suppose it all is realted to the sneakyindex change, but I'm unable to gather enough info from the documentation to figure things out 100%

Basically, if you have an “empty” namespace that DOES contain a start page, this node is rendered as simply a red X (in js mode) in the tree. I should also note that I'm using the “hide start pages” option. Older indexmenu versions displayed this “empty” namespace as folder icon named after the start page heading (this is what I still would like to see). Why the change? Can I get the old behavior back with v4.1?

I know it may seem strange to have a namespace with ONLY a start page, but as a wiki grows, one might create a namespace (with only the start page) as a placeholder for more pages to be added later. To just see a red X in this case seems a little strange. Again, I suppose this is related to the sneakyindex change, but the details that surround this change are unclear to me.

Cheers! — Ryan Jacobs 2008-02-20

It's not related to the sneakyindex, but it's a bug in the new mechanism to manage empty namepsaces. Even they could seem easy to manage, actually they are not. Would you test if http://samuele.netsons.org/darcs/indexmenu/indexmenu.tar.gz fix it and does not involve other bugs ? — Samuele Tognini 2008-02-21 11:08

Thanks. That link you provided (http://samuele.netsons.org/media/indexmenu.tar.gz) does not seem to work.. 404 not found. While testing for the other problem (that I posted above this one), I removed and re-installed 4.1. After clearing the cache, etc… I now see that the red X are gone, and instead the empty namespaces (with only a start page) just don't appear at all. Did something change with the current 4.1 download? I'm not using a development version or darcs, just the same 4.1 download link I used before. — Ryan Jacobs 2008-02-22

Link corrected, sorry for error. Nothing was changed in 4.1 download, i guess it was a cache issue. The red X should still be displayed according to about_empty_namespaces.

Ok, I tried that “patched” version and it looks good, I think you got it. Namespaces that only have a start page are displayed using the page title text and a page icon (in js mode)… just like old versions. I only get the red x now if I uncheck the Dokuwiki conf “Enabling this option will hide those where the user doesn't have read permissions….” option and there is a permission restricted namespace in the tree (which logically makes good sense). Apart from the nsort problem I described above (which I guess is totally separate) I don't see any other issues. I assume this change/correction will make it into the next official version if no other issues are found? Thanks! — Ryan Jacobs 2008-02-22

Thanks to you. Last minute change is that empty heapdages (namespaces with start) are displayed with headpage icon instead of page icon. Previuos link is now the way to get the last development changes in a tar.gz format.

Hi, I'm just upgraded to indexmenu 2007-10-26 (the most recent version according to DW's update plugin feature), and I'm facing a very strange problem where the {{indexmenu>...}} invocation in the wikitext just dissappears after I edit the page, being replaced by a blank line.

To clarify the problem:

1. Have wikipage named [[:wiki:hello]] where there is a {{indexmenu>.#2}} invocation somewhere in the wikitext.
2. Have indexmenu plugin upgraded.
3. Edit the contents of [[:wiki:hello]] to add some more information.
4. On save and then view page contents, the indexmenu has dissappeared. All other content seems to be fine.
5. On edit, the line containing {{indexmenu>.#2}} has been replaced by a blank line (ie.: a line containing only endline).

Any further attempt to add an indexmenu in such page will fail, whereas pages that had no indexmenus previously will flawlessly accept an indexmenu (however, if I then proceed to edit those pages again, their indexmenus will dissappear too). The only solution I've found up till now is to add the invocations directly to the wikitext by accessing the pagename file in the filesystem.

I haven't tested wether downgrading the plugin will resolve the problem.

I'm using DW release 2007-06-26, indexmenu release 2007-10-26, in my own server with Apache 2.2.6 and PHP 5.2.4. Any idea would be greatly appreciated. — Question posted by ryan.chappelle 2008-02-10 from his page

At this moment your site is down to be able to test it, but it seems like your deny_indexmenu_to_no-admins setting is on and your are editing pages not as superuser. — Samuele Tognini 2008-02-10 20:35

Samuele: I edit all pages as superuser, mine is a visitor-only wiki. However, I suspect a bug in my DW installation cache, as pages that have the ~~NOCACHE~~ tag included seem to not be affected. I've disabled deny_indexmenu_to_no-admins as suggested and the problem seems to hve gone away. Thanks again. — This comment posted by ryan.chappelle 2008-02-21

I have a wiki where by default nobody has access to anything (read, write, etc)
Moreover, I have namespaces that don't give access to any one, BUT within those namespaces i have sub-namespaces where access is public. This set up seems to trick your plugin, and the discussion on the plugin page about the script stopping its recursion once it finds a NS which is not accessible seems like a good reason

So to make the report concrete:
in my acl i have
* - group ALL doesn't have any kind of access
:work:* - group ALL doesn't have any kind of access
:work:public:* - group ALL has read access; group user has read+write+edit access

and what that does is, in any page in :work:public: the menu doesn't show up for non-registed users (users in “ALL” group). what i want is basically for the menu to list pages under :work:public: since they ARE accessible

i am using your “group” setting

Hard to work with acl. I'll investigate on it. Could you try this onthefly workaround and let me know (via email for long discussion) ?:

1) In syntax/indexmenu.php _search_index routine, modify:

if (auth_quickaclcheck($id.':*') < AUTH_READ) return false;

with

if (auth_quickaclcheck($id) < AUTH_READ) return false;

then add in your acl.auth.conf:

work:public @ALL 1

— Samuele Tognini 2007-11-06 12:51 — Hilikus

Fine workaround. But now you get empty-namespace-entries if there are no viewable pages inside.

I think there is no clean solution because this issue depends on a DW internal core mechanism. I've added a patch in the development release, and i'll be glad if you'll test it and give some feedback. It simply follow the DW sneaky_index option, which means:

• Enabled: indexmenu works like now. If a “*” subnamespace is denied (“:work:*” in you case), it stops its recursive search on that branch.
• Disabled (the default): Indexmenu doesn't stop its recursive search and it shows denied namespaces that are not empty (for example they contain another denied namespaces). Empty namespaces are not showed, but can be viewed in the html code.

In both cases, pages are never showed. If this patch is not useful for your intentions, you'd try the uncomfortable but working way to allow “*” subnamespace and deny one-by-one the subnamespaces you want to keep private. — Samuele Tognini 2007-11-13 15:29

Read About ACLs for further details about how this is managed by the upcoming indexmenu release — Samuele Tognini 2008-02-16 12:48

I have a namespace where all pages inside match the skip_file regular expression. This namespase shows up in the index as a normal page. For example, suppose I have the page foo:bar:dontshowme as the only page in the foo:bar namespace and the skip_file regular expression is set to /dontshowme/. Then the index will show a page called bar inside the foo namespace. I expected bar to not show up at all (and foo to not show up if there is nothing else in the foo namespace). 2008-02-04T18:01:05Z

I'm just working on a solution for empty namespaces in the development release. It was originated from the acl issue at the end of this bug section, but it should work also in your case. Hope to be able to implement it one day, at least for javascript mode. In the meantime, you could try with the unclean workaround to skip also the /^foo/ namespace. — Samuele Tognini 2008-02-05 10:22

Thanks for working on a fix! I really like the plugin and I appreciate your efforts! 2008-02-06T04:57:33Z

If the wiki title ($conf['title']) contains a single quote, e.g. ACME Inc.'s Wiki, the javascript rendering doesn't work. — 2008-02-04T17:54:50Z

It's fixed now, thanks:

hunk ./syntax/indexmenu.php 282
     if (!empty($js_opts['jsajax'])) $out .= "$js_name.config.jsajax='".utf8_encodeFN($js_opts['jsajax'])."';\n";
-    $out .= $js_name.".add('".idfilter(cleanID($ns))."',0,-1,'".$title."'";
+    $out .= $js_name.".add('".idfilter(cleanID($ns))."',0,-1,'".htmlspecialchars($title,ENT_QUOTES)."'";
     if ($hns) $out .= ",'".idfilter(cleanID($hns))."'";

Anyway, could you confirm that the bug happens only when headpage setting is not configured? — Samuele Tognini 2008-02-05 09:59

Thanks for the fix, that did the trick! And I can confirm that the bug only happens when headpage is disabled. If headpage is enabled and the first heading on the home wiki page contains a single quote, it works fine even without the above fix. — 2008-02-06T04:47:10Z

Ok thanks. Unfortunately there is bug with the previous patch, so please revert it and apply this working one:

hunk ./syntax/indexmenu.php 260
     if (empty($title)) {
-      (empty($ns)) ? $title=$conf['title'] : $title=$ns;
+      (empty($ns)) ? $title = htmlspecialchars($conf['title'],ENT_QUOTES) : $title=$ns;
     }

I reverted the old patch and applied the new. Everything seems to work fine. Thanks! — 2008-02-06T21:20:25Z

Hi. Dokuwiki has the nice “Search Highlighting” feature, where your search keywords are highlighted when something like Google is the refferer to your Dokuwiki page. However, I just noticed that if one of these keywords is part of the link URL used by indexmenu in JS mode, the menu tree is rendered full of URLs instead of page titles. I am not sure if this is a indexmenu-specific problem or not.

To duplicate this, you could do a google search for the domain name that we use for one of our dokuwiki wikis: “tools.iscvt.org”. If you follow one of the result links (to one of the pages in this tools.iscvt.org domain, such that google is the reffer) you´ll see of course that the words “tools”, “iscvt” and “org” are highlighted when found in the page. At the bottom the the page (where we always place an overall indexmenu box that uses JS mode), you´ll see that the results are full of link gibberish because it´s trying to highlight these keywords in the URLs instead of displaying the page titles. If you then type in the same page URL directly in your browser (no google reffer and no highlighting) the bug goes away.

Hope that´s a clear explination… and easily replicatable. Happy to expand if needed. Ryan Jacobs

Thanks Ryan, now it should be fixed in the development release (the diff patch is below). To reproduce the bug you can simply search for a node component with the dokuwiki search request ( ie: http://tools.iscvt.org/advocacy/020_craft_campaign/start?s=tools). Ah, don't forget to purge server cache after applying it:

hunk ./syntax/indexmenu.php 273
     }
     $out = "<script type='text/javascript' charset='utf-8'>\n";
+    $out .= "<!--//--><![CDATA[//><!--\n";
     $out .= "var $js_name = new dTree('".$js_name."','".$js_opts['theme']."');\n";
hunk ./syntax/indexmenu.php 294
     $out .= ");});\n";
+    $out .= "//--><!]]>";
     $out .= "</script>\n";
     }

Many thanks, I´ll give the fix a go. Cheers! Ryan

After installation version 4.0 of this great plugin i'm missing the toolbar button in editmode ('Deny indexmenu syntax to no-admins' is switched off). Eventhough it's not critical to my installation it's very much nice to have. Herman Huitema 2007-12-17 14:33

I can't reproduce it. Have you tried to purge the browser cache? If it persists, could you look for javascript errors (for example with the firefox javascript console) and post them here?

Firefox gives several JS warnings, only one error, stating that “oLink is not defined”. I've purged browser cache etc, but problem still exists.

You should be more detailed. This is what i need: File and number row of the error showed in the firefox console, DW version, template and extra plugins installed. Thanks. — Samuele Tognini 2008-01-06 13:06

SOLVED After some additional debugging i found that the script.js has two spaces between var and oLink, somehow in my case this translated to a concatenation of the two words on the clientside. In the end causing an undefined variable. Herman Huitema 2008-01-07 09:52

Hi there. I really like indexmenu but there's something that i couldn't figure out yet and what really questions the use of indexmenu for me unfortunately :/ i use indexmenu for a full tree index with js as navbar in a sidebar. it works well but for one instance: when it comes, that the tree is very deep (i.e. the wiki is structured through very hierarchical namespaces) indexmenu won't show a namespace as such but as ordinary site…

in our wiki it happens with the 4th ns under the root namespace… so :it:admin:srv-linux:php: won't show as namespace but as site in the menu (through being linked correctly to the namespace)… do you know what this is about? thanks a lot! Dominik Hertel 2007-11-05 10:49

I've sent an email to you. — Samuele Tognini 2007-11-06 11:51

I've replied — Dominik Hertel 2007-11-08 10:19
maybe it has something to do with where you put your data dir? i see yours is under your webroot and your indexmenu works perfectly, while ours is in a separate directory outside the webroot… maybe there's a connection?

Update: It seems that it had something to do with having (start|…) in hidden pages and the only subpage under that namespace besides “start” contained “start” which made it filtered out, too because of the regexp… if i just wanted to leave “start” out i should have written (^start$|…)… now it works just fine for me :) — Dominik Hertel 2007-11-19 17:31

• Are there any know issues with the tsort option and Dokuwiki 2007-06-26? I have my page titles defined by first headings (Dokuwiki option) and when I insert the tsort option (in javascript and non-javascript) mode, it still sorts by pagename/filename. I have even tried overwriting the “title” setting for each page with the meta data plugin, and though this indeed changes the link text in the indexmenu, it does not make the tsort option work (items are still sorted by pagename/filenames). The indexmenu version that I have reports date 2007-07-07. Happy to provide more info as needed. –Ryan

There should not be bugs with tsort since 3.7, anyway try to upgrate to 3.8. Just a note, tsort does not sort namespaces, only pages. Perhaps it's php related. if it persists, please continue discussion via email (if your site is public, you could send me its url). — Samuele Tognini 2007-07-26 12:54

Hi Samuel, thanks for the reply. I got the most recent version and all seems fine. However, I think the idea of applying tsort to sort namespaces as well is an interesting feature request. I'm going to post it in the appropriate feature-request thread (sorting) along with some more details. Thanks! –Ryan

• In this release, there could be problems when you use an url rewriting mechanism. There will be soon a fix.

Fixed — Samuele Tognini 2007-07-11 11:16

• Version 07.07.07 v3.7, firefox, using

  {{indexmenu>home#1|js#minimal navbar nocookie id#page}}

  behavior seems to have changed since previous version. The indexmenu is now shown closed. Previously the tree was open at the current page, with that page highlighted.

It should not. I can't reproduce it (here it works). Have you purged your browser cache after upgrade? If you navigate the tree, can you find the highlighted current node? Just few obvious notes: the current page has to be inside “home” namespace.It has not to be skipped in the indexmenu or hidepages dokuwiki settings. Please,contact me via email for debugging the problem.

Problem wasn't with indexmenu. Javascript had halted execution elsewhere.

• Rendering an index of many pages (i suppose more than 300) probably will slow down the page loading everytime its cache expire.

Added remark to this bug / issue : my wiki currently hosts around 950 files, and what i notice is that each and every time the dTree is filled with ALL nodes. Even though the max#1 feature is switched on, which in theory should only render to a certain level, but it does not seem to work. — hermanhuitema [at] yahoo [dot] com

Unfortunatly indexmenu has always to retrive the informations of all sub-pages, this is why it's slow with a lot of files when cache expires. Max option speeds up only the client browser because it's related to javascript rendering. I'll look for an ajax solution, but consider also the good indexmenu2 plugin that it should do what you need. — Samuele Tognini 2007-06-11 17:39

mkay, i've tried the indexmenu2 sadly the installation is not that stable. (can't get it to run, after several hours of fooling around) Would love to try out any beta solution you come up with. (have a full preproduction environment at my disposal. ) regards — Herman Huitema 2007-06-12 08:24

A beta release that supports a real max option, where nodes are retrivied throught ajax, is ready in development. Old max option is renamed maxjs. It'll be released as public in few days.

Done

After some time i finally managed to put some time into my wiki again, of course i used the 4.0 version of the indexmenu and i can really see the performance increase. Even since my 'complaint' the amount of pages hosted increased to 1500, the performance is as if it was a fresh install. Really good job!! Herman Huitema 2008-01-07 09:04

Using the js-option with IE6, the indexmenu ist listed under the TOC and not beside ¹⁾ — knut_k [at] gmx [dot] de

Hi, does the “noscroll” option solve this bug?

Yeeesssss!!! — knut_k [at] gmx [dot] de

My site seems to not be affected by this bug with ie6, could you confirm this?. If it's true, i think it's your template or one of your plugins fault, which put indexmenu inside a div incorrectly managed by ie6.

In my installation the scroll left image and the TOC preview show up underneath the rest of the frame. I'm using the monobook template. — hermanhuitema [at] yahoo [dot] com

Putting “z-index:100;” in style.css for “.indexmenu_toc” and “.dtree .indexmenu_arrow” should work. Please, send me feedback. Patch is in the development release too. — Samuele Tognini 2007-06-11 17:39

Hi samuele, some feedback on the quickfix the TOC preview works like a charm, but i still can't see the arrow. btw i also don't see the arrow when using firefox, however there i am able to scroll left again, with IE this doesn't work. :( — Herman Huitema 2007-06-12 08:24
Solved — Samuele Tognini 2007-07-05 18:57

Working like a charm Herman Huitema 2008-01-07 09:04

Started by Adrien CLERC on 2007-04-02 @ 09h51 GMT

I'm using 2006-11-06 debianized version of Dokuwiki. Dokuwiki is located at the root of my domain name (eg wiki.example.com). I use the provided example to make a sidebar {{indexmenu>..#1|js#vista.png navbar nocookie}}

I have the following issue : the tree is created, all links are correct except the root one. In fact, the root link is made of http://start/, and the generated JS show the following line :

indexmenu_1.add('start',0,-1,'My Dokuwiki Name','//start');

The double slash is the problem. I'm not going to explain how it comes doubled, but the following patch solved it, using dokuwiki functions :)

File indexmenu/syntax.php, line 313, replace

//check headpage

by

resolve_pageid($ns, $page, $exists);
//check headpage

This function is located in parseutils.php, and clean the page name. The $page variable is modified by side-effect, and the function actually returns no value.

Patch added in 3.2 release.Many thanks, Adrien. — Samuele Tognini 2007-04-04 11:45

Started by Kerry Bonin on 2007-04-23 @ 16h37 GMT

Using latest stable Doku & IndexMenu (sidebar w/ {{indexmenu>..#1|js navbar nocookie max#2}} ). Simple ACL setup, everybody can read everything but a private namespace off the root. Its ACL starts with group ALL having no access, then has a group w/ normal access. This works fine for regular use.

When I look at the site without logging in, I can see the internal namespace, and all of its children. The pages are not visible, and clicking on any of them gives a permission denied, but all of the namespaces that the default user has no read access to is visible.

I'd consider this a bug, and its a show-stopper for my application, as my namespace structure names imply things I'm trying to protect. I don't think namespaces should be visible unless the user has read privs, just as it works for pages.

Could you try the ~~NOCACHE~~ syntax in the sidebar and let me know if bug persists? Unfortuantely at this time i'm too busy with my job, when i'll be free i'll look better at code.

I had the same bug, but with ~~NOCACHE~~ ACL works correctly.

Thanks for bug reporting. It's fixed in 3.2 release, but only when the requested namespace is the root ns. Hope it's not a big problem as indexmenu is mainly used as rootindex, infos here. As soon as i'll have some free time, fix i'll try to fix others namespaces too. — Samuele Tognini 2007-05-10 12:53

Thank you for this essential plugin, because it's almost the first plugin I would like to install when I start a new DokuWiki site:-)

I have used it since 2.8, then upgraded to 2.9, and things went quite well, until recently I found that on my site, no matter how I set to “hide headpage”, the headpages are still there. But I have successfully hide headpages on another site, so it's really weird. When I look into the conf/local.php, I found that the “hide headpage” setting is not written by the configuration manager at all! If I uncheck the option, there would be one line going like this:

$conf['plugin']['indexmenu']['hide_headpage'] = 0;

but if I check the option, that line is gone! I guess that's why my setting is always ignored. But it really doesn't make sense at all because this won't happen on the other site which is on a private IIS server. Both site is under PHP 5, and one site has safe_mode on, one site not. I'm wondering what difference is making the different result? Could you help me out? — Roberto Ciang 2007-02-16 10:11

If $conf['plugin']['indexmenu']['hide_headpage'] is undef in local.php or local.protected.php then it should get the value in indexmenu/conf/default.php, which is on by default (check it).So it's ok that local.php does not contain the value when it's on, but it's strange that it does not work. How is headpage method set? Can you look at server log for errors or warnings?

Wow, thank you for your quick reply~ My favorite headpage method is :same:, and this part is working, because the page with the same name with the namespace is correctly recognized to be linked. Only the headpage is not working.
Could you instruct me where to look for the server log? Because my site is hosted by 110mb.com. Should I ask them let me see it? Would safe_mode has an effect in this too? — Roberto Ciang 2007-02-17 05:42
I'm sorry , but hosting providers deny their logs. Safe mode on does not affects indexmenu functionality (my own site is in safe mode). Better to continue this discussion via mail . — Samuele Tognini 2007-02-17 10:45

Solved! Samuele è un buon uomo! — Roberto Ciang 2007-02-19 14:38

It's a bug with not encode utf8 characters . It's only solved, until 3.1 will be out, in the development release. — Samuele Tognini 2007-03-05 15:29

I am having a problem displaying the javascript version of indexmenu to users who only have read privileges. Such users see the non-javascript version. Users with read privileges to the page see the javascript version fine. I am using the navbar option, but the problem exists without this option set. Comparing listings of the html of the page from the browser seems to show the indexmenu section, complete with javascript, to be the same for both write-privileged and non-write-privileged users. Can someone help with this problem? — Green Box 2007-02-24 04:57

Hi. Probably there is some javascript error that breaks the javascript code. Indeed, when it's broken ,the nojs tree is displayed in place of js one. I don't think it's directly related to users privileges, because on my site users has write permissions only on playground, and js tree is always displayed. You should check for errors with the firefox javascript console, or better give me the link of your site. Another reason could be a firefox bug which randomly corrupts javascript cache (check page with ie6/7 or empty firefox cache when you are a no privileged user), and if you switch for users it's easyer it can happen. Please, if you do not find any solution, continue discussion via email and write me details about your configuration (DW version, acl, sidebar syntax, indexmenu settings). — Samuele Tognini 2007-02-24 09:42

Thanks for prompt reply. Yes, it seems to be firefox cache. The problem does not happen with IE. After logging on as a different user, clearing the firefox cache and reloading brings back the JS menu. — Green Box 2007-02-28 02:39

• Hi, all! We are using this great plugin a lot. We have also some long titles in it. Should they wrap if wider than sidebar? Ours don't. Are we missing something?

Mathias

Hi.Have you followed the instructions in The tree is not displayed section ?(above all, have you purged cache browser?). Read also the first note on changelog. Tree should slide when nodes do not fit but i've tested this feature only on ie6/7,firefox 2 and safari. — Samuele Tognini 2007-01-26 16:19

• Is there a setting that the tree stay expand after editing a page

Simply don't use the #n option and the tree will be expanded. You can also use nocookie option to force it to remain open even after the user has navigated it. Please next time do your request in one of the below section , or open a new one, because this is the solved bug section :). — Samuele Tognini 2007-03-09 16:37

• I can do what I wont. But I can´t see the tree.I install with the plugin manager. What have I todo must?I can´t find infomation about that.

Check in the download section that your have installed the indexmenu release compatible with your dokuwiki version. Then read the faq and notes. If it not solve, email me the html source of you page. — Samuele Tognini 2007-01-18 10:54

• To avoid the “Warning: Call-time pass-by-reference has been deprecated…” message for certain configurations of PHP (which causes the menu not to work at all. Note, if you are already getting this error on some pages, you may have to force a refresh of those pages to clear the error out of the cache. -Peter phptard at gmail dot com):
  • syntax.php line 193: change to

    if ($headpage) $this->_check_headpage($ns,$headpage,$title,$link);

  • syntax.php line 221: change to

    $this->_check_headpage($item['id'],$headpage,$title,$link);

  • syntax.php line 461: change to

        if ($idxm->_check_headpage(&$nspage,$headpage,$title,$link)) {

  • syntax.php line 285: change to

      function _check_headpage ($ns,$headpage,&$title,&$link) {

>Hi,thanks but this bug should be already fixed since v2.8, as pointed in changelog . Please, try the last v2.9 release and check again. — Samuele Tognini 2006-12-29 11:28

• If your dokuwiki has too many pages and namespaces, indexmenu pages load get slow depending on tree nodes amount and pc client CPU power. Sometimes it could take more than 5 seconds. This is a javascript limitation, but a solution will be in the next stable release.

• It seems that a severe bug of firefox, under some circumstances, corrupts cached javascript files. It should be solved in indexmenu v2.9. More info in v2.8 bugs section.

• My indexmenu works ok (thanks!!), but after I click a page in the tree and the page is shown correctly, the hilite “jumps” up to its node. Like below

|_Node
   |_first
   |_second
   |_third

If I click “second”, the page “second” is shown, but the hilite goes to “Node”

Can you help, please?

Blaž 18.1.2007 9:13

Are you using the navbar option? This is how it should work, it highlights the current namespace. Anyway, i think i'll look for an implementation of your request for the next indexmenu release. — Samuele Tognini 2007-01-18 10:47

Thank you Samuele! Yes, I'm using navbar and this is exactly why I expected the page link to remain hilited. This is also what some usability guidelines (Highlighting the current location) suggest, don't they.

Blaž 19.1.2007 13:30

Feature added in darcs repository, it will be out as stable in next week. You can try it also on my site (is the highlight color too ugly?). — Samuele Tognini 2007-01-20 20:45

Thanks! I checked your site. I had some problems seeing some pages but basicaly the hilite worked OK. As far as color, I like current (cyan) better :). Great work, Samuele!
Btw, how do you insert the user&date stamp at the end of comments? Blaž 21.1.2007 19:30

The problems in displaying pages should be solved (it was a ie6/7 bug). Could you (or someone) confirm this (some pages could need a cache purge)? There is two highlighting color, one for the current page (yellow), and one for last visited page (cyan). So, have you some suggestion for default colors (users will be able to change them in style.css)? You need to be dokuwiki registerd to use the sign button. — Samuele Tognini 2007-01-23 11:12

Samuele, works like charm! All is perfect! So, is this version already downloadable? Blaž, 24.1. 1:55

• Incorrect js titles when headpage option is not enabled (solved in darcs).
• It seems that a severe bug of firefox, under some circumstances, corrupts cached javascript files. It doesn't depend on indexmenu, but it could lead sometimes to an undisplayed indexmenu tree in the user browser. A trick from client side is to force the reload of page, i.e with shift+reload. I guess that the real solution, till a new indexmenu realease is ready, is to:
  1. Go into doku_path/lib/plugins/indexmenu/ and rename script.js into script2.js.
  2. Edit doku_path/lib/template/your_template/main.php (where your_template is the template you are using), and insert this line after the <head> syntax and before <meta ..>:

     <script src="/dokuwiki_url/lib/plugins/indexmenu/script2.js"></script>

  3. change timestamp to local.php,i.e with linux touch command, so that server side cache is cleared), and reload your browser cache (shift+reload).

Installed the latest version of DokuWiki and the JS menu doesn't work; just doesn't load the right menu. You can see what I mean Here. Well you could if the menu displayed for users not logged in!!! The code is there, just no tree. Any ideas?

I also want the current namespace open to be opened in the menu? I can't get it to do that but I suspect I just have not got the syntax right.

Maybe i've not understand, but i can see the tree on your site,and i'm not logged in. I see there is a known bug, which displays wrong nodes names.I've already solved it in my darcs repository. If you don't want or can't use darcs, send me a mail. This bug happens in 2.8 when headpages are not enabled, therefore you can bypass it activating one of the headpages methods in admin panel. If you don't see the tree with firefox (but works with IE), then you should read bugs.

OK I have got DARCS and did a get. How do I get the latest 'version'? Can I easily create a zip file for the pluginmanager to import?

Darcs gets always the latest development version. Anyway, the quicker way is to use this link indexmenu-2.9beta with plugin manager .

Ah Much better .

To open a namespace, specify it after the main namespace option, in this way:

{{indexmenu>sbfaq:#1 .|js}}

The code above didn't do what I hoped. When in a page in a namespace I would like the menu in the side bar to expand at that level to show all the pages/namespaces at that level.

It could depend on you template, but at this moment it doesn't work for sure in your site because of the bug. Try first the above beta version.
Pay attention that “.” refers always at the page that your are reading. In the second example at your site {{indexmenu>sbfaq:#1 .|js}}, the “.” refers to “playground:test”, which is not inside “sbfaq” namespace, so no levels are open. Whereas in the first example, “:” refers to the whole site, which contains the page you are reading, so “.” is open — Samuele Tognini 2006-12-11 00:23

OK I have installed the latest version, but the sidebar still doesn't do what I expect. Never mind, it it still very good as it is and the namespace titles are all correct now. Thanks for all your help.

Thanks to you. Indeed i've noticed there is a stupid bug which displays red missed headpages even if headpages are off. About open levels, for the moment try putting ~~NOCACHE~~ sintax in your navigation page if it solves (this will slow down page rendering). The solution will be in 2.9 final release. Please,send me a mail describing how you have inserted indexmenu in navigation bar, this would really help me. — Samuele Tognini 2006-12-11 22:56

OK so, added in the NOCACHE syntax and the tree now doesn't stay expanded at all! Ho Hum. The Monobook template that I am using, just allows the syntax to be put into a sort of page and then uses the displaywikipage plugin to display it (I think). To be honest I have not develed too deep. It works and I like it!

• With PHP 5, sometimes the tree is not displayed. Until 2.8 is not out, solution is in darcs repository.Another temporary raw solution is here.

Solved in 2.8 — Samuele Tognini 2006-11-10 08:19

• Perhaps I am doing something wrong (I'm new to DokuWiki), but neither of the following is working for me:

{{indexmenu>.:myns#1|nons}}
{{indexmenu>.myns#1|nons}}

where myns is a namespace in the current namespace. Is this a bug in the plugin, or is my syntax off? – Tony Mann 2006-10-04

I've fixed it and include in the new release. — Samuele Tognini 2006-10-07 22:41

Thanks, I look forward to the new release. I am using the latest RC of DokuWiki, and this syntax is now supported (I use it for internal links elsewhere). If there is a better-supported alternative syntax for specifying a namespace relative to the current one, let me know.– Tony Mann 2006-10-05

Bug:The indexmenu_toolbar_icon is shown when u view the source of a page (read-only-permission).

Solution:

1. open script.js
2. find the following line

   function indexmenu_toolbar_additions() {

3. add the following below

           //to not show icon for read-only-users
   	var edbtn = document.getElementById('edbtn__save');
   	if (!edbtn) return; 

4. save!

– Neosky 2006-10-12

Thanks, Added in 2.7. — Samuele Tognini 2006-10-20 10:52

• No namespace title when the “.” namespace is requested. Wait next version for a fix.

• Indexmenu as navigation index for whole side (for example a sidebar) has strange behaviors when using userewrite and useslash. It opens wrong nodes because it should use an unique cookie to remember last node open, but with slash, you get a new cookie for every page visited.

• Javascript is not loaded, the script.js is not automatically loaded; I had to force it to load by adding the line below at syntax.php:188 :

187    $out = "<div class='dtree'>\n";
188    $out .= '<script type="text/javascript" src="'.DOKU_BASE.'lib/plugins/indexmenu/script.js"></script>'."\n";
189    $out .= "<script type='text/javascript'>\n";

Is that an issue with the plugin loader or… ? Thanks. Franck

Dokuwiki itself loads automatically every plugin scripts.js (javascript_dispatcher). Are you sure that it's not a js syntax error that breaks it? Have you tryed to purge cache (the better way is to use cacherevisionseraser)?.

Thanks, I still have to understand this javascript caching and at least make it work but this seems to be the explanation for my problem. Since this is not really related to this specific plugin, this can be deleted. Franck

• The level option doesn't work correctly in js mode. It opens one more node and level 0 doesn't work. I'll resolve it soon.</del>
• Empty namespace title when its headpage has no title.
• <del>JS tree is not built properly when there is a jump in levels between two following items bigger than 1. Here is the fix:

//remove last item
while ($item['level'] <= $data[end($q)-1]['level']) {
    array_pop($q);  
}

—-malyfred

Fix added in version 2.3. Many thanks, malyfred. — Samuele Tognini 2006-06-25 14:53