Ich stelle mir das einfach irgendwie anders vor...
Heute Nachmittag habe ich mal kurz gesucht und bin auf dieses Hamburger-Menü gestossen: https://codepen.io/ahmedhrayyan/pen/EremLG. (Noch besser gefallen hätte mir dieses hier: https://codepen.io/foxeisen/pen/YgEwbK doch ich traute mir nicht zu, die unnötigen Variationen zu löschen. Zudem war der Downloadcode auf github nicht mehr verfügbar).
Stand-alone und lokal habe ich das relativ rasch lauffähig gekriegt. Dann versuchte ich das Ganze auf https://styx.beatsblog.ch/ zu integrieren (in index.tpl, pure.js & user.css). Wie Du sehen kannst: Mit nur mässigem Erfolg.
Egal. So in etwa (einfach richtig funktionierend und in schön) stelle ich mir das vor. Bei Gelegenheit werde ich daran wohl noch etwas weiter herumexperimentieren.
Und ja: es wäre unabhängig vom ausgewählten Theme. Deshalb die Idee der Integration in Form eines Plugins, damit man die Links und deren Texte in einer Backend-Oberfläche eintragen könnte.
Wobei... wenn ich programmieren könnte so denke ich, dass es durchaus realisierbar wäre, die Werte der globalen Navigation in das Hamburger-Menü zu überführen. Dann wäre die Frage nur noch, ob der User ein Hamburger-Menü will, oder nicht.
Das zweite ist ein off-canvas menu. So wie das im Backend. Off Canvas ist ein hochfliegender Name der eigentlich nur bechreibt was es macht bzw ist. Es is ein Menü das wie eine Karte aus dem Seitenoff heraus in den sichtbaren Bereich hereinschliddert.
Im Moment hast du auf styx.beat nur einen Hamburger Button,und unsinnigerweise auch auf Desktops, der aber 1. deinen Zugang zur Entry Liste verhindert, jedenfalls für mich (...obwohl jetzt hab ich ihn wieder gefunden ?), und 2. die merkwürdige Eigenschaft besitzt im FF dev screen für Displaygrößen total zu blockieren, so dass man nicht daraus heraus kommt, außer den Browser neu zu starten.
Was du meines Verständnisses immer noch nicht ganz verstehst ist ja, dass es sich bei all solchen Beispielen um Beispiele handelt, in der das script auch die (ehemalige) Navigation erstellt. Das aber ist in deinen Themes und damit in Serendipity schon onboard. Die Navigation ist also das was schon da ist, und was ja auch genauso bleibt wie es da steht und abgestimmt ist, auch an dem alten Platz im #serendipity_banner Header, also:
BLOG
Kategorien
Stichworte
Suche
Fotogalerie
Verkaufe
Link(s)
Recht(s)
Es gilt also die gefundenen CSS, und wenns sein muss auch JS Schnipsel, Beispiele genau darauf zielen zu lassen, so dass sie ausgeblendet sind auf Mobiles und nach Belieben gestyled eingeblendet werden nach dem Klick auf den Hamburger, bzw ab bestimmten Größen wieder genauso sind wie ehedem auf Desktops.
Im Grunde sollte man also erstmal allen Spielkram auf die wesentliche Grundfunktionalität eindampfen. Später, wenn dann alles richtig läuft, kann man es aufpimpen.
Hilft das?
Und ja: es wäre unabhängig vom ausgewählten Theme. Deshalb die Idee der Integration in Form eines Plugins, damit man die Links und deren Texte in einer Backend-Oberfläche eintragen könnte.
Soetwas ginge eben nur über ein Plugin das einen Batzen javascript auf den Rechner des Besuchers schleust und alle gelieferten html nav Elemente entsprechend umstellt, mit events versieht und mit angereichertem CSS versieht.
Unabhängig vom theme geht es sowieso nicht, da ein Theme eine config haben muss, die eine Navigationstruktur (nur des Themes selbst, bzw eben jene auch global gesetzt, also in anderen Themes übernahmefähig) beschreibt und einstellt. Das heißt, das vom System über das Theme nur die Grundstruktur geliefert wird, der Rest aber vom Theme erlaubt und komplementiert wird.
Komplette Unabhängigkeit wäre eine Nebenläufigkeit zum System selbst. Das kann man sicher machen, aber vom Aufwand wäre es sicherlich einfacher wenn man das nimmt was es schon gibt und dies entsprechend über die template Dateien und das CSS anpasst.
Beat Post author am |
A propos rollendes Jahr in der Statistik: Wäre es möglich in der Grafik "Aufrufe, auf den Monat bezogen" nicht das aktuelle Kalenderjahr, sondern eben das rollende Jahr (die letzten 12 Monate) darzustellen?
So wie es jetzt ist, hat man Anfang eines Jahres immer wenig Möglichkeiten um eine Tendenz festzustellen.
Nur so eine Idee.
Beat Post author am |
Ich bin halt leider etwas schwer von Begriff und brauche immer mehrere Anläufe, bis ich die Zusammenhänge so erkenne, wie sie für Dich schon lange glasklar sind. ?
Auf der einen Seite ist es mir nicht so wichtig, dass ich unbedingt eine andere Lösung, als die bereits Bestehende, brauchen würde. Die funktioniert ja gut und braucht auch einen Klick weniger. Auf der anderen Seite finde ich ein Hamburger-Menü einfach cool und es juckt mich ab und zu in den Fingern und dann bastle ich etwas vor mich hin.....
Ich verstehe einfach nicht ganz, weshalb Dir ein "echtes Hamburger-Menü" so gegen den Strich geht. Aber, ich bin nicht das Mass der Dinge. So freue ich mich beispielsweise immer wieder am "go-to-top"-Button, scheine aber wirklich der Einzige zu sein, der so etwas toll findet. Das gibt es weder bei S9Y noch bei Styx und die Integration ist anscheinend auch kein Bedürfnis.
Ich verstehe [...] nicht [...], weshalb Dir ein "echtes Hamburger-Menü" so gegen den Strich geht.
Diese Behauptung kann ich nicht nachvollziehen. Gar nicht! ?
Ich fand halt den Hamburger unten einfach interessanter in Pure. Ansonsten ist es doch dieselbe Funktionalität. Oder nicht?! Klar, Off-Canvas hat es nicht. Aber das ist nur eine CSS+ Geschichte.
Der to top button ist zB in B46 bereits angelegt, ohne javascript halt. Das sind so featuristische Zugaben.
Wer nun soetwas gerne haben will kann es ja super einfach selbst einfügen so wie du.
Beat Post author am |
? "super einfach selbst einfügen" -> you made my day! ?
Dafür habe ich Matthias 3x um (Nach-)Hilfe gebeten und das hat mich ein Video aus seiner Wishliste gekostet. ? Aber ja, wer's kann, der kann das super einfach einfügen. ?
Irgendwie möchte ich das Hamburger-Thema beenden...
Um es einfach nocheinmal zu erwähnen. Den pure-Hamburger habe ich verworfen, weil man unten auf den Hamburger klickt und dann von oben der Header mit Menü eingeblendet wird. Ich mag meinen go-to-top-Button und komme damit an das genau gleiche Ziel. Ohne, dass ich unten immer diese Menüzeile eingeblendet habe. Die pure-Hamburger Lösung hat den Vorteil, dass die Seite nicht scrollt (wenn man das einen Vorteil nennen will). Meine go-to-top Lösung hat den Vorteil, dass sie nicht nur nach oben scrollt, sondern auch noch das Menü einblendet. (Vielleicht müsste ich das nach oben zeigende Dreieck noch um drei Hamburger-Längsstriche ergänzen). ?
Ja eben, das ist doch auch schick so. Ich habe ja auch nicht rumgemäkelt das Beat keinen Hamburger hat... (obwohl, .. hat er ja doch, er weiß es nur nicht... tztztz!)
Ist dir schon mal aufgefallen, dass dein jAlbum mit einem > beginnt? Ich nehme an es ist ein versehen und wird wahrscheinlich durch das javascript res/all.min.js bzw einem dort aufgerufenen weiteren scriptes nach dem body und nach einem der property og: eingesetzt, siehe:
Vielleicht findest du das ja als >> irgendwo in den dazugehörigen Dateien.
Ansonstem immer wieder tolle Reise, tolle Bilder! ?
Beat Post author am |
Danke für den Hinweis. Hab das auch mal gesehen, doch so auf die Schnelle keine Lösung gefunden.
Heute habe ich nun das Skin/Theme auf den neusten Stand aktualisiert, das Album neu generiert und hochgeladen. Und siehe da: Dieses >Dingens ist weg! ?
Und: Ja... seufz... schön war's! Dieses Jahr wegen Corina Corona und Hausumbau wohl kein Bike-Urlaub. ?
Ich denke, dass am 01.03.2021 der nächste "Checkpoint" ansteht. ?
...und offenbart, dass ich zu voreilig, und ein besonderer Fall eben doch noch nicht bedacht war, denn in Schaltjahren ist nach dieser Rechnung der 1. März eben doch eigentlich nur ein (eingeschobener) 29. Februar.
Der Algorithmus für multiyear Anzeigen zählt einfach den Tag + (365/366) hoch, damit man die Einträge mit wenig Aufwand aus dem timestamp der Datenbank auslesen kann. Morgen müsste also eigentlich alles wieder in Ordnung sein, bis zum nächsten 1. März.
Ich bin schlicht zu wenig Mathematiker um diesen Algorithmus so zu verändern, dass er dieses Schaltjahr mit verhältnismäßigem Aufwand richtig berücksichtigt und ich damit in der Lage wäre diesen Nagel endlich richtig einzuschlagen, so es überhaupt mit Tagen alleine ginge. Jetzt könnte man also sagen der 29. Februar sei ja auch ein schöner 1. März, aber man vergisst dabei, dass es eben auch Fälle gibt, wo es in Schaltjahren statt eines Eintrags am 29. Februar (auch) einen am 1. März gibt. So hatte ich gerade einen workaround bereitgestellt, der die gefundenen Schalttag-Einträge eben dann einfach nicht darstellt, wenn der heutige Tag nicht auch ein solcher Schalttag ist. Aber damit habe ich immer noch nicht die Einträge des 1. März in historischen Schaltjahren...
Ich kann das gerade nicht präzise genug denken wie man einen solchen 1. März in Schaltjahren mit der bisherigen Berechnung richtig ausgeben kann, außer man verwirft den jetzigen (365/366) Tag Zähler und macht die Datenbankanfrage strikt nach Tag/Monat.
Forget it! Ich hab es doch noch hinbekommen ? (fingers crossed!)
Wäre natürlich toll wenn du das heute noch überprüfen könntest. Wie so oft nähert man sich einer Lösung wenn man sie zu beschreiben versucht. Und dann stellt sie sich als relativ einfach heraus...
Beat Post author am |
? Passt!
Olà... V3.3.0... es steht also noch ein Update an. Gab es Änderungen in pure (index.tpl, entries.tpl oder pure.js)?
Für die index, ja! 2 Stück.
Siehe https://github.com/ophian/styx/commits/master/templates/pure/index.tpl
Beat Post author am |
Danke für die Hinweise
Öhm.. Die erste Änderung (on Jan 19, 2021) war einfach.
Bei der zweiten Änderung (Feb 21, 2021) war ich unsicher. In meiner index.tpl fehlte bisher der ganze "highlight.min.js"-Bereich. Habe nun ab Zeile 128 alles aus der original-pure-index.tpl in mein File (in dieser Installation) übernommen. Erste Tests zeigen keine Auffälligeiten. Ich weiss aber auch nicht genau, wie ich das prüfen kann.
Hmmm... ob das so passt?
Ian Styx am |
Passt schon, denke ich.
Jedenfalls wird bei single entry comments und bei /comments/ summary Seiten gehighlighted.
Aber irgendetwas ist falsch, denn es gibt einen javascript error. Du solltest also am besten ab Zeile 119 https://github.com/ophian/styx/blob/master/templates/pure/index.tpl#L119 die Übernahme starten.
Beat Post author am |
Danke! Was "gehighlighted" auch immer sein mag...
Dann kann ich ja morgen den Live-Blog auch auf V3.3.0 updaten. ?
Ich hatte es schon geahnt, dass es nicht auf den ersten März beschränkt sein könnte...
Gerade neu commitet und gefixt! (Ab jetzt sage ich nur noch ..vorerst..) ?
Beat Post author am |
Sieht vorerst ganz gut aus! ?
Beat Post author am |
Habe jetzt die \pure-beat\index.tpl noch einmal überarbeitet und auch www.beatsblog.ch auf V3.3.0 upgedatet.
In der Konsole sehe ich keine Fehler (konnte jedoch vorher auch den von Dir genannten javascript-error nicht sehen). Kannst Du vielleicht kurz nachsehen, ob Du noch einen Fehler findest? Danke!
Das war gestern als ich den letzten Kommentar verschickt hatte, der in die Moderation geschickt wurde, und ich dabei zufällig die Dev-F12-Konsole offen hatte. Es war ein Fehler des ckeditor javascriptes, welches meinte, irgendetwas nicht gefunden zu haben. Als ich heute Morgen meinen Kommentar schrieb habe ich das nachzustellen versucht, aber alles war in Ordnung.
Im Nachhinein konnte ich mir das nur dadurch erklären, dass du ja gestern das Styx Update gemacht hast, welches auch eine neue Version des assets Editors mitgebracht hat, mein Browser aber noch die vorherige Version aus dem Cache verwendet hat. Jedenfalls hoffe ich dass es das war.
Edit: Und da dieser Kommentar mit dem Abschicken auch in der Moderation landete, trat der Fehler eben auch erneut auf. Diesmal habe ich dann richtig hingeschaut und gesehen, dass es ein valider und guter Fehler ist. Aber auch nichts schlimmes, eher eine Art von Status Information.
Wenn ein Kommentar abgeschickt wurde, wird ja die Kommentarform und damit auch die textarea nicht angezeigt; aus gutem Grund übrigens. Nun will aber CKE die textarea input form, die eben nicht da ist, mit seinen Rich Text Eigenschaften ersetzen und scheitert.
Ich werde nachher mal einen JS Gegencheck überall nachtragen wo es derart verwendet wird, was mir vorerst einfacher erscheint, als aufwendig eine PHP/Smarty Variable für diesen 1-minütigen Fall zu setzen, die den Javascript Kram für diese Zeit ganz ausblendet.
Gerade erfolgt!
Und zur Übernahme bereit ?, wenn du möchtest.
Ich glaube vorerst aber nicht, dass solch kleine Fehlerchen ein Styx Punkt-Bugfix-Update erfordern, vor allem, wenn sie so gut versteckt sind und nicht wirklich etwas kaputt machen.
Beat Post author am |
Hmmm... ?
Ich stelle mir das einfach irgendwie anders vor...
Heute Nachmittag habe ich mal kurz gesucht und bin auf dieses Hamburger-Menü gestossen: https://codepen.io/ahmedhrayyan/pen/EremLG. (Noch besser gefallen hätte mir dieses hier: https://codepen.io/foxeisen/pen/YgEwbK doch ich traute mir nicht zu, die unnötigen Variationen zu löschen. Zudem war der Downloadcode auf github nicht mehr verfügbar).
Stand-alone und lokal habe ich das relativ rasch lauffähig gekriegt. Dann versuchte ich das Ganze auf https://styx.beatsblog.ch/ zu integrieren (in index.tpl, pure.js & user.css). Wie Du sehen kannst: Mit nur mässigem Erfolg.
Egal. So in etwa (einfach richtig funktionierend und in schön) stelle ich mir das vor. Bei Gelegenheit werde ich daran wohl noch etwas weiter herumexperimentieren.
Und ja: es wäre unabhängig vom ausgewählten Theme. Deshalb die Idee der Integration in Form eines Plugins, damit man die Links und deren Texte in einer Backend-Oberfläche eintragen könnte.
Wobei... wenn ich programmieren könnte so denke ich, dass es durchaus realisierbar wäre, die Werte der globalen Navigation in das Hamburger-Menü zu überführen. Dann wäre die Frage nur noch, ob der User ein Hamburger-Menü will, oder nicht.
Ian Styx am |
Das zweite ist ein off-canvas menu. So wie das im Backend. Off Canvas ist ein hochfliegender Name der eigentlich nur bechreibt was es macht bzw ist. Es is ein Menü das wie eine Karte aus dem Seitenoff heraus in den sichtbaren Bereich hereinschliddert.
Im Moment hast du auf styx.beat nur einen Hamburger Button,und unsinnigerweise auch auf Desktops, der aber 1. deinen Zugang zur Entry Liste verhindert, jedenfalls für mich (...obwohl jetzt hab ich ihn wieder gefunden ?), und 2. die merkwürdige Eigenschaft besitzt im FF dev screen für Displaygrößen total zu blockieren, so dass man nicht daraus heraus kommt, außer den Browser neu zu starten.
Was du meines Verständnisses immer noch nicht ganz verstehst ist ja, dass es sich bei all solchen Beispielen um Beispiele handelt, in der das script auch die (ehemalige) Navigation erstellt. Das aber ist in deinen Themes und damit in Serendipity schon onboard. Die Navigation ist also das was schon da ist, und was ja auch genauso bleibt wie es da steht und abgestimmt ist, auch an dem alten Platz im #serendipity_banner Header, also:
Es gilt also die gefundenen CSS, und wenns sein muss auch JS Schnipsel, Beispiele genau darauf zielen zu lassen, so dass sie ausgeblendet sind auf Mobiles und nach Belieben gestyled eingeblendet werden nach dem Klick auf den Hamburger, bzw ab bestimmten Größen wieder genauso sind wie ehedem auf Desktops.
Im Grunde sollte man also erstmal allen Spielkram auf die wesentliche Grundfunktionalität eindampfen. Später, wenn dann alles richtig läuft, kann man es aufpimpen.
Hilft das?
Soetwas ginge eben nur über ein Plugin das einen Batzen javascript auf den Rechner des Besuchers schleust und alle gelieferten html nav Elemente entsprechend umstellt, mit events versieht und mit angereichertem CSS versieht.
Unabhängig vom theme geht es sowieso nicht, da ein Theme eine config haben muss, die eine Navigationstruktur (nur des Themes selbst, bzw eben jene auch global gesetzt, also in anderen Themes übernahmefähig) beschreibt und einstellt. Das heißt, das vom System über das Theme nur die Grundstruktur geliefert wird, der Rest aber vom Theme erlaubt und komplementiert wird.
Komplette Unabhängigkeit wäre eine Nebenläufigkeit zum System selbst. Das kann man sicher machen, aber vom Aufwand wäre es sicherlich einfacher wenn man das nimmt was es schon gibt und dies entsprechend über die template Dateien und das CSS anpasst.
Beat Post author am |
A propos rollendes Jahr in der Statistik: Wäre es möglich in der Grafik "Aufrufe, auf den Monat bezogen" nicht das aktuelle Kalenderjahr, sondern eben das rollende Jahr (die letzten 12 Monate) darzustellen?
So wie es jetzt ist, hat man Anfang eines Jahres immer wenig Möglichkeiten um eine Tendenz festzustellen.
Nur so eine Idee.
Beat Post author am |
Ich bin halt leider etwas schwer von Begriff und brauche immer mehrere Anläufe, bis ich die Zusammenhänge so erkenne, wie sie für Dich schon lange glasklar sind. ?
Auf der einen Seite ist es mir nicht so wichtig, dass ich unbedingt eine andere Lösung, als die bereits Bestehende, brauchen würde. Die funktioniert ja gut und braucht auch einen Klick weniger. Auf der anderen Seite finde ich ein Hamburger-Menü einfach cool und es juckt mich ab und zu in den Fingern und dann bastle ich etwas vor mich hin.....
Ich verstehe einfach nicht ganz, weshalb Dir ein "echtes Hamburger-Menü" so gegen den Strich geht. Aber, ich bin nicht das Mass der Dinge. So freue ich mich beispielsweise immer wieder am "go-to-top"-Button, scheine aber wirklich der Einzige zu sein, der so etwas toll findet. Das gibt es weder bei S9Y noch bei Styx und die Integration ist anscheinend auch kein Bedürfnis.
Ian Styx am |
Weiß nicht....
Ian Styx am |
Diese Behauptung kann ich nicht nachvollziehen. Gar nicht! ?
Ich fand halt den Hamburger unten einfach interessanter in Pure. Ansonsten ist es doch dieselbe Funktionalität. Oder nicht?! Klar, Off-Canvas hat es nicht. Aber das ist nur eine CSS+ Geschichte.
Der to top button ist zB in B46 bereits angelegt, ohne javascript halt. Das sind so featuristische Zugaben.
Wer nun soetwas gerne haben will kann es ja super einfach selbst einfügen so wie du.
Beat Post author am |
? "super einfach selbst einfügen" -> you made my day! ?
Dafür habe ich Matthias 3x um (Nach-)Hilfe gebeten und das hat mich ein Video aus seiner Wishliste gekostet. ? Aber ja, wer's kann, der kann das super einfach einfügen. ?
Irgendwie möchte ich das Hamburger-Thema beenden...
Um es einfach nocheinmal zu erwähnen. Den pure-Hamburger habe ich verworfen, weil man unten auf den Hamburger klickt und dann von oben der Header mit Menü eingeblendet wird. Ich mag meinen go-to-top-Button und komme damit an das genau gleiche Ziel. Ohne, dass ich unten immer diese Menüzeile eingeblendet habe. Die pure-Hamburger Lösung hat den Vorteil, dass die Seite nicht scrollt (wenn man das einen Vorteil nennen will). Meine go-to-top Lösung hat den Vorteil, dass sie nicht nur nach oben scrollt, sondern auch noch das Menü einblendet. (Vielleicht müsste ich das nach oben zeigende Dreieck noch um drei Hamburger-Längsstriche ergänzen). ?
Ian Styx am |
Watn Freund... ?
Sorry für die Umstände!
Ja eben, das ist doch auch schick so.
Ich habe ja auch nicht rumgemäkelt das Beat keinen Hamburger hat... (obwohl, .. hat er ja doch, er weiß es nur nicht... tztztz!)
Ian Styx am |
Moin Beat
Ist dir schon mal aufgefallen, dass dein jAlbum mit einem > beginnt? Ich nehme an es ist ein versehen und wird wahrscheinlich durch das javascript res/all.min.js bzw einem dort aufgerufenen weiteren scriptes nach dem body und nach einem der property og: eingesetzt, siehe:
Vielleicht findest du das ja als >> irgendwo in den dazugehörigen Dateien.
Ansonstem immer wieder tolle Reise, tolle Bilder! ?
Beat Post author am |
Danke für den Hinweis. Hab das auch mal gesehen, doch so auf die Schnelle keine Lösung gefunden.
Heute habe ich nun das Skin/Theme auf den neusten Stand aktualisiert, das Album neu generiert und hochgeladen. Und siehe da: Dieses >Dingens ist weg! ?
Und: Ja... seufz... schön war's! Dieses Jahr wegen
CorinaCorona und Hausumbau wohl kein Bike-Urlaub. ?Ian Styx am |
??? tja
Ian Styx am |
...und offenbart, dass ich zu voreilig, und ein besonderer Fall eben doch noch nicht bedacht war, denn in Schaltjahren ist nach dieser Rechnung der 1. März eben doch eigentlich nur ein (eingeschobener) 29. Februar.
Der Algorithmus für multiyear Anzeigen zählt einfach den Tag + (365/366) hoch, damit man die Einträge mit wenig Aufwand aus dem timestamp der Datenbank auslesen kann. Morgen müsste also eigentlich alles wieder in Ordnung sein, bis zum nächsten 1. März.
Ich bin schlicht zu wenig Mathematiker um diesen Algorithmus so zu verändern, dass er dieses Schaltjahr mit verhältnismäßigem Aufwand richtig berücksichtigt und ich damit in der Lage wäre diesen Nagel endlich richtig einzuschlagen, so es überhaupt mit Tagen alleine ginge. Jetzt könnte man also sagen der 29. Februar sei ja auch ein schöner 1. März, aber man vergisst dabei, dass es eben auch Fälle gibt, wo es in Schaltjahren statt eines Eintrags am 29. Februar (auch) einen am 1. März gibt. So hatte ich gerade einen workaround bereitgestellt, der die gefundenen Schalttag-Einträge eben dann einfach nicht darstellt, wenn der heutige Tag nicht auch ein solcher Schalttag ist. Aber damit habe ich immer noch nicht die Einträge des 1. März in historischen Schaltjahren...
Ich kann das gerade nicht präzise genug denken wie man einen solchen 1. März in Schaltjahren mit der bisherigen Berechnung richtig ausgeben kann, außer man verwirft den jetzigen (365/366) Tag Zähler und macht die Datenbankanfrage strikt nach Tag/Monat.
Ian Styx am |
Forget it! Ich hab es doch noch hinbekommen ? (fingers crossed!)
Wäre natürlich toll wenn du das heute noch überprüfen könntest. Wie so oft nähert man sich einer Lösung wenn man sie zu beschreiben versucht. Und dann stellt sie sich als relativ einfach heraus...
Beat Post author am |
? Passt!
Olà... V3.3.0... es steht also noch ein Update an. Gab es Änderungen in pure (index.tpl, entries.tpl oder pure.js)?
Ian Styx am |
Klasse!
Für die index, ja! 2 Stück.
Siehe https://github.com/ophian/styx/commits/master/templates/pure/index.tpl
Beat Post author am |
Danke für die Hinweise
Öhm.. Die erste Änderung (on Jan 19, 2021) war einfach.
Bei der zweiten Änderung (Feb 21, 2021) war ich unsicher. In meiner index.tpl fehlte bisher der ganze "highlight.min.js"-Bereich. Habe nun ab Zeile 128 alles aus der original-pure-index.tpl in mein File (in dieser Installation) übernommen. Erste Tests zeigen keine Auffälligeiten. Ich weiss aber auch nicht genau, wie ich das prüfen kann.
Hmmm... ob das so passt?
Ian Styx am |
Passt schon, denke ich.
Jedenfalls wird bei single entry comments und bei /comments/ summary Seiten gehighlighted.
Aber irgendetwas ist falsch, denn es gibt einen javascript error. Du solltest also am besten ab Zeile 119 https://github.com/ophian/styx/blob/master/templates/pure/index.tpl#L119 die Übernahme starten.
Beat Post author am |
Danke! Was "gehighlighted" auch immer sein mag...
Dann kann ich ja morgen den Live-Blog auch auf V3.3.0 updaten. ?
Ian Styx am |
Wir sind uns gerade in die Quere gekommen. Bitte noch mal nachlesen.
gehighlighted = code farbig ?
Ian Styx am |
Ich hatte es schon geahnt, dass es nicht auf den ersten März beschränkt sein könnte...
Gerade neu commitet und gefixt! (Ab jetzt sage ich nur noch ..vorerst..) ?
Beat Post author am |
Sieht vorerst ganz gut aus! ?
Beat Post author am |
Habe jetzt die \pure-beat\index.tpl noch einmal überarbeitet und auch www.beatsblog.ch auf V3.3.0 upgedatet.
In der Konsole sehe ich keine Fehler (konnte jedoch vorher auch den von Dir genannten javascript-error nicht sehen). Kannst Du vielleicht kurz nachsehen, ob Du noch einen Fehler findest? Danke!
Ian Styx am |
Das war gestern als ich den letzten Kommentar verschickt hatte, der in die Moderation geschickt wurde, und ich dabei zufällig die Dev-F12-Konsole offen hatte. Es war ein Fehler des ckeditor javascriptes, welches meinte, irgendetwas nicht gefunden zu haben. Als ich heute Morgen meinen Kommentar schrieb habe ich das nachzustellen versucht, aber alles war in Ordnung.
Im Nachhinein konnte ich mir das nur dadurch erklären, dass du ja gestern das Styx Update gemacht hast, welches auch eine neue Version des assets Editors mitgebracht hat, mein Browser aber noch die vorherige Version aus dem Cache verwendet hat.
Jedenfalls hoffe ich dass es das war.
Edit: Und da dieser Kommentar mit dem Abschicken auch in der Moderation landete, trat der Fehler eben auch erneut auf. Diesmal habe ich dann richtig hingeschaut und gesehen, dass es ein valider und guter Fehler ist. Aber auch nichts schlimmes, eher eine Art von Status Information.
Wenn ein Kommentar abgeschickt wurde, wird ja die Kommentarform und damit auch die textarea nicht angezeigt; aus gutem Grund übrigens. Nun will aber CKE die textarea input form, die eben nicht da ist, mit seinen Rich Text Eigenschaften ersetzen und scheitert.
Ich werde nachher mal einen JS Gegencheck überall nachtragen wo es derart verwendet wird, was mir vorerst einfacher erscheint, als aufwendig eine PHP/Smarty Variable für diesen 1-minütigen Fall zu setzen, die den Javascript Kram für diese Zeit ganz ausblendet.
Ian Styx am |
Gerade erfolgt!
Und zur Übernahme bereit ?, wenn du möchtest.
Ich glaube vorerst aber nicht, dass solch kleine Fehlerchen ein Styx Punkt-Bugfix-Update erfordern, vor allem, wenn sie so gut versteckt sind und nicht wirklich etwas kaputt machen.