Extension talk:TreeAndMenu

How to open only certain folder by default?
Hi, is there any way to open only certain folders by default instead of all or nothing? Thanks (again) in advance. --71.184.105.187 03:18, 4 September 2007 (UTC)
 * Currently the only way to do that is to use multiple trees each with their own openlevels parameters. --Nad 03:25, 4 September 2007 (UTC)
 * Perfect. Thanks! --71.184.105.187 03:31, 4 September 2007 (UTC)

Can't hide toolbox and navigation
Hi, I followed the directions on adding CSS to hide the toolbox and navigation sections, but it hides the tree, too. This is at http://wiki.passwordmaker.org. If you view the HTML source of that page, you'll see MediaWiki renders &lt;div id="p-tb"&gt; around the NavTree, so hiding that div also hides the tree. How do I make the tree render outside that div, or is there another solution? Thanks in advance. --71.184.105.187 00:21, 4 September 2007 (UTC)
 * I had a look at the source of your page and it should be possible to hide the heading and bullets specifically while keeping the main portlet container visible. I've changed the notes at Extension:Tree_view to reflect this. Let me know if it works since our wiki's don't do the sidebar this way so I can't test it myself. --Nad 00:38, 4 September 2007 (UTC)
 * Very close. The only thing remaining is &lt;h5&gt;Toolbox&lt;/h5&gt;, which is between the p-tb div and the pBody div. Take a look at the source again to see what I mean. It's too bad IE6 doesn't understand descendant selectors otherwise we could write #p-tb > h5 {display: none;}. Any other ideas? --71.184.105.187 02:32, 4 September 2007 (UTC)
 * No it's my fault, there shouldn't be a dot before the h5 selector as that specifies an element with class="h5", it should be fixed with the dot removed --Nad 02:47, 4 September 2007 (UTC)
 * That's it! Thanks for such a great extension! --71.184.105.187 03:11, 4 September 2007 (UTC)

Constructing Toolbox Links
Ok, last problem (I think)... When I try to duplicate some of the links in the normal toolbox - specifically the 'What links here', 'Related changes' & 'Printable version' links - using the {PAGENAME} variable, they don't work right for pages that have spaces in their names... see http://wiki.passwordmaker.org/index.php/How_it_works - even though apparently Mediawiki automatically adds the underscores to the page name, the actual page name has spaces, not underscores, and apparently the {PAGENAME} variable doesn't capture them correctly - I'm guessing this is a MEdiawiki bug, not necessarily a Treeview bug, but any ideas on how to fix this (worst case, I can rename all of our pages to ones with explicit underscores, which may not be a bad idea anyway)...
 * You should use the FULLPAGENAMEE variable (notice double E on the end meaning "encoded"), the best wikitext to make the link would be:

[ What links here]
 * --Nad 13:02, 4 September 2007 (UTC)
 * Hmmm... the above didn't work, but this did:

[fullurl/Special:Whatlinkshere/ What links here]
 * I was careful to recreate yours precisely, so don't know why it didn't work... but as I said, the above works, so unless there is a good reason not to use it, I think we're good to go... thanks for the pointer to the FULLPAGENAME variable!
 * "fullurl" is a mediawiki parser function, the wikitext above should have been copied and pasted exactly as is including the word "fullurl". It's ok how you have it now, but using fullurl is better as it's independent of your wiki's installation location etc. --Nad 22:35, 4 September 2007 (UTC)
 * duh! Thanks for banging me on the head! Much better, thanks!
 * hmmm... now, what is the 'Special' target page for the 'Printable version'? Tried 'Special:Printable' and 'Special:Printable=yes'... thanks again for your help! - charles, 5 Sep 07

Doesn't work for me at all
I've added the include code to my LocalSettings.php file, and put the latest Treeview.php into my "wiki/extensions" directory, and it simply prints my code out verbatim, without even trying to produce the tree view, i.e.

