Archive of TreePluginDev

Bugs

• Topics with same name in different webs are noted as the same (when checking for recursion).
• the web parameter does not work for another web as the current web.

• Several bugs are entered in the Support web (see HowShouldBugsBeReported). These include:
  • TreePluginBugsGlew2002Apr14
    • TreePluginBugsGlew2002Apr14Sample
    • TreePluginBugsGlew2002Apr14SampleOutput
  • TreePluginBug2003May28PagesGetDropped
  • TreePluginBug2003May28NonWikiwordLinks

Bugs Fixes

• Before version 0.300 the mailnotify script was corrupted by not finding query_string.
  This is now fixed in version 0.300!
• The version 0.300 had a corrupt file structure in the zip file. New version 0.310 has this repaired.

Enhancements

?

See also: TreePluginSamples; and related RenderListPlugin.

-- SlavaKozlov - 16 Feb 2002

Thanks for the samples, I now understand what this plugin is all about! Looks very useful - would be good to have a quick summary at the top of TreePlugin, e.g. 'enables dynamic generation of outliner-style hierarchies based on a set of pages, for use as a dynamic sitemap or ...'.

Using this to generate a sitemap would be particularly useful. TWiki sites are often quite hard to navigate if they grow organically over time (hence work such as MasterRefactor).

-- RichardDonkin - 17 Feb 2002

This looks great. I have been doing a fair amount of hacking on WebMap lately. Stuff like porting it to TWikiRelease01Sep2001 and fixing a lot of bugs. I do have it working & deployed on our internal site, but it needs a complete rewrite something along the lines of WebDOTPlugin.

If you are interested, maybe we could do some work together to share base classes for generating the parentage etc, then allow the components to be easily used together. Hopefully in the end we would have a kick butt mechanism for either text based trees or graphical treemaps.

-- JohnCavanaugh - 17 Feb 2002

Thanks, Richard - I'll change the description at some point.

John- It's not a problem to cooperate on the code. The current TreePlugin is extensible as formatting goes, though it does assume that the tree will be in HTML (and embedded within a topic) and that it can be constructed more or less linearly. Making this into a stand alone cgi script to interact with a Perl friendly graphics package shouldn't be too hard. Interfacing with a WebDOT server (which I know nothing about) is an open question.

I looked at the WebDOT topic and the focus appears to be more on references between topics, no? These are much harder to both gather together and to draw (trees can always be drawn in 2D).

I do have one caveat about using lots of cool-looking interactive graphics apps for a sitemap: that the tool may become an impediment to the task (ie, users will have to figure out how to use the tool before getting to their real intent, which is navigating thru the site). See a Jakob Nielsen article.

-- SlavaKozlov - 22 Feb 2002

Added basic design description above.

-- SlavaKozlov - 28 Feb 2002

When I use the Web="SomeWeb" parameter, the generated tree is right except the links generated all point to the current web instead of the SomeWeb web. Hence broken links.

-- JeromeBouvattier - 10 Mar 2002

Slava, I just noticed annoying bugs related to cron jobs. I am using 20011201 on W2K/Apache.

The mail notification command generates the following error : "TWiki mail notification - to suppress all normal output: mailnotify -q Can't call method "query_string" on an undefined value at c:\twiki\lib/TWiki/Plu gins/TreePlugin.pm line 66."

The statistics generation command generates the following error : "Can't call method "query_string" without a package or object reference at c:\twiki\lib/TWiki/Plugins/TreePlugin.pm line 66."

These command work very well if I disable the TreePlugin . Any clues ?

-- JeromeBouvattier - 11 Mar 2002

Jerome:

Yes, I guess I only tested it under 'web circumstances', where CgiQuery will be a real object. You'll need to change

line 66 of TreePlugin.pm to:

my $plist; $plist = $CgiQuery->query_string() if $CgiQuery;

line 68 to:

$CurrUrl = $CgiQuery->url . $CgiQuery->path_info() . "?" . $plist if $CgiQuery;

line 275 to:

