Deprecate usage of GMENU

(Benni Mack) #1

Discussion Topic

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

Con

  • People using GMENU would be upset
  • We loose functionality

Organizational

Topic Initiator: Benni Mack

(Andreas Fernandez) #2

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.

(Stefan Neufeind) #3

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.

(Presedo Roberto) #4

Last time I used this was when I was studying for 4.x certification… Never used that in my projects… In my opinion, this can be dropped.

(Björn Jacob) #5

#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

(Bernd Wilke) #6

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.

(Oliver Klee) #7

HTML + CSS it the way to go nowadays. So let’s deprecate and remove GMENU and friends.

(Alexander Opitz) #8

Deprecate and then remove it.

(Martin Bless) #9

Sounds good. Keep HMENU and TMENU and drop the rest. I’ve never used one of “the rest”.

(Moritz) #10

Totally agree to remove it. Never used it; Photoshop was faster and flexibility was not needed in Most cases.

(Richard Haeser) #11

That you even had to ask :wink: deprecate and remove please!

(Tizian Schmidlin) #12

I’m definitely for removing the GMENU feature.

I could imagine that writing an optional core extension as separate package that you’d have to require yourself would bring two benefits though:

  1. It can be loaded for people who really use it
  2. 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)
(Frans Saris) #13

I’m also in favor of cleaning this up.

(Riccardo De Contardi) #14

In favor of deprecation and then removal

(Helmut Hummel) #15

:+1:
Go ahead. No need to keep this legacy code!

(Matthias Toscanelli) #16

In favor of deprecation and then removal.

(Daniel Siepmann) #17

Just remove these as soon as possible. There is no need anymore to keep such old ways of doing things in a, now, bad way.

(Wouter Wolters) #18

Never used it, get rid of it IMO.

(Benni Mack) closed #19

This topic was automatically closed after 14 days. New replies are no longer allowed.