Menu handling

[Illori]

The development team is considering ways to better handle the menu in future versions. Some have suggested

• storing the menu in the database where custom changes to the menu will not be overridden during upgrades
• Also they are considering some type of menu editor built into SMF

What do you all think?

[Robert.]

I don't use menu editors a lot, but it would be a great feature though. Especially because 10% of the support requests are how to create a new tab

[Joker™]

storing the menu in the database where custom changes to the menu will not be overridden during upgrades

But won't it be placing more pressure and queries on DB and specially when server is down, i.e when site is lagging and you are calling menu from database.

Also calling menu for everyone including guests from database doesn't sound good to me performance wise .

Also they are considering some type of menu editor built into SMF

That sounds like some cool feature to have.

[lurkalot]

I love the idea of a menu manager as core feature.  To be honest I asked about this over a year ago, Add menu button function

[Antechinus]

The development team is considering ways to better handle the menu in future versions. Some have suggested

• storing the menu in the database where custom changes to the menu will not be overridden during upgrades
• Also they are considering some type of menu editor built into SMF

What do you all think?

We had this discussion in the team/beta boards already, and it was pointed out that calling the menu directly from the db would be very bad for large sites. For good scalability, any editor would have to write to a flat file.

[Joker™]

We had this discussion in the team/beta boards already, and it was pointed out that calling the menu directly from the db would be very bad for large sites. For good scalability, any editor would have to write to a flat file.

Just a thought -- what if some mod has made the edit to the file already?

[Matthew K.]

Every time the menu is modified from the provided admin interface, the file is wiped and re-populated from the database menu table. This is already in the feature-set of my Menu Editor, not the lite version, but the full version.

We had this discussion in the team/beta boards already, and it was pointed out that calling the menu directly from the db would be very bad for large sites. For good scalability, any editor would have to write to a flat file.

Just a thought -- what if some mod has made the edit to the file already?

[live627]

Every time the menu is modified from the provided admin interface, the file is wiped and re-populated from the database menu table.

That's called the cache. :p

[Matthew K.]

Except it's not the same...

Every time the menu is modified from the provided admin interface, the file is wiped and re-populated from the database menu table.

That's called the cache. :p

[live627]

Ok, now I'm curious... how does it differ?

[Matthew K.]

It doesn't really, except for the fact it's not in /cache. It's not "SMF's cache" if you will.

[live627]

You mean it doesn't expire?

[Matthew K.]

It's a flat file...with a menu array that is only re-populated when the menu is modified.

You mean it doesn't expire?

[青山 素子]

Couldn't you just set a different expiration time on individual cache files? If you're going to cache data, you might as well keep that all in one place. Some cache files would expire much sooner, others would be nearly static.

[Xarcell]

It's a flat file...with a menu array that is only re-populated when the menu is modified.

You mean it doesn't expire?

+1

[JohnWayne999]

1) Menu Editor sounds excellent. Be sure to have a feature that lets you choose whether a button when pressed will open up in current window or will open up a new window. That'll be very good. For example I have a Chatroom button and I'd like it to open into a new window, rather than steering the user away from current.

2) Have the menus, buttons settings all in one central file so people don't need to apply changes to every single theme. The problem now is if you install new themes, the new themes won't have all the changes you've made to date. Having a centralised menu/button registry makes things a lot neater and flexible.

[Antechinus]

You're obviously still using 1.1.x.  SMF 2.0.x has all menus called from the same file.

[Matthew K.]

The target variable is already an option for SMF 2.0, as is the flat file in the logic end of things, so it's loaded the exact same way into each theme.

But yes, Menu Editor would allow you to select a target through the interface.

1) Menu Editor sounds excellent. Be sure to have a feature that lets you choose whether a button when pressed will open up in current window or will open up a new window. That'll be very good. For example I have a Chatroom button and I'd like it to open into a new window, rather than steering the user away from current.

2) Have the menus, buttons settings all in one central file so people don't need to apply changes to every single theme. The problem now is if you install new themes, the new themes won't have all the changes you've made to date. Having a centralised menu/button registry makes things a lot neater and flexible.

[Account Abandoned]

Menu editing like being where I can add menus to the main navigation? If that is the case, I would LOVE a feature like that Make it internal too or I mean make it where I can add custom menus to the ACP as well!

[kat]

How difficult would it be, to do this in the way that Bloc did it, with Helios?