my $tmp; $tmp = $CgiQuery->param( $paramname ) if $CgiQuery;

Let me get back on your other question regarding crossing web boundries.

-- SlavaKozlov - 15 Mar 2002

Thanks Slava ! Stat and Notifications are working now. I also had to comment the debug line in InitPlugin that was polluting the debug.txt file.

-- JeromeBouvattier - 19 Mar 2002

Is there a way to generate the tree offline similar to WebStatistics? The presentation capabilities look promising, but I can't image, that it will be faster than the WebIndex. And that one is too slow for regular use.

Just a thought: couldn't be the formatter create a Javascript file with a tree menu? After it's loaded once, it could speed up usage considerably.

-- PeterKlausner - 04 Sep 2002

I find this plugin a very usable idea! But I would like to have the option to omit the top node, so I can only display the topic's children.

-- ArthurClemens - 12 Nov 2002

Anybody any idea how to combine that with stuff like http://www.treeview.net ?
And: the current way to modify the parent is too inconvenient. While it is ok to build up a high barrier for a function like rename, maintaining the parent tree this way is unpractical, see also NavbarPluginDev. I changed the <input name=topicparent type=hidden to <input type=text and edit it directly. Much more convenient. Allows you even to work bottom up, i.e. create parents from children.

-- PeterKlausner - 13 Nov 2002

I tried installing this plugin but..... it expects a CGI query to exist in the init procedure, so any scripts (such as actionnotify from ActionTrackerPlugin) that call TWiki::initialize outside the context of a CGI query blow up. You cannot assume a CGI query will exist!

• That's probably SlavaKozlov's patch from 15 Mar 2002 above, PeterKlausner

-- CrawfordCurrie - 14 Nov 2002

There is a bug in the script, since it generates img links pointing to the topic's folder, but the gifs are in /pub/Plugins/TreePlugin!

E.g.: http://localhost/twiki/pub/Sandbox/TestTopic2/L.gif
should read as
http://localhost/twiki/pub/Plugins/TreePlugin/L.gif

-- MartinRaabe - 15 Jan 2003

Excuse me, this was not a bug in the script, this was a bug in the sample page TreePluginSamples.

-- MartinRaabe - 19 Jan 2003

Added a bugfix and uploaded the Version 0.300 to the TreePlugin topic. I would love to insert this into CVS. How should I do that, since I have no write access to it.

-- MartinRaabe - 19 Jan 2003

Added a bugfix and uploaded the Version 0.310 to the TreePlugin topic. I have inserted this TreePlugin into CVS.

-- MartinRaabe - 20 Jan 2003

How do I get the TreePlugin to display a tree rooted at the current topic. I have tried something like:

%TREEVIEW{web="TWiki" topic="%TOPIC%" formatting="outline"}%

But this does not work. I assume that the TOPIC variable is not getting evaluated correctly, but I don't understand why and therefore how to correct it.

Another question:

Is there anyway to get the TreePlugin (with multiple calls or combined with something else) to display something similar to the following for a topic like TreePluginDev

GrandParent
   Parent
      Sibling 1
      TreePluginDev
         Child 1
            Subchild 1
         Child 2
            Subchild 1
            Subchild 2
      Sibling 2
      Sibling 3

Basically this would allow support for something that would look like and expandable menu. If this isn't supported, can anyone give me pointers on ways to get to something similar to this or places to start hacking on the plugin to support this?

-- AllenBierbaum - 10 Feb 2003

I think I just found a bug. If I try to use TREEVIEW more then once in the same topic, only the first tree is displayed. The rest of the trees are empty and do not evaluate correctly.

Does everyone else see this bug as well? Any ideas on how to fix it?

-- AllenBierbaum - 10 Feb 2003

Hello Allen, I can see this as well and unfortunately don't know, ho to fix it.

-- MartinRaabe - 11 Feb 2003

Hello, everyone, I haven't looked at this for like a year (it worked, so you know...). Glad others have found it useful. Here are some answers from my memory....

