TypoScript allows for generating menus (HMENU) via TMENU (Textual Menu Items) or GMENU (Menu Items built with Images), additionally we had GMENU_LAYERS, TMENU_LAYERS and JSMENU, removed some time during TYPO3 v6.x development.
Due to the movement of going into more flexible layouts without navigation titles written into images, I suggest to drop the functionality of all other possibilities other than TMENU in TYPO3 v10. This also means to deprecate GMENU in TYPO3 Core for v9, and then to remove this functionality in TYPO3 v10.
This allows to reduce complexity inside the HMENU functionality drastically, which will also show visible points for.
As a TYPO3 user/developer for 15 years, I’ve done all sorts of menus with GMENU, TMENU, GMENU_LAYERS and JSMENU, and with custom menus. I haven’t done any updates to v6.2+ while keeping any of the layers code or GMENU code, but all is done now natively with CSS 2.1 or JS directly, I do not see a need to keep that functionality at all anymore. However, in my opinion, if people need some kind of functionality like GMENU, it is possible via TypoScript to build this in a very custom manner + HMENU has lots of flexibility to extend the menu rendering process on top.
Impact
Deprecation of GMENU in v9
Breaking: Removal of GMENU code + *_LAYERS and JSMENU support in TYPO3 v10 (mostly internal functionality within HMENU code)
Possible Migrations
Integrators would need to migrate to either TMENU or custom TypoScript/PHP code, which is doable IMHO.
Pro
Faster page generation (with TMENU anyway)
Possibilities to refactor HMENU (easier) and to reduce complexity in the PHP code
Less code to maintain, which is used by (personal estimate) less than 0.1% of the integrator base in TYPO3 v9
I really like the approach. I never used anything different than TMENU for 10 years now and even in our “most challenging” projects it’s not used at all.
I also didn’t use GMENU since ages and believe most people use TMENU to have accessible menus. In case somebody really needs that functionality it should be possible with a MenuProcessor to create an extension to create custom graphics. If need be I’m sure somebody would come up with an extension for that. The advantages of cleaning up the core in that regard clearly stand out.
#1 for streamlining the class and removing all of the outdated MENU objects. I would even go further and remove all of the HMENU stuff. Since we have data processors for the menu generation I don’t see why one would like to build menus with TS anymore. Also the new site package tutorial suggests using fluid for menus, see https://docs.typo3.org/typo3cms/SitePackageTutorial/MainMenuCreation/Index.html
If someone needs graphics it is possible to generate the graphics as before.
Either as IMAGE for simple images, or as COA with multiple images for focus/rollover effects
A guide would be helpfull, an update wizard probably too much effort for too few cases.
I could imagine that writing an optional core extension as separate package that you’d have to require yourself would bring two benefits though:
It can be loaded for people who really use it
You actively track how many people actually use it so you have an argument later in case it is decided that it should be dropper because of poor adoption (and still giving the people needing it the possibility to maintain it themself by forking it)
deprecate and remove please!