As you see in the screenshot, there are many nodes, which can't contain threads (also not there childs)
Even pages are shown in the form (and ATM it's not possible to search for text in them..)
XF_Model_Node::getNodeDataForListDisplay needs IMHO a big refactoring.
It's too unflexible (see also http://xenforo.com/community/threads/select-nodetree-with-nodetype-limit.14555 )
I'm not sure if i understood the node system complete, but haven't you introduced this, to make it easier to seperate,handle & show the different content types?
If yes, => one of the biggest problems is the way, how you select & output the nodes see also (this problem that we have: http://xenforo.com/community/threads/select-nodetree-with-nodetype-limit.14555/ )
I know there's a problem with the child nodes( http://xenforo.com/community/threads/node-permissions-page.12615/ ), but IMHO we/you need to find a solution for this (or they are useless for add-on coders).
For example, will really anybody have an so complexe nodetree with so many childnodes and different nodetypes as childes?
name7 pagename8 category
That's one of the scenarios, why it would be necessary to show all parents of name14 in the search form, BUT this would make a big, confusing, not userfriendly select list,.
All this things will be a horror with > 50 nodes, and as i said already, if the nodesystem is that, what i think, and more add-on coder understand & use it, people will get really soon > 100 noders..
With all categories, forums, article sections, gallery categories,linklist categories, i'll reach soon > 300 nodes ( which shouldn't be a problem said mike http://xenforo.com/community/threads/performance-with-custom-content-nodetypes.12904/ )
(hope you understand what i mean, i've tried to describe it so good as possible^^)
29.6 KB Views: 44