OnePage mit jQuery [abgetrennt von OP-Template "OP_IHave a

[lck]

Das kam auch schon mal zur Sprache. Normalerweise kann man ja mit den Klassen .doc und .sdoc die Links gut gestalten.

[lck]

Hm, nth-child(N) ist aber eigentlich genauso fragil wie die numerischen oder namensbasierten IDs, oder? nth-child(odd|even) könnte man auch jetzt schon nutzen, wenn man es auf einen Container im Template bezieht (z.B. .tpllck_content), soweit ich es überblicke.

Das wird auch schon genutzt, wenn du dir die Templates mal anschaust.
Es geht um rein bessere, optische Gestaltung der einzelnen onepage_page-Seiten, z.B. Hintergrundfarbe und dergleichen. Mit einem zusätzlichen umgebenden div-Container sind da mehr Möglichkeiten gegeben als mit nur einem Einzigen.

[frase]

@ Christoph

cmb hat geschrieben
Ist eine zweite Klasse wirklich nötig? Kannst Du nicht über einen übergeordneten Container stylen (.container .onepage_page)? Vielleicht ist das eine dumme Frage, aber ich habe mich mit Bootstrap noch nicht beschäftigt.

Das habe ich bisher so gemacht im Controler geändert:

Code: Select all

<div id="%s" class="onepage_page">
<div class="container">%s</div>
</div>

Besser wäre es, wenn ich nicht mehr in euren Dateien herumbastle.
Der zusätzlich div könnte somit entfallen.

Hol Dir Dein Bootstrap. Sehr gute Doku.
http://holdirbootstrap.de/

@Ludwig

lck schrieb
Das kam auch schon mal zur Sprache. Normalerweise kann man ja mit den Klassen .doc und .sdoc die Links gut gestalten.

Es geht um Hervorhebung während des Scrollens, abhängig von der Seitenposition.

[cmb]

um den gerade aktiven Menüpunkt hervorzuheben - auch während des Scrollens - ginge möglicherweise sowas Ähnliches in der onepage2.js:
[…]

Geplant ist das schon lange, ich kam aber leider noch nicht dazu. Dein Code könnte hilfreich sein – danke!

2. Es braucht einen optionalen top-Offset für Layouts/Templates mit fixer Nav oben. -> Konfiguration
Das hilft vielleicht auch anderen.

Das Thema hatten wir auch schon mal angesprochen

Danke für den Link, Ludwig. Das hatte ich wohl im Issue-Tracker noch nicht vermerk, was ich nun nachgeholt habe.

Würde ich so nicht zustimmen, eigentlich ist das eine Plugin-Sache und keine direkte Template-Geschichte.

Sehe ich auch so. Soll ich alle relevanten Posts in einen neuen Thread verschieben? Ich hoffe, dass dann die externen Links noch funktionieren, wenn ich die alten Posts als Shadows erhalte (wenn das überhaupt geht; bin kein phpBB Experte).

Es geht um rein bessere, optische Gestaltung der einzelnen onepage_page-Seiten, z.B. Hintergrundfarbe und dergleichen. Mit einem zusätzlichen umgebenden div-Container sind da mehr Möglichkeiten gegeben als mit nur einem Einzigen.

Okay. Ich habe das Issue entsprechend angepasst.

Das habe ich bisher so gemacht im Controler geändert:
[…]

Hm, das ist aber genau anders herum als das was Ludwig sich wünscht. Ist es möglich, beide Wünsche mit einer Klappe zu erschlagen?

Hol Dir Dein Bootstrap. Sehr gute Doku.

Danke für den Link.

[lck]

Das habe ich bisher so gemacht im Controler geändert:

Code: Select all

<div id="%s" class="onepage_page">
<div class="container">%s</div>
</div> 

Hm, das ist aber genau anders herum als das was Ludwig sich wünscht. Ist es möglich, beide Wünsche mit einer Klappe zu erschlagen?

Im Prinzip ist es das Gleiche. Frank hat halt einen inneren Container hinzugefügt und über die Klassennamen und Anordnung kann man sich ja noch streiten

Der zusätzlich div könnte somit entfallen.

Was meinst du genau damit, du willst doch das Gleiche, ein zusätzliches div.
Nochmal zum besseren Verständnis, bisher siehts in der Controller.php so aus:

Code: Select all

<div id="%s" class="onepage_page">%s</div> 

[frase]

Hi Ludwig,
jaja, manchmal bin ich nicht schnell genug - ist zu viel Input von allen Seiten, begrenztes Aufnahmevermögen.

Du hast Recht, wir meinen beinahe das Gleiche.
Wenn ich richtig verstehe, möchtest du, wenn möglich, jeden div individuell gestalten. Hintergrund-Farbe, -Bild usw.
Soweit okay?
Da hilft aber weder eine Nummer noch eine allgemeine Klasse noch ein zusätzlicher div - du könntest sie nicht ansprechen.
In meinem Fall ist es egal, ob ich einen zusätzlichen div einfüge oder dem div mit der onepage_page-Klasse noch eine weitere anfüge.
Auch ich will Styles für bestimmte divs verändern.

Zwei Möglichkeiten:
1. Bisher habe ich im Template händisch abgefragt, ob ein bestimmter div vorhanden ist und dann Klassen oder Styles hinzugefügt oder entfernt.
Und zwar mit jQuery. (das sind umständliche unkomfortable und fehleranfällige Template-Funktionen, ich wusste es nicht anders)
2. Es gäbe aber die Möglichkeit, dass das Plugin in irgendeiner Form im Editor (evtl. über den "Seite"-Tab ähnlich wie bei Morepagedata) ein Feld oder mehrere Felder zur Verfügung stellt, in die man zusätzliche Klassen Eintragen kann.
Diese Klasse(n) werden dann dem (und nur dem dieser Seite) onepage_page-Div hinzugefügt. (idealerweise mit der Möglichkeit auch KLassen zu entfernen oder zu ersetzen - das bräuchte ich)
Alles Weitere kann dann jeder im CSS selber gestalten.

So wie es jetzt ist - jeder 2te div erhält eine andere Hintergrundfarbe - könnte/sollte so bleiben als Standard, wenn nichts anderes angegeben.

Die zweite Möglichkeit wäre echt toll - macht aber 'ne Menge Arbeit für Christoph und/oder Holger.

(Übrigens: "container" als className stammt nicht von mir = Bootstrap)

Und hier sind wir wieder bei einem neuen Plugin-Thread. Ich habe noch so einige Ideen für das Onepage-Plugin in der Pipeline. Aber schon das Ausformulieren is nich Ohne.

@Christoph
Ich wäre sehr einverstanden, mit einer Verschiebung/Neueröffnung wie oben angeboten.

[cmb]

Hm, das ist aber genau anders herum als das was Ludwig sich wünscht. Ist es möglich, beide Wünsche mit einer Klappe zu erschlagen?

Im Prinzip ist es das Gleiche. Frank hat halt einen inneren Container hinzugefügt und über die Klassennamen und Anordnung kann man sich ja noch streiten

Dann tut das bitte mal (natürlich nicht wirklich streiten, sondern sachlich diskutieren). Mit ist's egal, ich will halt ungern beide/mehrere Varianten einbauen.

Es gäbe aber die Möglichkeit, dass das Plugin in irgendeiner Form im Editor (evtl. über den "Seite"-Tab ähnlich wie bei Morepagedata) ein Feld oder mehrere Felder zur Verfügung stellt, in die man zusätzliche Klassen Eintragen kann.
Diese Klasse(n) werden dann dem (und nur dem dieser Seite) onepage_page-Div hinzugefügt. (idealerweise mit der Möglichkeit auch KLassen zu entfernen oder zu ersetzen - das bräuchte ich)

Es gibt auf jeden Fall die Möglichkeit, wie bereits weiter oben erwähnt, dass man der jeweiligen Überschrift eine Klasse per HTML-Ansicht zuweist. Ist für den Anwender nicht so komfortabel, aber im Prinzip entspricht das der klassischen CMSimple-Philosophie.

Ich selbst finde ja, dass es so simple heutzutage nicht mehr geht (oder besser gesagt, dass es nur sehr wenige Anwender gibt, die die Vorteile schätzen können). Daher wäre ein Pagedata-Tab für eine individuelle Klasse gar nicht so abwegig. Im Prinzip habe ich das bei Toxic_XH auch schon mal programmiert (da wird die Klasse aber nur für das Menü verwendet). Schaut Euch doch das Plugin mal an, falls Ihr es noch nicht kennt; in der Konfiguration können die verfügbaren CSS-Klassen vorbelegt werden, so dass der Anwender nichts mehr viel falsch machen kann. Das Konzept könnte für den Onepage-Fall (und natürlich auch den Toxic-Fall) noch erweitert werden, indem das Template diese Klassen selbst festlegen kann. Das geht mit ein bisschen Trickserei allerdings auch jetzt schon notdürftig; oben in template.htm einfügen:

Code: Select all

<?php $plugin_cf['toxic']['classes_available']="tpl_page_red,tpl_page_green";?>

[lck]

Dann tut das bitte mal (natürlich nicht wirklich streiten, sondern sachlich diskutieren). Mit ist's egal, ich will halt ungern beide/mehrere Varianten einbauen.

Edit: Wir streiten doch nicht wirklich. Die Änderungen müssen dann sowieso intensiv getestet werden.

Was Bootstrap betrifft, bin ich hier raus.

Wenn ich richtig verstehe, möchtest du, wenn möglich, jeden div individuell gestalten. Hintergrund-Farbe, -Bild usw.
Soweit okay?
Da hilft aber weder eine Nummer noch eine allgemeine Klasse noch ein zusätzlicher div - du könntest sie nicht ansprechen.

Per css geht einiges und man sollte das Ganze nicht zu verkomplizieren.

[Holger]

Hallo zusammen!

Ui, so viel Lesestoff .

@Holger

*** Awesome! ***

Wenn es bei mir eine Webcam gäbe, hättet ihr heute Nacht sehen können wie einer in den Tisch beißt.
Woher kommt denn diese kurze onepage.js? Ist das die Ursprungsversion?

Also, Schnelltest. Ich glaube, ich bekomme das hin, es in meinem Template zu verwenden.
[..}

Die kurze onpage2.js habe ich neu geschrieben. Aber freu' Dich da mal nicht zu früh. Für den speziellen Fall mag es vielleicht passen. Aber allgemein?
Die ersten Problemchen sind ja schon aufgetaucht:

Eine Sache ist mir auch schon in deiner Demo aufgefallen. Nachvollziehbar bei einem Viewport von kleiner 980px, also wenn das Menü für kleine Viewports aktiv ist.
Klickt man zum Beispiel auf "News02" springt die Seite fast zu "News03". Mit der Originalversion von Christoph passiert das nicht. Als Vergleich hier die Demo von op_ihaveadream mit Christoph's Version Onepage_XH-1beta1.
Wenn man die Scroll-Duration mal auf 3000 setzt, sieht man auch den Unterschied. Bei Christoph's Version wird erst das Menü geschlossen und dann gescrollt, bei deiner Version ist es umgekehrt.

In Firefox passiert das nicht, wie ich festgestellt habe. Aber schon mit Chrome sieht man das Übel. Nein, es hat nichts damit zu tun wann das Menü geschlossen wird. Auch die Scroll-Distanz habe ich mal per console.log() überprüft. Das Problem liegt an... ja woran? Es sind mehrere Ursachen. Es hat damit zu tun wie das Template das Menü per CSS :target öffnet und schließt. Das "beißt" sich jetzt mit jQuerys animate(). Beim Scrolling mit animate() wird die URL im Browser (und auch die History) nicht aktualisiert, wenn eine ID "angesprungen" wird (das sieht man auch schön in Franks Demo). Bei deiner CSS-Lösung ist das aber notwendig. Also aktualisiere ich die URL nach dem Scrollen mittels window.location.hash = target im Callback von animate(). Das bewirkt im Browser, dass der Hash in der Variable target nochmal angesprungen werden soll. Das ist gängige Praxis und dabei sollte eigentlich nichts passieren, denn der Browser befindet sich ja normalerweise an der richtigen Position. Da Chrome, im Gegensatz zu FF, wohl dabei von der falschen Position ausgeht (obwohl animate() ganz sicher an die richtige Stelle gesprungen ist), hüpft die Anzeige dann noch einmal um die Menühöhe weiter. Diese falsche Position könnte auch etwas mit der Browser-History zu tun haben. Ein einfacher Workaround wäre, per window.location.hash zunächst eine ungültige ID (oder einfach "#") anzuspringen. Dabei bleibt der Browser dann an seiner Scrollposition. Der nochmalige Aufruf mit dem richtigen Hash bringt dann Chrome dazu nachzurechnen. Und siehe da: alles passt - ganz ohne hüpfen.
Aber: das wäre eine Sache speziell für ein Template und außerdem ist die Aktion auch mittels Back-Button für den User sichtbar. Ok, auch den Eintrag könnte man anschließend aus der Browser-Historie löschen...

Nicht schön. Und ehrlich gesagt enttäuscht mich das jetzt auch. Denn eigentlich sollte der Test mit jQuery mehr Kompatibilität bringen... .

So langsam frage ich mich ob der Versuch überhaupt Sinn macht, solch eine universelles onpage.js dem Plugin beizulegen. Wie man sieht ist es in der Regel mit ein paar Zeilen im Template-Ordner getan. Und auch für das aktuell in der Demo genommene Template gibt es eine passende Lösung. Aber wirklich universell?
Der nächste Punkt wäre ein Offset für Menüs mit position:fixed, den man vielleicht abhängig des Viewports noch anpassen müsste. Da hilft dann auch keine Konfigurationsvariable mehr. Und was, wenn der User einmal das Template wechselt?

Zu den anderen Punkten habe ich auch noch Ideen. Aber dazu später. Für mich wird's jetzt erst 'mal Zeit.

LG
Holger

[cmb]

@Christoph: es läuft nun (sauber) mit und ohne aktiviertem JavaScript. Allerdings hattest Du Recht: ohne $sn geht es nicht. Die Menülinks von ihrem Pfad zu befreien ist also keine gute Idee. Am JS musste ich zusätzlich auch noch ein paar Prüfungen etc. einbauen um potentielle Fehler abzufangen. Auch ein weiterer Fix, ähnlich der ursprünglichen fixViewModeLink() - Funktion, war noch nötig. Trotzdem sind nur ein paar wenige Zeilen dazu gekommen.
Ich hoffe es passt so ziemlich...

Bezüglich der $sn Sache bin ich gerade auf eine entsprechende Anfrage von manu gestoßen. Ganz interessant: ursprünglich hatte ich $sn drin, dann hatte Ludwig angemerkt, dass das $sn wohl unnötig ist, so dass ich es entfernt habe. Daraufhin hat Knollsen bemängelt, dass nach dem Logout erst mal nichts mehr funktioniert, so dass ich es wieder eingefügt habe. manus Argumente müsste ich mir noch mal genauer anschauen, aber das Problem mit den Formularen wiegt wohl schwerer.

Bezüglich des display:none für #onepage_toplink, das Du eingefügt hast: das finde ich nicht so gut, falls kein JS verfügbar ist. Daher habe ich das per JS und zwei zusätzlichen Klassen gelöst.

Bezüglich des (Nicht-)Ladens des JS im Bearbeitungsmodus: da bin ich nicht ganz sicher, da dann zumindest der Toplink immer sichtbar wäre. Vielleicht ist Deine Idee, den Toplink per CSS auszublenden, doch das beste. Vielleicht sollte auch das JS aufgeteilt werden?

Bezüglich der Beschränkung des smooth Scrolling auf Links mit scrollTo Klasse bin ich mir nicht wirklich sicher. Wenn der Anwender manuell interne Links setzt, dann wäre es eigentlich schön, wenn auch diese weich Scrollen würden, ohne dass manuell die entsprechende Klasse vergeben werden soll. Aber irgendein Problem gab es wohl mit der derzeitigen Variante – ich muss mal suchen, was ich aber auf "Morgen" verschiebe.

Bezüglich der jQuery-Variante: die würde ich, wie schon gesagt, einbauen. Konfigurierbar, aber als Default. Wenn Du nichts dagegen hast, übernehme ich die derzeitige Variante (und passe ggf. an). Okay?

Jetzt sehe ich gerade, dass Holger noch mehr gepostet hat – uff! Also später weiter.

PS:

Also aktualisiere ich die URL nach dem Scrollen mittels window.location.hash = target im Callback von animate().

Im onepage.js habe ich das gerade anders herum gemacht: erst die location ändern, und dann scrollen. Vielleicht auch für die jQuery-Variante eine Möglichkeit?