I know it's finding the Treeview.php file correctly, though, because if the file is not present it complains a lot. Sorry, I have no idea about mediawiki extensions or how to debug them. I just followed the instructions as best I could and it just ignored my attempt at making a tree. 217.42.127.214 20:07, 28 August 2007 (UTC)
 * When the code gets printed like that it usually means you've missed out the php delimteres (&lt;? and ?&gt;) --Nad 20:22, 28 August 2007 (UTC)
 * Sorry, I don't understand. I have the <? ?> delimiters in my treeview.php file and my LocalSettings.php file, (except there it starts with "<?php").  I just copied the treeview.php exactly as it's given here in the wiki.  Do you mean that I have to include those delimiters within the wiki code as well? 158.125.1.113 16:07, 30 August 2007 (UTC)
 * No if you've copied the code exactly and have the delimiters it must be another problem. I think I misunderstood your problem - when you say it's "print out the code" I thought you mean the treeview's php code, but you're meaning the wikitext as shown above right? that's a different problem, what version of MediaWiki are you running? does the extension show up the the special:version page? --Nad 20:41, 30 August 2007 (UTC)

I am having the same problem... here is our wiki so you can see what it looks like - see the 'toolbox' and 'navigation' entries underneath the real 'toolbox'? I'm completely open to the possibility that I did something wrong, but I dbl-checked and can't find a syntax error or anything in the mods I made... any help appreciated!

