[dk_mmenu] Mobile Navigation - nicht nur für mobile Websites

Wenn du dir den Code auf der verlinkten Seite anschaust, dann kannst du erkennen, dass API eine Objektvariable ist, die vor ihrer Verwendung belegt werden muss:

Code:

---

var API = $("#offcanvas").data( "mmenu" );

---

#my-menu aus dem Beispiel musste durch die ID ersetzt werden, die du für dein Menü vergeben hast, also #offcanvas.
Danach kann die Funktion close von dem Objekt aufgerufen werden.


Insgesamt müsste es also ungefähr so funktionieren (ungetestet):

Code:

---

<script>
(function($) {
    function myFunction(x) {
        x.classList.toggle("change");

        if ($("#my-menu").hasClass("mm-opened")) {
            var API = $("#my-menu").data( "mmenu" );

            API.close();
        }
    }
})(jQuery);
</script>

---

Ich bin dabei vorsichtshalber davon ausgegangen, dass close() nur aufgerufen werden sollte, wenn das Menü gerade offen ist (d.h. die class "mm-opened" zugewiesen ist). myFunction wird ja auch beim Öffnen des Menüs aufgerufen, und da soll es ja nicht gleich wieder geschlossen werden ;-)

Ich bin auch nicht der Javascript-Guru. Z.B. ist mir die Reihenfolge nicht wirklich klar, in der die Funktionen aufgerufen werden - zuerst myFunction oder zuerst die Funktion, die das Menü öffnet?

Ach ja, die Klammer (function($){ ... })(jQuery) dient, soweit ich es verstanden habe, dem sauberen Zusammenspiel von jQuery und Mootools. Falls das nicht stimmen sollte, dann versuch es mal ohne diese beiden Zeilen...

Probier es bitte mal aus - vielleicht auch in verschiedenen Browsern.
Viel Erfolg!

mhm.. habe den Vorschlag einmal versucht umzusetzen.. leider ohne wirklichen Erfolg. Auch animiert es nun nicht mehr. Ich möchte dich nicht länger mit dieser Kleinigkeit aufhalten, kann es ja auch ohne Animation umsetzen. Solltest du noch einmal Zeit und Lust haben, ich habe dir mal einen Backend Zugang gelegt. Passwort und Username sende ich dir zu :) Und danke für deine bisherige Hilfe

So, hier die Lösung:


das Modul 'Burger' (eigenes HTML):

HTML-Code:

---

<div class="container">
<a href="#offcanvas" onclick="myFunction(this)">
<div class="bars">
  <div class="bar1"></div>
  <div class="bar2"></div>
  <div class="bar3"></div>
</div>
</a>
</div>
<script>
    var api;
    function myFunction(x) {
        x.classList.toggle("change");

        var mmenu = document.getElementById("offcanvas");
        if (mmenu.className.indexOf("mm-opened") !== -1) {
            api = jQuery.data(mmenu, "mmenu" );
            api.close();
        }
    }
</script>

---

Ich habe gegenüber deiner ursprünglichen Version onclick="myFunction(this)" an das a-Element geknüpft, damit man tatsächlich auf den Burger klicken muss, denn das Menü öffnet sich auch nur hier. Sonst kannst du irgendwo in den oberen Balken klicken, der Burger ändert sich, aber das Menü bleibt geschlossen.

In meinem ursprünglichen Vorschlag war ein Schreibfehler. Jetzt habe ich das mmenu "offcanvas" direkt ohne jQuery gesucht. Falls es die class "mm-opened" hat, dann ist es offen, d.h. der Burger verwandelt sich vom X zurück und das Menü muss geschlossen werden. Das api Object müssen wir uns allerdings per jQuery besorgen, es wurde bei der Erzeugung durch jQuery als data im DOM-Element gespeichert.

Gruß, folkfreund

Vielen lieben Dank! Genauso habe ich es mir vorgestellt. Ich denke ich sollte mich mit dem Thema Javascript mal intensiver befassen.

Moinsen,

wenn ich über das dk_menu zu einer Seite navigiere die eine Artikelnavigation beinhaltet,
dann wird diese Seite anschließend in der Navigation nicht als Standpunkt (mm-selected/active) angezeigt wenn ich weiter navigieren will, sondern der Startpunkt der Website.

Gibt es da möglicherweise einen Konflikt mit den vielen article-URLs bei einer eingebundenen Artikelnavigation oder habe ich eine Einstellung übersehen?

