Wrong Cookie Name of Menus

posts: 15

Hello it's me again.

I tried to get the Option "Cookie Menu" to work. After different trys and almost a day working on it I found the problem.

Tiki Wiki trys, in the /lib/menubuilder/menulib.php to get the cookie like this:
$ck = getCookie('menu'.$params'id'.'__'.$option'position', 'menu');

With a easy to use tool from chrome, called Cookies, I was able to look at the cookies and refresh them on the fly.

The cookiename is:

So, what I did was, i changed the string to:

No my menus are still open when i change the site.

More informations:
I use the current svn Version (14.1 i think)

Hope that this is really a bug, and with my code it's fixable

posts: 15

I tested different cases and i noticed, that with my solution, the sub menus don't get openend, even if they have a cookie, it seems that the 

elseif ($option'type' == 's')

is not applied to the submenus.


I removed the if statement as a workaround, we use cookies everywhere for the menus, so in our case it's okay.


And another information, which could be useful, we use structures for the menus, not menus themselfes.

posts: 1561 Germany

Hi Griessbrei,

did you check, if you face a "overflow:hidden" issue in the css, which could be fixed with "overflow:visible" as parameter for the relevant ss selector?



posts: 15

I don't think that this belongs to my problem, or to the bug.


What Tiki Wiki does when you click a menu:

  • you click a menu entry
  • the menu entry opens
  • tiki wiki creates the cookie "Menu"
  • tiki wiki inserts the open menu point into the cookie like:


What Tiki Wiki does when you reload the page:

  • tiki wiki loads all menus
  • it checks every  menu entry, if there is a cookie like:
    • menu . menu _ id _ location _ params
  • if there is something like this, he copies the params
  • then, when the param is c, he sets the css to "display: none" and when the param is  o he sets, in the smarty template, the css to "display: block"

I wrote the bug in bold. He creates a cookie like menu.menus and than looks for a cookie like menu.menu which, of course, he can't find. It's in my opinion a typo. And, as I wrote, after i added the "s" when he looks for the cookie, he is able to find it, and it works like described.


What  I did to find the problem is the check, what the php code gets from the cookie, and it was always "undefined". I don't think that it has anything to do with scrollbars or hidden overflows.

It is simply, that php cannot read the cookie, so that "display:none" is set in the /template/tiki-user_menu.tpl line 84. There, smarty checks if $open is set to "inline".

$open is defined on line 37 in the same file. There, if $chdata.open is defined and $chdata.open is true, than $open is set to "inline", else it is set to "none".


And $chdata.open is set using the cookie, which php isn't able to get because of the typo. I hope now it's clear what i wanted to say. :-)


posts: 20 United States

Not sure this is related, but I have had major headaches with the very same line of code. I use structure as a menu and on every page I get dozens of php warnings:

PHP (5.5.33-1~dotdeb+7.1) NOTICE (E_NOTICE):
File: lib/menubuilder/menulib.php
Line: 468
Type: Undefined index: position

Line 468 is the one you fixed. I changed "menu" to "menus_" but there is no difference in the errors. I also turned off menu cookies, but as far as I can tell there is no difference.

posts: 20 United States

And the problem persists after upgrading to Tiki 15, and running on a different server with php5.5. Again, I think this is related to using navigation structure menus. Without those, I don't really understand how you can make a user driven wiki where the content shows up on the menus.

PHP (5.5.33-1~dotdeb+7.1) NOTICE (E_NOTICE):
File: lib/menubuilder/menulib.php
Line: 468
Type: Undefined index: position

posts: 1817 Catalan Countries

Thanks GriessbreiLP and Doug Higby:

Can you please post a bug report at the bug tracker?:

And create a show.tiki.org demo instance to reproduce the issues there (whichever ones you are not able to fix)
For structures, you can easily recreate a basic setup in the show.tiki.org instance by means of applying the "Structured Master Documents" profile (from the profiles Wizard), and tweak the site to have the module menu fed from that structure. (just a proposal). See:

And of course, if you know how to fix a bug, please go ahead, request commit access and commit it, for the sake of Tiki's health!
See: https://dev.tiki.org/Commit


Xavi (a big fan of structures in Tiki, and navigation menus based on structures and I agree that we need them as bug-free as possible!)