1) Thank you Martin for taking care of Plugin in my inattendance. Sure, CVS inclusion (what that is I'm not sure) would be cool.

2) Thank you AllenBierbaum for encountered the dragon-cannot-eat-its-own-tail feature (gentle self-sarcasm). There are problems in having two TREEVIEWs in the same topic or even in the same tree and having TREEVIEW view its own ancestor's tree. Basically infinite loops because it does parse the whole tree's pages. So I just clamped it down cold (nothing at all can happen on the second TREEVIEW) and left that design for another day (mentioned above in design notes). Suggestions for fixture (that's fix + feature) welcome.

• I (AndyGlew) have run into this bug, as well as several others (listed above, below, and in Support web).
  • It seems to me that the problem arises because TreePlugin is run as a Perl module in the context of the twiki/bin/view Perl scri[t.
  • I think the problem will go away if some or all of TreePlugin is run as a separate process, so that the hash tables that record what has been seen are started afresh for each TREEVIEW (not just for each page)
    • should be fine for UNIX
    • might hurt Windoze performance - but, premature optimization, right?
  • this approach could also provide some useful command line utility programs for visualizing the wiki contents without a web browser
  • suggest separating (1) figuring out tree structure, and (2) formatting of tree. XML?

3) PeterKlausner's suggestion of integrating with www.treeview.net (what a curious name coincidence) ... I mention the possibility of using JavaScript in Samples file. If some one can figure out the pattern that the javascript needs, this is probably possible with current Plugin implementation (that's how I did the image tree).

4) Yes, I don't make use of TWiki's features like mailnotify, etc, so never bumped into these bugs (where's the feature-wide test suite?! )

5) Performance considerations: a) "premature optimization is the root of all evil" (D. Knuth); b) I speedied up search considerably on my host (all uses of SEARCH, including in WebIndex) by using perl do to do the searching not some process-expensive 'grep' calls; c) it is possible to make a static instead of a dynamic generating, as now, mode - though I'm not sure how well TWiki's mechanism for 'preparsed' or 'precompiled' txt is (like WebStatistics).

Any more questions? Does this work with the Beirut release? I guess I'm about to find out.

-- SlavaKozlov - 20 Feb 2003

Hello SlavaKozlov, yes it workd with Beijing as you might see in the Category form below.

The CVS story is, that TWiki now is on sourceforge.net, which meand there is a public Repository of version controlled files maintained by the version control tool cvs.

I'd love to see a hint (or the entire fix) from you to be able to generate the treeview for another web. The bug is that the TWikiWords are rendered in the current and not the referred web.

-- MartinRaabe - 20 Feb 2003

Yeah, Ok on info on CVS. I have read the relevant docs on Twiki. Will put up when chance is had.

As far as seeing trees across webs ("transweb trees"): I guess at the time I thought it odd thing to cross webs much at all, so I never fully tested. I will look into matter (seems like a minor bug), but it may take a few days as I haven't done any perl since a year ago either.

Any other features desired?

-- SlavaKozlov - 24 Feb 2003

Hello SlavaKozlov, the TreePlugin is already on CVS. I already imported it! So no work to be done there. See also the attached WebForm!

Regarding the Transweb Tree. There is definitely a demand. I would love to see you doing the fix. It is only that the Web variable has to be inserted in the generated topic links. that's all.

-- MartinRaabe - 25 Feb 2003

Anyone else getting Use of uninitialized value in concatenation (.) or string errors in TWiki.pm (line 1833 and 1834) and TopicVarsPlugin.pm (line 76, 177 and 206)? Looks like some functions are called without the appropriate arguments.

-- MichaelRausch - 10 Apr 2003

I'm getting a Can't call method 'query_string' on an undefined argument from line 63 of TreePlugin.pm. Again, it looks like some functions are called without the appropriate arguments.

I'm running Twiki of 01-Feb-2003.

-- AntonAylward - 29 Apr 2003

I've got a web that uses a lot of non-TWikiWords. The TreePlugin didn't make these into links, so I hacked the portion I was using so that all topics in the tree are rendered as topic links.