Zitat:

---

Zitat von folkfreund

Da machst du dir lieber zusätzlich ein 'normales' Contao-Menü.
Per CSS kannst du dann abhängig von der Fenstergröße das eine oder das andere Menü anzeigen bzw. verstecken.

---

Verstehe ich das richtig? Um die Erweiterung dk_mmenu zu nutzen brauche ich zwei Layouts: ein reguläres mit dem regulären Navigationsmodul (für „große“ Bildschirme“) und ein mobiles Layout (für die lütten Geräte), in dem dann statt des regulären Navigationsmoduls dk_mmenu nebst „Sandwich“-Icon zum Einsatz kommt.

Oder – was ich gerade vergeblich versuche – geht das auch mit einem Layout, bei dem die Navigation von regulär zu dk_menu in dem Moment wechselt, in dem der Bildschirm respektive das Browserfenster eine (wie auch immer das gehen mag) definite Größe unterschreitet? Klingt aus Deiner antwort für mich heraus. Wenn ja: Wie muss denn das CSS konkret aussehen, um das zu steuern?

LG, Jens

Zitat:

---

Zitat von cyborg06

Wenn ja: Wie muss denn das CSS konkret aussehen, um das zu steuern?

---

Ja, so meinte ich das: eine normale Navgation und ein mmenu im gleichen Layout.
Per mediaquery im CSS dann das 'normale' Menü für kleine Bildschirme ausblenden und das mmenu und den Button zum Öffnen einblenden (oder bei 'mobile first' für große Bildschirme das 'normale' Menü einblenden und mmenu inkl. Button ausblenden). Die Idee geht davon aus, dass immer nur eines der beiden Menüs sichtbar ist.

Du setzt also grundsätzlich die nicht benötigten Elemente auf 'display: none', die anderen auf 'display: block'. Die entgegengesetzten Regeln fügst du über ein passendes Mediaquery ein.
Beispiel:

Du hast irgendwo auf deiner Seite den Button zum Öffnen des mmenu

HTML-Code:

---

<a class="deinMobileNavLink" href="#deineMobileNavIdWieImBackend">...</a>

---

Dann könnte das CSS so aussehen (nicht 'mobile first'):

PHP-Code:

---

.deinMobileNavLink {  /* der MMenu Button */
    display: none;
}
.mod_navigation {  /* normale Navigation */
    display: block;
}
    
@media screen and (max-width: 730px) /* oder irgendeine andere passende Breite */
{
    .deinMobileNavLink {
        display: block;
    }
    .mod_navigation {
        display: none;
    }
} 


---

Zitat:

---

Zitat von cyborg06

Oder – was ich gerade vergeblich versuche – geht das auch mit einem Layout, bei dem die Navigation von regulär zu dk_menu in dem Moment wechselt, in dem der Bildschirm respektive das Browserfenster eine ... definite Größe unterschreitet?

---

Wenn du versuchst ein und dieselbe Navigation einmal als dk_mmenu und einmal normal anzuzeigen, das wird schwer, weil das JS von mmenu die Liste der Navigation total zerreißt und neu aufbaut. Mit [mobile_menu] geht sowas einfacher.

Jetzt hätte ich doch noch eine Frage.
Ich möchte gerne in meinem mmenu ein integriertes Suchfeld haben, welches immer unterhalb des Seitentitels steht. Dabei meine ich ein Suchfeld, welches tatsächlich die Seitenstruktur und nicht die Navigation durchsucht. Welche Datei gilt es hierbei zu editieren?

Zitat:

---

Zitat von folkfreund

Ja, so meinte ich das: eine normale Navgation und ein mmenu im gleichen Layout.

[/PHP]

---

Danke für Deine Antwort?

Was (wenn es einen gibt) ist denn der Vorteil, beides in einem Layout zu haben? Anders gefragt: Was spricht gegen zwei getrennte Layouts, wo doch, wie Andreas unten sagt, dk_mmenu die reguläre Navigation zerpflückt?

LG, Jens

Zitat:

---

Zitat von Andreas

Wenn du versuchst ein und dieselbe Navigation einmal als dk_mmenu und einmal normal anzuzeigen, das wird schwer, weil das JS von mmenu die Liste der Navigation total zerreißt und neu aufbaut. Mit [mobile_menu] geht sowas einfacher.

