Page 3 of 3

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Tue 12. Jan 2016, 10:07
by kukki
Beim weiteren Probieren (Stand V. 1.8.2 von heute früh 11.°° Uhr) habe ich noch keinen Parameter/ Einstellung bei NAV_LIST_UL: ...} gefunden, die die Links in der Parent-Ebene nicht ausführt, wenn dort in der Kind-Ebene Menüpunkte enthalten sind. Bei Sliknav kann man das Verhalten über

Code: Select all

allowParentLinks: false/ true
regeln, aber bei {NAV_LIST_UL: ...} fand ich keine Einstellung, die diesen Efekt hat. :?: Weiß da jemand Rat :?:
Die ganze Sache soll auch funktinieren, wenn die Kind-Menüpunkte versteckt sind!



----START---------------
------------MENU_A----- (hier soll kein Link MENU_A ausgeführt werden)
---------------------MENU_1
---------------------MENU_2
------------MENU_B----- (hier soll das Link MENU_B ausgeführt werden)
---------------------MENU_1 versteckt!
---------------------MENU_2 versteckt!

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Tue 12. Jan 2016, 10:22
by Oliver Georgi
dafür existiert bisher keine konfigurierbare Lösung. Ich würde es über Klassen mit JavaScript abfangen, die dafür sorgen, dass ein Klick darauf wirkungslos bleibt. Und gleichfalls würde ich ein Weiterleitungsziel setzen, wie z.B. # oder eine Subebene, in der die Suchmaschine einsteigen soll.

Überlege einfach, was hier logisch ist und was nicht.

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Tue 12. Jan 2016, 12:56
by kukki
Das geht doch bestimmt auch mit (D)einem PHP-Trigger, indem man die entsprechenden class= sub_ul sucht und dort setzt man den HTML-Tag auf

Code: Select all

href="#"

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Tue 12. Jan 2016, 14:27
by Oliver Georgi
nicht nötig. Der Ebene Menu_A gibts du eine Klasse mit, z.B. "noclick"

Code: Select all

$(function() {
    $('li.noclick > a').removeAttr('href');
});

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Wed 13. Jan 2016, 06:00
by Uwe367
Ich habe das bisher immer mit einer Raute im Weiterleitungsziel gelöst. Funktioniert in allen gängigen Browsern. Klickt man auf einen solchen (toten) Link, passiert nichts, es wird lediglich an die URL in der Browserleiste eine Raute angefügt. Somit dient dieser Menüpunkt nur noch als Roll-Over für Unterkategorien. Ist für mich selbst und auch aus meiner Sicht die einfachste und schnellste Lösung, ohne viel Schnick Schnack und drumherum rudern. Zudem hat es den Vorteil daß du explizit einzelne Menüpunkte damit "totschalten" kannst falls andere in der gleichen Ebene funktionieren sollen. Funktioniert auch wunderbar bei Sub-Ebenen.
Irgendwo hier im Forum existert aber auch ein Thema dazu.

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Wed 13. Jan 2016, 07:18
by Oliver Georgi
auch Anker # sollte man abfangen, es bleibt ein Link und hüpft zum Anker, da kein Ziel vorhanden, wird zu Top des Dokuments gesprungen. Ohne Attribut href verhält sich der <a> Tag wie ein <span>.

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Wed 20. Jan 2016, 09:10
by kukki
Nach dem Vorschlag von Oliver bezüglich der parent-Elemente des Menüs habe ich für die Testseite die Menüfürung umgestellt, was nach einigen Probieren gut funktionierte. Das Slik-Nav-Menü zeigt sich optisch o.k., das horizontale Menü muss mann ein klein wenig per CSS erweitern.

ABER: wenn ich dieses Menükonstrukt 1:1 auf ein geupdates System verwende, werden die parent-Elemente nicht angezeigt. Ich bin nicht dahintergestiegen, weshalb das nur bei neu installierten Systemen funktioniert. Ist dafür eventuell eine zusätzliche Einstelung in der config.inc vorzunemen?

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Wed 3. Aug 2016, 13:25
by kukki
:?: Wie kann man bei Verwendung von NAV_LIST_UL/ Slick_Nav/ das entsprechende Elternelement beim RT breadcrumb killen, bzw. eine Klasse ("sub_ul") einfügen um diesen Vorgang zu unterstützen.

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Wed 3. Aug 2016, 13:43
by Oliver Georgi
Entsprechendes Verhalten des Menüpunktes definieren:
Bildschirmfoto 2016-08-03 um 13.43.08.png

Re: responsives {NAV_LIST_UL:F/FP/P,n,m}

Posted: Thu 4. Aug 2016, 13:29
by kukki
Danke Oliver, - Problem gelöst - habe ich noch gar nicht bemerkt. In der V 1.7.1/3 war das bestimmt noch nicht an dieser Stelle :?: