Onepage_XH

Ein CMSimple Support Forum für deutsch sprechende Nutzer und Entwickler
lck
Posts: 1544
Joined: Wed Mar 23, 2011 11:43 am
Contact:

Re: Onepage_XH

Post by lck » Thu Jan 03, 2019 2:16 pm

frase wrote:
Thu Jan 03, 2019 11:05 am
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 {...}
frase wrote:
Thu Jan 03, 2019 11:05 am
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.
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“   👉 Ludwig's XH-Templates for MultiPage & OnePage

frase
Posts: 2545
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Onepage_XH

Post by frase » Thu Jan 03, 2019 2:25 pm

lck wrote:
Thu Jan 03, 2019 2:16 pm
Man kann doc und sdoc ja eindeutig ansprechen mit:
Klar kann man.
lck wrote:
Thu Jan 03, 2019 2:16 pm
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
Posts: 13169
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Onepage_XH

Post by cmb » Thu Jan 03, 2019 3:33 pm

lck wrote:
Thu Jan 03, 2019 10:15 am
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.
cmb wrote:
Wed Jan 02, 2019 7:59 pm
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.
frase wrote:
Thu Jan 03, 2019 11:05 am
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.
lck wrote:
Thu Jan 03, 2019 2:16 pm
Scheint schon seit Onepage_XH 1.0beta2 so zu sein.
Ja, siehe https://github.com/cmb69/onepage_xh/issues/1.
frase wrote:
Thu Jan 03, 2019 2:25 pm
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.
Christoph M. Becker – Plugins for CMSimple_XH

lck
Posts: 1544
Joined: Wed Mar 23, 2011 11:43 am
Contact:

Re: Onepage_XH

Post by lck » Thu Jan 03, 2019 5:12 pm

cmb wrote:
Thu Jan 03, 2019 3:33 pm
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.
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“   👉 Ludwig's XH-Templates for MultiPage & OnePage

lck
Posts: 1544
Joined: Wed Mar 23, 2011 11:43 am
Contact:

Re: Onepage_XH

Post by lck » Thu Jan 03, 2019 5:14 pm

cmb wrote:
Thu Jan 03, 2019 3:33 pm
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
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“   👉 Ludwig's XH-Templates for MultiPage & OnePage

lck
Posts: 1544
Joined: Wed Mar 23, 2011 11:43 am
Contact:

Re: Onepage_XH

Post by lck » Thu Jan 03, 2019 7:33 pm

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 :? :) .
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“   👉 Ludwig's XH-Templates for MultiPage & OnePage

cmb
Posts: 13169
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Onepage_XH

Post by cmb » Fri Jan 04, 2019 10:57 pm

lck wrote:
Thu Jan 03, 2019 5:12 pm
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.
lck wrote:
Thu Jan 03, 2019 7:33 pm
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.
lck wrote:
Thu Jan 03, 2019 7:33 pm
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.
Christoph M. Becker – Plugins for CMSimple_XH

lck
Posts: 1544
Joined: Wed Mar 23, 2011 11:43 am
Contact:

Re: Onepage_XH

Post by lck » Fri Jan 18, 2019 10:51 am

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.
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“   👉 Ludwig's XH-Templates for MultiPage & OnePage

cmb
Posts: 13169
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Onepage_XH

Post by cmb » Fri Jan 18, 2019 12:53 pm

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).
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply