HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


Dynamic Tree Menu for Wiki Possible?

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#95547 (In Topic #19013)
Avatar

Honoured member


I will shamefully admit I have not fully researched the wiki yet, so this may be possible, but I would like to ask so no to get ahead of myself. Is there a way to have a CEDI (wiki's) tree structure automatically update a menu box on a side column? I am interested in making a wiki with relatively ease navigation, one expected to have many tiers and sub levels.
 
Ideally I would like to have a menu that expands and adds new links as new content is added to the wiki without the need to manual input or create each one. If this is already possible could someone give me a brief introduction of how to achieve it?
 
Thanks.

--Also
 
Is it possible to remove/disable posts all together from the wiki? I know you are able to hide them, but I'd rather it not be possible to post at all. I Know I can cheat and simply remove the make post link from the template file, but this isn't ideal.
 
--Revision History
 
I know Revision History is viewable in the admin zone, is it possible to translate that information to the actual wiki page? So that it can be shown the wiki article has undergone changes, by who, and possibly reference the exactly changes. I know this functionality does not currently exist, but would it be difficult to implement?


Last edit: by DivinityOne
Back to the top
 
Posted
Rating:
#95581
Avatar

1…

Only very basic.

This shows everything under the home category:

Code

[block="!!!site:cedi:type=misc:id=1" type="popup"]side_stored_menu[/block]
Unfortunately by everything, I don't just mean direct children. Deeper relatives are all shown as flat entries in the menu, not as popups.

For this kind of thing to work better we need to rearchitect the guts of ocPortal quite a bit:
0000142: Merged sitemap API - ocPortal feature tracker

2…

You'd need to template this.

3…

Don't confuse the CMS zone with the Admin Zone. They are separate for this kind of reason – it is perfectly okay and normal to give regular members access to certain modules within the CMS zone.
Also note this on tracker: 0000709: Add View Changes functionality to CEDI - ocPortal feature tracker


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#95583
Avatar

For this kind of thing to work better we need to rearchitect the guts of ocPortal quite a bit:
0000142: Merged sitemap API - ocPortal feature tracker

Just to be clear, for this kind of thing to work better universally across ocPortal in a tidy way, #142 is the solution. Obviously just to get this specific case to work could be done a lot quicker.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#95588
Avatar

Honoured member

Chris Graham said

For this kind of thing to work better we need to rearchitect the guts of ocPortal quite a bit:
0000142: Merged sitemap API - ocPortal feature tracker

Just to be clear, for this kind of thing to work better universally across ocPortal in a tidy way, #142 is the solution. Obviously just to get this specific case to work could be done a lot quicker.

What would a quote be for just the wiki modification? This funtionality to me is highly desired, but it cost VS convience in the end. Let me know.

Thanks
Back to the top
 
Posted
Rating:
#95589
Avatar

Honoured member

Just had a though for a quick and dirty fix actually. The wiki tree as is works fine for a menu interface and it auto generates. So I'm thinking something a bit odd here, it's quite the MacGyver fix actually.

Say I make a two column Wiki Zone, left menu column loads the wiki tree, and the right content column would be left open to load the wiki page content. It's not the most ideal thing, but it may do the job.

The wiki I plan to make is quite massive however and that brings up the question of the 300 children limit I saw listed in language. Does that mean a wiki can only have 300 pages in all (300 children from wiki home) or dose that begin one tier down?
Back to the top
 
Posted
Rating:
#95593
Avatar

300 would be direct children.

Regarding menuing, yeah that should work. I think you could use the main_include_module block on a panel with site:cedi:tree, and then template it. It's the SPLURGH templates,which generate the tree structure via a compressed data structure that we handle via Javascript code – so they're reasonably efficient in terms of bandwidth even for large trees.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#95621
Avatar

Honoured member

A quick test of that shows it has possibility, though its wrapping ability is minor. Deep sub tiers exceed the width of the column creating strange behavior. This fix will need quite a bit of arm twisting to work. I think the sheer amount of sub tiers is going to need a 'very' wide column or very small text. Theme wise neither case is ideal, so I am still interested in an actual dropdown menu block if you could quota me an estimate?
Back to the top
 
Posted
Rating:
#95660
Avatar

Hi,

I'll need to know a bit more in terms of required specs.

In particular, I assume you want multi levels of menu (if you didn't it'd be really easy to maintain by-hand anyway). Is there a limit on the number of layers? e.g. maybe you want up to 4 layers to show, via our popup menu type (i.e. 1st layer always visible, subsequent layers come out as the horizontal version of a drop-down menu).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#95674
Avatar

Honoured member

Sorry I used the wrong menu style term. I'd like a popup menu, where the first tier is listed and everything else is a sub branch. There will be about a dozen main tier entries, with categories that can go 4-5 branches deep.

I'd like a few custom links at the beginning of the menu though like a FAQ or Proper Use guidelines page, then the wiki tree, followed by the actual wiki links. If it would help I can provide the general menu structure so you see what I am attempting to achieve.
Back to the top
 
Posted
Rating:
#95675
Avatar

Oh, so you actually kind of need some items added on the front of the top level menu items? That wasn't something I had been considering at all. It's currently possible I think to splice generated menus under a sub-node in a specified menu, but not a group of them amongst others.

i.e. you can do like…

Code

A
B
C <contains forum tree underneath this>
D

or…

Code

<insert forum tree here>

but not like…

Code

A
B
<insert forum tree here>
D

So I'd need to consider this.

What I was really asking though, does the depth of the menu need limiting compared to the Wiki+ depth. If you made Wiki+ 10 levels deep, do you want to limit the menu to only go 5 levels deep?


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#95677
Avatar

Honoured member

I'd prefer the menu not be limited in how deep it could go. Since some areas won't go deep, but others depending on content might go fairly deep. It's not a uniform structure so I can't say where a menu cut off should take place. An option to mark a page saying "Final child to be on menu" Would be appealing, so its specific children would not be indexed by the menu. But still appear on the wiki tree.

I know that's a bit of a push for a feature, and I doubt easy to implement so the best thing to do is simply let the menu generate as deep as it has too and let me worry about keeping the wiki pages neat and organized so not to overwhelm the menu.
Back to the top
 
There are too many online users to list.
Control functions:

Quick reply   Contract

Your name:
Your message: