Wedge
Public area => Bug reports => The Pub => Archived fixes => Topic started by: Arantor on March 2nd, 2012, 10:46 AM
-
There are two separate issues being discussed but they're heavily related.
Firstly, the items in the menu are cached - including the consequences of calling a hook. Which means on caching level 2, weird things can happen where plugin menu items won't necessarily be displayed (or worse, they'll continue to be displayed even when deactivated)
Secondly, determining the active menu item is potentially inaccurate because of the above.
I'm sort of wondering what the point of caching it is, though. It's very straightforward as it stands, and in fact the caching can screw things up given the gallery unread count.
Perhaps it would simply be better not to cache it at all.
-
And I suppose it's not possible to move the hook further down, preferably below the caching code...?
-
That sort of defeats the point of caching, because other than Aeva's unread count (which is per user as opposed to the caching which is groups+language), it's all permissions tests which are pretty cheap and there are better places to worry about caching.
-
Is this for the main menu or admin menu (or both?)
If it's admin, then I agree, caching can be disabled to simplify everything...
If it's main menu, no need to bother either, because it's short enough.
If it's non-main and non-admin (profile...), then it gets interesting. I guess.
-
Main menu only. The admin menu is not cached anyway.
The idea is that the main menu is 'so busy' that it should be cached on level 2+ but I fail to understand the logic of why.
-
Level 2+ isn't recommended by SMF anyway. I understand the logic of having multiple caching levels, but it's not clear what exactly is cached and isn't.
I suppose it'd be good to time the time taken by the admin menu from build time to display time. Just to see how much of a percentage of performance it takes on the page.
-
but it's not clear what exactly is cached and isn't.
I suppose it'd be good to time the time taken by the admin menu from build time to display time. Just to see how much of a percentage of performance it takes on the page.
-
How about we cache dynamic entries as {cache:id} and fill in the ids at runtime?
-
Well... it depends how you define 'dynamic' entries. More than one button is already variable depending on state, e.g. the login and register buttons.
As far as the admin menu goes, simple expansions that only add their own page and nothing more, they're already sort of cached and don't need to load any files, they're in $settings.
I have thought about doing something similar for the main menu too, so that simple menu buttons (nothing that is *too* dynamic) from plugins can be handled much the same, leading to files not being loaded just to make a tiny change to the array.
For more complex cases, caching is probably useless anyway and will convolute things more than it'll help.
-
The decision is in your hands. :)
-
http://wedge.org/pub/plugins/7120/menu-integration/ is what I had in mind ;)
-
Meanwhile caching has been removed so this is no longer a bug.