Matte
New Member
Posts: 92
inherit
264111
0
Oct 21, 2024 20:35:25 GMT -8
Matte
92
April 2021
matte
|
Post by Matte on Jun 8, 2021 20:36:52 GMT -8
I'm looking for a code to:
1) get rid of the ellipsis in the nav tree whenever there are 4+ steps. For example, on this forum: ProBoards Support > Coding Development and Design > Coding Help > Code Submissions "Coding Development and Design" becomes "..." even though there is ample space to include the full text in the nav tree. I'd like to eliminate the ellipsis and have the full board name display instead.
2) expand the number of "steps" that show in the nav tree to more than 4. For example, on this forum: ProBoards Support > General > General Talk > The Game Board > Proposing A New Game "General" and "General Talk" are combined and placed into the "..." step, rather than just expanding the number of visible steps to 5. I'd like to eliminate the grouping of steps if possible.
|
|
inherit
Official Code Helper
65613
0
1
Oct 22, 2024 1:56:19 GMT -8
Chris
"'Oops' is the sound we make when we improve"
9,018
December 2005
horace
RedBassett's Mini-Profile
|
Post by Chris on Jun 8, 2021 21:42:09 GMT -8
|
|
Matte
New Member
Posts: 92
inherit
264111
0
Oct 21, 2024 20:35:25 GMT -8
Matte
92
April 2021
matte
|
Post by Matte on Jun 8, 2021 22:09:49 GMT -8
Don't know how I didn't find that thread through my search. Unfortunately, the code provided doesn't seem to work anymore. EDIT: I found this solution from Brian , which solves my #1 issue until the #2 issue occurs and breaks it. So it works until you get to 5 or more steps in the nav tree, at which point the second step again becomes a grouping with the ellipsis label to force it back down to 4. Is there a way to allow more than 4 steps in the nav tree? * per the thread I linked, the current thread title being displayed was also added to the code, which does then allow for 5 steps in the tree, and makes the third step the ellipsis grouping instead of the second step.
|
|
inherit
Official Code Helper
65613
0
1
Oct 22, 2024 1:56:19 GMT -8
Chris
"'Oops' is the sound we make when we improve"
9,018
December 2005
horace
RedBassett's Mini-Profile
|
Post by Chris on Jun 8, 2021 23:55:01 GMT -8
Don't know how I didn't find that thread through my search. Unfortunately, the code provided doesn't seem to work anymore. EDIT: I found this solution from Brian , which solves my #1 issue until the #2 issue occurs and breaks it. So it works until you get to 5 or more steps in the nav tree, at which point the second step again becomes a grouping with the ellipsis label to force it back down to 4. Is there a way to allow more than 4 steps in the nav tree? * per the thread I linked, the current thread title being displayed was also added to the code, which does then allow for 5 steps in the tree, and makes the third step the ellipsis grouping instead of the second step. Ahh yes, the microdata structure the script looks for to identify individual components of the tree has indeed changed since that script was released, try this updated one <script> /* Navtree Expansion Module - INSTALL IN GLOBAL HEADER (last updated: 21 June 2021) */
$(function () { var menu = pb.data('pop_menu_structure'); var root = menu.menuStructure var submenu = null; var ID=0; $('#nav-tree a:contains(...)').each(function (i, e) { if ($(e).attr('itemprop') == 'item' && this.title) { if(this.title.indexOf(">") === -1){ $(this).find('[itemprop="name"]').html(this.title); addMenu($(this).parent()) }else{ let $t = $(this),$branch = $t.closest('.nav-tree-branch'), $n=$(); this.title.split(/\s*\>\s*/).forEach((_e,_i)=>{ submenu = submenu || root[menu.startingMenu]; if(_i==0){ $branch.find('[itemprop="name"]').html(_e).parent().attr('title',_e).attr('href',findHREF(submenu,_e)); addMenu($branch) }else{ $n = $n.add((()=>{ let $clone = $branch.clone().attr('id',$branch[0].id+'.'+_i).addClass('clone'); $clone.find('[itemprop="name"]').html(_e).parent().attr('title',_e); $clone.find('[itemprop="position"]').attr('content',-1); $clone.find('a[itemprop="item"]').attr('href',findHREF(submenu,_e)) addMenu($clone) return $clone; })() ); } }) $n.length && $n.insertAfter($branch) } } }) function findHREF(smenu,f) { var ret = null; $.each(smenu.items, function (x, o) { if (o.submenu) { if (root[o.submenu].title == f) { submenu = root[o.submenu]; ret = o.href; return ret } else { var r = findHREF(root[o.submenu],f); if (r) { ret = r; return r; } } } }) return ret; } function addMenu($nav_branch){ let nav_tree_menu_0 = $('#nav-tree-menu-0'), menu_config = nav_tree_menu_0.data('menu').options, menu_link =$('.popup_html').find('[href="'+$nav_branch.find('a[itemprop="item"]').attr('href')+'"]'), new_menu = menu_link.eq(0).closest('[role="navigation"]').clone().appendTo(nav_tree_menu_0.parent()).attr('id','nav-tree-menu-clone-'+nav_tree_menu_0.parent().find('>ul[id]').length), nav_link = $nav_branch.find('[itemprop="item"]'); new_menu = new_menu.find('>.state-selected'); let s = /\/board\/\d+\//.test(nav_link[0].href) ? new_menu.siblings().add(new_menu) : new_menu; new_menu = new_menu.closest('ul[id][role=navigation]').empty().append(s) new_menu.menu($.extend({},menu_config,{ button:$nav_branch, position: { of: $nav_branch, offset: ($.browser.msie && parseInt($.browser.version) == 8) ? '3 -1': '3 0', collision:'flipfit', at: 'left bottom', my: 'left top' } })); nav_link.attr('title',''); } }) /* June 10, 2021 @4:28pm GMT -0500 : Updated code to be in compliance with Google rich results guidelines (passes test) June 15, 2021 @5:55pm GMT -0500 : Updated hrefs on newly created branches June 21, 2021 @6:25am GMT -0500 : Added dropdown menus for newly created navigation tree sections */
</script>
|
|
Matte
New Member
Posts: 92
inherit
264111
0
Oct 21, 2024 20:35:25 GMT -8
Matte
92
April 2021
matte
|
Post by Matte on Jun 9, 2021 0:18:45 GMT -8
Ahh yes, the microdata structure the script looks for to identify individual components of the tree has indeed changed since that script was released, try this updated one This one works great! Thanks! Side note: I'm curious if there's a reason why the nav tree defaults the way it does. Seems odd that modifying code is required to make it look the way you'd think it should already look.
|
|
inherit
252032
0
Apr 26, 2024 23:51:41 GMT -8
Retread
Tribbial Pursuit.
5,017
January 2018
retread
|
Post by Retread on Jun 10, 2021 6:39:10 GMT -8
Ahh yes, the microdata structure the script looks for to identify individual components of the tree has indeed changed since that script was released, try this updated one This one works great! Thanks! Side note: I'm curious if there's a reason why the nav tree defaults the way it does. Seems odd that modifying code is required to make it look the way you'd think it should already look. We can only guess. Back in the day, the most common displays were much narrower than those of today. You probably had about 800px of width available for the nav-tree-wrapper AND the recent-threads-button combined. If there were a few levels of nesting in boards and sub-boards and the thread title had the maximum number of characters, it would require more width than was available and the overflow on the right would be hidden. I'm guessing the current design was meant to prevent that possibility.
|
|
Kami
Forum Cat
Posts: 40,201
Mini-Profile Theme: Kami's Mini-Profile
#f35f71
156500
0
Offline
Jul 24, 2021 11:48:29 GMT -8
Kami
40,201
July 2010
kamiyakaoru
Kami's Mini-Profile
|
Post by Kami on Jun 10, 2021 9:42:02 GMT -8
This one works great! Thanks! Side note: I'm curious if there's a reason why the nav tree defaults the way it does. Seems odd that modifying code is required to make it look the way you'd think it should already look. We can only guess. Back in the day, the most common displays were much narrower than those of today. You probably had about 800px of width available for the nav-tree-wrapper AND the recent-threads-button combined. If there were a few levels of nesting in boards and sub-boards and the thread title had the maximum number of characters, it would require more width than was available and the overflow on the right would be hidden. I'm guessing the current design was meant to prevent that possibility. I'm sorry, but "we can only guess" is a statement that isn't even remotely true. If you personally don't know, it's 100% okay to admit that! But you don't have to phrase it as if this is some elusive, unknowable ancient secret. Quite frankly there are those of us who a) have been using ProBoards for almost it's entire existence, b) who were here for the cutover from v4 > v4.5 > v5, c) who have or had professional careers in the web development space, or d) some combination (or all!) of the above. It is incredibly frustrating to see (incorrect) guesses being paraded as existing because it's not possible to know something, when the truth is much more simply that you don't personally have the knowledge or experience to speak to the topic. - V5 came out in 2013, not in Ye Olden Days™. During this time, the most common monitor resolutions were:
- 1280 x 1024 (usually desktop)
- 1366 x 763 (most common on laptops)
- resolutions above these sizes**
** about 36% of users used a higher resolution than these two stated sizes, according to W3Schools, if you wanted a more defined number.
The most common width for PB forums at a fixed width, immediately prior to v5 was approximately 900px; however, PB forums have—since v3—been a fluid (%) width of your viewport (the default was, and is currently, 90%). Your citation of "800px" hasn't been true since the early 00s, but even then it would have been mostly irrelevant for PB unless someone specifically opted to create a fixed width of that size or less. 800px width forums have been mostly phased out since approximately 2010, when 900-1100px width forums came in vogue (following the popularity of 1280px or wider resolutions).
- The style of navigation in PB's navtree (which is a secondary navigation) is called breadcrumb navigation. It is best practice for breadcrumb navigation to truncate the tree after a certain number of levels deep in the middle to avoid truncating the current page, as the best practice guidelines state to not truncate the current page title. This is particularly for SEO best practices, so the page title is not obscured when crawling the page & navigation tree itself. This particular version you see today, with a truncated "middle" path, did not exist prior to v5 (2013); as such, viewport width being 800px would have been almost completely irrelevant as users with that resolution were in the very small minority at that point. Moreover, you could only have one level of subboards prior to v5 — the issue of "few levels of nesting in boards and subboards" was simply nonexistent, as you could not go beyond 1 subboard deep.
- The participated button / module did not exist prior to 2013, so that would 100% not have been a consideration during the time when browser sizes were 800px or less.
In summation: "we", broadly, do know the answer to this. Lacking information or context on a personal level is not cause to state that "we" as a broad group are only able to guess. It's totally okay if you don't know the answer, but please, don't presume to speak for the "we" when you can only speak to what you know, and not to what other people might or might not know.
|
|