Category: Menu

{syntax type="tiki" editor="plain"}
It used to only take checking a checkbox to create a beautiful horizontal menu instead of the horrible, default vertical menu on the left side of the page.



Now it is a complete mystery to me how this is accomplished. I have tried it at OpenSourceCMS.com only to get marginal results.

The module freetags should have an option to disable the display it as a menu item in the main menu.

{syntax type="tiki" editor="plain"}
Since tiki-9.1 opening links in new page stopped working
http://doc.tiki.org/Menu#url_-_attributes_target_rel_..._

{CODE()}http://someurl" target="_blank{CODE}

Turning on the following does not seem to work
*"Allow HTML in menu option names and URLs"
*"REALLY allow HTML (INSECURE)"

I turned this on before but with some upgrade it seems to have been turned of again.
Although it is turned off in tiki-8.5 and tiki-9.0 it does work.

Please ad a option to open links in new page in "Create menu option" or fix the above.

On doc.tiki.org/Installation, there is a link to doc.tiki.org/tiki-index.php/page=Installation

{img fileId=54}

And then, this page is broken, and it has many new links to index, most of which are invalid.

{img fileId=55}


Another example:
{img fileId=63}

{syntax type="tiki" editor="plain"}
When I place 2 menu modules under eachother, the second one doesn't show up.
And I can't figure out why. When I place something between the modules (e.g. Switch Language), all 3 show up.

When I view the source code of the generated page, the second menu has a display:none value. So I know the problem does not lie within the css file.
{CODE(caption="source" wrap="1" colors="htmlmixed")}<div title="Module Execution Time 0.011s" id="module_20" class="box box-menu cssmenubox module">
<div id="mod-menul1" style="display: block;" class="clearfix box-data"></div>
<div class="box-footer"></div>
</div>
<div title="Module Execution Time 0.004s" id="module_21" class="box box-menu cssmenubox module">
<div id="mod-menul2" style="display: none;" class="clearfix box-data"></div>
<div class="box-footer"></div>
</div>{CODE}

Modules have been set with decoration=n, notitle=y.
And the menu type=f. Though neither option has an effect on the problem.

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

{syntax type="tiki" editor="plain"}
Even with the feature turned off (being able to assign an icon to each menu item), when I look at the page source I see many lines of JavaScript containing the Font Awesome icon information for the icons that can be used by the feature. This doesn't affect the interface, but it seems like more unneeded data to transfer. At the April 2023 Roundtable meeting we talked about features that aren't activated shouldn't load scripts that won't be used. This looks like an example of that.

Menus items can have
Name
URL:
Sections:
Permissions:
Group:
Type:

We need an extra option for the language. Using the nifty lang & notlang as below gives more flexibility:
{CODE()}
{LANG([not]lang=>code[+code+...])}text{LANG
{CODE}

In the URL, it would nice to [tiki-view_tracker_item.php?itemId=948|be able to use variables]

URL:
{CODE()}
tiki-index.php?page=BogusPage{lang}
{CODE}


Name:
{CODE()}
{tr}my translated text{/tr}
{CODE}

There is a table in the database which seems unused.
tiki_menu_languages

Related:
*{wish id=521}
*{wish id=3030}

When using phplayer menu system, using a sorted level 0 menu item - the msnu options under that sorted level are not sorted. This option works fine if your menu is not using phplayer, but once phplayer is used, it does not sort.

Error message:

LayersMenu Error: setMenuStructureString: empty string.
Halted.

Main app menu in side column not translated anymore

Site lang changed to spanish, for instance, and the main application menu shown in the side column is still shown in English. The rest of Tiki insterface seems to be shown as translated (provided that the strings are trnaslated, of course).

But the basic strings in the main app menu are mostly translated since years ago, and they are nowadays shown always in English.

and add in the menu like the other features.

[15:41]<ohertel> marc, what's tiki mobile? :)
[15:42]<damian> the HAWHAW interface
[15:42]<damian> for WAP, PDA, and VoiceTiki browsing
[15:42]<marclaporte> de.tikiwiki.org/tiki-mobile.php
[15:43]<marclaporte> you have this on without you knowing
[15:43] *** marclaporte sets topic for #tikiwiki : http://dev.tikiwiki.org/tracker5 For the next 1-2 hours, please keep all discussions focused on 1.9.0
[15:43]<ohertel> ah that one. :)
[15:43]<ohertel> marclaporte: so what you want for it? perms?
[15:44]<marclaporte> naw, just on / off
[15:44]<marclaporte> from main admin panel
[15:44]<ohertel> is only 1 entry in the prefs table
[15:44]<ohertel> no biggie
[15:44]<marclaporte> perfect!
[15:44]<ohertel> so it needs no read db change
[15:45]<ohertel> just a feature_mobile = y/n :)
[15:45] *** ohertel doing update and starting debugger.
[15:45]<marclaporte> in theory default should be on be y by default to respect 3 rules, but since it isvery specialized, you can put n by default. Your choice!
[15:46]<damian> respect the rules.
[15:46]<damian> it causes less hassle for everyone that way
[15:46]<cpw> I'm going to submit what I have for my Japanese translations then
[15:46]<ohertel> we switch it off and write that to the release notes.

maketoc is often used in a div like this:

{CODE()}{DIV(float=>right,width="200px")}^{maketoc}^{DIV}{CODE}


How about making a param for this?
{CODE()}{maketoc float=left}{CODE}

Related: {wish id=1045}


dev.tw.o has too many items on the menu. Using ((doc:Module MenuPage)), so we would need CSS menu or Phplayersmenu.

But if so, we lose the version history, ease of contribution of a menu in wiki wage.

How about the best of both worlds?

Perhaps a menu using a special code around the hierarchy (with bullet points), it can be caught and used by css menu.

This tracker item could not be found

--The new 'visual' menu structure in tiki 18x is missing the 'position' number. It is only available when clicking on the 'I' (information) link which brings a pop-up. This is time consuming because I will have to go into many of them, and, than remember (or write down on a piece of paper!) how to re-number them if necessary (to add space).

I rely on this to give me an idea of how much spacing I should leave.

The best option would be to include it directly in the new visual information bar.

Not so good, but better than nothing - include the position number in the 'mouse-over' (but not click) feature.--

__UPDATE (an hour or two later):__

New visual Menu's in Tiki 18 = FRUSTRATION, FRUSTRATION, FRUSTRATION.
very, very buggy - definitely regression here (not business grade / production grade).

Attempted in vain to get my menus the way I need them, no luck, they are still screwed up.
They are partially listing the levels correctly, but visually showing them differently. And the result is the menu (horizontal menu, in the 'Top Bar' is showing incorrectly.

here is a screenshot: {img fileId="1165" thumb="box"}

The new interface is pretty straightforward, I tried several times over several hours (including clearing cache and re-indexing) but the menu structure just keeps setting back to the way 'it' want it.

I only noticed the menu structure was incorrect after upgrading from 17.1 > 18.1

I will take a fresh look tomorrow, maybe I missed something, maybe I have to delete my entire menu structure and start over (don't really want to),

If no changes or omissions on my part, I will be reclassifying this as: BLOCKER (now changing from Feature Request > Bug:Regression)


Thanks,
Mike

In a superfish menu, a menuSection (parent) item followed by an option (child), then a "separator", then another option, will put the menuSection and the last option on the top level, and the first option will be below the menuSection. This is the right way. But in a Bootstrap menu, both of the options will be under the menuSection, with the separator ignored.

Related:
[wish1887|Modules use should be restrictable with standard permissions]


Read from bottom up:

2008-05-27 00:46:33 Norrin_Rrr mmh
2008-05-27 00:45:57 prozaq you could probably modify that
2008-05-27 00:45:39 prozaq that displays all categories
2008-05-27 00:45:32 prozaq Norrin_Rrr: in 1.10 there is a module called "categories"
2008-05-27 00:41:25 Norrin_Rrr will try it
2008-05-27 00:41:16 Norrin_Rrr the example in the documentation says its for features not sections that s weird
2008-05-27 00:40:51 prozaq oh - yes I think so, but Ive never tried it
2008-05-27 00:40:34 prozaq beg your pardon?
2008-05-27 00:39:45 Norrin_Rrr the section parameter in the menu its to set wich section (wiki/cms/forums) will display the menu ?
2008-05-27 00:38:54 Norrin_Rrr that should be doable
2008-05-27 00:38:19 prozaq so you should be able to copy some of the code from the tiki-browse_categories pages
2008-05-27 00:34:38 Norrin_Rrr yes
2008-05-27 00:34:16 prozaq but isnät that when you are creating a module from scratch?
2008-05-27 00:34:07 Norrin_Rrr i am not sure but there seems a possibility for hacking ?
2008-05-27 00:33:44 Norrin_Rrr "So if you know about Smarty template editing you can use any Smarty tag in your user modules."
2008-05-27 00:33:05 Norrin_Rrr ah okay i am at the module documentation, and its seems there are some conditionals with TW1.10 for modules but unfortunatly none for specific category
2008-05-27 00:32:56 *** franck has left #tikiwikin
2008-05-27 00:29:43 *** kiilo_ has quit IRCn
2008-05-27 00:28:34 Suprano even more if you paste in in a formular :D
2008-05-27 00:28:15 Suprano hmmm copying 4mb text slows down the pc
2008-05-27 00:28:10 Norrin_Rrr and display a menu that gather the various item of this category
2008-05-27 00:27:59 prozaq marclaporte: earlier I posted a bug to the tracker item Bugs & Wish list on dev.tikiwiki.org but how do I post to the "All Bugs" section or the "Release 110 taged bugs" ? section
2008-05-27 00:27:38 Norrin_Rrr yes
2008-05-27 00:27:30 marclaporte the goal would be to show a certain module only if current item (page, etc) is in category X ?
2008-05-27 00:26:07 prozaq eek...
2008-05-27 00:25:45 Norrin_Rrr its seems it works for feature enabled on the site but not for category (?)
2008-05-27 00:25:16 Norrin_Rrr yep i have the doc about the menu under my nose but i don't understand the section parameter
2008-05-27 00:24:39 marclaporte hi prozaq
2008-05-27 00:24:24 prozaq marclaporte: hi
2008-05-27 00:24:19 prozaq but Iäm not sure a specific category would fall under that
2008-05-27 00:23:57 prozaq it seems that you can tell a module which "section" it should appear in
2008-05-27 00:22:37 Norrin_Rrr for now 1.9.9 but 1.10 soon i hope :)
2008-05-27 00:21:20 *** marclaporte has joined #tikiwikin
2008-05-27 00:20:45 prozaq which version are you using norrin?
2008-05-27 00:18:38 Norrin_Rrr i am not sure, a module with a menu would be nice
2008-05-27 00:18:08 prozaq a menu item or a module with menus?
2008-05-27 00:17:29 Norrin_Rrr and hello everybody ;)
2008-05-27 00:16:39 Norrin_Rrr Is it possible to show a menu only when a user reach an item belonging to a given category ?
2008-05-27 00:15:24 *** Norrin_Rrr has joined #tikiwikin







