Neues "MultiOnePage" - Plugin

Ein CMSimple Support Forum für deutsch sprechende Nutzer und Entwickler
frase
Posts: 2852
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Neues "MultiOnePage" - Plugin

Post by frase » Fri Jun 28, 2019 9:26 am

Holger wrote:
Fri Jun 28, 2019 8:08 am
Aber wie muss der Code dann aussehen, damit es nicht das gleiche Dilemma wie beim Toplink wird und der Templateautor den Link komplett anders gestalten und ausrichten kann?
Denn per Plugin bleibt mir wohl lediglich nur die Möglichkeit, die Links jeweils oberhalb der Seiten-Ids, bzw. des Editors, links ausgerichtet drüber zu klatschen. Und für den Fall würde ich Icon + Text bevorzugen, weil das Icon alleine im Zweifel zu klein sein könnte. Und einfach ersetzbar, wie toplink(), sind die Funktionen im Template ja nicht.
Es wird nicht das gleiche Dilemma. Der Toplink erscheint im Frontend und will evtl. gestyled werden.
multionepage_previewlink und multionepage_editlink sind Bedienelemente für den Admin - ähnlich wie die Buttons im Pagemanager. Da wird kaum jemand auf die Idee kommen, die umstylen zu wollen - außer vielleicht die Position.
Mach es einfach so, wie du es schon hast beim multionepage_previewlink. Klatsche es darüber.
Die Dinger haben eine eindeutige Klasse und können per CSS angesprochen werden. Wat willste mehr?
Die Links befinden sich im Inhalts-Bereich und haben dadurch die im Template-CSS festgelegten Größen und Farben wie für normalen Text bzw. Links. Das müsste in 99,9% der Fälle gut sein. Damit bist du auf der sicheren Seite.

Meine private Meinung - nicht allgemeingültig:
Nur ein Button mit Icon, links der Seiten-Ids mit negativem Einzug (wie vorher schonmal vorgeschlagen).
Das könnte allerdings in einigen Spezial-Templates Probleme geben - und du erreichst die 99,9% nicht ;-)

Holger
Site Admin
Posts: 3097
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany
Contact:

Re: Neues "MultiOnePage" - Plugin

Post by Holger » Fri Jun 28, 2019 10:16 am

frase wrote:
Fri Jun 28, 2019 9:26 am
Es wird nicht das gleiche Dilemma.
Ja, hast recht.
frase wrote:
Fri Jun 28, 2019 9:26 am
Meine private Meinung - nicht allgemeingültig:
Nur ein Button mit Icon, [...].
Das könnte allerdings in einigen Spezial-Templates Probleme geben - und du erreichst die 99,9% nicht ;-)
Du meinst mit Button aber einen Link, der als Button gestyled ist, oder?
Jo, fände ich auch gut. Ist mir, als CSS-Unwissenden, aber zu kompliziert um das "robust und schön" darzustellen :( .

Werden dann halt einfache Links mit entsprechenden Klassen und vielleicht <span> - Tags, damit zur Not nachgebessert werden kann.

BTW: deine "Alternative" gefällt mir sehr gut. War da nicht mal was mit der Aufhübschung der Core-Styles?

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

Re: Neues "MultiOnePage" - Plugin

Post by frase » Fri Jun 28, 2019 10:32 am

Holger wrote:
Fri Jun 28, 2019 10:16 am
Werden dann halt einfache Links mit entsprechenden Klassen und vielleicht <span> - Tags, damit zur Not nachgebessert werden kann.
Richtig so.
Holger wrote:
Fri Jun 28, 2019 10:16 am
BTW: deine "Alternative" gefällt mir sehr gut. War da nicht mal was mit der Aufhübschung der Core-Styles?
Ja, da war mal was. Ist aber versickert, deshalb hübsche ich mir XH ganz privat etwas auf ;-)
Im Moment sollten wir froh sein, wenn überhaupt mal eine Version 1.7.3 kommt, die bereits festgeklopfte Änderungen enthält (z.B. Filebrowser).

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

