Contao: Individual navigation active item is trail instead active when get params in URL

[Aybee]

Affected version(s)
4.4.36

Description
Auch bei einer individuellen Navigation wird der Menüpunkt der aktuellen Seite als strong.active genrendert. Dies funktioniert nicht mehr, sobald ein GET-Parameter in der URL vorkommt. Dieser Punkt wird dann als a.trail gerendert.

How to reproduce
Teste eine individuelle Navigation mit GET-Parametern in der URL. Z.B. mit einem angepassten nav_default Template.

...
<?php foreach ($this->items as $item): ?>
  <?php
    $item['href'] = $item['href'].'?key=value';
  ?>
...

[leofeyer]

Wie genau sieht Deine URL aus?

[Aybee]

Online Demo:

1. Erstelle ein individuelles Navigations-Menü
2. Wähle eine Seite (content-elements)
3. Füge das Modul im Layout "2 columns - [ default ]" als erstes oben hinzu (Kopfzeile)
4. Gehe auf die Seite https://demo.contao.org/en/content-elements.html
5. Die Navigation ist oben sichtbar, der Punkt ist strong.active
6. Ergänze die URL in der Address-Bar mit ?key=value
7. Der Punkt ist jetzt a.trail

[leofeyer]

Naja, theoretisch ist /en/content-elements.html ja auch eine andere URL als /en/content-elements.html?key=value. @contao/developers Wie seht ihr das?

[Toflar]

Ich glaube nur der Pfad sollte relevant sein 🤔

[fritzmg]

Hm, ich finde eigentlich, dass trail hier richtig ist.

@Aybee war es bspw. in Contao 3 anders?

[asaage]

Wenn ich mal von einem News-Listing ausgehe und ?key=value = ?page_nxy=2 als Beispiel nehme würde ich eigentlich ein .active erwarten und die Breadcrumb-navigation verhält sich auch so

mod_customnav und mod_navigation hingegen liefern .trail.
Das war in in Contao 3 auch schon so.
Ich würde eher dazu tendieren es als Bug zu bezeichnen.

[Toflar]

Die Definition einer Seite ist der Pfad. Query-Parameter sind dazu da, Filterungen vorzunehmen.
Für mich ist der Fall ziemlich klar, alles was den gleichen Pfad hat, sollte active sein, weil es die gleiche Seite ist.

[Aybee]

War mir gar nicht bewusst, dass das bei der normalen Navigation auch so ist. Evtl. hätte ich es dann nicht gemeldet, sorry. .trail kann ja auch seine Vorteile haben, weil man darüber ja z.B. die Paginierung wieder entfernen kann.
https://demo.contao.org/en/applications.html?page_l62=2

In meinem Usecase war es kontraproduktiv, sodass ich es im Template geändert habe, aber ich musste das Template sowieso anpassen, damit ich die Get-Parameter auf die Links bekomme. Bei Bedarf kann ich meinen Usecase auch zeigen.

[asaage]

.trail kann ja auch seine Vorteile haben, weil man darüber ja z.B. die Paginierung wieder entfernen kann.

Stimm - das hab ich nicht bedacht - wenn ich nach einer Umstellung darauf verzichten müsste mit einer Hauptnavigation auf die erste Seite springen zu können wäre das denke ich schon ziemlich ärgerlich.
Dann vielleicht doch lieber alles so lassen, wie es ist? oder clickbares .active einführen? 😕

[Aybee]

Klickbares .active? Och nö, strong ist schon OK - ohne Verlinkung.

Von mir aus kann man das jetzt dann auch so lassen, wie es ist. Die Situation mit nem GET-Parameter auf ner individuellen Navigation ist doch ziemlich ungewöhnlich. Entschuldigt den Aufstand, den ich verursacht habe. Ich schließe das Ticket erstmal noch nicht, falls noch weiter drüber diskutiert wird.

[leofeyer]

Wie am 9. Mai auf Mumble besprochen, dürfen die GET-Parameter nichts am .active-Status des Links ändern.

[asaage]

Unter der Vorraussetzung, dass .active nicht klickbar ist und bleibt sehe ich bei einer Änderung eigentlich nur Usability-Nachteile wenn sich paginierte News- oder Event-Seiten, mp_forms oder auch Suchergebnisse nicht mehr mit Navigationsmodulen auf ihren Ausgangszustand zurücksetzen lassen.

[leofeyer]

Da hat @asaage allerdings Recht.

[Toflar]

Das sehe ich anders. Paginierte Seiten werden über die Pagination erreicht. Dort findet sich auch der Link zurück auf die 1. Seite (welche nicht page=1 enthalten sollte). mp_forms bietet ebenfalls einen eigenen zurück-Button. Die Navigation ist nicht dazu da, Filter von anderen Modulen zurück zu setzen, das muss jedes Modul selber machen.

