Menu order issue

kona

Member
Occasionally we run into the issue where multiple menu items have the same menu order (see attached screenshot).

We have lots of tables, lots and lots of views (including active views that are suppressed from showing up in the menu with settings in our custom_config file), and many custom pages.

It is extremely difficult to find the duplicate number causing the problem when the menu order numbers are configured across several different screens (Tables / Views / Custom pages), and the data on these screens is not sortable by menu order.

It would be really helpful if the error message could state which menu entries are clashing, or at least which menu order number has been used more than once.

In the interim, Eugenio, is there an SQL query I can run directly on the database to extract this information about clashing entries? (I can do this directly on the database, I don't need to do it in DaDaBIK).

Thanks!
 

Attachments

  • MenuOrderBug.jpg
    MenuOrderBug.jpg
    154.6 KB · Views: 2

kona

Member
PS It would probably also be helpful if any views that have been manually excluded from the menu, using the $menu_hidden_tables config setting, could be hidden from the "Pages based on Views" list (or perhaps displayed in a second, separate table on the same page).

This would help to disambiguate actual menu entries from disabled possible menu entries. (At the moment, for example, we have 23 manually disabled tables and views, and we are going to end up with many more. This makes the Pages section more difficult to use, because it's full of views and tables that we don't really need to see there.)
 
Last edited:

deep64blue

DaDaBIK Guru
I've been meaning to post about this as well!

You might find this query helpful:-

SQL:
SELECT
    COALESCE(`alias_table`, `name_table`) AS `label`,
    CAST(`name_table` AS CHAR)            AS `target`,
    `allowed_table`                       AS `allowed`,
    `menu_order_table`                    AS `menu_order`,
    `menu_parent_table`                   AS `menu_parent`,
    COALESCE(`separator_before_table`, 'n') AS `separator_before`,
    'table'                               AS `item_type`
FROM `dadabik_table_list`

UNION ALL

SELECT
    `link_static_page`,
    CAST(`id_static_page` AS CHAR),
    1,
    `menu_order_static_page`,
    `menu_parent_page`,
    'n',
    'static_page'
FROM `dadabik_static_pages`

ORDER BY `menu_order`, `label`;
 
Last edited:

kona

Member
I've been meaning to post about this as well!

You might find this query helpful:-

SQL:
SELECT `name_table`, `allowed_table`, `menu_order_table`, `menu_parent_table`, `separator_before_table` FROM `dadabik_table_list` WHERE 1

Oh thank you, that did the trick perfectly and gave me a sortable column to help find the duplicate. (I then just changed the duplicate number in the actual database.)

Interestingly, it was the dadabik_errors table that caused the problem (ie had a duplicate menu order). I definitely didn't set that one!
 

kona

Member
The same problem with dadabik_errors occurred on my staging server too. In both cases, the allocated menu order was 1002 which already existed.
 

eugenio

Administrator
Staff member
Hi,
you are right, the message should specify which are the items with same order. It should be a small fix, I will add it to the next release.

About the dadabik_errors position, for historical reasons dadabik_users and dadabik_groups got position 1000 and 1001 so dadabik_errors gets position 1002, my assumption was that 999 menu items were more than enough but maybe I was wrong? :oops:
 

kona

Member
Yes we don't actually have >1000 menu items (yet) ;)

When controlling order with explicit numbers, I never use sequential numbers - otherwise I end up having to re-number all the subsequent entries when wanting to insert a new item in the middle. (This is a wariness I have gained from managing multi-forum discussion sites, accounting charts-of-account, etc etc).

Our menu has different sections, and each one gets a different number range x00-x99, with non-sequential numbers within that range.

I wasn't explicitly using the 1000s range for our own items, but some items seem to have been autocreated there.

Thankyou for the forthcoming change, that will be very helpful.
 

deep64blue

DaDaBIK Guru
some items seem to have been autocreated there.
Because the id for static pages is an auto_increment

SQL:
DESCRIBE `dadabik_static_pages`;

id_static_page    int(11)    NO    PRI    NULL    auto_increment 
link_static_page    varchar(255)    NO        NULL     
type_static_page    varchar(10)    NO             
file_static_page    varchar(100)    NO             
content_static_page    text    NO        NULL     
menu_order_static_page    int(11)    NO        1     
menu_parent_page    varchar(500)    NO        top     
enabled_static_page    int(11)    NO        0     
href_link_static_page    text    NO        NULL     
separator_before_static_page    char(1)    NO        n     
is_homepage_static_page    char(1)    NO        NULL     
icon_static_page    varchar(255)    NO
 
Last edited:

deep64blue

DaDaBIK Guru
When controlling order with explicit numbers, I never use sequential numbers - otherwise I end up having to re-number all the subsequent entries when wanting to insert a new item in the middle.
This is my scenario as well.
 
Top