Here is the syntax I'm using:

%TREEVIEW{topic="SpatialDataCatalogue", web="Gisdata", formatting="imageoutline:threadexp"}%

I modified /lib/TWiki/Plugins/TreePlugin/ImgNodeformatter.pm

line 64 from: ...\$topic...

to : ...[ [\$topic] ]...

It'd be nice if I could change this easier for all the different formatting options in the plugin, but really, this is the only one I'm currently using.

Anyone see problems with my approach?

-- TylerMitchell - 01 May 2003

Is it possible to get the TreePlugin to also list attachments included in the "File Attachment Contents Table" (i.e. not hidden attachments) when it generates it's tree structure?

-- IanGilmour - 16 May 2003

I've entered several bug reports into the support web, including some that have already been discussed above:

• Several bugs are entered in the Support web (see HowShouldBugsBeReported). These include:
  • TreePluginBugsGlew2002Apr14
    • TreePluginBugsGlew2002Apr14Sample
    • TreePluginBugsGlew2002Apr14SampleOutput
  • TreePluginBug2003May28PagesGetDropped
  • TreePluginBug2003May28NonWikiwordLinks

-- AndyGlew - 02 Jun 2003

I thought that I would do the right thing, and run the Treeplugin test suite, before fixing any of the bugs I have found.

I must be stupid - I cannot get the TreePlugin test running. Or, rather, I am spoiled - I am used to being able to type

make test

and having a test run.

I am not even clear as to how I am supposed to run the TreePlugin tests. I am guessing that, in the .../twiki/lib/TWiki/Plugins/TreePlugin/test directory, I should just run

perl PluginTest.pl

but I have tried

perl TestRunner.pl

for good measure.

I am getting error messages like "Undefined subroutine &TWiki::getCgiQuery...". Since the TWiki module is being use'd, and since the function exists, it is probably just the usual crap of having to get the @INC or other path set up right. (The sort of thing that should have been figured out once and for all; I note that PluginTest.pl attempts some use of relative paths.)

Running the tests should not take so long.

I note, by the way, that I do have PerlUnit installed; other PerlUnit tests run fine. Just not TWiki's TreePlugin tests.

The bug... TreePlugin/test/PluginTest.pl use's TWiki::Func. TWiki::Func is not freestanding - it depends on TWiki::getCgiQuery (in TWiki.pm), which was not loaded at this point in the script, but which is, of course, normally loaded in the twiki server.

Sigh. It looks like this sort of thing is spread throughout TWiki, not just the TreePlugin tests. I'll add more details in a proper "bug report" (I continue to have this naive belief that entering a well described bug report in the support database is a good thing to do.) See TreePluginTestBugsExposeTWikiModuleDependencyBugs

-- AndyGlew - 18 Jun 2003

OK, separate from the module dependency bug, I still get the test failing... this time it looks like a real bug. TreePlugin::cgiOverride was not doing a null check on the global $cgi variable.

Adding the null check... there still appear to be errors.

-- AndyGlew - 18 Jun 2003

OK, the next error was due to not having a definition of assert available. It looks to me as if TreePlugin's tests were written with an older version of PerlUnit; use'ing Test::Unit::Procedural peels that layer of onion skin.

-- AndyGlew - 18 Jun 2003

To the support/bug-report TreePluginBug2003May28PagesGetDropped I have attached a patch that

• fixes the bug whereby pages disappear - GOOD FIX?
• fixes the bug whereby non-wiki-word page titles do not get linked. unfortunately, this fix not 100% kosher. See TreePluginBug2003May28PagesGetDropped for details.

-- AndyGlew - 04 Jul 2003

This is a nice plugin, and my users have been using it to help them refactor the hierarchy of webs. I will just contribute the 3 topics I have made for it. To use them, just:

1. download the tar.gz somewhere, e.g. /tmp/TreePlugin.topics-v1.tar.gz
2. go to your data/ twiki dir, and as root or with the id of the web server,
3. type: for d in _default [A-Z]*;do cd $d;tar xfz /tmp/TreePlugin.topics-v1.tar.gz;cd ..;done

