Bugtracker is available.

This is some text.

Hello, after having installed the plugin, when I edit any page, after I click on preview, the syntax button bar disappears and the edit window becomes small and is not resizable any more.

Hi the option “skip_index” worked fine for me with IndexMenu, but I can't get it to work with IndexMenu2.

No matter what I try, IndexMenu2 still displays the relevant namespaces and pages.

I tried the following:

(discussion|wiki|playground)

/(discussion|wiki|playground)\

/^(wiki|discussion|playground)\$/i

(from conf/default.php)

/\/(discussion|wiki|playground)(\.\w+)?$/i

(from the plugin page)

I'm trying to make this plugin work for me after a recent upgrade. One problem I've found is that Firefox is having trouble with at least one of the JavaScripts. I found an interesting page at javascript - the dom addEventListener and AttachEvent and followed the code to change the file indexmenu/cms/modifiers/followlinkcontent.js at the very end:

    el.appendChild(span);
    // <<-- BEGIN DELETED
    //    el.attachEvent('onclick', preventFollowLink);
    //    el.attachEvent('onmouseup', preventCloseOnFollow);
    // <<-- BEGIN INSERTED
    if (el.addEventListener) {
        el.addEventListener ("onclick",preventFollowLink,false);
        el.addEventListener ("onmouseup",preventCloseOnFollow,false);
    } else if (el.attachEvent) {
        el.attachEvent ("onclick",preventFollowLink);
        el.attachEvent ("onmouseup",preventCloseOnFollow);
    } else {
        el.onclick = preventFollowLink;
        el.onmouseup = preventCloseOnFollow;
    }
    // <<-- END CHANGES