Yes, we are also having the same problem with the code from 30-Aug-07. MediaWiki 1.10.0 and the extension DOES show up in the special:version page!


 * I can see what the problem for the site at the url shown above from html source of the page. The treeview image paths are not set to the url's of the uploaded images, it's best to use $wgUploadPath to set the image names (I've updated the documentation to use it). Also the required image "doc-icon" is missing, probably because it was missing from OrganicDesign:Category:Tree view images but has been added now. --Nad 21:50, 31 August 2007 (UTC)


 * A few people have had trouble in the past with setting up the images properly, so I've made a new version (3.6.1) which requires only the image titles with no preceding path information, and only those that are different than the defaults need to be defined. The documentation has been updated again to reflect these changes. --Nad 23:33, 31 August 2007 (UTC)


 * That did it, thanks! Looks like your renamed Spacer.gif to Blank.gif too? This confused me for a bit (no indents in the tree). --71.233.89.119 02:19, 1 September 2007 (UTC)


 * Yeah some people had trouble with spacer.png because IE doesn't render png transparency properly without the monobook JS hack, but blank.gif works fine. --Nad 02:50, 1 September 2007 (UTC)

Eerror messages
I've tried to install it on my wiki but i get a lot of errors when i make a tree-entry on a page. (the tree is properly displayed!) The error messages are similar to this:
 * Notice: Use of undefined constant wgUser - assumed 'wgUser' in /var/www/html/wikidelfia/extensions/Treeview3.php on line 59

In the localsettings I put : include_once('extensions/treeview3.php') and the $wgTreeViewImages = array( with the proper links to the images. What is going wrong? --BB70 11:28, 14 March 2007 (UTC)
 * I know what that is - that's a setting in your php.ini that doesn't allow the array indexes to have their quotes missing - just put quotes around all the arrays, or download again - I've change the code to not depend on that setting now (I think I got them all, here's the diff). --Nad 23:19, 14 March 2007 (UTC)
 * It helps a little.. but i still get errors like: Notice: Undefined index: doc in /var/www/html/wikidelfia/extensions/Treeview3.php on line 84 (same for line 79 till 83) and these two: Notice: Undefined index: openlevels in /var/www/html/wikidelfia/extensions/Treeview3.php on line 85 ; Notice: Undefined offset: 5 in /var/www/html/wikidelfia/extensions/Treeview3.php on line 93. And there is a pop-up box with the message [object error] --BB70 07:42, 16 March 2007 (UTC)
 * You have your settings set extrememly strictly for it not to allow reading uninitialised variables and indexes! Check if it works now, I've made it only read them if they exist. --Nad 09:43, 16 March 2007 (UTC)
 * This works! Thank you for the quick response... --BB70 12:02, 18 March 2007 (UTC)

Parameter openlevel
When I use the paramater openlevel=1 (I also tried id=1) the tree stays closed. I tried the example in the article-text with the same result. Is there something else in the configuration I must change to get this work? --BB70 09:11, 19 March 2007 (UTC)
 * I've found the solution... It's not openlevel but openlevels --BB70 09:52, 19 March 2007 (UTC)
 * Sorry about that - typo fixed --Nad 21:00, 19 March 2007 (UTC)

JavaScript not being included
I have the same problem between 3.1 and 3.5. Here is my testwiki from home computer: testwiki two_php_files_modifiedphp_files
 * Well it seems to be wroking perfectly except for not adding the javascript for some reason - that bottom line problem is as I suspected which is that you have made an item two levels deeper than the one before which isn't allowed. I've updated it to add the JS in a better way which may solve your problem. If not there's a hack you can add to your localsettings after the treeview include to force it to add the javascript - the only drawback is that it'll be added even if there's no tree on the page.
 * $wgTreeView->addJS($wgOut);
 * Hmm, if i add the line above in my localsettings.php, i got the follow error message:
 * Fatal error: Call to a member function addJS on a non-object in /var/www/mwiki/LocalSettings.php on line 144
 * Besides, i just create a simple tree with only one sub-layer but result isn't much differentsingle-layer-tree
 * Lastly, i found that if i `touch` localsettings.php, then problem go away. But if i went to other computer and the Javascript just not insert again. This even happen between different browser (eg.IE and firefox). Could it be due to any setting on wiki i mis-configured? or sth i omit on LAMP configuration?
 * You must have added the hack before the include of the tree to get that error --Nad 08:13, 28 March 2007 (UTC)
 * I tried to add the line just right before "?>" and before "include_once('/var/www/mwiki/extensions/treeview3.php');". But it doesn't give me any different result apart from the line where error occurred.
 * Sorry, my mistake - you'll need to put the hack at the end of the wfSetupTreeView function before it's closing curly brace --Nad 23:35, 28 March 2007 (UTC)
 * and also change it to $wgTreeView->addJS($GLOBALS['wgOut']); since its inside a function now.
 * Also, are you using the usual MonoBook skin? your problem sounds a lot like bug 3603 which was that the monobook skin wasn't adding the headscripts, that was resolved in 1.6. --Nad 00:07, 29 March 2007 (UTC)

I also had the same problem. I'm on MW 1.9.3, Treeview 3.52 (2007-03-27) - standard monobook skin (some modifications to css, but none to the php file). Treeviews worked fine in preview mode, but no js was added to page in article mode. Tested a very simple treeview to eliminate weirdness there. Your hack above - $wgTreeView->addJS($GLOBALS['wgOut']); - works. Would link to the wiki, but it's on an intranet only. Zarius 10:53, 16 April 2007 (UTC)

Treeview in Sidebar!?
Hi as I can see on http://www.wikifs.org i.e. there must be a possibility to use the Treeview instead of the original Sidebar from MediaWiki. May anybody like to give a clou how it works?! Thanks.
 * I just commented out all the sidebar stuff in /wiki/skins/MonoBook.php and replaced it with the following, which then uses the "Navigation" article as sidebar content. You'll also need the CURRENTUSER variable for some of the links in you sidebar tree. --Nad 20:49, 3 April 2007 (UTC)

global $wgUser,$wgTitle,$wgParser; if (is_object($wgParser)) $psr =& $wgParser; else $psr = new Parser; $opt = ParserOptions::newFromUser($wgUser); $nav = new Article(Title::newFromText('Navigation')); $out = $psr->parse($nav->fetchContent(0,false,false),$wgTitle,$opt,true,true); echo $out->getText; return true; }


 * Isn't there an easier way, like by using MediaWiki:Sidebar? I tried doing it but I don't think that field recognizes templates (or however Treeview is called). There needs to be a user-friendlier way of adding/editing the sidebar treeview menu than having to dork with PHP files... :/ -Eep² 22:08, 23 July 2007 (UTC)
 * No, for some reason they didn't make MediaWiki:Sidebar allow wikitext and there's no hooks allowing it to be extended. We use Extension:WikiSkin which allows the entire skin to be defined in wikitext. --Nad 22:51, 23 July 2007 (UTC)
 * I added a new hook to Monobook.php (just one line of code) right at the top of the nav bar and tied the navtree to that hook. And I used mediawiki:Common.css to hide the original navbar items with #p-navigation { display:none }. This works fine, see http://semeb.com/dpldemo. Algorithmix 07:02, 16 August 2007 (UTC)