It will create topics WebTree, WebTreeTable, WebTreeBars in webs that are linked to each other. change your skin to point to one (WebTree for instance).

You can see them in action at http://koala.ilog.fr/wiki/bin/view/Koala/WebTreeBars. It will be part of the next KoalaSkin release.

archive is: TreePlugin.topics-v1.tar.gz: Sample topics to use in all webs

-- ColasNahaboo - 13 Aug 2003

I am wondering if anyone has any ideas on how to implement the ability to display, say, the first heading from a Topic that is included in the tree. In other words, display that heading instead of the WikiName. This would be useful in creating more user-friendly trees in certain situations.

-- TristanGreaves - 15 Aug 2003

Can someone explain why it is currently not possible to handle multiple %TREEVIEW%'s in the same topic? I ask because I have an "index" of parent topics and I would like to display, on the same page, the child tree of each parent topic. Each parent is independent of the other so the liklihood of recursion is <0% . I guess I don't quite grok the issues. Thanks

-- SteveRJones - 10 Dec 2003

Ok, I've discovered a way around this. If I add the %TREEVIEW% command into the Parent topic, wrap the command with %STARTINCLUDE% %STOPINCLUDE% and %INCLUDE% the TREE portion of that topic into my master index, all works well and I get multiple trees all collected within the same topic. I suppose this has to do with the %INCLUDE% and how TWiki manages the parsing and rendering.

-- SteveRJones - 10 Dec 2003

This Plugin could be used together with the RenderListPlugin by specifying formatting="ullist". There is one issue: The tree top is a paragraph; and the RenderListPlugin expects it to be a bullet with one indent (that is all bullets should be shifted to the right by one.)

-- PeterThoeny - 11 Dec 2003

I discovered a line in TreePlugin whereby the plugin was always writing to data/debug.txt regardless of the state of Set DEBUG. The changed lines are:

FROM:

    &TWiki::Func::writeDebug( "installWeb: $installWeb" );

    # Get plugin preferences, the variable defined by:          * Set EXAMPLE = ...
    # $exampleCfgVar = &TWiki::Prefs::getPreferencesValue( "TreePlugin_EXAMPLE" ) || "default";

    # Get plugin debug flag
    $debug = &TWiki::Func::getPreferencesFlag( "TreePlugin_DEBUG" );

TO:

    # Get plugin preferences, the variable defined by:          * Set EXAMPLE = ...
    # $exampleCfgVar = &TWiki::Prefs::getPreferencesValue( "TreePlugin_EXAMPLE" ) || "default";

    # Get plugin debug flag
    $debug = &TWiki::Func::getPreferencesFlag( "TreePlugin_DEBUG" );

    &TWiki::Func::writeDebug( "installWeb: $installWeb" ) if $debug;

The salient changes are:

• Added the $debug test
• Moved the Preferences fetch to occur prior to the test for $debug

This isn't really a big find but logging at every invokation can become expensive and our internal TWiki site is using TreePlugin quite extensively on a growing number of topics. Unfortunately I don't have a diff or patch file but will upload a patched version.

-- SteveRJones - 23 Jan 2004

Ok, I've rev'd TreePlugin.pm, pulled the patched TreePlugin.pm into the zip distro, and uploaded to the TreePlugin topic.

-- SteveRJones - 23 Jan 2004

I wrote a small improvement to show only nodes on the current path. By specifying pathview="on" option only nodes which are on the path from the specified topic root to the current topic or if their parent is on this path are displayed. The intension is not to expand all of the nodes, but only the necessary subset for navigation tasks. The patch based on V0.311 is here: TreePlugin_pathview.diff.

I tested it only with the ImgNodeFormatter.pm e.g. imageoutline style. But the computation and processing of the node subset should also work with other styles. Enjoy it!

-- RobertSuna - 03 Feb 2004

