Onepage_XH

[lck]

Wäre es nicht sinnvoller, diese Klasse evtl. "current" (oder vielleicht "active") statt "sdoc" zu nennen? [1]
Oder gibt es da wieder Inkompatibilitäten (BC break)?

Ja genau, das führt eventuell zu Problemen mit früheren Templates. Wenn dann als zusätzliche Klasse, muss aber nicht sein. Man kann doc und sdoc ja eindeutig ansprechen mit:

Code: Select all

#onepage_menu .doc {...}
#onepage_menu .sdoc {...}

Wie ich das verstehe, wird im aktuellen Master scrollabhängig dem aktiven Menüpunkt die Klasse "sdoc" verpasst.

Scheint schon seit Onepage_XH 1.0beta2 so zu sein.

[frase]

Man kann doc und sdoc ja eindeutig ansprechen mit:

Klar kann man.

Scheint schon seit Onepage_XH 1.0beta2 so zu sein.

Tatsächlich, das ist wirklich so (sdoc : doc). Habe ich nicht gewusst.
Wahrscheinlich fiel es mir nicht auf, weil der Klassennamen eben "standard" ist.
Aber gut. Wenn das richtig dokumentiert ist, dann ist es gut handlebar.

[cmb]

Bei einem neueren Template mit horizontalem Slider funktioniert es nicht, da das switchen zwischen der Klasse doc und sdoc wohl sollabhängig und zwar in vertikaler Richtung ist.

Stimmt. Horizontale Onepager hatte ich bisher gar nicht auf dem Schirm.

Eine zusätzliche Klasse onepage_menu macht keinen Sinn und ist auch nicht nötig. Für das Problem mit der doppelten ID bei zweifachem Menüaufruf, habe ich ja jetzt eine Lösung per MyLi.

Na ja, wenn tatsächlich mehrere Menüs gemäß der Seitenposition synchronisiert werden sollen, dann wäre eine Klasse wohl schon sinnvoll.

Wäre es nicht sinnvoller, diese Klasse evtl. "current" (oder vielleicht "active") statt "sdoc" zu nennen? [1]
Oder gibt es da wieder Inkompatibilitäten (BC break)?

Naja, ich habe mich einfach an den Klassen des Standard-Menüs orientiert. Das könnte die Umstellung eines klassischen Templates auf einen Onepager erleichtern; zumindest muss man dann nicht umdenken.

Scheint schon seit Onepage_XH 1.0beta2 so zu sein.

Ja, siehe https://github.com/cmb69/onepage_xh/issues/1.

Wenn das richtig dokumentiert ist, dann ist es gut handlebar.

Bislang ist das dynamische Ändern der Menuitem-Klassen tatsächlich nicht dokumentiert. Bezüglich der Klassennamen gibt es nur den sehr allgemeinen Hinweis, dass onepage_toc() halt die Entsprechung zu toc() ist.

[lck]

Na ja, wenn tatsächlich mehrere Menüs gemäß der Seitenposition synchronisiert werden sollen, dann wäre eine Klasse wohl schon sinnvoll.

Hm, eine Klasse wird ja bereits mit ausgegeben per

Code: Select all

return preg_replace('/<ul class/', '<ul id="onepage_menu" class', $html, 1);

und zwar die Klasse menulevel1

Code: Select all

<ul id="onepage_menu" class="menulevel1">

Bisher brauchte ich keine zweite Klasse. Die Menüs die eventuell im Template aufgerufen werden sind ja nicht gleichzeitig aktiv, bzw. wenn dann jeweils nur partiell.

[lck]

Naja, ich habe mich einfach an den Klassen des Standard-Menüs orientiert. Das könnte die Umstellung eines klassischen Templates auf einen Onepager erleichtern; zumindest muss man dann nicht umdenken.

+1

[lck]

Bei der Recherche zu My_Li bin ich auf diese zwei Themen gestoßen, im Wiki und hier im Forum. Beides mal ist im Menü-Aufruf eine öffnende Klammer hinter my_li, diese scheint zuviel.

Code: Select all