Re: Neues "MultiOnePage" - Plugin

Post by lck » Fri Jun 28, 2019 12:08 pm

Holger wrote:
Fri Jun 28, 2019 6:09 am
So, im aktuellen Master sind die folgenden Punkte nun gefixt:

- sitemaplink() kann nun ganz normal verwendet werden.
Config->Versteckte Seiten in Sitemap anzeigen wird (absichtlich) nicht unterstützt.
Es macht hier keinen Sinn, weil direkte Aufrufe eh umgeleitet werden.
Dokumentation dazu fehlt noch.

- multionepage_toplink() unterstützt nun eine optionale Id

- Unbenutzbare PD-Tabs ausblenden: !important hinzugefügt

- außerdem JS Fehler beim Aufruf diverser Seiten im Admin-Menü behoben

Die komplette Übersicht ist hier: https://github.com/TN03/multionepage_xh ... 2?closed=1
Offen wäre zur Zeit noch das: https://github.com/TN03/multionepage_xh/milestone/2
und die Frage, was mit Fa_XH passiert. Wenn es im Plugin bleiben sollte, müsste man es noch ordentlich einbauen. Bisher funktioniert es ja nur, wen in Fa_XH "Require -> auto" eingestellt ist.
Super! Funktioniert alles.
frase wrote:
Fri Jun 28, 2019 7:05 am
Mein Bauchgefühl sagt mir, dass FA im Moment wahrscheinlich noch die beste und praktikabelste Lösung ist. Außerdem entspricht es so der aktuellen XH-Philosophie. FA wird ja auch (noch) im Pagemanager und anderen wichtigen Plugins verwendet und ist standard-mäßig verfügbar. Also wird es wohl das Beste sein, wenn du es "ordentlich" einbaust.
+1
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“   👉 Ludwig's XH-Templates for MultiPage & OnePage

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

Re: Neues "MultiOnePage" - Plugin

Post by frase » Mon Jul 15, 2019 2:11 pm

Grundlage für weitere Plugin-Besprechung
('s woar groad a weng Zeiid)

http://fhs.bplaced.net/mop/

multionepage_xh - aktueller master
Template - irgendwas ähnliches wie anchorific
Inhalt - Dummy
multionepage_topleveltoc() - funktioniert sauber
multionepage_toc() - ...
Ich habe es mal - um es zu benamen - "QuickLinks" genannt, weil es ja Schnell-Links zu Seiteninhalten sind.
Fragen:
Wo soll das Ding eigentlich hin?
Soll es permanent geöffnet sein? Überhaupt umschaltbar?
Was passiert bei schmalen Viewports -> dann überhaupt nötig? -> ab wann nicht mehr?
Muss es permanent im Blickfeld bleiben? (denke ja -> sticky, funzt nur mit modernen Browsern)
Wie hoch darf es sein?

Anzeige der Levels
Wäre es nicht besser im Plugin zu konfigurieren, wieviele Levels man bei den QuickLinks anzeigen möchte (Tiefe)?
Ich habe im Beispiel nur bis L4 formatiert. Mehr dürfte nicht sinnvoll sein - oder? (siehe Seite Menu Levels)

Sollte es in den PD-Tabs die Möglichkeit geben: Diese Seite ohne QuickLinks?
Wenn es nur wenige oder nur eine Unterseite gibt, sind die evtl. überflüssig.

onepage_customOffset
In diesem Template muss dieser Wert berechnet werden. Ich habe extra die ganzen Newsboxen sichtbar geschaltet, damit die Zeile umbrechen muss bei zu schmalen Viewports. Damit wird ein neuer onepage_customOffset fällig.
Die Berechnung dafür steht im Template ganz unten (script).
Problem: wird der Viewport gedreht (geändert) müsste on the fly ein neuer Offset berechnet werden. Ich habe es mit einer $(window).resize(function () versucht (ebenfalls im Template, auskommentiert) - das hat nicht geklappt.

Aus Zeitgründen jetzt erstmal genug.
Über das Handling im Adminmodus reden wir später.

Holger
Site Admin
Posts: 3097
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany
Contact:

Re: Neues "MultiOnePage" - Plugin

Post by Holger » Mon Jul 15, 2019 8:55 pm

frase wrote:
Mon Jul 15, 2019 2:11 pm
Grundlage für weitere Plugin-Besprechung
('s woar groad a weng Zeiid)

http://fhs.bplaced.net/mop/
Schön :) .

Erstmal zum Technischen:
frase wrote:
Mon Jul 15, 2019 2:11 pm
onepage_customOffset
In diesem Template muss dieser Wert berechnet werden. Ich habe extra die ganzen Newsboxen sichtbar geschaltet, damit die Zeile umbrechen muss bei zu schmalen Viewports. Damit wird ein neuer onepage_customOffset fällig.
Die Berechnung dafür steht im Template ganz unten (script).
Problem: wird der Viewport gedreht (geändert) müsste on the fly ein neuer Offset berechnet werden. Ich habe es mit einer $(window).resize(function () versucht (ebenfalls im Template, auskommentiert) - das hat nicht geklappt.
Ich habe es eben mal in einem anderen Template getestet, was dann so wie unten auch funktioniert hat :? :

Code: Select all

<script>
var onepage_customOffset = $('.classname').innerHeight() + 10;
console.log(onepage_customOffset);

$(window).resize(function () {
    onepage_customOffset =  $('.classname').innerHeight() + 10;
    console.log(onepage_customOffset);
});
</script>
In der Konsole ist das auch nachvollziehbar (produktiv dann natürlich auskommentieren).

Den Rest muss ich mir noch genauer überlegen.
Aber, was eigentlich klar sein sollte: es geht um Multi-Onepager. Also mehrere Onepager in einer Seite. Das Onepagemenü halte ich schon für wichtig und es sollte, wie beim Anchorific-Template, auch immer sichtbar sein (halt ohne JS, immer offen).
Bei kleinem Viewport stelle ich mir das ähnlich vor. Eventuell dann die Links zu den Kindseiten nur für den jeweiligen Onepager sichtbar (wobei die jetzige "QuickLinks" - Lösung auch was hat!).
BTW: auch das https://www.ge-webdesign.de/h2onepagers/ wäre eine Option -- halt nur für L2-Unterseiten geeignet und Menü müsste oben fixed sein.
frase wrote:
Mon Jul 15, 2019 2:11 pm
Sollte es in den PD-Tabs die Möglichkeit geben: Diese Seite ohne QuickLinks?
Wenn es nur wenige oder nur eine Unterseite gibt, sind die evtl. überflüssig.
Coole Idee! Aber nicht speziell für die Quick-Links. Vielleicht etwas Allgemeineres, das man, je nach (Template-) Anforderungen / Features, universell nutzen könnte. Eine CSS-Klasse im <body>, die per Checkbox aktiviert wird? Oder...? Möglichst allgemein und möglichst auch ohne JS.

Aber, wie gesagt, ich muss noch einmal genauer überlegen.

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

Re: Neues "MultiOnePage" - Plugin

Post by frase » Tue Jul 16, 2019 11:07 am

Holger wrote:
Mon Jul 15, 2019 8:55 pm
Erstmal zum Technischen:
Tja, da bist du genau wie ich dem gleichen Irrtum aufgesessen.
Dein Skript funktioniert. Der richtige Wert wird geloggt.
Nur: Dein multionepage.js bekommt von der Änderung nichts mit.
Das schaut nur einmal beim Laden oder Reload nach dem onepage_customOffset.
Vielleicht gehört die resize-Funktion deshalb in das Plugin-Skript? Oder wäre das zu speziell?
Ich denke allerdings, dass ein solcher Fall wohl häufiger vorkommen wird (siehe weiter unten).

Womit wir auch schon beim eigentlichen Thema wären: MultiOnePage.
Nach meiner Meinung sollte es bei solchen Seiten eine HauptNavi geben (multionepage_topleveltoc() = L1 = OK).
Dann gibt es ein Sprung-Menü zu den einzelnen Abschnitten (multionepage_toc() - hier mal QuickLinks genannt).
Wo das Sprungmenü angeordnet wird, direkt unter dem Hauptmenü oder an anderer Stelle, ob neben- oder untereinander, ist nur Sache des Geschmacks und der Styles.
Allerdings denke ich, dass ein Sprungmenü das mit wegscrollt - also nicht permanent im Blickfeld bleibt - überflüssig wäre.
Bei Gerts (guten) Templates H2OnePagers oder ML2OnePagers ist das irgendwie suboptimal. Das Sprungmenü scrollt weg und man muss erst hochscrollen (evtl. an gesuchten Inhalten vorbei) um den nächsten Punkt anzuhüpfen.
Also ist meine Meinung: Die QuickLinks (oder das Sprungmenü) irgendwo fixed oder sticky positionieren.
Das wird bei schmalen Antippgeräten (Mobiles, Cellphones, Wichtigtuter) ziemlich eng.
Die eine Möglichkeit wäre (wie bei anchorific) ab einer bestimmten Viewportgröße auf das Sprungmenü zu verzichten. Denn eigentlich kann man dann ziemlich gut und schnell wischen.
Die andere Möglichkeit wäre ab einer bestimmten Viewportgröße das Sprungmenü mittels Button o.Ä. einblendbar zu machen.

Es wäre schön, wenn es von anderen Usern (Ludwig, Richu ?) noch weitere Gestaltungs-Vorschläge gäbe, damit man die unterschiedlichen Ansätze vergleichen könnte. Es muss ja kein fertiges Super-Template sein (siehe meine Demo).

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

Re: Neues "MultiOnePage" - Plugin

Post by lck » Tue Jul 16, 2019 12:22 pm

frase wrote:
Tue Jul 16, 2019 11:07 am
Wo das Sprungmenü angeordnet wird, direkt unter dem Hauptmenü oder an anderer Stelle, ob neben- oder untereinander, ist nur Sache des Geschmacks und der Styles.
Allerdings denke ich, dass ein Sprungmenü das mit wegscrollt - also nicht permanent im Blickfeld bleibt - überflüssig wäre.
Denke ich auch.
frase wrote:
Tue Jul 16, 2019 11:07 am
Also ist meine Meinung: Die QuickLinks (oder das Sprungmenü) irgendwo fixed oder sticky positionieren.
Das wird bei schmalen Antippgeräten (Mobiles, Cellphones, Wichtigtuter) ziemlich eng.
Die eine Möglichkeit wäre (wie bei anchorific) ab einer bestimmten Viewportgröße auf das Sprungmenü zu verzichten. Denn eigentlich kann man dann ziemlich gut und schnell wischen.
Die andere Möglichkeit wäre ab einer bestimmten Viewportgröße das Sprungmenü mittels Button o.Ä. einblendbar zu machen.
Da bin ich deiner Meinung, bei kleinen Viewports beansprucht das OnePage-Menü zu viel Platz und überdeckt damit zu viel Content.
frase wrote:
Tue Jul 16, 2019 11:07 am
Es wäre schön, wenn es von anderen Usern (Ludwig, Richu ?) noch weitere Gestaltungs-Vorschläge gäbe, damit man die unterschiedlichen Ansätze vergleichen könnte. Es muss ja kein fertiges Super-Template sein (siehe meine Demo).
Ansatz ist da, habe vor ein paar Tagen mal angefangen etwas zu entwickeln (ist aber noch nicht vorzeigbar und die Zeit dafür ist momentan einfach zu knapp). Meine Vorstellung: horizontales Level-1 Menü und ein vertikales Onepage-Menü (Sprungmenü). Das Onepage-Menü bei mobilen Geräten (kleinere Viewports) ausblenden oder nur Level-2 Links anzeigen. Oder, eine Dot-Navigation (oder ähnliches/platzsparendes) ausgeben, also ohne Linktext und diesen eventuell bei hover oder aktivem Link anzeigen.
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“   👉 Ludwig's XH-Templates for MultiPage & OnePage

Holger
Site Admin
Posts: 3097
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany
Contact:

Re: Neues "MultiOnePage" - Plugin

Post by Holger » Tue Jul 16, 2019 12:41 pm

frase wrote:
Tue Jul 16, 2019 11:07 am
Tja, da bist du genau wie ich dem gleichen Irrtum aufgesessen.
Dein Skript funktioniert. Der richtige Wert wird geloggt.
Nur: Dein multionepage.js bekommt von der Änderung nichts mit.
Klar, blind :roll: . Fix kommt ASAP.
frase wrote:
Tue Jul 16, 2019 11:07 am
Womit wir auch schon beim eigentlichen Thema wären: MultiOnePage.
Ich stimme dir komplett zu.

Optisch würde mir besser gefallen, wenn die "Quick-Links" nicht in einer Box wären, sondern eher so wie bei anchorific-pure, maximal mit dünner Linie senkrecht abgegrenzt und ohne Überschrift. Vielleicht sogar auch mit Toplink-Icon drüber.
Bei schmalem Viewport dann ähnlich wie jetzt, als Balken mit Toggle-Icon, direkt unten am L1-Menü, ein- und ausklappbar.
[Edit] Vielleicht wäre es auch gut, wenn das gesamte Menü (L1 + OP-Menü) einklappbar werden. [/Edit]
lck wrote:
Tue Jul 16, 2019 12:22 pm
Ansatz ist da, habe vor ein paar Tagen mal angefangen etwas zu entwickeln (ist aber noch nicht vorzeigbar und die Zeit dafür ist momentan einfach zu knapp). Meine Vorstellung: horizontales Level-1 Menü und ein vertikales Onepage-Menü (Sprungmenü). Das Onepage-Menü bei mobilen Geräten (kleinere Viewports) ausblenden oder nur Level-2 Links anzeigen. Oder, eine Dot-Navigation (oder ähnliches/platzsparendes) ausgeben, also ohne Linktext und diesen eventuell bei hover oder aktivem Link anzeigen.
Hört sich auch gut an!

Aber macht keinen Stress...

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

Re: Neues "MultiOnePage" - Plugin

Post by frase » Tue Jul 16, 2019 2:39 pm

Holger wrote:
Tue Jul 16, 2019 12:41 pm
Fix kommt ASAP.
Auch dir: Kein Stress.
Holger wrote:
Tue Jul 16, 2019 12:41 pm
Optisch würde mir besser gefallen, wenn ...
Klar. Da gibt es Millionen Möglichkeiten.
Das Beispiel ist ja auch (noch) gar kein Template sondern nur eine Rede-Grundlage.
Mal sehen, wie es sich entwickelt. Wenn Zeit ist, werde ich da sicher noch rumschrauben.
lck wrote:
Tue Jul 16, 2019 12:22 pm
Ansatz ist da, habe vor ein paar Tagen mal angefangen etwas zu entwickeln (ist aber noch nicht vorzeigbar und die Zeit dafür ist momentan einfach zu knapp). Meine Vorstellung: horizontales Level-1 Menü und ein vertikales Onepage-Menü (Sprungmenü). Das Onepage-Menü bei mobilen Geräten (kleinere Viewports) ausblenden oder nur Level-2 Links anzeigen. Oder, eine Dot-Navigation (oder ähnliches/platzsparendes) ausgeben, also ohne Linktext und diesen eventuell bei hover oder aktivem Link anzeigen.
Grundsatz: Uns treibt niemand - außer wir selbst ;-)
Wenn mehrere Vorschläge vorhanden sind, stoßen wir vielleicht eher auf Probleme oder geniale Lösungen - wer weiß?
Insofern muss dein Entwurf nicht "vorzeigbar" sein. Es genügt, wenn er deine Idee der Anordnung usw. rüberbringt.
Und nebenbei geht es ja auch noch um das Handling und Aussehen im Adminmodus. Und es ist immer besser, wenn mehrere Augen draufschauen ;-)

Post Reply