---

Danke für Deine Antwort.

Auch an Dich die Frage: Was (wenn es einen gibt) ist denn der Vorteil, beides in einem Layout zu haben? Anders gefragt: Was spricht gegen zwei getrennte Layouts, wo doch, wie Du sagst, dk_mmenu die reguläre Navigation zerreißt?

LG, Jens

Nur ein Layout zu haben ist immer ein Vorteil, weil die Pflege leichter ist. Nur eine Navigationsliste im HTML-Markup zu haben wäre auch ein Vorteil, weil weniger HTML, einfacher in der Pflege und einfacher für Screenreader.

Außerdem kann Contao (PHP) kein Layout anhand der Viewportbreite anbieten, weil die erst clientseitig per JS ermittelt werden kann und nicht bereits auf dem Server nach dem HTML-Request. Das mobile Layout in den Seiteneinstellungen versucht dann in Aktion zu treten, wenn Contao meint anhand des gesendeten UserAgents beim Besucher ein mobiles Gerät zu erkennen. Wenn jemand einen 27" Monitor an sein mobiles Gerät anschließt, würde es dann ein Layout optimiert für Smartphones bekommen, was evtl. wenig Sinn macht.

Das Vorteilhafteste wäre also ein Layout mit einer Navigationsliste. Die Bedienbarkeit kann dann mit CSS und evtl. noch JS an die Viewportgröße angepassst werden.

Zitat:

---

Zitat von Andreas

... Das mobile Layout in den Seiteneinstellungen versucht dann in Aktion zu treten, wenn Contao meint anhand des gesendeten UserAgents beim Besucher ein mobiles Gerät zu erkennen. Wenn jemand einen 27" Monitor an sein mobiles Gerät anschließt, würde es dann ein Layout optimiert für Smartphones bekommen, was evtl. wenig Sinn macht.

---

Wer in aller Welt schließt einen 27-Zöller an ein Smartphones an? Diese Zeitgenossen haben es doch auch nicht anders verdient, als dann ein mobiles Layout vorgsetzt zu bekommen :D

Im Ernst: Als Contao-mehr-oder-weniger-Anfänger nutze ich immer noch Peter Müllers Contao-Bibel als Leitfaden. Ist so schön verständlich; nun also auf zu neuen Ufern!

Danke für Deine Antwort

Lg, Jens

Nicht an ein Smartphone, an ein mobiles Gerät. Ich habe z.B. einen 27" an meinem mobilen Convertible. Aber ich denke es würde von Contao nicht als mobile erkannt. War auch nur als Info für dich gedacht, was hinter dem mobilen Layout von Contao steckt. Es hat also nichts mit dem Viewport oder der Touchfähigkeit zu tun, sondern nur mit dem UA.

Zitat:

---

Zitat von Andreas

Nicht an ein Smartphone, an ein mobiles Gerät. Ich habe z.B. einen 27" an meinem mobilen Convertible. Aber ich denke es würde von Contao nicht als mobile erkannt. War auch nur als Info für dich gedacht, was hinter dem mobilen Layout von Contao steckt. Es hat also nichts mit dem Viewport oder der Touchfähigkeit zu tun, sondern nur mit dem UA.

---

Das heißt; wenn den von Peter Müller beschriebenen Weg eines separaten mobilen Layouts beschreite, bin ich eigentlich auf der sicheren Seite, trotz des ggf. zusätzlichen Pflegeaufwands und des üppigeren HTML-Codes?
Den von Folkfreund o.g. Weg eines Layouts will mir nicht gelingen ...

Zitat:

---

Zitat von cyborg06

...eines separaten mobilen Layouts beschreite, bin ich eigentlich auf der sicheren Seite, ...

---

Nein, eben nicht. Ich kenne das Buch von PM nicht, aber benutze am besten kein mobiles Layout (Einstellungen in den Seiten). Benutze nur Media Queries. Du kannst natürlich eins benutzen, aber die meisten hier tun das nicht. Du hast dann keine Kontrolle darüber, was der Besucher sieht. Mit Media Queries kannst du schön auf die Viewportgröße reagieren.

Zitat:

---

Zitat von cyborg06

Den von Folkfreund o.g. Weg eines Layouts will mir nicht gelingen ...

---

Bei mir funktioniert es jedenfalls ;-)