[asaage]

Filter von anderen Modulen zurück zu setzen, das muss jedes Modul selber machen.

Das machen sie ja auch seit jeher.
Ich würde auch die These unterstützen, dass .active Seiten durch einen Queryparameter nicht zu .trail Seiten werden sollten.
Vielleicht kann jemand mal eruieren, warum ein .active Navigations-Item nicht mehr klickbar sein soll (vielleicht eine SEO-Fachkraft) - dieses Pattern sehe ich nämlich auf einem Großteil der Seiten, die ich besuche nicht.

Url's nach dem Schema news/page/2, events/month/201907 oder myform/step/4 wären evl. auch ein Weg, das elegant zu umschiffen (https://github.com/contao/contao/issues/390) weil die Queryparameter dann wegfallen. In diesen Fällen wären die Seiten (news, events, myform) in der Navigation dann jeweils korrekt als .trail markiert. Klingt nach einer komischen Herangehensweise - war mir aber die Überlegung wert ;)

[leofeyer]

Vielleicht kann jemand mal eruieren, warum ein .active Navigations-Item nicht mehr klickbar sein soll (vielleicht eine SEO-Fachkraft) - dieses Pattern sehe ich nämlich auf einem Großteil der Seiten, die ich besuche nicht.

Eine SEO-Fachkraft wird Dir hier wohl nicht weiterhelfen können; eher jemand, der sich mit der Barrierefreiheit auskennt. Siehe z.B.: https://www.einfach-fuer-alle.de/artikel/menues/tag2/

@MacKP @kikmedia Trotzdem wäre es interessant zu wissen, warum das die Navigation barrierefreier macht. Wisst ihr das zufällig?

[fritzmg]

Erst dadurch ist ja tatsächlich semantisch festgelegt, welcher Menüpunkt gerade aktiv ist. Die CSS Klasse alleine ist ja dahingehend nicht aussagekräftig.

[MacKP]

Da muss ich @fritzmg zustimmen. Zusätzlich ist es eigentlich auch noch so, dass man aus Sicht der Orientierung nicht auf die eigene Seite verlinken sollte (man geht über den Link auf den selben Inhalt und wundert sicht). Deswegen mach ich den Link um das Logo auch nicht auf der Startseite ;-)
Inzwischen gibt es zwar auch noch weiter möglichkeiten die aktuelle Seite zu kennzeichnen -> aria-current Aber: Wo ohne aria gearbeitet werden kann ist immer besser ;-)
Viele Grüße

[fritzmg]

Ich denke wir sollten, wie @Toflar vorgeschlagen hat, den active state beibehalten, wenn GET Parameter vorhanden sind.

Den Rest kann sich ja jeder selbst im Template anpassen, nach Belieben.

[kikmedia]

Sehe ich exakt so wie @MacKP - und ich bin ebenfalls der Meinung, das bei Verlinkung eigentlich die Orientierung schlechter wird, weil ich dort, wohin ich navigieren kann, ja bereits bin.

[leofeyer]

Wir haben das Thema übrigens schon einmal diskutiert. Vor Contao 3.4 war es offenbar schon so, wie wir es jetzt neuerdings wieder haben wollen: https://github.com/contao/core/issues/7189

[asaage]

Abstimmung durch Münzwurf... 😄 ich glaub ich bin raus.

[MacKP]

Wir haben das Thema übrigens schon einmal diskutiert. Vor Contao 3.4 war es offenbar schon so, wie wir es jetzt neuerdings wieder haben wollen: contao/core#7189

Und ich bin da immer noch ganz bei @NinaG ^^

[leofeyer]

Wir müssen also $href == Environment::get('request') durch einen neuen Check ersetzen, der nur den Pfad ohne Query-String vergleicht. Dann sollte es passen.

[Toflar]

Richtig.

[leofeyer]

Dann sollte dies jetzt in 7a4cd8404a1ec0c4b701de501f738959042fd304 behoben sein.

[Toflar]

Environment::get('path') wäre wohl die elegantere Variante gewesen anstatt zu exploden, nicht? 😄 Oder gibt die nicht das zurück was sie sollte (den Pfad 😄 )?

[leofeyer]

Environment::get('path') ist nicht dasselbe wie Environment::get('request') ohne Query-String!

[Toflar]

I see, also wäre die Antwort auf meine Frage ein "Nein" gewesen 😄

[asaage]

Wie oben bereits erwähnt ist nicht nur mod_customnav sondern auch mod_navigation davon betroffen.

[Toflar]

Und? Der Fix ist ja auch in ModuleCustomnav? Oder was meinst du?

[asaage]

In ModuleCustomnav ja - hatte mich nur gewundert warum nicht auch in ModuleNavigation

[Toflar]

ModuleNavigation erbt von Module und nutzt die parent Methode für die Navigation. Passt schon alles so 😄