Certain Link List Categories Will Not Expand

My Link List has basically a 3 tiered heirarchy:

MainTopic
.....Subtopic1
.....Subtopic2
..........Document1
..........Document2

I have a situation where my first 15 to 20 Subtopics show me all the Documents they contain but then the last 2 Subtopics will not expand to show me their documents. It's as though I've reached some critical mass and it wants some config value increased.

It's not like there's a plus sign and nothing happens when I click it. It's more like "Hey buddy I'm not showing you any more".

My terrible solution is to find the ResourceID I want to link to in the tree in the left panel, write down the ID number, and then hand enter it with the brackets and tildes. Then its name will show up in the "Link List" area.

Did some searching here and in Google but no cigar.

Can someone help?

Thanks much ... Sam

We'll definitely need more information before there's anything meaningful to add.

How are you building the link list, are those resources (weblinks?)? What's your snippet call look like to build it?

Mark, I do web design for this client and when they had a MODx system built for them by a developer I inherited the responsibility of maintaining the host code, backing up the MySQL databases and pushing the staging site to the production site. I can author content and use the TinyCEA editor. I've become barely proficient enough to modify aspects of the site, making minor mods to certain plug-ins like AJAXSEARCH, various stylesheets, etc. Firefox's Firebug has become my best friend in understanding some of the page internals.

All this is to say that I'm not a MODx developer and don't understand the larger picture. Mark, I'm clueless about how to create a link list for use by TinyCEA and can't answer your question about the snippet call that builds the link list. I don't even understand your question "are these resources". To my knowledge the entire "link list" is nothing but CMS Resources. Clearly I'm referring only to the drop-down menu of link list resources for link selection, and not to the entire insert link dialogue box which of course can include weblinks.

My question focused only on the construct of the link list drop down since it was not showing child entries for two of the parent (container) entries and I have no clue why.

My intuition was to inspect the dropdown box using either "view source" or Firebug to see if I could spot a difference between the coding for a parent that has children and one of the two parents that is not showing its child resources. View source showed me nothing intelligible and not a single string of what was contained in the insert link dialogue. Firebug, on the other hand, revealed considerable html that was quite understandable. Actually, Mark, I was able to locate BOTH of the two subtopics without its children and found that their links are NOT present in the lengthy html form. This I just discovered now while I was preparing my response to you.

Mark, if you're still reading this, can you think of any way I can help you help me? Could there be anything revealing in the Firebug rendition of the html that I could look for?

Sorry if this is more than you bargained for. I'm Ok if you want to drop this thread and do something more promising with your time.

Thanks for your response ... Sam

This link list code for TinyMCE's "insert link" function is found in assets/plugins/tinymce/inc/tinymce.linklist.php and assets/plugins/tinymce/inc/tinymce.linklist.flat.php. Exactly how this is inserted into the "insert link" function I don't know, but those files provide the resource names and IDs to use for building the list.

Ok, a bit of digging determines that this is a feature of TinyMCE, and the list is provided by the specified source. In our case, that source is the above mentioned .php files.

http://www.tinymce.com/wiki.php/Configuration:external_link_list_url

[ed. note: sottwell last edited this post 14 years, 5 months ago.]

Susan, thank you for this helpful information. I'll look at those files.

Susan and Mark, I stumbled onto something interesting which should make the solution to my problem much more obvious.

Turns out the "missing children" for the two empty subtopics are not missing at all. They are in the link list but are associated with one of the other subtopics by mistake.

Now my question becomes much simpler and clearer:

Why does the link list show documents in different categories from the site tree? Are there any common or popular reasons for this type of "mis-sorting?"

Susan and Mark, I fixed the problem (I think) but I was totally shooting in the dark. Often intuition bails me out when I totally do not understand something.

I noticed that there were 8 major categories (not 15 or more as I had said initially) and I saw that 3 of them had the same menu index of 0. The other 5 had menu index values that were unique and not zero.

Of the 3 designated "0", one was getting all the others' children, and the other two were the ones in the link list that accordingly had no children.

I renamed the menu index of the 0's to 1, 2 and 3, the same order as in one of the web sites menus.

It is becoming apparent to me that MODx pays strict attention to the designated "parent" when it categorizes the items in the site tree,

It is equally apparent that the link list sort pays attention to both the designated parent AND the parent's menu index. So ... now that these 3 designated parents have unique menu indexes, their designated children are following them into the correct categories of the link list.

The Million$$ question is am I correct in everything I've just told you?

Also, would you agree with me that the link list sort is flawed?

Thanks so much for your interest. I look forward to your replies.

I've only taken a quick glance at the code for the link list, but I did notice that it does make use of the menuindex value. I haven't determined exactly how, though. This sounds like some kind of bug; menuindex should only apply after the parent/child structure has been determined.

All such code, for example the Manager resource tree, and Wayfinder, does in fact make use of the "parent" field; that's how the structure is built, and within that structure the items can be ordered by menuindex, create_date, pub_date, or even alphabetically by pagetitle or whatever other field the programming allows for.