Kannst du einen Link zu der Seite geben, dann können wir uns das ja mal ansehen.
Und außerdem hatte Andreas dir ja noch [mobile_menu] empfohlen. Ich habe damit keine Erfahrungen, kann mir das aber als Alternative sehr gut vorstellen.

[mobile_menu] ist von Kamil Kuzminski, einem erfahrenen Contao Entwickler. https://codefog.pl/extension/mobile-menu.html

Zitat:

---

Zitat von Andreas

[mobile_menu] ist von Kamil Kuzminski, einem erfahrenen Contao Entwickler. https://codefog.pl/extension/mobile-menu.html

---

läuft bei mir sehr gut!

Zitat:

---

Zitat von Patric

Jetzt hätte ich doch noch eine Frage.
Ich möchte gerne in meinem mmenu ein integriertes Suchfeld haben, welches immer unterhalb des Seitentitels steht. Dabei meine ich ein Suchfeld, welches tatsächlich die Seitenstruktur und nicht die Navigation durchsucht. Welche Datei gilt es hierbei zu editieren?

---

..hat vielleicht jemand eine Lösung?

Zitat:

---

Zitat von Andreas

Nein, eben nicht. Ich kenne das Buch von PM nicht, aber benutze am besten kein mobiles Layout (Einstellungen in den Seiten). Benutze nur Media Queries. Du kannst natürlich eins benutzen, aber die meisten hier tun das nicht. Du hast dann keine Kontrolle darüber, was der Besucher sieht. Mit Media Queries kannst du schön auf die Viewportgröße reagieren.

---

Ich werde das beherzigen, danke.

Zitat:

---

Zitat von folkfreund

Bei mir funktioniert es jedenfalls ;-)

Kannst du einen Link zu der Seite geben, dann können wir uns das ja mal ansehen.
Und außerdem hatte Andreas dir ja noch [mobile_menu] empfohlen. Ich habe damit keine Erfahrungen, kann mir das aber als Alternative sehr gut vorstellen.

---

Die Seite noch nicht online, sondern noch auf meinem lokalen Server.

mobile_menu steht jetzt erst an, das Wochenende war seeehr lang ;-)

LG, Jens


edit: Ich habe dann doch noch mal Deine o.g. Beschreibung nachvollzogen ... und jetzt offensichtlich alles richtig gemacht, sprich: das externe Style-Sheet komplett neu geschrieben. Was auch immer vorher falsch war, jetzt klappt es. Zur Feier des Tages höre ich jetzt eine Folk-Platte - wenn denn Sue Sheehan in diese "Schublade" passt :-)

Na dann herzlichen Glückwunsch!
Ich werde demnächst mobile_menu ausprobieren.

Ach ja, und ich halte nichts von 'Schubladen' - Hauptsache es gefällt :-)

Gruß, folkfreund

Zitat:

---

Zitat von Andreas

Nein, eben nicht. Ich kenne das Buch von PM nicht, aber benutze am besten kein mobiles Layout (Einstellungen in den Seiten). Benutze nur Media Queries. Du kannst natürlich eins benutzen, aber die meisten hier tun das nicht. Du hast dann keine Kontrolle darüber, was der Besucher sieht. Mit Media Queries kannst du schön auf die Viewportgröße reagieren.

---

Für das reine Layout stimme ich Dir 100% zu - falls man jedoch Elemente oder Content hat, dass für die Benutzbarkeit von "mobilen"-UAs nicht ausgeliefert werden soll, benutze ich sehr gerne diese Möglichkeit.

Ja, das kann man so machen. Es sollten dabei natürlich keine für die Seite relevanten Objekte geblockt werden. Innerhalb von Templates könnte man das mit

PHP-Code:

---

if(\Environment::get('agent')->mobile)... 


---

steuern. Ich weiß aber nicht, wie das dann mit gecachten Seiten wäre.

Hallo zusammen, diese Option möchten wir gerne nutzen für eine Sprung-/Anker-Navigation innerhalb der Seite. Sie scheint aber nicht immer zu funktionieren wenn aktiviert.

Version 1.5.1 B7 unter Contao 3.5.27.

Habe festgestellt, dass wenn aktiviert das Menu sich 1x schliesst. Beim nächsten öffnen mit Klick auf einen Ankerlink hingegen bleibt es offen …?