I've got the Problem that the tree does not open at anytime? sometimes it works and sometimes not, is there anybody with a helping hand or the same problem?
 * It sounds similar to the problem above under the "JavaScript not being included" heading. Otherwise, give me the url of your wiki and I can have a quick look --Nad 10:01, 11 April 2007 (UTC)
 * I can't come out I am sitting behind a firewall. :( What kind of problem might it be? Setting the var. $wgAllowUserJs = true; does not change a lot.:(
 * Have you tried the hack recommended above? is you tree in normal page or in sidebar? --Nad 21:07, 11 April 2007 (UTC)
 * Oh yeah my mistake. Think I have to learn reading again ;) Thank you for you fast answeres!! Now it works.

Subtree functionality
I'm having problems getting the subtree functionality working. I took your example and Tree1 does not show Tree2 as a folder that I can click to open. It just shows as a DOC icon. Here is my code:

Roger R Cruz 22:18, 14 May 2007 (UTC)

Treeview can't be invoked from a template
I have the following template: Test

when I try to invoke it in another page via

I get the following error: O@@@ Tree1 Item1 Item2 C@@@ Roger R Cruz 22:40, 14 May 2007 (UTC)
 * That's a current bug which I'll fix when I've got some time to work on it next, but there's a temporary solution, for example to transclude your "Test" tree article, do the following:

Empty Folder
I have the need to create just the top level bullet list (folder) that does not have any sub-entries below it. However, if I don't at least include a list subentry (** subitem 1), I don't get a folder to show for the tree. It shows as a DOC. --Roger R Cruz 22:52, 14 May 2007 (UTC)
 * All nodes having no child nodes show as a doc (leaf node), you'd have to change $wgTreeViewImages['doc'] to your folder icon if you want them all to be folders regardless of whether or not there's any child nodes. --Nad 23:31, 14 May 2007 (UTC)

Missing JavaScript and missing parser tags
I'm having problem similar to the other non-included JavaScript issue on my two wikis (running 1.10), but the head JS is included, and the Body JS isn't, so none of the folder icons are clickable (to expand the tree!) I would link to the wikis but they're on my computer and on an intranet... I will provide any troubleshooting information needed upon request.

Thanks! Rockerbaby 19:15, 7 June 2007 (UTC)
 * I have the current version running properly on 1.6.10, 1.9.3 and 1.10.0, so it's not a mediawiki version problem, if either of your wiki's are publically accessible I could have a look and see if I can see what the problem is... --Nad 22:53, 8 June 2007 (UTC)


 * I will set up a blank test wiki (running 1.6.9 due to the fact that my host only supports PHP4) and install the extension there. I cannot open the 1.10 wikis to the public due to ISP restrictions on servers, but if it helps I can copy the produced HTML code and the LocalSettings.php files to my userspace here. What happens is the A HREF tags in the body aren't being copied into the rendered content. I removed all other parser hook extensions to check for compatibility, and it still didn't work. Thank you for your help! Rockerbaby 04:52, 9 June 2007 (UTC)


 * Actually All fixed. Turns out I had the file extensions wrong on plus and minus in the configuration, so the links weren't even showing up. Oops! Rockerbaby 05:24, 9 June 2007 (UTC)

Tree View Doesn't Display at all
I have installed the extension and the pictures, added it all to the localsettings. When I try the syntax all I get is Root displaying. Only Root shows. Any ideas? Please e-mail me @ mike.madeja@gmail.com, Thanks
 * I have the exact same problem. Manu3d
 * This problem has been solved, it was due to wrong image paths. Check the html source of the page containing the problematic tree in your browser, and ensure that the image paths it's using are correct. --Nad 21:00, 27 June 2007 (UTC)

Tree View in Sidebar : advanced

 * I integrated Tree View in the side bar and its working so far (ehm so great)
 * I don't like to miss "Seek" and "Toolbox", anythig else is missing using personal css, (and will show up again for other users)
 * but I'ld like to see Tree View on top, just below the logo and before the seek-option

I can't figure out to change from "MonoBookTemplateToolboxEnd" to the beginning of this array (while the automatic changing of the Toolbox-content should be still working)

Any Idea? - Thank you!
 * If you're wanting more control over the sidebar content, then you'll need to hack the /skins/MonoBook.php file. The way I do it is to replace the part of the file which renders the toolbox with the following code which allows the MediaWiki:Sidebar article to contain normal wikitext such as a treeview:


 * I asked for "Any Idea", and you are right presenting this one. But I have to face that this informtaion is to heavy for me.
 * I did a workaround within monobook.php:


 * 1.) Killing line
 * which I found in the end of div
 * which I found in the end of div


 * 2.) including
 * which I placed just behind the closing div of
 * seems to work so far
 * seems to work so far
 * seems to work so far

Collapseable tables
Hello, I am seeing a error when I place a treeview inside a template page, and then refer to that template in a [collapsible] table. Once I click on show, it expands all of the nodes at once, but still shows the root nodes as unexpanded. Is there any way to make the treeview resume the default setup and not expand every node? --Jgetzke 15:50, 17 August 2007 (UTC)
 * Can you give me a link to the site this is happening on or is it intranet? --Nad 22:37, 19 August 2007 (UTC)
 * Unfortunetly it is on intranet. If you want, I would be happy to duplicate the error on your wiki.  You would need to install the Navframe/collapseable function from Wikipedia first.  Below is what the code looks like on our wiki:  --Jgetzke 16:12, 20 August 2007 (UTC)


 * style="border: 3px solid #E41F1F; align: left; color: #42617B; height:210px; font-size:11px; width:300px;" valign="top" |


 * Sorry for the slow response, I've been away and have a lot of work to catch up on. If you like you can set up the problem on www.wikifs.org, which is one of our test wiki's, I can make you a sysop on it so you can access the css and js articles. --Nad 23:22, 24 August 2007 (UTC)

Sidebar Tree Issues
I'd like to be able to replace the navigation box at the top of my sidebar with http://daniel.cook.name/index.php?title=FamilyTree but the I'm not sure what to replace in monobook.php. I read your comments above (from April 3rd)"I just commented out all the sidebar stuff in /wiki/skins/MonoBook.php and replaced it with the following" I cannot figure out what stuff to comment out...  Can you please be a little more descriptive?

...Also, how do you get your sidebar to dynamically resize at http://www.organicdesign.co.nz/? Thanks in advance.
 * Not sure what you mean by this, my sidebar always stays the same size...? --Nad 23:52, 24 August 2007 (UTC)
 * Click on Site Map - The Nodal Model. Watch your sidebar grow to the right to accommodate the text.
 * I see, it probably happens by itself because we use a table for our layout (using Extension:WikiSkin to define the skin in an article instead of a file). It can probably be done with css too, but the guy who does most of our css (OrganicDesign:User:Rob) is on holiday for a couple of weeks and I'm not all that good at it. --Nad 02:31, 25 August 2007 (UTC)

Okay, thanks. I'll take a look at WikiSkin. Regarding the first question. Can you please tell me what I should delete and exactly where I should drop this code in to Monobook.php?

global $wgUser,$wgTitle,$wgParser; if (is_object($wgParser)) $psr =& $wgParser; else $psr = new Parser; $opt = ParserOptions::newFromUser($wgUser); $nav = new Article(Title::newFromText('Navigation')); $out = $psr->parse($nav->fetchContent(0,false,false),$wgTitle,$opt,true,true); echo $out->getText; return true; }

I've created a copy of my FamilyTree article and called it Navigation. I'd like to lose the default navigation and toolbox and replace them with mine. I appreciate the help!
 * I've added a modified version of Monobook.php at Replacing sidebar content which has the search, toolbox and language links commented out, and the code added to render the navigation article in their place. --Nad 04:03, 25 August 2007 (UTC)
 * You ROCK, Nad. Thank you.  [EDIT] Hmmm.  I get

Parse error: syntax error, unexpected ';', expecting T_FUNCTION in /home/listcoo6/public_html/daniel/skins/MonoBook.php on line 266 Ideas?
 * Oops didn't have the php delimiters quite right - probably best just to remove those commented out bits you don't want anyway (make a backup of the file first tho). And may be best not to use the version on OD just in case the version isn't the same as yours - that example was from a MW 1.10.0. --Nad 04:23, 25 August 2007 (UTC)
 * You may want to also install Extension:Semantic MediaWiki at some stage too which allows relationships between the people to be defined for better reporting etc. I'm working on a gedcom importer for mediawiki too, but have had too much work on recently to make much headway with it but the format doesn't look too difficult. --Nad 04:38, 25 August 2007 (UTC)

Excellent lead on Extension:Semantic MediaWiki. Thanks for everything.

Nodes instantly collapse after expansion
Hello! - I'm having two problems that I can't figure out...
 * When I expand a node, as soon as I click on an item in the list, the node collapses again - very frustrating - and,
 * That's a strange problem?! can you give me a link to the wiki in question? if not supply html-source code of page having the trouble, and let me know info from special:version page. --Nad 06:48, 1 September 2007 (UTC)
 * http://wiki.passwordmaker.org... I'm working with Eric on getting Treeview working properly, and he already got your help with hiding the normal toolbox and navigation trees (thanks!) - The bottom unexpanded 'toolbox' and 'special' trees exhibit the problem...
 * No idea on how/why to get these to stay expanded after a link is clicked? -- Charles, 05 Sep 07
 * Are you meaning that when you click on a node, it goes to that page correctly, but then after the new page loads the tree is no longer open to the correct position? or do you mean that when you click a node the tree closes up straight away without even going to the new page? if the former, then unfortunately the current version cannot remember it's open position, but this feature is in the development pipeline. --Nad 11:26, 5 September 2007 (UTC)
 * Ahhh... ok, yes, I meant the former - it does open the link, but then the tree collapses again... good to know this is being worked on... thanks again for all your help!


 * Is there a way to make some of the nodes expanded by default?
 * Add openlevels=some-number to your tree definition. I've added an example in the usage section. --Nad 06:48, 1 September 2007 (UTC)

Thanks for any help! - charles

Differences between treeview4 and former version, wishes
Hello Nad,

the new version produces a tree which is always indented by '16 spacers'. This consumes space. The older version did not do that (which I think was better). You might want to change line 118 to . "$open"

Apart from that it would be nice if one could use explicit line breaks in the tree element texts. Sometimes a label is too long and should be broken at a certain point. Putting a line break marker like \n into the text (which you could find and then break the label accordingly) would help. Using  directly leads to the next line starting at the very left which looks awkward.

Third, it would be good if the "width" parameter could be changed by the user (I would prefer 12 instead of 16 which gives less indentation per level). If you try bigger values like width=32 you will see that something is not correct with the vertical alignment.

Thanks, Gero from DPL (Algorithmix 09:43, 8 September 2007 (UTC))
 * Ok I'll add the newline soon, and make the width definable by the user. I indented it differently starting at version 3.6.2 because even though it seems too indented now, it was actually logically incorrect before because the doc-nodes and folder-nodes of the same level should be exactly lined up. --Nad 11:13, 8 September 2007 (UTC)
 * I just updated to to 4.0.3 which has the whole-tree-being-indented problem fixed and adds $wgTreeViewIndent which is set to the number of extra pixels to indent each level by. If it's set to zero (default) then it will use the pixel width of the doc icon. Haven't added newline capability yet. --Nad 12:04, 8 September 2007 (UTC)