Sylvie has recently added some useful code in BRANCH-1-10 so we can use categories as conditions in templates (.tpl)

[http://dev.tikiwiki.org/Hello+World#To_do_something_specific_in_a_template_ex_tiki_tpl_conditional_to_the_current_item_being_in_a_category_Ex_different_header_picture_|related info in Hello World]

The menu cache can't create the directory at /templates_c, when the user loged has a lot of assigned groups. The name of the directory are the concatenation of the groups names.

Hello,

I already reported my discovery in the forum. But here again for the formal way.

The problem:
If you want to use the feature "cookie" on a menu, it will not work.

Test Case:
Open up a menus sub structure, click on a link, and the menu is collapsed on the new site.

Reason:
tiki wiki checks if the menu cookie "menu.menu_structure_pageID" is existing and if so, it looks if it is opened or closed.

But, the cookies name is not "menu.menu" but "menu.menus".

Where is the problem:
/lib/menubuilder/menulib.php:468
$ck = getCookie('menu'.$params['id'].'__'.$option['position'], 'menu');

should be changed into:
$ck = getCookie('menus_'.$params['id'].'__'.$option['position'], 'menu');


Another problem is, that this only works for a flat hierachie (like in the bootstrap menu), but if you want to work properly in all menus, you have to change the else if statement too.
Same file, line 464:
} elseif ($option['type'] == 's') {

on every lower level, the option.type is not set. We commented it out, so we have a simple } else { and it works.

{syntax type="tiki" editor="plain"}
Menu dropdowns (with Smartmenus turned on) are opening upward when there is no need to, such as in the default system menu in the left column, when there is plenty of space to open in the normal downward position. This is caused by the class "dropdown-menu-bottom" in the menu code. Could this class just be removed?

In my experience (Windows 11, Edge and Firefox browsers), Smartmenus dropdowns will open upward when the parent item is near the bottom viewport edge and there isn't enough room for them to open downward. I thought this problem was resolved a few months ago but it's back in master currently.

__Looks like this only happens for menus that have got the "Wiki parse" option set__

When a menu is exported the resultant CSV file contains html (and other end of line characters?) for the Name field

Particular difficulties occur when the option to wiki parse the label is set 'on' ie the Name field may have something like:

~np~Home {img src="img/icons/home.gif" height="12" width="12" alt="Image"}~/np~

so that a small icon is included - but when this is exported it appears as:

~np~Home <img src="img/icons/home.gif" height="12" width="12" alt="Image" class="regImage pluginImg" />~/np~

with additional spurious end of line characters that do not show up in the Excel spreadsheet

Similar end of line characters appear on all simple text entries in the Name field.

The difficulty arises when you want to reimport previously exported data and this then causes corruption

It looks like the parsed output of the Name field may be being exported instead of the simple stored value ?

I have been trying all weekend to get a menu item to be visible and active for an anonymous user.
The uri is elkstudy.com.
There are four items in the menu. Here is the .csv:
"optionId","type","name","url","position","section","perm","groupname","userlevel","remove"
203,"o","Home","tiki-index.php",2,"","","Anonymous",0,"n"
205,"s","About EMG","",3,"","","Anonymous",0,"n"
208,"o","Introduction","tiki-index.php?page=Introduction",4,"","","Anonymous",0,"n"
207,"o","Purpose","tiki-index.php?page=emgPurpose",5,"","","Anonymous",0,"n"
204,"s","FAQs","tiki-list_faqs.php",8,"feature_faqs","tiki_p_view_faqs, tiki_p_suggest_faq,tiki_p_view","Anonymous",0,"n"
206,"s","News","tiki-view_articles.php",10,"feature_articles","tiki_p_read_article, tiki_p_topic_read","Anonymous",0,"n"

I made FAQs work only by pointing to a Wiki page, which is OK.
But I cannot get the item to be visible either for anonymous or registered users (only admin) so that anyone can get to the articles section, which I want to be a news section.
I have looked into a theme problem (same issue with any of a dozen themes) I'm using a variant of absE.
I have tried plain menus {menu id=45} and the three variations on the PHPLayers (fixed, etc.)
I have tried a simple flat arrangement (all section0).
I have tried attaching a public category to all menu items.
I have spend this weekend chasing around for a solution but I haven't found one.
I would prefer to link to the FAQs module instead of building Wiki pages, but I couldn't get that to work either.
Thanks
db

When "site menu bar" is selected under "site identity features", and a menu is specified in the "tiki-top_bar.tpl" file, as below:


{if $feature_phplayers eq 'y' and $feature_siteidentity eq 'y' and $feature_sitemenu eq 'y'}
<br><br>
{phplayers id=44 type=horiz}
{/if}


If the menu does not have any options that are permitted by the current user (no sections to display - prior to loggin in to site, for example), the system crashes because of an empty string.

To recover it is necessary to manually edit the tiki database to add a menu section that has no permission requirements.

In the example above, menu id 44 has no sections or options that are viewable by unregistered users. When the site is entered, tiki halts because of an empty string, apparently because there is no menu selection possible for the user (not logged in yet.)

After upgrading to 1.10, php layers menus from 1.9 are gone from site identity.

Apparently, there are also reports of display of horizontal CSS ("suckerfish") menus not correct. Tag isn't setting horizontal style or getting css/cssmenu_horiz.css so top-level items display vertically rather than horizontally.