Besteht die Möglichkeit seitens des Entwicklers, die Erweiterung auch für Contao 4.X. lauffähig zu machen? Aktuell lässt sich die Erweiterung meines Wissens nach nicht installieren.

Zitat:

---

Zitat von Dublay

Besteht die Möglichkeit seitens des Entwicklers, die Erweiterung auch für Contao 4.X. lauffähig zu machen? Aktuell lässt sich die Erweiterung meines Wissens nach nicht installieren.

---

https://github.com/dklemmt/contao_dk_mmenu/pull/18
https://github.com/dklemmt/contao_dk_mmenu/pull/15

Hallo zusammen! Ich erhalte folgende Meldung, bei Verwendung der Erweiterung unter Contao 4.4:

Code:

---

Warning:  filemtime(): stat failed for /system/modules/dk_mmenu/assets/css/themes/.css in /vendor/contao/core-bundle/src/Resources/contao/library/Contao/Controller.php on line 790

---

Was hat das zu bedeuten?

Sieht so aus, als stünde in $GLOBALS['TL_CSS'][] eine Datei "/system/modules/dk_mmenu/assets/css/themes/.css", diese Datei kann aber nicht gefunden werden und somit auch kein filemtime() ausgelesen werden.

Suche mal in den Dateien nach 'TL_CSS', ob da irgendwo sone Datei ".css" eingebunden wird. Wenn nicht, dann versuche mal diese Flags zu entfernen "||static". Vielleicht liegt es ja an diesen Flags, ich weiß nicht, ob man die in Contao 4 noch benötigt. Oder probier mal nur mit einer Pipe "|static".

Dort in "/system/modules/dk_mmenu/assets/css/themes/", das scheinen die CSS für die Themes zu sein, vielleicht stimmt auch was bei der Auswahl der Themes im Modul nicht.

Mach an dieser Stelle
https://github.com/dklemmt/contao_dk...Mmenu.php#L226
mal das hier

PHP-Code:

---

dump($objMmenu->dk_mmenuTheme); 


---

Siehe auch hier https://github.com/dklemmt/contao_dk_mmenu/issues/9

Okay, danke dir!

Hallo liebe community,

ich habe Probleme mit dk_mmenu in kombination mit dem Rocksolid Slider.
Ich nutze aktuell Contao 3.5.24 | dk_mmenu 1.5.1 und rocksolid-slider 1.6.2

Sobald ich die Navigation in das Seitenlayout einbinde, verschwindet der Slider. Es blinkt kurz auf und dann wird es ausgeblendet.
Ich habe dk_mmenu schon häufiger verwendet aber hatte noch nie diese Probleme.

Hat jemand eine Idee was ich machen kann.

Danke für die Hilfe im voraus!

Servus zusammen,

ich möchte gerne die mobile Navigation einbauen. Ich habe auf meiner Website den #wrapper auf height: 100% gesetzt weil ich einen 20px starken Rahmen um die komplette Seite gelegt habe. Wenn ich die mobile Navigation einbaue dann wird beim #wrapper dieses height: 100% ignoriert und er setzt die höhe so wie der Inhalt ist. In welcher Form beeinflußt die mobile Navigation denn die css Dateien? Sie ist ja eigentlich auf der normalen Seite ausgeblendet... Hat jemand ne Idee?

Gruß toto

mmenu fügt eigene Styles hinzu und fügt auch (je nach Situation) eigene CSS Klassen zum #wrapper hinzu.

Zitat:

---

Zitat von toto

In welcher Form beeinflußt die mobile Navigation denn die css Dateien? Sie ist ja eigentlich auf der normalen Seite ausgeblendet... Hat jemand ne Idee?

---

In den Entwicklertools Deiner Wahl kannst Du das doch sehen.

Tja, da wird wohl auch ein wrapper für die navi verwendet. Quasi das fenster was einfadet. Hm aber wie kann ich das lösen? Hab schon das page template geändert und ne classe dazugefügt aber das klappt nicht.

ne hab mich vertan. Ach ich weiß es doch auch nicht :( Ich bin nicht so versiert mit firebug

Versuch mal #wrapper {min-height: 100vh;}.

Krass! Geht! was ist das für eine Größe? vh ??

volle Höhe ;)
*scherz*
viewport height

https://www.w3schools.com/cssref/css_units.asp
https://www.drweb.de/magazin/neue-cs...designs-47490/
http://www.hongkiat.com/blog/css-vie...-vh-wmin-vmax/