Feature Request
Nad - I would like to ask for you to consider adding lines between the nodes in Tree View with a future revision. You can see what I mean here with [DTree]. Well, I finally figured out how to get my [Family Tree] in the sidebar, so I put Wiklets on the shelf for another application someday. Thanks for your cool extensions.

[EDIT] One more thing if you will. It would be nice to have the ability to change the icon for the root. In my case I would use something like this  Still haven't figured out what would be good for open and closed. Definitely not folders, but I'm still looking. --Cooknn 19:57, 9 September 2007 (UTC)
 * Those would be good features, I'll see if I can get them done soon ;-) --Nad 02:35, 10 September 2007 (UTC)
 * At the risk of wearing out my welcome, could you look at the possibility of using custom icons for *any* node? For me that would be cool as I could use the tree for root then a male or female icon for the descendants of my family tree.  I think DTree allows for that as well.  Maybe there are some clues in his .js :) --Cooknn 22:39, 10 September 2007 (UTC)
 * Don't worry, I was thinking along similar lines. I just have to think of the best way to handle it... I'm thinking of moving all the image specification into css and making the code just generate css-classes. I could then make a way to override the class by supplying a parameter in the tree's row. I've redone the main rendering code in preparation for adding the dotted lines between nodes, so that should be ready soon too --Nad 02:15, 11 September 2007 (UTC)
 * Nice! One good thing I noticed about about DTree is how the nodes line up vertically.  The + and - signs are centered directly below the parent node, therefor the children's icons and text descriptions all line up vertically even if they have children as well.  I guess it would be hard to incorporate the lines between nodes if that wasn't the case... Good luck, and thanks for your work! --Cooknn 12:27, 11 September 2007 (UTC)
 * Have a look at OrganicDesign's sidebar tree now, that's using TreeView4.0.5 which has connector lines, but with a couple of small bugs to iron out. I should have 4.0.6 finished tomorrow which will have the line bugs fixed, and will allow specifying icons on a per node basis using   where each parameter is an image name and the "opened" parameter is optional. --Nad 12:47, 11 September 2007 (UTC)
 * Yeah!!! Looks great :) --Cooknn 14:29, 11 September 2007 (UTC)
 * Hey thanks a lot for the donation! ;-) --Nad 22:22, 11 September 2007 (UTC)
 * No problem. Thank you.  Your next Beer Thirty can be on me :) --Cooknn 22:46, 11 September 2007 (UTC)
 * Phew - those connector line things were pretty tricky! but they're working properly now ;-) probably best to wait for 4.0.7 though because I still have some finishing touches (such as making $wgTreeViewShowLines enable/disable them) and to implement $wgTreeViewIconMagic for allowing rows to change their icons. Also I need to be able to have an optional root node at level 0 which has no +/-. Once I've done those things I'll make version 4 the main stable version because I think it's rendering method is more solid and efficient than 3.6.x. --Nad 09:23, 12 September 2007 (UTC)
 * I could see that the lines were becoming a challenge. Appreciate your diligence.  When trying the 4.0.6 at my site everything looks the same as on your sandbox except I'm losing my css font style for some reason.  Are mod's to that file necessary?  Here's my MediaWiki.css currently.  The addition of $wgTreeViewIconMagic will be sweet :) --Cooknn 11:13, 12 September 2007 (UTC)