One thing we have noticed about this plugin is that it appears to be extremely expensive to run, especially as the size of a particular TWiki web grows. As I noted above, we discovered a way around the "one Topic, One Tree" self-imposed limitation by having a tree contructed in separate topics then INCLUDING them each in a single topic, but doing this simply makes the expensiveness that much more obvious.

I suppose my comments are simply a warning -- I am not pointing out any fix -- and I may simply be stating the obvious.

-- SteveRJones - 17 Feb 2004

I've emailed the author about bringing the cvs copy up to date with the released zip version.

-- MattWilkie - 28 Mar 2004

Because this plugin is used and seems to be being maintained I have given it a non-default CVS modification policy. If you have a problem with this, switch it back.

-- CrawfordCurrie - 03 Apr 2004

I've tried the TreePlugin and it works great. I'm not sure if I understand how it should work with no options. If I include %TREEVIEW% is that supposed to create a tree based on that particular topic? When I try this I get a list based on the web and not the topic. I think this is wrong unless I don't understand the instructions properly. I've tried with v0.310 and v0.311 and get the same results both times.

-- ChrisPurves - 08 Apr 2004

The TreePluginv311.zip distribution on TreePlugin always renders $topic and $spacetopic in doubled square brackets, regardless of what the format string is. This breaks things like this:

[[$web.topic][$spacetopic]]

(used in several of the examples) by inserting lots of extra brackets, confusing the WikiML to HTML converter. I've attached a patch which removes the brackets when a formatting string is present.

-- DiabJerius - 12 Apr 2004

I'm trying Outline mode with summaries and I'm curious what goes into the summary e.g. how many letters/word/lines or what determines what's taken out of the page to become the summary.

-- WayneDahl - 17 Jun 2004

Btw, it seems to be working with the CairoRelease also.

-- OlivierBerger - 24 Feb 2005

I mentioned in TreePlugin that this does not scale well with large number of documents. With a Web of 10,000+ documents, the plugin dies after about 9 minutes after consuming over 1000MB of memory.

-- BrianPark - 10 Jul 2005