Another issue - I have my wiki setup in the following manner:
* /
* /start.txt
* ns1/
* ns1/ns1.txt
* ns1/sometopic_related_to_ns1.txt
* ns1/another_topic_for_ns2.txt
* ns2/
* ns1/ns2.txt
* ns1/sometopic_related_to_ns2.txt
* ns1/another_topic_for_ns2.txt
* and so on to nsN…
* The issue I have is when indexmenu2 creates my index (I'm using

{{indexmenu>.#1|js#IndexMenu+ajax}}

), The expandable folders all show Error: could not fetch data from the server… I have moved my ns1.txt and ns2.txt to the root dir, but with this configuration, the behaivor of indexmenu2 is I don't get the expandable folders (to show ns1/*, and ns2/*)…
* Is this a configuration problem on my side? or is there something I'm missing?

Please, check the bug http://bts.debugger.ru/task/3 and leave comment, where can I see the error.

My Wiki is on a private intranet, so no public access to it… I have identified that the error is due to to this chunk of code in modifiers/ajaxum.js

    try {
      mo.ajaxum.fetcher(s, callback);
      showmsg('ajaxum_loading',mo.ajaxum.message.loading);
    } catch (e) {
      showmsg('ajaxum_error',"here");
      showmsg('ajaxum_error',mo.ajaxum.error.fetch);
      return;
    }

I added the showmsg('ajaxum_error',“here”); - I've looked in /syntax.php for the fetcher function (on line 234) but don't see where that function would be throwing an exception (you'll have to forgive my lack of knowledge about JavaScript)…

Its call is in the ajaxum.js file, line 133.

Please, email me menu's HTML code, it begins with '<ul id=“indexmenu'. I'll check what's wrong there. Thank you. — Ilya Lebedev 2006-10-06 12:02

I'm having similar problems with the recent version… when I have a namespace, which doesn't have sites in it but the “start” page it will throw out this message when I try to open the tree node… shouldn't it say something like “this namespace doesn't contain any sites”? in addition to that it messes up special chars in headings… for them in namespace headings, they are okay, but in article headings they are screwed up… where in namespace headings I have the word “Über” for example, in sites under that “üh” becomes “쨲” and “äm” becomes “䵭” and such stuff… Dominik Hertel 2007-11-05 10:28

I have Indexmenu2 v2.2.1 and have my setup in the ROOT of my domain. Given this setup, the JavaScript options of indexmenu simply will not load. >However, if I place the root of my wiki in a subdir, it does work.

You mean 2.1.1? There were no newer releases.

Yea, sorry, it reports full version as : Indexmenu 2 v2.1.1.93

In other words, a front page (with an indexmenu call) of:

http://www.mydomain.com/doku.php

JavaScript DOES NOT work/load!

however:

http://www.mydomain.com/wiki/doku.php

JavaScript DOES work/load

This is independent of whether or no I use rewriting rules (internal or .htaccess) or not. Also, indexmenu works either way, it's just a question of getting the JavaScript stuff to kick in.

I dug around in some logs and such and it seems that it's trying to find the lib/plugins/indexmenu/cms/extensions/e.js script, but is trying to call it from http://lib/plugins/indexmenu/cms/extensions/e.js (which won't work of course as it's missing the domain or a relative path reference).

This is as far as my knowledge would take me… I just suspect there is some path reference that is not robust enough (assumes that everyone runs their wiki in a subdir of their domain root). –Ryan

I cannot reproduce this bug on my local installation. Please, check http://pg.debugger.ru/ and http://pg.debugger.ru/dw/start – for me they both works the same.
Please, give me more details: DokuWiki release, config settings, etc. Do you have a public installation, where I can check the things? — Ilya Lebedev 2007-07-26 08:40

To test I took a basic installation (including indexmenu) and then put a copy in a public subdomain root and one in a public subdir of another domain:
- http://test.ryanjacobs.name
- http://www.ryanjacobs.name/test
I cleared the caches using the cache/revision eraser plugin, cleared my browsers caches, and tested each with both Firefox and Safari. For me, the JavaScript only works with the /test install. I can't seem to find any other way to duplicated this (apart from this subdir vs. no subdir thing) as both installations are otherwise equal copies. I should also note that I am not using any kind of rewriting, the only htaccess rule I have (in both installs) is

AddType x-mapp-php5 .php

(as I can't seem to get any of the indexmenu sorting to work without php5).

I am using the Firefox web developers plugin, and when I ask it to report all the JavaScript that each page loads, the results are different for the root and subdir installs. In the root install it shows that it is trying to load http://lib/plugins/indexmenu/cms/extensions/e.js (which is a path that makes no sense). However, with the subdir install, it seems that all called js paths are loading.
Could there be something strange on my end, or some kind of Apache or PHP conf stuff with my host that effects the results of indexmenu?
Please let me know if I can provide any other information, or if I am just missing something really obvious and/or crazy… — Ryan Jacobs

Ah, I see what happens. Somehow, DokuWiki does not set correct DOKU_BASE variable, used by Indexmenu to load all its stuff. http://test.ryanjacobs.name/lib/exe/js.php?edit=0&write=1 contains

  var DOKU_BASE   = '/';

As quick fix I suggest to set baseurl config property, pointing to your wiki installation. I'll submit the patch, fixing this behavior and upload new Indexmenu release on the weekend.
— Ilya Lebedev 2007-07-27 08:01
PS: I'll check sorting bugs, but as far as PHP4 is discontinued since 2007-12-31, I'm not sure if this makes sense…

I've modified string

.cmsRoot=DOKU_BASE+'/lib/plugins/indexmenu/cms/'

in script.js to

.cmsRoot=DOKU_BASE+'lib/plugins/indexmenu/cms/'

because DOKU_BASE always ends with a slash. This solved my problem with http://lib/plugins/.... — Alexander Zubkov 2007-10-16 13:54

Versions: DokuWiki rc2007-05-24, RemoteScript v0.9 and IndexMenu2 v2.1.1
On a fresh install of DokuWiki with the two plugins above, I get the following error(s):

Compact CSS and JavaScript output: disabled
Error: c.theme.merge is not a function
Source File: https://localhost/dokuwiki/lib/exe/js.php?edit=0&write=0
Line: 1318

Compact CSS and JavaScript output: enabled
Error: c.theme.merge is not a function
Source File: https://localhost/dokuwiki/lib/exe/js.php?edit=0&write=0
Line: 1318

Error: syntax error
Source File: https://localhost/dokuwiki/doku.php/nullextensions/e.js
Line: 1
Source Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">

This affects Firefox 2.0.0.4 and IE 6.0.2900. JS/Ajax does not function. Cache has been cleared >on the server several times Does anyone have any information on this? Thank you.

Hello,

Do you have public wiki installation, to check things there? — Ilya Lebedev »2007-06-15 07:50

I'm sorry, I'm not quite sure I understand what you're asking? This installation is on a private server contained in a private network. I can duplicate the installation on a public website so you can see the errors if you need me to? Thanks

You get it right - I need to have access to DokuWiki installation, to check things right on the place. Or, >have exact config settings, to reproduce the bug on my dev server. Please, send me the settings or >duplicate your wiki on a public server. — Ilya Lebedev 2007-06-23 10:28

I will do the installation and get everything set up for you and reply back again when it is ready. Thank you

Hmmm… there were a broken archive uploaded. It's strange, that you're the first, who noticed this. I've uploaded fixed release, please download and try it. — Ilya Lebedev 2007-07-01 14:11

I'm extremely interested in being able to easily write a JS-treeview directly from the code and not necessarily from the namespaces pages. First, I need to control the sorting of the pages (I don't want the pages to be alphabetically sorted but have a custom order).

Explain this, please. Navigation plugin does not do any sorting, because it operates with the static content. You can sort the list manually, on creation time.

Navigation respond perfectly to my need but I can't have it working, on the other side the {indexmenu} tag works perfectly.

Please, provide the steps to reproduce, or create test case at http://pg.debugger.ru/dw/playground/navigation

Any idea on my bug?
Thanks anyway, It's a great plugin :)

You're welcome 8*)
Feel free to record bugs at http://bts.debugger.ru/index.php?project=6 — Ilya Lebedev 2007-02-17 12:08

I set the 'hide_headpage' option to 'On'.
But, still find the namespace page (I use 'start' as pagename).
When I use PHP 4.4.2, that is happen.
When I use PHP 5.2.0, that is not happen.
For 'skip_index', same problem is occurred.
Don't you know why?
buffy 2007/02/14

I don't know why this happens, you may try to change 4.4.2 to some newer/older release, because it has several weird bugs. — Ilya Lebedev 2007-02-15 12:21

I try to use PHP 4.4.0 and 4.4.4. I get same result:-(
But, Don't worry.

I achieve a desired result using DokuWiki standard option (hidepages) and ACL feature.
Thanks for reply – buffy

Buffy, do you have the same DokuWiki release and config options on both servers?

Could you, please, give me more info to reproduce this locally?

If you have such a bug, then someone else could have the same… — Ilya Lebedev 2007-02-18 02:21

Hi, Ilya. An answer becomes slow, and I'm sorry. Every case, I use 2006-11-06 release. And DokuWiki's options are same. I tried PHP 5 and 4.4.4 on Windows XP and default installation of XAMPP 1.5.5a, locally. Other versions on the several free hosting servers. buffy 2007/04/03

Hi Buffy, I think, it's the function

  /**
   *  Emulates getConf for DokuWiki releases prior to current release candidates
   *
   *  @param string $var variable to get
   *  @return string value
   *  @access protected
   */
  function getConf($var) {
    global $conf;
    if (method_exists(DokuWiki_Syntax_Plugin,'getConf')) {
      if (!$this) {
        $tmp = & new syntax_plugin_indexmenu_indexmenu();
        $res = $tmp->getConf($var);
        unset ($tmp);
        return $res;
      } else {
        return parent::getConf($var);
      }
    } else {
      /*return @$conf['plugin_indexmenu'][$var];*/
	return @$conf['plugin']['indexmenu'][$var];
    }
  }

I commented out the current code and inserted a working version for DokuWiki 2006-11-06.
Additionally, in function indexmenu_search_index(), the parameter $file contains e.g. /namespace/page.txt, which doesn't match /^(wiki|page|playground)\$/i
– Christoph Purrucker, 2007-07-08

Hi, Christoph. Thanks for your advice. I tried to your code, and I get the good result. buffy 2007/07/30

Hello, I have try indexmenu2 with the latest stable release of DokuWiki but I receive this error message:
Warning: Invalid argument supplied for foreach() in /export/home/www/bin/apache-2.2.3/htdocs/dokuwiki/lib/plugins/indexmenu/indexmenu.php on line 24
Thanks, Alessandro Celli 07 Dec 2006

Hello Alessandro,

It might happen because you have alone the headpage in the namespace, or because of the empty namespace at all.

I've uploaded the new - 1.10 release - it does display the message, defined with the 'Empty message' config value. Maybe it will be better to don't show the folder, if only the headpage available… But for now plugin will show the error message.

Sincerely yours, — Ilya Lebedev 2006-12-08 19:10

Hello Ilya, thanks for your help. I have try to populate manually my workspace (I have create some file by console), I have clear the DokuWiki cache and I have retry. The problem does not solve. Any other idea? Can it be dependent on server side reading of folders and file?
Thanks, Alessandro Celli 2006-12-11 10:30

Do you still receive the 'Invalid argument' error? Could you, please, attach the `ls -la /problem/folder` screenshot and screenshot with the error? — Ilya Lebedev 2006-12-11 12:17

Hello Ilya, I have try to do some debug and I have see that the problem is on call of function search. I have try to modify its call like that:

  //search($data,$conf['datadir'],"indexmenu_search_index",$opts,"/".str_replace(":","/",$ns));^M
  search($data,$conf['datadir'],"indexmenu_search_index",$opts,str_replace("?","/",$ns)."/");^M

With the original call $data is empty, with the new call $data contains the correct info.
This is a simple example of $data array created by search function.

Array
  (
    [0] => Array
        (
            [id] => ced:sistemisti:testim:aaa
            [date] =>
            [type] => d
            [title] => ced:sistemisti:testim:aaa
            [target] => ced:sistemisti:testim:aaa
            [qry] => idx=ced:sistemisti:testim:aaa
            [level] => 1
            [open] =>
        )
    [1] => Array
        (
            [id] => ced:sistemisti:testim:page
            [date] => 1165840749
            [type] => f
            [title] => ced:sistemisti:testim:page
            [target] => ced:sistemisti:testim:page
            [qry] =>
            [level] => 1
            [open] => 1
        )
  )

Hello Alessandro,
Please, tell me your DokuWiki's URL rewriting settings and the initial value of the $ns var. — Ilya Lebedev 2006-12-11 14:20

Hello Ilya, I haven't setting DokuWiki's URL or $ns, DokuWiki's URL is empty. I have try to set basedir and baseurl variable, but the problem remain.

I meant DokuWiki's configuration settings. And, please, do the

 var_dump ($ns)

, like you did with the resulting array earlier. — Ilya Lebedev 2006-12-11 15:05

From

 var_dump ($ns)

I receive the string: ced?sistemisti?testim

Okay, thank you.
Could you, please, check the configuration settings - I don't understand, why do you have the question mark as the namespace separator…
If you could use any debug tool, like LiveHTTPHeaders plugin for Firefox or Proxomitron, please take a look - what headers are sent on the menu Ajax call.
And, check, please - what data do you have in the HTML comment (<!– –>) blocks in the menu body. In the normal case you'll see ced:sistemisti:testim
Ps: the final patch for your bug is:

$ns = strtr($ns,":?","//");
search($data,$conf['datadir'],"indexmenu_search_index",$opts,"/".$ns);

— Ilya Lebedev 2006-12-11 16:00

Hi Ilya,
This is the page content:

<ul><!-- ced:sistemisti:testim --></ul></li><li><a href="/dokuwiki/doku.php?id=ced:sistemisti:attivita" class="wikilink1" title="ced:sistemisti:attivita">attivita</a></li>

I haven't the plugins LiveHTTPHeaders, Proxomitron, if is need I try to install it.
I have try to apply your patch but index menu does not work yet. I receive the error: Error: could not fetch data from the server

Hello again, Alessandro
Huff that becomes boring

Let's continue. Please, open the following URL:

http://<your_host>/<wiki_base>/lib/plugins/remotescript/rs.php?args[src]=ced%3Asistemisti%3Aattivita&callback=indexmenu&method=getsubmenu&JsHttpRequest=11658514489590-script

and paste the result here with and without the last patch.

I need to localize a place, where do we get the question marks on the wrong places…

Hi Ilya, this is the output.

// BEGIN JsHttpRequest
JsHttpRequest.dataReady(
  '11658514489590', // this ID is passed from JavaScript frontend
  '<br />\n<b>Warning</b>:  Invalid argument supplied for foreach() in <b>/export/home/www/bin/apache-2.2.3/htdocs/dokuwiki/lib/plugins/indexmenu/indexmenu.php</b> on line <b>45</b><br />',
  ''
)
// END JsHttpRequest

It seems, that it was with the patch?
Please, append there

 var_dump($ns)

and paste it again, please. — Ilya Lebedev 2006-12-11 17:38

I have do:

// BEGIN JsHttpRequest
JsHttpRequest.dataReady(
  '11658514489590', // this ID is passed from JavaScript frontend
  'string(26) \"NS=ced/sistemisti/attivita\"\n<br />\n<b>Warning</b>:  Invalid argument supplied for foreach() in <b>/export/home/www/bin/apache-2.2.3/htdocs/dokuwiki/lib/plugins/indexmenu/indexmenu.php</b> on line <b>47</b><br />',
  ''
)
// END JsHttpRequest

Please, try this search call

search($data,$conf['datadir'],"indexmenu_search_index",$opts,$ns);

Hello Ilya, I have tried but I haven't any changes.

Hello Alessandro,
Please, update the indexmenu and try again. — Ilya Lebedev 2006-12-12 18:07

Hello Ilya,I have try to update the indexmenu version but the problem persist.
But I have try to do a simple test. I move all my DokuWiki site on a Linux machine (actually is under a Solaris 10) and all work fine!
I think that the problem can be involved by the management of charset. I have this suspect because the $ns contains the chars ? and not /. this a typically error given by character representation.

Hello Alessandro,
Yes, I agree with you.
That's why I trying to find, on what point you receive the question marks.
Could you, please, do the following: assign $ns manually, i.e.

$ns = "ced:sistemisti:attivita";
echo "NS=";
var_dump($ns);
echo ";"
$ns = strtr($ns,":?","//");
echo "NS=";
var_dump($ns);
echo ";"
search($data,$conf['datadir'],"indexmenu_search_index",$opts,"/".$ns);
echo "Data=";
var_dump($data);
echo ";"

save the output, then comment $ns assignment and try it again with the same namespace in the URL. — Ilya Lebedev 2006-12-14 13:59

Alessandro, please update the both indexmenu2 and remotescript plugins. I've found the solar server and tried menu there - solar does something strange with the encodings, at least autodetection does not work. I've forced to use 'UTF-8' and everything worked. — Ilya Lebedev 2006-12-22 11:11

I get an unexpected result with indexmenu2, which may be caused by the structure of my namespaces. If I use:

{{indexmenu>:#2|js#IndexMenu+ajax}}

I would expect to see a tree with all the namespaces under the top level, plus all the pages at the top level. But all I see is a single link to “Home”. Do I have to specify a namespace instead of simply using a : to represent the top level?

Hello,
Please, update the indexmenu plugin. I've solved this issue. — Ilya Lebedev 2006-12-12 17:50

I've updated to Indexmenu 2 v1.11.2.11 but the problem remains, even after flushing my cache.

Could you, please, paste your filelist from data/pages (root namespace)? It seems that you've namespace with name similar to $conf['start'] ('start' by default). — Ilya Lebedev 2006-12-14 11:32

Another bug: my DokuWiki is in /wiki/, so my URL are like /wiki/folder/doc.
I have this

{{indexmenu>Playground#1#sort+title+rev|js#IndexMenu+ajax}}

and when I try to expand the menu, URL includes a “wiki” so it breaks URL. There are some screen shots:


Thanks for your support!

Please, update the RemoteScript plugin, it seems that you use older version, that do not take in count DokuWiki's internal settings. If this won't help, please take a look at pg.debugger.ru/wiki (test|test) and try to reproduce the bug there

Thanks for your answer. I've updated remotescript and indexmenu2 plugins without success.

Could you, please, tell me as much as you can about the config, to help me to reproduce the bug?

Plugins
* default
* remotescript
* indexmenu
URL
* I use the .htaccess rules, with RewriteBase /wiki
* basedir: /wiki/
* baseurl: http://dev03
Files
* http://elicoz.org/bugs/dokuwiki/htaccess.txt
* http://elicoz.org/bugs/dokuwiki/local.php.txt
If you want I can send you my complete installation with files.

That will be great, if you can do that. And what OS/server do you use?

And, if possible, check the invalid_argument_supplied_for_foreach_in_indexmenu.php bug report, maybe both bugs are related together…

I don't think it's the same bug for what I understood, but I didn't get it very well.

I've also tried to create a page on pg.debugger.ru/wiki but the id does not allow it.

I've updated the ACL policy, try again, please. — Ilya Lebedev 2006-12-18 17:26

It doesn't seem to work on the “wiki” namespace.

Test login had to be lost somehow. Fixed.

And thanks again Ilya for your quick support! — Corentin 2006-12-18 18:22

You're welcome 8*)

Ok, the source code is online: http://elicoz.org/bugs/dokuwiki/wiki.tgz
I'm trying to install it on a Debian. It works fine when I move the wiki to the root, otherwise that behaviour persists.

Hello, Corentin

I've fixed several uses related to this problem and your installation works fine on my server
Please, update both Indexmenu and RemoteScript plugins. — Ilya Lebedev 2006-12-22 11:11

Hello and happy new year Ilya!

Mine starts just fine with those new updates that have fixed that bug. — Corentin 2007-01-02 14:35

Hello Ilya I have find a little bug on URL generation from menu. If the DokuWiki base URL is like: http://localhost/dokuwiki/doku.php?id=lavoro:database:clonazione with the option:

indexmenu>:ws#1|js#IndexMenu+ajax

On expand node of the tree the URL of this page is:

http://localhost/doku.php?id=lavoro:database:clonazione

Obviously it is wrong because is less “dokuwiki/” after http://localhost If I can give to you a suggest you can build the URL with basedir configuration options to resolve the problem Thanks for the attention. Alessandro Celli

Hello Alessandro,

I use built-in DokuWiki's function to create the href attribute for the anchors… Is the URL correct with other options (i.e., when static menu is generated)? — Ilya Lebedev 2006-10-14 22:12

Hello Ilya,
yes with static menu generation like indexmenu>:lavoro|js#IndexMenu all URL are right — Alessandro Celli 2006-10-15 13:32

It is not the direct issue of Indexmenu2 plugin, but of the remotescript one. It has been fixed, update plugin, please. — Ilya Lebedev 2006-10-15 16:34

* I had an issue where upon initial installation I was getting unexpected T_VARIABLE errors from line 338 in syntax.php… I corrected these by using this code snippet:

/* $base = array_pop(explode(":",$item['id'])); */
/* above is the original, below is the modified */
$temp = explode(":", $item['id']);
$base = array_pop($temp);

Thank you, I've updated the package. — Ilya Lebedev 2006-10-01 00:08

Hello Ilya, I think there is another bug in the dynamic URL generation (ajax). When using the static menu generation the menu is alright, but when using something like

{{indexmenu>:technical_sessions#1|js#IndexMenu+ajax}}

all subsequent opened menu's point to a path on the server's local disc instead of a relative URL (eg. d:\Program Files\xampp\htdocs\dokuwiki/doku.php?id=technical_sessions:ptw2006:arch-01 instead of http://server-name/dokuwiki/doku.php?id=technical_sessions:ptw2006:arch-01). I'm using the latest version of both remotescript and indexmenu2. Any idea? Thanks for any help at solving this, Lieven.

Hello Lieven

Please, try to replace the original string in the /plugins/remotescript/rs.php

if(!defined('DOKU_BASE'))  define('DOKU_BASE',str_replace($_SERVER['DOCUMENT_ROOT'],"",DOKU_INC));

with this one:

if(!defined('DOKU_BASE'))  define('DOKU_BASE',str_replace(str_replace("\\","/",$_SERVER['DOCUMENT_ROOT']),"",str_replace("\\",Δ"/",DOKU_INC)));

It seems, that the bug is in the incorrect DOKU_BASE calculation, because of the windows-style paths, provided by the realpath&&dirname and UNIX-style paths in the DOCUMENT_ROOT.

That seems to do the trick, thanks a lot!

Thank you for the report. RemoteScript plugin has been updated. — Ilya Lebedev 2006-10-26 16:11

I don't know if it's a bug, but indexmenu2 won't work with when you activate gzip compression for CSS and JavaScript files.

It works fine for me with IE5, 5.5, 6, 7, FF1.06, 1.5, Opera 9.02.

Please, provide more info: browser, its version, DokuWiki build and error message, if any exists. — Ilya Lebedev »2006-11-20 19:52

Version is 2006-11-06, it happens with Firefox2 or IE6 when config gzip output is on. It may have an impact: I use .htaccess rewriting with a slash as category separator.

Personally, I use the same settings on the cms.debugger.ru and cannot reproduce the error.
Do you have any errors in the Firefox's console?

I cannot reproduce this bug anymore. I am also not able to say which upgrade fixed it.

Another issue - I have my wiki setup in the following manner:
* /
* /start.txt
* ns1/
* ns1/ns1.txt
* ns1/sometopic_related_to_ns1.txt
* ns1/another_topic_for_ns2.txt
* ns2/
* ns1/ns2.txt
* ns1/sometopic_related_to_ns2.txt
* ns1/another_topic_for_ns2.txt
* and so on to nsN…
* The issue I have is when indexmenu2 creates my index (I'm using

{{indexmenu>.#1|js#IndexMenu+ajax}}

), The expandable folders all show Error: could not fetch data from the server… I have moved my ns1.txt and ns2.txt to the root dir, but with this configuration, the behaivor of indexmenu2 is I don't get the expandable folders (to show ns1/*, and ns2/*)…
* Is this a configuration problem on my side? or is there something I'm missing?

Please, check the bug http://bts.debugger.ru/task/3 and leave comment, where can I see the error.

My Wiki is on a private intranet, so no public access to it… I have identified that the error is due to to this chunk of code in modifiers/ajaxum.js

    try {
      mo.ajaxum.fetcher(s, callback);
      showmsg('ajaxum_loading',mo.ajaxum.message.loading);
    } catch (e) {
      showmsg('ajaxum_error',"here");
      showmsg('ajaxum_error',mo.ajaxum.error.fetch);
      return;
    }

I added the showmsg('ajaxum_error',”here“); - I've looked in /syntax.php for the fetcher function (on line 234) but don't see where that function would be throwing an exception (you'll have to forgive my lack of knowledge about JavaScript)…

Its call is in the ajaxum.js file, line 133.

Please, email me menu's HTML code, it begins with '<ul id=“indexmenu'. I'll check what's wrong there. Thank you. — Ilya Lebedev 2006-10-06 12:02

The <div …> for the tree is enclosed in a <p> tag. to stop this, the plugin needs to implement another method that tell DokuWiki that the plug will handle the block level, and prevent the <p> ~~output~~ </p>:

  /**
   * What about paragraphs?
   */
  function getPType(){
    return 'block';
  }

2007/01/23 kite [at] puzzlers [dot] org

Thanks kite, I've updated the plugin

2007-02-05 09:11 CEST (Austria)
I would like to install this plugin, but the website for the downloads at
http://cms.debugger.ru is not reachable!
Please repair this. Mark Jackson

Sorry, ISP had a huge crash, and I was out of office to fix this. Currently, site is up and running.
— Ilya Lebedev 2007-02-05 17:26

Okay, thanks a lot; Mark

I have installed the plugin on my 2006-11-06 DokuWiki and everything seems okay, no error messages.
I attempt to try some tests, nothing works. Finally I got

{{indexmenu>:#2|js#IndexMenu+ajax}} 

to work but no Ajax or JavaScript is working. I want dynamic lists basically. There are no »error messages and yet something is wrong because it doesn't work. I installed all the necessary plugins (remotescript). Please email me at nickjon at gmail dot com with any advice on how to »get JavaScript+Ajax functionality. Other JavaScript works on the webserver but I've had issues with DokuWiki. Thanks Nick

You need to purge the cache to have plugin JavaScript code used in the page. — Ilya Lebedev 2007-02-07 11:15

I figured this out when I chmodded +x the js file for a different plugin called outliner to get it working, not only did 'it' start working, the indexmenu plugin started working, then came here to let you know how I fixed it. From the cache purge howto “Plugins can now influence cache use via the PARSER_CACHE_USE event.” It would be great if the plugin manager or the plugin itself could do this for you. For now I'm just going to disable the cache as it does more harm than good. Well thanks a lot for your assistance, this plugin is great! Nick

Hi Nick,
Unfortunately, this event does not allow to prevent caching for CSS and JavaScript files. I can suggest to post feature request for plugin manager, to clean up cached CSS and JavaScript files on update. In my opinion, it's quite bad practice to implement such core-related features in the ordinary plugins. — Ilya Lebedev 2007-02-13 22:56

Often, Konqueror goes slowly and use a lot of CPU.
This error appears, enabling JavaScript “report errors” feature:

An error occurred while attempting to run a script on this page.
http://www.mysite.com/lib/plugins/indexmenu/cms/extensions/objec...line26:
RangeError:Exceeded maximum function call depth

This error happens 3 times, followed by this one (for more times):

An error occurred while attempting to run a script on this page.
http://www.mysite.com/lib/plugins/indexmenu/cms/extensions/objec...line27:

No problems with Mozilla-Firefox-2.0.0.1-r2 (Gentoo box).

It looks similar to the problems in Safari.
Please, try using this patch: http://forum.dokuwiki.org/post/2341 — Ilya Lebedev 2007-03-13 06:52

Sorry, this patch: http://cms.debugger.ru/dl/lib.zip doesn't work for me.

It does not solve the problem? Can you explain it a bit?
Please, clean the DokuWiki's cache and try again. — Ilya Lebedev 2007-03-16 14:49

Okay, problem solved without the patch. I've just removed old installation, saving just data dir and some conf file. So, the problem may depend from a bad update.

The now version of this plugin will cause the latest version of dokuwiki 'Weatherwax' broken in js. because it maybe use prototype.js or sth. like that, which will extend the original object in js, this will cause the new jQuery to behave quirks.