There is a slight change to the css structure (dropping the tr.tree-row class and adding td.tree-text and td.tree-icon, my css is as follows: --Nad 12:23, 12 September 2007 (UTC)
 * I updated the CSS slightly again after fixing a bug preventing multi-line items from working properly. --Nad 00:53, 13 September 2007 (UTC)
 * I've got the latest CSS (slightly modified) up at daniel.cook.name. Looking good. I found some icons to work with my family tree.  Here they are [[image: Dcmale.png]] [[Image: Dcfemale.png]] [[image:Dcouple.png]] .  I'll use the male and female icons for descendants regardless of whether there are children or not.  If there are, when opened I'll display the couple.  That should work, right?  Heh.  Sorry man.  I hope I'm not being difficult :P --Cooknn 01:24, 13 September 2007 (UTC)
 * No worries, tree-view's come a long way thanks to your feedback ;-) --Nad 02:33, 13 September 2007 (UTC)

Breaks Live Preview
Hi, Nad. I know I can't rightfully expect that you would support an experimental MediaWiki feature, but here goes at least making you aware. I have MW 1.11.0 on my computer, and am preparing it to be launched as a wiki for a project I'm doing with some friends. I just discovered the Live Preview function and tested it, and it works quite well, except (it seems) when the page being previewed contains a tree with more than one root in it, at which point the returned text is cut off. Looking at what I'm actually getting "back" from my computer as a result of the POST, I notice that it appears to include all the text, but the script isn't displaying it all. I'm no AJAX whiz, so I was wondering if you could track this down?
 * Thanks for the great extension; aside from this, it works great! — Tuvok[Talk/Contribs] 04:47, 17 September 2007 (UTC)
 * Interesting problem, I'll check out the live-preview with tree on my new 1.11 install soon --Nad 07:36, 17 September 2007 (UTC)
 * Yay, I had a problem that was interesting... :D Just being silly; thanks for the quick response! Looking forward to seeing input from a developer on this. — Tuvok[Talk/Contribs] 09:06, 17 September 2007 (UTC)
 * Unfortunately I haven't been able to get the live-preview to work in either 1.10 or 1.11 and there's no docs on it - did you do anything other than set $wgLivePreview to true in LocalSettings? --Nad 03:54, 20 September 2007 (UTC)
 * Let's see... I could post my configuration file. I'll create a sanitized version and post it to a website I have with Google. You'll find it at http://voyagerfan5761.googlepages.com/LPSettings.php
 * I don't think I changed anything but the one variable, but my setup was heavily customized as it was, so something else might need to be changed. If you've disabled $wgUseAjax, that'll definitely block LP. — Tuvok[Talk/Contribs] 00:16, 21 September 2007 (UTC)
 * Oops, I didn't realise you had to turn it on in your preferences :-/ I'll be able to check out the tree problem soon --Nad 00:48, 21 September 2007 (UTC)
 * I just did a test of live-previewing a page with a tree in it and it works except a minor bug which hides some of the bottom of the tree behind the preview... in what way is your live-preview breaking, is your tree the latest version? and can this bug be viewed or is it intranet? --Nad 00:54, 21 September 2007 (UTC)

(clear indent) I have version 4.0.6. What I'm seeing is when a tree with multiple root nodes is previewed, the second root is the last element displayed (sometimes with its text truncated) and all the preview text after it is also chopped. I can post a screenshot, too, if you like. Should I take down the config file?

Unfortunately, the wiki is indeed an intranet. Technically, that is. Only I use it, on one computer. But it will be put up on the Internet some time, with restricted access, because it's for a project I'm doing.

It seems that this could perhaps be an issue with the LivePreview JavaScript and yours conflicting, given that things are truncated. Maybe, if you have Firebug in Firefox, you can look at the changes to the DOM in real-time when you preview a page and see if it's conflicting with something. Thanks for the attention! — Tuvok[Talk/Contribs] 10:25, 21 September 2007 (UTC)
 * yes I'm getting that same thing, at first I thought it was just being half hidden behind the textarea, but then when I checked in firebug I found that only part of the html was being received by the ajax request. I then checked the live preview on some other content which was not treeview related and found that also was being chopped. I believe that the live-preview code is deliberately imposing a maximum on the amount of content it retrieves. I'll check the live-preview code soon and confirm. --Nad 11:41, 21 September 2007 (UTC)
 * I see I neglected to mention that I preview after the edit box... whatever, it doesn't matter (or shouldn't). I think it can be narrowed down to a conflict or bug in preview.js or EditPage.php. You agree? — Tuvok[Talk/Contribs] 15:07, 21 September 2007 (UTC)
 * I'm not sure but it seems to be done on purpose I think. I can't find anything in the live-preview code which is doing it, but I still have to check the ajax code. If it's done on purpose then there should be a setting which can be adjusted to allow a larger maximum. --Nad 20:19, 21 September 2007 (UTC)