create new tag
, view all tags

TreePluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on TreePlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below
• See TreePluginDevArchive for older discussions.

Development discussion for TreePlugin

Plugin Design


The basic design of TREEVIEW:

  • Parses through the tag attributes
  • Makes a SEARCH tag string and asks the core TWiki to return a string of all the topics
  • Creates a tree by iterating through the topic list and hooking up parents and children of TWikiNode objects
  • Makes an appropriate NodeFormatter object and tells the asked for topic node of the tree to apply the formatter to itself recursively
  • Parses and renders the outputted string using TWiki handles


  • NodeFormatter is an abstract class. There is a handful of specific classes which correspond to the formatting attribute options. In theory additional ways to format the output could be added simply by making another NodeFormatter classes (subclassed from existing ones if need be).
  • The way the tree is walked is still coupled too much between the TWikiNode and NodeFormatter classes (the for loop is in the TWikiNode class). Making a seperate Visitor class which walks through the collection would be more useful. It could easily be integrated back into the TWiki core to provide a generic way for SEARCH to format its output.

To Do

  • Add more thorough documentation
  • Enable format with ullist and ollist.
  • Enable and document CREATECHILD macro.
  • Test TESTVIEW spanning across trees.
  • Add support for more SEARCH format variables (shouldn't these be centralized?).
  • Use standard bookview template (ie support for %-type tags).
  • Decouple TWikiNode and Formatter(s) by adding visitor pattern class.
  • Handle web root node formatting better (ie, better than just calling it a space char.)
  • True recursion checking (not just: have we expanded TREEVIEW for this topic on this page).
  • Add unit tests for library components.
  • Add searching for specific forms (fix current bug).
  • Check for compatibility with modperl

StephaneLenclud, I just saw your 19 Feb 2006 comment on doing a new release. If you're still interested in maturing this plugin, you should start out by reading ReadmeFirst and the links from it (in particular PluginsInSubversion) and then consider if you want to take this on.

(Again, I will be happy to keep things aligned in subversion, should you prefer to do your development locally).

-- SteffenPoulsen - 14 Jul 2006

I would like to get rid of the line "Tree for specific topic".

-- ArthurClemens - 23 Jul 2006

Looks like the same has been suggested a few times before, let's take it out. New version uploaded.

-- SteffenPoulsen - 23 Jul 2006

I don't have a clue how to deal with an omitroot variable. Perhaps in TWikiNode.toHTMLFormat, but that doesn't feel right code-wise.

-- ArthurClemens - 24 Jul 2006

Asked in Support web Support.TreePluginWithCairoRelease

The info for TreePlugin indicates this plugin was originally created in 2002; the download was updated in 2006. The Package Form states "TestedOnTWiki 4.0.0"

I hate to admit that the company where I am currently working has not yet upgraded to 4.*. Specifically they are still running 03 Sep 2004 $Rev: 1742 $

Before I bother to request that the part-time TWiki support people please install TreePlugin... can anyone vouch for how well I can expect it to work in this older release of TWiki? Will I have any problems?

-- VickiBrown - 27 Jul 2006

You are not the only one who did not / could not upgrade to TWiki 4. Exactly for this reason I prefer to see our Plugins maintained so that they run on Cairo and TWiki 4. You can try if the latest version runs on your Cairo installation. If it does, please update the "TestedOnTWiki" form field. If not, you can download an older .zip version (click on "manage".)

-- PeterThoeny - 27 Jul 2006

Can somebody update the main plugin page. I'm happy to see that a new version has been released, but there's little info on what was changed from version 3.11. The version table still lists .20 as the last release and though I would still say this is beta, it's not an alpha plugin. The new release doesn't even look to have a version number.

-- ChrisScott - 31 Jul 2006

Not much was done, just a re-wrap for Dakar and an attempt at making this topic less noisy. This plugin still needs a maintainer.

I will upload a new version with information on deltas and touch the rev number.

-- SteffenPoulsen - 01 Aug 2006

New revision uploaded. Thanks for the pointer, Chris.

-- SteffenPoulsen - 01 Aug 2006

I'm just coming back to that plugin since I'd like to install it at work. Sorry I missed all your comments was just enjoying the summer wink I'm glad it's been updated. Is TreeBrowserPlugin any good? Is it better than this one? Answering my own questions: TreePlugin and TreeBrowserPlugin are complementary. TreePlugin gives you a list of children topics which could be potentially made collapsable using TreeBrowserPlugin.

-- StephaneLenclud - 18 Aug 2006

VickiBrown asked if I actually tried using TreeBrowserPlugin in combination with TreePlugin. The answer was 'no'. So I tried eventually and could not get it to work smile The problem I believe comes from the fact that TreeBrowserPlugin works only with list using TWiki syntax whereas TreePlugin output some HTML list. I had to patch TreePlugin to make it render lists using TWiki syntax. I'll publish that patch and try to update the code in subversion as soon as I get a chance. To get started with TWiki SVN read: SubversionReadme.

-- StephaneLenclud - 29 Aug 2006

Here is the patch for combination with TreeBrowserPlugin. I'm trying to submit my changes to Subversion but I can't pass the authentication. It asks me for a root password then a login and password. Anyone can help me on that?

-- StephaneLenclud - 30 Aug 2006

Here is a quick demo of how those two plugins could be used together to implement a discussion forum. Forum Demo

-- StephaneLenclud - 30 Aug 2006

TreePlugin occasionally emits a blank line between sections of a bulklet list. TWiki doesn't mind this (and I personally approve). But when it occurs, the remainder of the list will be ignored by TreeBrowserPlugin. See my bnote at TreeBrowserPluginDev.

I'm not sure which plugin should be considered "at fault" here; however, I think I'd lean toward "fixing" TreeBrowserPlugin to keep working even if a blank line is discovered. RenderListPlugin simply emits the blank line and keeps rendering. TreeBrowserPlugin should do the same.

-- VickiBrown - 14 Sep 2006

Thanks Vicki for trying out that patch. I still need to commit those changes to subversion and do a proper release.

TreePlugin output a blank line before a topic if its parent belongs to another web. Moreover those topics with parent belonging to another web should be showing at the bottom of the tree.

I can see two situation where you end up with topics having foreign parent:

  • Topics with foreign parent were installed on the server as part of a plug-in installation for instance.
  • A topic has been moved from one web to another retaining is parent that still belongs to its original web.

IMHO those situations should be unusual and easily fixable by changing the parent. The TreePlugin behaviour makes it easy to spot topics with foreign parent.

-- StephaneLenclud - 15 Sep 2006

This is a reason to remove the PoorLittleOrphans. I consider parents across webs a bug.

-- PeterThoeny - 15 Sep 2006

About TreePlugin performance: No matter what parameters you give to TreePlugin (web or topic) it just do a ".*" search in the relevant web and reads every single topics meta to determine topics parents. Doing a search for topic with a certain parent in the first place might give use better performance especially if we only want one level of children.

Also having in mind to use that plugin as a left bar menu I wonder how could we cache the results and update the tree only if something has changed in the web. In fact since the left bar is always displayed the TREEVIEW needs to be expanded for every single page and that's a lot of processing for nothing. Is there a TWiki API I could use to determined if something has changed in a web?

Am I asking for trouble here? Should I be happy with a static menu? wink

-- StephaneLenclud - 18 Sep 2006

I guess if you only want one level of children you better off doing a %SEARCH% in a %SEARCH% like that:

%SEARCH{ "Web*" scope="topic" regex="on" format="   * $topic$percntSEARCH{ \"META\:TOPICPARENT.*$topic\" format=\"      * $dollartopic\" nosearch=\"on\" nototal=\"on\" regex=\"on\" header=\"$n\"}$nop%" nosearch="on" nototal="on" }%

Maybe we could just have TreePlugin doing that for you so that users don't have to understand %SEARCH% inside out. In fact that search above doesn't look very KISS does it? stick out tongue

-- StephaneLenclud - 18 Sep 2006

If you want to cache the result you can update it on topic save: Use the afterSaveHandler callback. Please note that at this time there is no callback to notify plugins when a topic has been renamed (see PluginHandlerForContentMove); that is you'd need to periodically refresh the tree of a web.

-- PeterThoeny - 19 Sep 2006

Thanks Peter that's exactly the kind of thing I was looking for. WIBNIF we had something like webChangeHandler with the name of the web as parameter. Thus plugins like TreePlugin would be notified whenever they need updating. A web change event could be sent whenever a topic in that web is created/saved/moved/renamed/deleted.

-- StephaneLenclud - 19 Sep 2006

As requested by VickiBrown I'm trying to make that plugin compatible with both Cairo and Dakar. We are having problem with TWiki::Meta. I have a feeling it's due to the fact that we are using that findOne / get function. Can I still use findOne in Dakar? If not how can I call findOne if I'm running on Cairo and get if I'm running on Dakar? I don't have a Cairo install for testing right now.

-- StephaneLenclud - 19 Sep 2006

Now I remember having myself problems with findOne as I was probably the first to try that plugin in Dakar. Look at Revision 80 for instance. It looks to me like a code compatible with both Cairo and Dakar would look like that:

my $ref=0;
if ($TWiki::Plugins::VERSION < 1.1)
   $ref = $meta->findOne( "TOPICPARENT" );
   $ref  = $meta->get( "TOPICPARENT" );

I'm also having concerns with TWiki::Func::getCgiQuery and the cgi object is that compatible with Cairo?

-- StephaneLenclud - 19 Sep 2006

Ok, here is a version of TreePlugin.pm that should provide use compatibility with both Cairo and Dakar. Vicki can you try it out on Cairo for me? Just use the latest version of TreePlugin and replace TreePlugin.pm with this one.

-- StephaneLenclud - 19 Sep 2006

Hi Stephane,
I use your plugin for the two purposes:

  1. dynamic web map (in combination with TreeBrowserPlugin)
  2. to display all topics belonging to some subgroup of the chosen group

In order to achieve the second goal I have modified the plugin and added a new formatter which lists the children as a delimited list. I then use this list in a %SEARCH{}% to list all topics that refer to any child of the chosen group


  • group 1
    • group 11
    • group 12

when I visit the group 1 topic, I can see both topics from group 11 and 12
In case you are interested, I can post my changes here (bud I dont know Perl, so the changes may be poor from Perl programmer's view)

-- JanFilipsky - 20 Sep 2006

Thanks for your interrest in those plugins, they are yours as much as mine now wink Please do post a patch and give us a link to a demo site if possible. I'm not sure I fully understand the second scenario, a demo site would help.

-- StephaneLenclud - 20 Sep 2006

I am sorry, but I don't know how to make a patch file, so I will have to post here the whole zip.
As for the second scenario: Our TWiki installation is only the intranet one, so I can't make the demo site.
The idea of my modification is as follows:

  1. call the %TREEVIEW{formatting="delimited:|" formatbranch="\[$topic\]" topic="TreePluginDev"}%
  2. this will list all the children, grandchildren, ... in this way: [DeviceGroupSymbian]|[DeviceGroupS60]|[DeviceGroupS60v1]|
  3. Place a SEARCH around it %SEARCH{"%TREEVIEW{...}-DoNotMatchMe" regex="on" nosearch="on" nototal="on"}
  4. This search will list ALL the topics that have a link to any subgroup of current group topic

Hope this explanation helps a bit

-- JanFilipsky - 21 Sep 2006

There is probably a lot of effort duplication here, but DynamicReparenting might be of interest to this discussion.

-- PankajPant - 26 Sep 2006

Am I missing something with the $modTime formatting variable? If for instance I put TREEVIEW{format="$topic - $modTime
"} in a topic it lists all the topics in the web as I would expect, but the $modTime equals the timestamp of the current topic, not the timestamp of the individual topics listed. Is there another way to go about this?

-- WalterFrancis - 29 Sep 2006

Funny that, thanks for reporting that bug, I'll look into it.

-- StephaneLenclud - 30 Sep 2006

v0.6patch.txt: Patch for v0.6 See TreePlugin for release notes.

-- StephaneLenclud - 30 Sep 2006

The next release will be about performance. In oder to improve the performance of that plugin we will attempt to:

  1. Make smarter use of the search. Like limiting the scope of the search for instance.
  2. Cache the results.

-- StephaneLenclud - 01 Oct 2006

This could be common knowledge, but I thought this was cool!, this is how I implemented the TreePlugin and TreeBrowserPlugin on my WebHome page

<a href="javascript: tree.openAll();">open all</a> | <a href="javascript: tree.closeAll();">close all</a>
%TREEBROWSER{"thread" title="[[%HOMETOPIC%][%INCLUDINGWEB% Web Home]]" shared="tree"}%
%TREEVIEW{web="%WEB%" topic="WebHome" formatting="outline" format="* $topic" levelprefix="   "}% 

To get:
-- ScottWBlack - 16 Dec 2006

Wetpaint uses AJAX to fold open deeper menu levels.

-- ArthurClemens - 17 Dec 2006

I am trying to get the format variables to work. Basically I want to list a all the generations of children of a topic and I want to display the last author and the latest modification date. I have gotten the author to list and the Modifcation time (which is really not helpful without a date) but only in a bulleted, non-nested list. I cannot get it to work with outline numbers or in a nested unordered list. Is there anyway to get additional formatting? I would settle for the bulleted list if I could at least get the date, but I prefer to at least have some way of identifying parent child relationship of all the generations.

-- XochipalaValdez - 08 Feb 2007

XochipalaValdez: I got to look into that too. I'm afraid you may find that quite a few features are broken in certain formatting. Talking from experience smile

TODO: make use of TWikiCache once it's ready.

-- StephaneLenclud - 28 Feb 2007

Already now (without code change) you should be able to use the VarCachePlugin to cache trees.

-- PeterThoeny - 01 Mar 2007

The " Limitations and Known Issues" on http://twiki.org/cgi-bin/view/Plugins/TreePlugin says that the "web" parameter does not work correctly and gives a workaround.

Another workaround is to wrap $topic in double brackets. The double brackets also help if a topic is not a "proper" WikiWord, e.g. if it includes an _ character.

-- VickiBrown - 02 Mar 2007

I'm wondering why there is a $modTime but no $modDate variable. I find the time of last change to be virtually useless without knowing the date :-{

-- VickiBrown - 05 Mar 2007

My problem with VarCachePlugin is that it's not user dependent. So I understand that when caching a tree it will cache it as seen by the user generating the cache and therefore potentially including links to topics with restricted access. Not sure how TWikiCache does that anyway. Mmmh caching is no easy thing smile

-- StephaneLenclud - 10 Mar 2007

I have fixed the web parameter bug. And added parameter startlevel to be able to skip the root: use startlevel="1" to omit the root node from view (release 0.7).

-- ArthurClemens - 14 Mar 2007

Thanks for that enhancement Arthur. I updated that plug-in and used the startlevel parameter today, it's most useful smile

-- StephaneLenclud - 22 Mar 2007

ArthurClemens I think your last version introduced an empty bullet (entry) at the root of the tree if no topic parameter is given. That is if one wants to get the the tree of the entire web. I might be wrong though and it might just be some of my changes. Can you confirm that? I'm doing some modification like adding parameters to pass on to the search and doing some code cleaning.

-- StephaneLenclud - 03 Apr 2007

Maybe we should just default to startlevel="1" if not topic.

-- StephaneLenclud - 03 Apr 2007

Arthur I implemented a workaround for the problem mentioned above. Just published V0.8. See the release notes. For the next release:

  • I think we have extra new lines either before or after the tree
  • Better pseudo var substation support
  • Alignment with VarSEARCH

-- StephaneLenclud - 04 Apr 2007

Just published v0.9. Next release:

  • Fix 'all' web tree
  • Do more testing, add demo topic
  • Add other parameters similar to VarSEARCH
  • Extra new line issue

-- StephaneLenclud - 06 Apr 2007

Just published v1.0. Tested most formatting. Next release:

  • Rewrite the try building loop, fix orphan blank line issue
  • Extra new line issue Use nodiv.
  • Add other parameters similar to VarSEARCH ( i.e. includetopic )
  • Publish demos

-- StephaneLenclud - 06 Apr 2007

Just published v1.1. Tested most formatting. Next release:

  • Add other parameters similar to VarSEARCH ( i.e. includetopic )
  • Publish demos

I'm done with that plug-in for now. v1.1 should be good. It even feels like it's three tenth of a second faster wink lol

-- StephaneLenclud - 06 Apr 2007

Just published v1.2. Tested most formatting. Next release:

  • Add other parameters similar to VarSEARCH
  • Publish demos

Maybe I'm done now smile

-- StephaneLenclud - 07 Apr 2007

LutzLeonhardt (probably accidentially) overwrote this plugin zip with a version of GenPDFAddOn - re-synced plugin zip from SVN.

-- SteffenPoulsen - 19 Apr 2007

Can anyone help with TreeViewBookViewConfusion ??

-- SvenDowideit - 28 Apr 2007


  • Fix or deprecate bookview as it's currently broken
  • Fix $onum.

-- StephaneLenclud - 30 Apr 2007

Stephane -

Have you considered folding the "delimited" functionality into TreePlugin?

It would be immensely useful to be able to wrap a search around the results of TREEVIEW!

-- VickiBrown - 31 May 2007

No I haven't really. I just had a read through JanFilipsky proposal again and that sounds interesting. However I won't get a chance to implement that any time soon. Maybe in October. Thanks for the reminder Vicki.

-- StephaneLenclud - 01 Jun 2007

I'm running into an issue with TreePlugin running on a virgin install of TWiki 4.1.2. Performing an RDIFF (history) of a topic that includes %TREEVIEW% I recive the following error:

Undefined subroutine &TWiki::Plugins::TreePlugin::installWeb called at /proj/.web_twiki/web_twiki/twiki-4/html/lib/TWiki/Plugins/TreePlugin/ImgNodeFo
rmatter.pm line 220.

Disabling TreePlugin results in the RDIFF to complete.

-- SteveRJones - 04 Jun 2007

The offending line is lib/TWiki/Plugins/TreePlugin/ImgNodeFo rmatter.pm line 220:

$dir =~ s/\$installWeb/TWiki::Plugins::TreePlugin::installWeb()/geo;

this should be:

$dir =~ s/\$installWeb/$TWiki::Plugins::TreePlugin::installWeb/geo;

-- SteveRJones - 04 Jun 2007

re: delimited functionality

> Maybe in October. Thanks for the reminder Vicki.

Ouch. Long time. If only I had more cycles.

Keep in mind that JanFilipsky did more than create a proposal. He posted an update to TreePlugin ....

There's a new module: DelimitedListFormatter.pm. So it's should be less of an implementation and more of a merge...

p.s. I've tried the updated TreePlugin., The delimited functionality is sooooooo useful. (wistful sigh)

-- VickiBrown - 13 Jun 2007

Thanks you Steve and Vicki for your feedbacks.


  • Fix or deprecate bookview as it's currently broken
  • Fix $onum.
  • Fix ImgNodeFormateer.pm to $dir =~ s/\$installWeb/$TWiki::Plugins::TreePlugin::installWeb/geo;
  • Incorporate JanFilipsky delimiter functionality
  • Implement unit test

-- StephaneLenclud - 16 Jun 2007

It seems that TreePlugin can not handle falsly set recursiv topic-parents. E.g. if %META:TOPICPARENT{name="SomeTopic"}% is set in WebHome and SomeTopic contains %META:TOPICPARENT{name="WebHome"}% this recursion leads to an endless loop.

This first happend with TreePlugin Version 0.6. I updatet to Version 1.2 and the problem remains. Just by opening e.g. a Topic containing %TREEVIEW{topic="WebHome" stoplevel="5" formatting="imageoutline:thread"}% the server dies.

Btw. with the new Version 1.2 the formatting option formatting="imageoutline:thread" does not seem to work?

Can anyone reproduce the problem?

-- CedricWeber - 27 Jun 2007

Hi Cedric. Thanks for your feedback. WebHome being typically the root of your web I'm not so surprise about this behaviour. The use case you describe has probably never been tested before. This must be fixed though especially if it can bring down the server. Don't know about imageoutline:thread I have to look at that.

-- StephaneLenclud - 28 Jun 2007

I also found imageoutline:thread not to be working in the lastest version (nothing renders).

-- LynnwoodBrown - 28 Jun 2007

Hi Stephane, thanks for your fast reaction. It took me quite some time to find that problem. TreePlugin had been disabled for weeks and users started complaining. wink The Plugin is is quite important in our case.

-- CedricWeber - 28 Jun 2007

Ok I understand your concerns. I'll try to come up at least with a quick fix for that endless loop so that you can patch your server. I hope I get a chance to do that this weekend. In the best case scenario you should get a new plug-in version on Monday.

-- StephaneLenclud - 29 Jun 2007

Sorry I haven't managed to look into that yet. Maybe it's because I'm not looking forward to crash my server smile

-- StephaneLenclud - 10 Jul 2007

Version 1.3 was published. It's a maintenance release. It fixes bad bugs and existing functionalities. Check the release notes on TreePlugin. Big thanks to the community for allowing me to enhance that plug-in through your comments and feedbacks.

Here is what's left of the TODO list:

  • Remove booktree.tmpl from MANIFEST
  • Incorporate JanFilipsky delimiter functionality
  • Add other parameters similar to those in VarSEARCH ?
  • Implement unit test

-- StephaneLenclud - 10 Jul 2007

CedricWeber: install V1.3, re-enable TreePlugin and tell me if it fixes your broken topics.

-- StephaneLenclud - 10 Jul 2007

Hi StephaneLenclud, thanx for the Update, but the endless loop remains.

This is what I am doing: Edit WebHome Topic:

%<nop>META:TOPICINFO{author="CedricWeber" date="1174682216" format="1.1" reprev="1.131" version="1.131"}%

Loading WebHome leads to the endless loop and constanly growing view process.

imageoutline:thread is back, thank you.

One more thing, Topics that are no WikiWords are not Linked in the Tree (useing imageoutline:thread and others?). So e.g. if a Topic New_topic exists TreePlugin does not link to it.

-- CedricWeber - 19 Jul 2007

Mmmh funny that. For me it definitely fixed endless loop for closed parent/children relations which I thought was the main problem here. This was done by introducing some code to prevent nodes rendering more than once. I can't see what's so special with WebHome, I just double checked in the code and there is no hard coded knowledge of WebHome.

Can you clarify how you get the endless loop?

  • What kind of TREEVIEW are you using in your faulty WebHome topic?
  • What's the parent of your WebHome ?
  • What's the parent of your WebHome parent?
  • Are you sure this is still caused by TreePlugin? Does the view script complete if TreePlugin is disabled?

On my side I'll try to reproduce that problem as soon as I have enough time before me to investigate and fix it.

-- StephaneLenclud - 20 Jul 2007

This is the TREEVIEW I use e.g in a Topic called= WebTree= or any other Topic.

%TREEVIEW{topic="WebHome" stoplevel="5" formatting="imageoutline:thread"}%

The Parent of WebHome is SomeTopicBelowWebHome. The Parent of SomeTopicBelowWebHome is WebHome.

Yes, if I disable TreePlugin the page Loads without any errors (and without rendering %TREEVIEW{topic="WebHome" stoplevel="5" formatting="imageoutline:thread"}%)

It is not dependent on WebHome. I can reproduce this as well with these other topics, TestTopic, TestTopic2, TestTopic3:

Topic 1: TestTopic

%<nop>META:TOPICINFO{author="CedricWeber" date="1185276883" format="1.1" reprev="1.1" version="1.1"}%
---+ !TreePlugin Test

Topic 2: TestTopic2

%<nop>META:TOPICINFO{author="CedricWeber" date="1185276833" format="1.1" reprev="1.1" version="1.1"}%
---+ !TreePlugin Test Child

Topic 3: TestTopic3

%<nop>META:TOPICINFO{author="CedricWeber" date="1185279886" format="1.1" version="1.2"}%
---+Test !TreePlugin
%TREEVIEW{topic="TestTopic" stoplevel="5" formatting="imageoutline:thread"}%

If I try to open TestTopic3 my system tilts. Please let me know if you can reproduce this case. Thank you for your help.

-- CedricWeber - 24 Jul 2007

Hi all, Thanks for all your efforts with the TreePlugin, it is amazing! I was wondering if anyone could take a look at the problem I am having. http://twiki.org/cgi-bin/view/Support/VariableExecution Your help is greatly appreciated smile

-- BrianMahoney - 07 Aug 2007

TODO: Add a prefix parameter to allow building up titles by doing something like:

prefix="---+" levelprefix="+"

Use outline as default formating if format is specified?

-- StephaneLenclud - 08 Aug 2007

Can anybody confirm the endless Loop I mentioned above?

-- CedricWeber - 09 Aug 2007

Sorry Cedric I had no time to investigate this issue any further and can't commit to any deadline.

-- StephaneLenclud - 10 Aug 2007

It appears that WikiWords that contain dashes are processed correctly by TWiki but are displayed incorrectly by the plugin. For example


Can be used to create a valid topic but will render by the TreePlugin as:

WikiWord? -MoreWords

-- BrianJones - 13 Oct 2007

An other testszenario for the endless loop / cycle

I use Plugin v0.6. on a TWiki v4.1.2. The scenario mentioned above is fixed, thanks. When I embed the TreePlugin within topics that loop, the webserver still goes down!

This is my setup:

Create the following two topics (remove the <nop>):

Topic LoopTest

%<nop>META:TOPICINFO{author="TestUser" date="1193041990" format="1.1" reprev="1.1" version="1.1"}%

---++ Test !TreePlugin Loop

Topic LoopTest2

%<nop>META:TOPICINFO{author="TestUser" date="1193042174" format="1.1" reprev="1.1" version="1.1"}%

---++ Test !TreePlugin Loop
%TREEVIEW{topic="LoopTest2" stoplevel="3" formatting="imageoutline:thread"}%

Try to browse to LoopTest2.

-- CedricWeber - 22 Oct 2007

Yes, I can confirm the Loop in version 1.3 of the plugin.


%TREEVIEW{web="Projects" topic="SomeTopic" formatting="imageoutline:thread"}%

in a subtopic called AllSomeTopicPages tilted my system by going OOM.

-- MatthiasWientapper - 10 Jan 2008

I have found a bug when specifying a root topic


%TREEVIEW{web="%WEB%"  topic="WebHome" formatting="outline" format="* [[$web.$spacetopic]]"  levelprefix="   "}% 

Result - note that the WebHome (root topic) is prefixed with an asterisk, not a bullet. The output formatting is off)

  • screenshot:

  • screenshot without TREEBROWSER:

-- VickiBrown - 22 Jan 2008

It's because the root is level zero therefore the levelprefix is not prepended at the root level. Adding 3 spaces at the beginning of your format string should fix you up.

-- StephaneLenclud - 23 Jan 2008

Does anyone know if the delimiter functionality by JanFlipisky has been merged into the latest release? I would really like to use this plugin to do restrict a SEARCH to a specific topic tree. I can see I am not the only one to want to do this, see SearchWithinTopicTree.

-- DeanSpicer - 16 Mar 2008

Thanks for your request. I don't think it's been implement in SVN. I'll consider doing it next month. In the mean time feel free to do it yourself or just patch your local installation.

-- StephaneLenclud - 23 Mar 2008

Just had a quick read through Jan's proposal again. I'm under the impression it might already be possible to do something like that using existing parameters. I'll have a closer look next month, I'm on vacation until next week.

-- StephaneLenclud - 23 Mar 2008

Did some quick testing concerning the endless loop issue and it appears to be specific to formatting="imageoutline:thread".

-- StephaneLenclud - 28 Mar 2008

I submitted a fix for the endless loop issue concerning imageoutline:thread. I also noticed that the rendering of imageoutline:folder and imageoutline:single is kind of broken. I won't bother fixing it though as single does not make much sense (also admitted by the original plug-in author) and a static folder view is also kind of useless especially since one can get a nice dynamic folder view using TreeBrowserPlugin.

Still need to publish that fix.

-- StephaneLenclud - 28 Mar 2008

So 18 months after JanFilipsky first proposal for a delimited formatting I eventually got around looking at it seriously wink

First of all you must know that I don't like formatting and I would vote against adding any extra formatting unless you have a very good reason for doing so. In fact most formatting results can be achieved by using the default formatting and passing the appropriate format and/or formatbranch.

I'm under the impression that Jan's results could be obtained by doing:

%TREEVIEW{topic="TreeRoot" format="$topic" nodiv="1" formatbranch="$parent|$children"}%

In which case there is no need for a delimited formatting. Thank you all for contributing to the development of TWiki:Plugins .

-- StephaneLenclud - 28 Mar 2008

The main idea behind JanFlipsky's delimiting functionality (as I understand it) was that the output could be used to pass a list of topic names to SEARCH (or other plugins that accept a list of topics). This is useful if you only want to search a tree subset of a web. For example, if I had a topic tree like the following:

- MainTopic
   - ParentTopic1
      - ChildTopic1
      - ChildTopic2
   - ParentTopic2
      - ChildTopic3
I could write
%TREEVIEW{topic="MainTopic" formatting="delimited:, " formatbranch="$topic"}%
and get:
MainTopic, ParentTopic1, ChildTopic2, ParentTopic2, ChildTopic3
Your suggested syntax above does not give a similar output.

-- DeanSpicer - 29 Mar 2008

Thanks Dean I see now that the solution I suggested above is not working. I had tried it only with a very very small tree.

Talking about your example, I don't quite get what is the $topic doing in formatbranch as I understand formatbranch only supports $parent and $children. It must be something introduced by the delimited formatting.

-- StephaneLenclud - 29 Mar 2008

Ok I just published a new version fixing the endless loop and adding a separator parameter.

No delimited formatting I'm afraid but you should be able to get similar result by doing:

%TREE{web="Sandbox" topic="GrandParent" format="$topic" nodiv="1" separator=","}%

-- StephaneLenclud - 29 Mar 2008

Note: in the current implementation separator won't behave nicely for Web tree or in combination with startlevel.

-- StephaneLenclud - 29 Mar 2008

TODO: provide a proper example page

-- StephaneLenclud - 29 Mar 2008

Nice! Your latest version can output a comment delimited like I outlined above, thanks Stephane. If only I can get it passed to SEARCH properly I'd be ecstatic. Any idea why the following:

%SEARCH{search="junk" web="Foo" topic="$percntTREEVIEW{web="Foo" topic="GrandParent" format="$topic" nodiv="1" separator=", "}$percnt"}%
doesn't work?

-- DeanSpicer - 30 Mar 2008

Nevermind. I got it working. The following:

%SEARCH{search="junk" web="Foo" topic="%TREEVIEW{web="Foo" topic="GrandParent" format="$topic" nodiv="1" separator=", "}%"}%
did the trick smile I got carried away with the escaped %'s I guess.

Thanks for all the help Stephane. Getting this working made my day!

-- DeanSpicer - 30 Mar 2008

Good to hear that smile Thanks for the feedback. $percnt will only work in the format and header parameters.

-- StephaneLenclud - 30 Mar 2008

This is an excellent plugin! Thank you!

-- MarcusLeonard - 04 Apr 2008

We really need a caching mechanism. The plugin runs through all topics in a web, every time a tree is displayed. I am using this plugin a lot, but the pages get unacceptably slow now as the number of topics has grown past 1000.

-- ArthurClemens - 05 Apr 2008

Unless you have the tree in a skin or included page (such as sidebar) you can cache it using VarCachePlugin.

-- PeterThoeny - 06 Apr 2008

That is the problem: the tree is defined in topic templates.

-- ArthurClemens - 06 Apr 2008

Or we could just speed things up. As a quick experiment, on a web with 1600 topics, on a slow machine, a shell script can output a full tree view in 0.8s. I think a C program could do it in ~ 0.1s. Also the intermediate data can be easily cached (like the TagMePlugin does), as we know when it is obsolete by comparing its dates to the ones of the web directory and .cache. I guess it should then be possible to recode this plugin in a much faster version, but possibly much less customizable. Note that creating a separate metadata cache on topic save could help immensely with these kind of functions, that could be an interesting idea. I attach my shell script koala-webtree to this topic if others with more time than me want to make a proper plugin out of it before I manage to do it.

To use it:

  • put it in your bin/ dir
  • call it via %INCLUDE{%SCRIPTURL%/koala-webtree/%WEB%/%TOPIC%}%
-- ColasNahaboo - 07 Apr 2008

The challenge is to keep the flexibility while improving the performance. Arthur can you post here the %TREE% for which you need improved performance?

As a generic thought on TWiki and/or %SEARCH% performance do we know were exactly is the bottleneck? Is it file access? Is it data processing? I'm under the impression that with today's hardware we could easily keep the whole topics and templates data in RAM and thus gain lightning fast access to it. Do we do something like that in the core already? Do we have one of the cache plug-ins doing something like that already?

-- StephaneLenclud - 07 Apr 2008


%TREEVIEW{web="%URLPARAM{"treeweb" default="%treeweb%"}%" topic="%URLPARAM{"treetopic" default="%treetopic%"}%" startlevel="1" formatting="outline" format="* [[$web.$topic][$topic]]" levelprefix="   " nodiv="1"}%
So the output is just a simple bullet list, from the current topic downward.

To that end Colas' script works sufficiently, and very fast.

The only thing I am missing (in both implementations) is a fast way to see if there are any children. I do not want to show the div block with title if there are none. I would also be helped if I can put a conditional header and footer - only if the tree gives any output.

-- ArthurClemens - 08 Apr 2008

Thanks for the feedback Arthur feel free to jump into the code and fix the header and footer as you see fit. Otherwise I'll try to stick those changes in the next release whenever that is.

One thing we could do to mitigate the performance issue is implement a REST handler to use TreePlugin via AJAX in combination with JQueryPlugin / JQueryDevPlugin spinner. I did something similar in PerforcePlugin.

I guess we could use a FastTreePlugin for fast generation of simple bullet tree.

-- StephaneLenclud - 09 Apr 2008

Stephane, you do not need to put files in ram... the OS (linux, but if you want performance you do not use windows anyways) already does it, it uses all available RAM to cache files already. the trick for performance is just to directly access the files and not use intermediate "caches" - or databases - that would just copy things in RAM, as this will [1] slow things down [2] gobble RAM that would be best used as a disk cache. For instance I use egrep with -mmap that do not copy things in RAM but maps them, and -m 1 that stops scanning the file as soon as the parent metadata is found. (so that we could accelerate a lot more if ALL topics had a parent line: now I must do a second slow grep pass just to detect topics without any parent line). Or we could use a patched grep version that would stop after N lines of input (here: 2). I guess the best of both worlds (speed and power) could be achieved by my script outputting fast a (cached) inverted index (a file with lines "parent son son..."), that you could process then with your perl code.

Actually, I think this approach is the one that could give the most impressive speedups to TWiki while keeping its TML roots: make slow things not 100% perl, but have the "close to the metal" things implemented as calls to C programs (standard as GNU grep, or custom ones), preparing things - cached - for a powerful perl backend. It may mean that we would be linux-only as it may be too hard to maintain C code for windows too, and promote the use of Virtual Machines (VirtualBox is nice, fast and GPL) for window users. Note that it was the original design of TWiki anyways, as it relied on external C programs a lot (RCS, grep, sendmail...). The recent trend to recode everything in perl is a very bad move as far as performance is concerned, IMHO.

-- ColasNahaboo - 09 Apr 2008

Thanks for sharing your thoughts Colas.

You are saying the bottleneck is not file access. I would love to see some profiling proving it. I know the theory about file systems I just wonder how well this works for TWiki in practice.

Actually I quite like the fact that TWiki being all Perl works just fine out of the box on Windows. Don't tell anyone but even though I run Ubuntu I find it more productive to develop on Windows sometimes :). I think the key is modularity so pure Perl fans can be happy and a Perl module can easily be replaced with a platform optimized one at will. In this respect I'm under the impression that the core developers did a really good job lately, thinking of the Store notably.

I was looking at TreePlugin.pm again and I have a feeling that we actually read every web topic twice. I'm gonna try to get some profiling done with JMeter and see how much I can improve things.

-- StephaneLenclud - 09 Apr 2008

Just published version 1.5. Checkout the release notes on TreePlugin. I used JMeter but did not took time to make extensive and precise profiling. I tested rendering of %TREE{web="TWiki" formatting="ullist"}% and observed an average performance improvement superior to 230 ms. That's about 10% of the rendering time on my mod_perled Ubuntu.

Arthur, I did very limited testing on that header and footer feature. I hope it will work for you.

-- StephaneLenclud - 10 Apr 2008

Comparing average performance of %TREE{web="TWiki" formatting="ullist"}% (2770 ms for TWiki 4.2.0 on Windows XP) with %TREE{web="TWiki" topic="BehaviourContrib" formatting="ullist"}% (2473 ms for TWiki 4.2.0 on Windows XP) it's quite clear that most of the processing is spent on resolving the SEARCH and building up the topics relationship rather than the final rendering. I guess no one doubted that wink

Arthur, if your TWiki is behind a firewall I guess you don't care so much about your server load so the REST/AJAX/Spinner solution should make you happy right? In fact it should dramatically improve your page loading time and that's another low hanging fruit we can grab. Would that be a suitable solution for your TWiki?

Caching the tree in a file might not be that complicated though. Question is: what should invalidate the cache? Should we empty any web tree cache in response to any afterSaveHandler ?

-- StephaneLenclud - 10 Apr 2008

Although we have to be careful with caching in respect to user permissions. We can't really do caching per user either that would not make any sense I think. What we could do however is cache the complete web tree and use it to feed the includetopic from the SEARCH. That should only give use improvement on topic tree. It should make a huge difference though on any topic tree from a large web.

Assuming I can implement the above we are left with the case of the full web tree whose performance won't be improved. To be honest I have no idea how I could cache a full web tree without bypassing user permissions. I wonder what is Michael's approach to this problem in TWikiCache. I should do some more reading.

-- StephaneLenclud - 10 Apr 2008

Version 1.6 now includes the file caching mechanism described above. It gives dramatic performance improvement for topic tree. See the profiling results below where the average topic rendering times (out of 100 requests) are given in milliseconds:

TWiki 4.2.0 PatternSkin and Apache2.2 on Windows XP behind firewall
Tree root TWiki.BehaviourContrib TWiki.WebHome TWiki Web
No cache 2366 2424 2675
With cache 592 728 2707

TWiki 4.1.2 NatSkin and Apache2.2 mod_perl on Ubuntu public access
Tree root TWiki.BehaviourContrib TWiki.WebHome TWiki Web
No cache 1710 1892 2275
With cache 294 532 2458

That should solve your issue Arthur smile I can only hope the caching mechanism will behave nicely, limited testing has been performed so far. Note to the administrators: if you hack into your topic files server side you better off delete the cached files from the working area. I'm already contemplating having a nice AJAX solution for Web tree. The idea would be to render the Web tree branch per branch using AJAX, spinner and/or fancy animations from JQuery.

Please feel free to review the cache implementation. Our Web file cache is generated if not already present upon the first TREE request targeting a given Web. Web cache is deleted on afterSaveHandler. Cache creation was not profiled in the above results. It didn't look too bad though, the larger Web I tested so far is the TWiki Web.

-- StephaneLenclud - 11 Apr 2008

Could possibly update the documentation saying that includetopic will be overridden for topic tree when using cache.

-- StephaneLenclud - 14 Apr 2008

It seems there is a bug for subwebs, say A/B. The plugin does not auto-create the working/work_areas/TreePlugin/A directory to store B.tree in, so it fails. Possible solutions could be to autocreate A, or to replace / by . in web names before using them as filenames for the cache. The second solution is simpler and faster.

Also, in the Img rendering modes, the topics are outputted as $topic which fails for non-wikiword topics. I replaced it by [[$web.$topic][$topic]] in the following patch

-- ColasNahaboo - 17 Apr 2008

Since upgrading from v1.3 to v1.6, I have noticed the following:

If stoplevel is set to 2, any topics with children below this level will be shown with blank lines below them in the tree view, corresponding to the topics which are not shown.


  • Topic A
    • Topic A1
  • Topic B
    • Topic B1
    • Topic B2 (this topic has children which are excluded by stoplevel="2"

    • Topic B3
  • Topic C

Is there another parameter which I can set to suppress these emply lines, or is this a bug?

-- TamsinTweddell - 18 Apr 2008

Thanks for your patches Colas. I have to confess I never test subwebs wink I won't be surprised if that plug-in does not support them in many ways. Can you submit your patches using Bugs:Item2942? Feel free to publish v1.7 too, if you can't be bothered I'll do it soon. Can you also post here the %TREE% you were using to test that img rendering bug?

-- StephaneLenclud - 18 Apr 2008

Tamsin please post your faulty %TREE%.

-- StephaneLenclud - 18 Apr 2008

Did some quick testing.

  • This works:
%TREE{topic="GrandParent" formatting="ullist" stoplevel="2"}%
  • This is broken:
%TREE{topic="GrandParent" format="   * $web.$topic" levelprefix="   " stoplevel="2"}%

-- StephaneLenclud - 18 Apr 2008

BTW if you are having problems with TreePlugin and subwebs in 1.6 you can disable to cache by setting {Plugins}{$pluginName}{NoCache} to 1 in LocalSite.cfg.

-- StephaneLenclud - 19 Apr 2008

Ok TreePluginSubWebs.patch commited as rev 16687, TreePluginNonWikiWords.patch as rev 16688. Stephane, I will let you publish 1.7

The faulty %TREE was %TREE{formatting="imageoutline:threadexp"}%

-- ColasNahaboo - 19 Apr 2008

Stephane, my %TREE% is

%TREE{stoplevel="2" formatting="outline" excludetopic="Web*" format="* [[$topic][$spacetopic]]" levelprefix="   "}%

I can see that you get an unbroken tree using ullist rather than outline, but I can't see how to incorporate SpacedWikiWordPlugin with ullist. The tree is also broken if $spacetopic is leftout.

-- TamsinTweddell - 21 Apr 2008

I'm having trouble with a particular tree. When using formatting="imageoutline:thread" non-WikiWord topics are not linked correctly.
This works:

%TREEVIEW{topic="WebHome" stoplevel="3" formatting="ullist"}%
This doesn't:
%TREEVIEW{topic="WebHome" stoplevel="3" formatting="imageoutline:thread"}%

-- DeanSpicer - 22 Apr 2008

Thanks for the feedbacks.

  • TamsinTweddell: It's just that stoplevel and levelprefix don't work very nicely together. Until this get fixed you will have to choose between stoplevel and spaced wiki word I'm afraid.
  • DeanSpicer: I'm not using imageoutline myself. I rather combine with TreeBrowserPlugin instead.

-- StephaneLenclud - 22 Apr 2008

The problematic tree above just doesn't link the topic names that are non-WikiWords.

-- DeanSpicer - 24 Apr 2008

Dean, apply my TreePluginNonWikiWords.patch, it should patch your bug (or get the SVN version of the plugin)

-- ColasNahaboo - 24 Apr 2008

It's probably trivial to fix. Maybe you can just edit ImgNodeFormatter.pm search for the format of THREAD_MODE and replace the value there with something like:

<table border='0' cellspacing='0' cellpadding='0'><tr><td nowrap>\$images</td><td> [[\$web.\$topic][\$topic]] </td></tr></table>

You can also probably fix it without touching the Perl code just by passing the format above as parameter along with the images definitions as explain on TreePlugin.

-- StephaneLenclud - 24 Apr 2008


Thanks for your response. I will leave out the stoplevel attribute for now.

-- TamsinTweddell - 25 Apr 2008

Line 354 of the 1.6 version of TreePlugin.pm needs a patch:

-   if ($node!=$webRoot) #no point creating cache for the fake webroot
+   if (defined $webRoot && $node != $webRoot) #no point creating cache for the fake webroot

Unless, of course, it should be:

-   if ($node!=$webRoot) #no point creating cache for the fake webroot
+   if (!defined $webRoot || $node != $webRoot) #no point creating cache for the fake webroot

-- HarlanStenn - 20 May 2008

Were you getting warnings in Apache logs?

-- StephaneLenclud - 21 May 2008

I fixed some bad links in http://twiki.org/cgi-bin/view/Plugins/TreePlugin?rev=45

-- SeanCMorgan - 28 May 2008

Make sure this gets back into the svn repository.

-- PeterThoeny - 29 May 2008

Stephane, there were hundreds of occurrences of the following warning:

view: Use of uninitialized value in numeric ne (!=) at D:\\Prd\\TWiki\\lib/TWiki/Plugins/TreePlugin.pm line 354., referer: [...]/bin/view/TWiki/WebHome

In fact there was so much logging going on that the performance nose-dived and topic tree became unusable. I used Harlan's first fix, and problem solved.

Thanks Harlan!

P.S. to Peter, if the svn check in remark was to me, I don't know how to do that.

-- SeanCMorgan - 03 Jun 2008

Thanks for the feedback.

-- StephaneLenclud - 04 Jun 2008

There are a problem with umaluts (ä,ü,ö) in the version 1.6! They break the topic names. In the version 1.5 it worked fine.

-- PaulBraun - 05 Jun 2008

Thanks for reporting that problem. Can you give precise examples?

-- StephaneLenclud - 05 Jun 2008

Paul: Did you try disabling the cache to see if it fixes your problem?

-- StephaneLenclud - 05 Jun 2008

Also without caching (mod_perl) i cannot see topics in the treeview with an ä,ü, or ö For example the topic RückVerfolgung.

-- PaulBraun - 13 Jun 2008

That's odd! I can't really explain myself how could that have been introduced in 1.6. Are you sure that your issue is not caused by moving from TWiki 4.1.x to 4.2 rather than just by upgrading tree plug-in from 1.5 to 1.6?

-- StephaneLenclud - 16 Jun 2008

With the version 1.5 the Topic RückVerfolgung is shown in the tree. But with version 1.6 i cannot see the topic in tree. I test this in twiki 4.2

-- PaulBraun - 17 Jun 2008

Does the current plugin version allow for additional search parameters within the TREE tag besides the Include and Exclude Topic attributes? I'm trying to figure out if this plugin would be a good option for generating a Table of Contents based on form field values.

-- GarySprague - 21 Jul 2008

I don't think it does put you could get it to do it with very little work I think.

-- StephaneLenclud - 23 Jul 2008

Paul I was talking about the caching mechanism from TreePlugin itself not mod_perl.

-- StephaneLenclud - 25 Aug 2008

I'm working on v1.7. I've already fixed a few issues I noticed with the cache mechanism. I fixed the warnings. I still have to integrate ColasNahaboo patches. I should also try that umaluts things if I get a chance.

-- StephaneLenclud - 26 Aug 2008

Ok, I had a very quick try to reproduce the umlaut bug on 4.2.2 using my TreePlugin with cache patch and it worked just fine. So if I do %TREEVIEW{web="Sandbox" formatting="ullist"}% It does show my umlaut topic. See http://slion.net/view/Sandbox/SandboxTree and search for RückVerfolgung.

-- StephaneLenclud - 28 Aug 2008

I eventually realized that Colas had check-in his patches, so I simply did a merge of that with my cache fix and the warning fix and checked in v1.7 in SVN. I will publish 1.7 as soon we get BuildContrib to work with upgraded twiki.org. I keep getting 302 Moved error upon save.

-- StephaneLenclud - 28 Aug 2008

Just published version 1.7. I hope you like it. It's been test on 4.2.2. Tell me if you are still having problems with umlauts. As said above I could not reproduce that bug.

-- StephaneLenclud - 31 Aug 2008

Just switched to trunk Version 1.7 but I still have problems with non WikiWords as described above e.g. WikiWord-Morewords. Can someone confirm that? Any Help?

-- CedricWeber - 23 Sep 2008

Thanks for the reminder. I totally missed that. Can you post your faulty TREE.

-- StephaneLenclud - 26 Sep 2008

Shouldn't this work?

%TREEVIEW{topic="VbrownBagelry" formatting="outline" format="$topic <br /> $percntTOC{\"$topic\"}$percnt  <br />" }%

The backslashes get eaten frown

-- VickiBrown - 2009-12-18

The Tree plugin did not work when I upgraded to TWiki 5.0. It kept saying the plugin was disabled.

-- HunterMoseley - 2010-08-20

I have this plugin running with TWiki-5.0.0. Could you let us know what kind of issues you found? Any error messages in Apache error log?

-- PeterThoeny - 2010-08-20

New plugin version is posted. Issue was with a variable that was not declared, TWikibug:Item6562. Thanks for reporting.

-- PeterThoeny - 2010-08-21

I'm trying to get %TREEBROWSER and %TREEPLUGIN working together according to the instructions on the TreePlugin page. eg

%TREEBROWSER{"file" title="%WEB%"}% %TREEVIEW{web="%WEB%" topic="GrandParent" formatting="outline" format="* $topic" levelprefix=" "}%

But this just doesn't work.

%TREEVIEW is putting in a <div> which I suspect is killing %TREEBROWSER...

The versions I have installed are:

TreeBrowserPlugin (v1.8): TreePlugin (2010-08-21, $Rev: 19347 (2010-08-21) $):

I also suspect there's going to be a problem with TreePlugin outputting the first line as the name of the topic you are searching for, without making it a bullet.

Really appreciate any help with this since I'm pretty new to how all this works.


-- NormanCates - 2011-10-12

I am having some strange behaviour with Treeplugin which I have so far been unable to fix. I am using it with TreeBrowserPlugin but this behaviour is present if I use TreeBrowserPlugin or not.

When I use the "formatting="outline"" option with a format of "format="* $topic " levelprefix=" "" the first child item of each web is listed on the same line as it's parent with a * in between. All other children are rendered correctly.

The code I am using is below: -

%TREEBROWSER{"thread" title="<h3>Topic Tree Of %WEB%</h3>" openAll="off"}%
%TREEVIEW{web="%WEB%" formatting="outline" format="* $topic " levelprefix="   " excludetopic="Web*,User*,TWiki*"}%

The output looks like this: -

MatrixScienceDocuments	* AdministrationInformationAndProcedures	* LicensingAdminGuide	* LicenseAdminGuideTest
   *   * MatrixSciencePhoneDirectory
   * PaperLessOrderProcessing

Any ideas?

-- Neil Roberts - 2015-08-12

Sorry my bad on the formatting of those examples. I will try to do better here.

%TREEBROWSER{"thread" title="<h3>Topic Tree Of %WEB%</h3>" openAll="off"}%
%TREEVIEW{web="%WEB%" formatting="outline" format="* $topic " levelprefix=" " excludetopic="Web*,User*,TWiki*"}%

Web2 * FirstChildOfWeb2 * FirstChildOfFirstChildOfWeb2
   * SecondChildOfWeb2
   * ThirdChildOfWeb2

-- Neil Roberts - 2015-08-12

(I added pre tags to above examples so that they have the proper look.)

I checked, one issue is the level prefix, it needs to be three spaces:

levelprefix="   "

However, there seems to be another problem with missing newlines. I need to check.

-- Peter Thoeny - 2015-08-12

There was a bug, is now fixed. Please install the latest TreePlugin version.

-- Peter Thoeny - 2015-08-12

That is brilliant. Works fine now. Thankyou very much for your fast response.

-- Neil Roberts - 2015-08-13

Topic attachments
I Attachment History Action Size Date Who Comment
Perl source code filepm TreePlugin.pm r1 manage 15.3 K 2006-09-19 - 23:22 StephaneLenclud Cairo/Dakar compatiblility
Unknown file formatpatch TreePluginNonWikiWords.patch r1 manage 1.9 K 2008-04-17 - 15:52 ColasNahaboo patch to 1.6 for topics not in wikiword for img rendering
Unknown file formatpatch TreePluginSubWebs.patch r1 manage 1.3 K 2008-04-17 - 15:32 ColasNahaboo Patch on 1.6 to make it work with sub webs
Compressed Zip archivezip TreePluginUpdated.zip r1 manage 20.8 K 2006-09-21 - 08:46 JanFilipsky Modified plugin, DelimitedListFormatter added
Unknown file formatEXT koala-webtree r2 r1 manage 2.1 K 2008-04-07 - 17:57 ColasNahaboo an experiment to redo the core algorithm in shell
Texttxt tbppatch.txt r1 manage 12.4 K 2006-08-30 - 22:47 StephaneLenclud Patch for combination with TreeBrowserPlugin
Texttxt v0.6patch.txt r1 manage 7.5 K 2006-10-01 - 20:04 StephaneLenclud Patch for v0.6
Edit | Attach | Watch | Print version | History: r232 < r231 < r230 < r229 < r228 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r232 - 2015-08-13 - NeilRoberts
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.