<?php echo toc(null, null, my_li();?>

Ich rufe ja das angepasste Menü so auf:

Code: Select all

<?php echo my_li($hc, 1);?>

Habe mal der Neugier halber obigen Aufruf probiert, mal mit

Code: Select all

<?php echo onepage_toc(null, null, my_li);?>

... und mal mit

Code: Select all

<?php echo toc(null, null, my_li);?>

Bin überrascht, beides funktioniert .

[cmb]

Bisher brauchte ich keine zweite Klasse. Die Menüs die eventuell im Template aufgerufen werden sind ja nicht gleichzeitig aktiv, bzw. wenn dann jeweils nur partiell.

Die zusätzliche Klasse .onepage_menu ist auch nicht unbedingt für Template-Designer gedacht, sondern eben dafür dass alle Onepage-Menüs gemäß der Seitenposition synchronisiert werden. Es ist vielleicht möglich auf .menulevel1 zurückzugreifen, aber ich bin mir nicht sicher.

Bei der Recherche zu My_Li bin ich auf diese zwei Themen gestoßen, im Wiki und hier im Forum. Beides mal ist im Menü-Aufruf eine öffnende Klammer hinter my_li, diese scheint zuviel.

Stimmt. Habe ich nun an beiden Stellen korrigiert.

Ich rufe ja das angepasste Menü so auf:

Code: Select all

<?php echo my_li($hc, 1);?>

Habe mal der Neugier halber obigen Aufruf probiert, mal mit

Code: Select all

<?php echo onepage_toc(null, null, my_li);?>

... und mal mit

Code: Select all

<?php echo toc(null, null, my_li);?>

Bin überrascht, beides funktioniert .

Variante 1 und 3 sollten tatsächlich das gleiche Ergebnis erzielen, wenn es nur eine Menüebene gibt. Und ja, Variante 2 ist letztlich dasselbe wie Variante 3. Für die meisten Fälle sollte Onepage\Li aber passen, und dann ist onepage_toc() eben die etwas simplere Notation.

[lck]

Onepage_XH,1.0beta2
Warum bekommt man, wenn man im Browser das Verzeichnis http://www.example.com/plugins/onepage/ aufruft, folgende Meldung.

Onepage_XH detected an unsupported CMSimple_XH version.
Uninstall Onepage_XH or upgrade to a supported CMSimple_XH version!

Das sollte doch nur unter CMSimple auftauchen . Na ja scheint ok, ist so gewollt da in der index.php steht:

Code: Select all

 * Prevent direct access and usage from unsupported CMSimple_XH versions.

Aber irgenwie unter XH nicht passend.

[cmb]

Das ist ein historisches Überbleibsel. Früher wurden index.php und admin.php von Plugins üblicherweise vor direktem Zugriff geschützt, weil sie sonst unter Umständen unerwünscht Code ausführen konnten (besonders in Verbindung mit register_globals, was von PHP 5.4 an nicht mehr verfügbar ist). Später habe ich bei meinen Plugins die Versionsprüfung ergänzt (muss CMSimple_XH sein, und eine bestimmte Mindestversion wird erfordert) – mir schien das mal sinnvoll, um spätere Fehlfunktionen, die vielleicht nicht einfach zu debuggen sind, zu verhindern. Letztlich habe ich davon aber Abstand genommen – User sollten die Anforderungen in der Doku nachlesen, bevor sie ein Plugin installieren, und im Zweifel die Systemprüfung des Plugins konsultieren (wenn sie überhaupt bis dorthin kommen).

Jedenfalls kann diese Zugriffs- und Versionprüfung ersatzlos gestrichen werden, da der einzige Code, der ausgeführt würde, gleich einen fatalen PHP-Fehler auslöst. Ganz korrekt ist das resultierende 500 Internal Server Error nicht wirklich (ein 403 Forbidden wäre wohl angebrachter), aber da mache ich mir keinen Kopf drum (letztlich sollte ja niemand auf eine solche Datei zugreifen, und würde CMSimple_XH einen vernünftigen Pluginloader zur Verfügung stellen, dann gäbe es das Problem sowieso nicht; man sollte Deklarationen/Definition nicht mit ausführbarem Code in einer Datei mischen, und konkret sollte nicht das Plugin selbst Code ausführen, sondern nur auszuführenden Code registrieren).