Yes, I mentioned this in a comment entered back in February, 2004 (see #StevesComment for the exact entry). This is an extremely expensive plugin.

-- SteveRJones - 13 Jul 2005

Just wanted to add my thanks to all those who have helped with TreePlugin. Our site uses a combination of PublishAddOn, TreePlugin and some templates to automatically generate a sidebar with navigation menu. The internal site (a proper TWiki, editable by staff) is published to our public site regularly. We have some automated scripts to find-and-replace selected WikiWords within the published html. Some of our products have WikiWords in their title - we want them to show up as WikiWords in (say) the treeview and page titles. We also replace standard TreePlugin graphics with our own in the sidebar. Thanks again, all.

-- RossC - 05 Oct 2005

This plugin is broken for Dakar release. I had a look at the code and their was some issues with plugin initialisation cause plugin loading mechanism has changed in Dakar. Once I eventually managed to load the plugin the tag handler appear to be broken cause of that TWiki::Meta::findOne function. So I had a quick look in meta.pm and decided to replace the calls to findOne by find. Now pages with %TREEVIEW% tag don't break twiki but they don't seems to display the expected tree either. So maybe TWiki::Meta::find is not the correct function to use in replacement to TWiki::Meta::findOne or the parameter has changed.

Any help or advice about that? Is there other keywords I can use to display topic trees in Dakar?

-- StephaneLenclud - 07 Feb 2006

I created a patch (which I attached to this page) that allows the plugin to work on TWiki 4.0.0. It addresses the issues with TWiki::Meta::findOne, and it also gets rid of all the global parameters (that made it not work with mod_perl). It works in my installation. There is only one possible issue. The old code used a global parameter to keep track of topics processed to try to prevent infinite loops. This doesn't work with mod_perl so I just stripped it out. It doesn't cause a problem with my install. If someone else knows what situation requires the inifinite loop check then perhaps we can find a way to deal with it.

-- GeoffreyLowney - 08 Feb 2006

Thanks Geoffrey for working on this. Consider updating the zip file on the Plugin topic. This Plugin had no update for over two years.

If possible, please keep this Plugin compatible with Cairo and Dakar codebase. HandlingCairoDakarPluginDifferences has more.

-- PeterThoeny - 08 Feb 2006

I've just applied Geoffrey's patch and it seems to work just fine I'm a quite a newbie to wikis but I'm very pleased with twiki. I'm trying to get my company to use twiki rather than some other wiki.

Anyhow you guys are doing a great job, thank you again for that patch!

-- StephaneLenclud - 09 Feb 2006

I just realize that I'm getting a lot of Apache error logs due to that plugin. I did not get a chance to look at it yet. It's probalby an easy fix. Beside that that plugin works just fine with Dakar. Here is what I get in the error logs:
[Sat Feb 18 15:56:20 2006] [error] [client 192.168.178.10] [Sat Feb 18 15:56:20 2006] view: Use of uninitialized value in pattern match (m//) at /srv/www/htdocs/twiki/lib/TWiki/Plugins/TreePlugin.pm line 110
Here is what I have at line 110 in Treeplugin.pm:
if ($formatter->data("format") =~ m/\$(summary|text)/) {

-- StephaneLenclud - 19 Feb 2006

Here is a fix for that, just replace line 110 with the following:
if ($formatter->data("format") && $formatter->data("format") =~ m/\$(summary|text)/) {
We ought to produce a new zip file for Dakar really. I would do it myself but I'm still a newbie with linux and don't even have access to twiki source control.

-- StephaneLenclud - 19 Feb 2006

When doing something like %TREEVIEW{topic="MyTopic"}% it displays the following line followed by the tree for the topic:
Tree for specific topic MyTopic MyTopic.
Maybe we should get ride of that line as it's dead easy to add it in your topic if you want it and it's quite annoying to have if you don't want it

-- StephaneLenclud - 24 Feb 2006

I responded to InitPluginErrorinTreePlugin saying that I had just installed TreePlugin on my new twiki site; but I did the dirty and just restored findOne and _key. I.e. I had to modify the main TWiki::Meta code to get it to work. I look forward to installing the proper fix as soon as I have time.

My TWiki site nees the infinite loop check - in fact, I may have been the guilty party who added the global. (Sorry, I don't normally use globals.)

Why I need the infinite loop check: I try to fix up the parent link to make the TreePlugin TREEVIEW make sense. Unfortunately, sometimes when I do this I get an infinite loop.

-- AndyGlew - 23 Mar 2006

I agree with Stephane Lenclud. The %TREEVIEW{topic="MyTopic"}% code gives out Tree for specific topic "Topic Name" (The name is mentioned twice in my case.) Does anyone have a workaround to this so that the sentence is eliminated? Thanks

-- PriyaSeth - 12 Jun 2006

me too - would like a workaroung to the extra "specific topic TopicName" as without these extra lines, it would be very easy to use the unordered list with a TREEBROWSE command to get a nice collapsible menu

-- HelenHulme - 07 Jul 2006

In the interest of best coordinating efforts on getting this plugin ready for Dakar I have baselined the plugin with patches here and synced it with SVN. I will try to keep SVN in sync with patches suggested from this point on.

I do not use this plugin myself; if anyone cares for this plugin feel free to take over the maintenance role.

I have moved some content from 2002-2005 from this topic to TreePluginDevArchive.

-- SteffenPoulsen - 12 Jul 2006

Did you include the patches offered on this page?

• Some patches were contradicting, so I have just done a subjective best-effort on what I thought were the reasonable ones. End result functionality needs to be reviewed by the real world users of the plugin now and I expect it can then be determined if some of the patches should go in or out again. This should be somewhat easier to accomplish with just one development track to consider. -- SteffenPoulsen - 14 Jul 2006

-- ArthurClemens - 12 Jul 2006

I moved the hidden attachments to the archive topic.

• Thanks! -- SteffenPoulsen - 14 Jul 2006

-- PeterThoeny - 14 Jul 2006