Ja so war das genau richtig. Ich habe es auch schon überprüft und zur Dokumentation einen kleinen mobile comment hinterlassen.
Mobile Test. Gboard funktioniert wie es soll. ?
Also ist das Problem entweder eine Frage in der Pure CSS, oder in der pure.js, oder in einer der hineingehängten CSS Teile. Ich hätte da zum Beispiel das shariff im Verdacht! Das hängt einen gewaltigen Block in den unteren Bereich des zusammengebundenen serendipity.css builds hinein (und das ja bei dir anders heißt) und hat möglicherweise irgendetwas darinnen, was im Verbunde mit dem pure.js das Verschwinden vom GBoard bei Verwendung beider Seitenleisten auslöst. Aber der Reihe nach. Wir werden - sobald du wieder kannst - das nach und nach untersuchen.
?
Beat Post author am |
Hat das Shariff-Zeugs nicht mit dem imagesidebar-Plugin zu tun? Auf www.styx.beatsblog.ch habe ich nun auf pure-Theme umgestellt und imgasidebar deaktiviert. Leider löst dies das Problem nicht.
Beat Post author am |
Neues pure.js jeweils unter /templates/pure-beat von www.beatsblog.ch, www.styx.beatsblog.ch und www.blog.dokumenzi.ch (hier).
Beat Post author am |
Ne... Shariff hat was mit dem event_social-Plugin zu tun. Dieses ist jedoch auf www.styx.beatsblog.ch gar nicht installiert (auch nicht auf dem Server).
Inzwischen halte ich es für einen "Bug" der GBoard App, die einfach zu übersensibel reagiert auf das resize DOM element Sidebar Verschiebungsscript in Kombination mit dem CKE Skript. In dessen Historie gíbt es immer wieder mal solche Vorkommnisse. Sehr interessant wäre es in diesem Zusammenhang ja zu sehen, ob Apple Geräte ein gleiches Verhalten zeigen.
Wenn du diesen Teil im pure.js daher abschaltest, mit /* inhalt */, sollte es eigentlich wieder funktionieren. Prüfe das mal. (Allerdings hat man dann das Problem das die left sidebar auf unter 1024px Geräten oben bleibt.)
Ich sitze daran etwas anderes zu finden, bzw diese javascript gänzlich abzuschalten und das wie bei dem Dude per CSS und Media Queries zu erschlagen. Leider hätte ein Verzicht auf das doch sehr einfache aber eben so ungemein praktische javascript weitere Nachfolgewirkungen, so das dass nicht so schnell gehen wird. Und heute wahrscheinlich gar nicht mehr.
Habe dir zur Nachfolge noch etwas (zum Herumspielen) im backend hinterlassen. ?
Beat Post author am |
Sehr interessant wäre es in diesem Zusammenhang ja zu sehen, ob Apple Geräte ein gleiches Verhalten zeigen.
Mit dem iPhone 7 meiner Frau klappt es problemlos... ? (gerade auf www.beatsblog.ch getestet)
Beat Post author am |
Wenn du diesen Teil im pure.js daher abschaltest, mit /* inhalt */, sollte es eigentlich wieder funktionieren. Prüfe das mal. (Allerdings hat man dann das Problem das die left sidebar auf unter 1024px Geräten oben bleibt.)
Stimmt. Habe das auf www.styx.dokumenzi.ch gemacht. Dann funktioniert das Kommentieren mit Android, doch sorry, left sidebar zu Beginn, das geht gar nicht! So etwas mache ich im Live-Blog auf keinen Fall.
Beat Post author am |
O.K. Habe auf www.styx.beatsblog.ch soweit alles implementiert. Kommentieren mit Android funktioniert. Neu wird auf dem Mobile die linke Seitenleiste zum Schluss, also unter der rechten Seitenleiste, angezeigt.
Andersrum war es schon schöner (und irgendwie logischer). Dies vor allem, weil die Plugins der rechten Seitenleiste teilweise nebeneinander und teilweise untereinander dargestellt werden. Das war aber schon vorher so (und scheint so gewollt). Also: Falls dies der Beginn der neuen Lösung darstellt, dann werde ich wohl zukünftig die Inhalte der zwei Seitenleisten austauschen (was ja nur ab 1024px Breite einen Unterschied macht).
Auf www.beatsblog.ch mache ich derzeit noch nichts. Ich warte mal, was Du ausknobelst.
Ok Danke. Das bestätigt, dass es sich um die Kombination der simplen DOM Element Verschiebung javascript mit dem CKE RichTextEditor und eben Gboard handelt. Ob irgendein beteiligtes Scriptteil in einem der beiden letzteren eine klarere Ausnahme für irgendetwas benötigt, sei mal dahingestellt und können vielleicht nur die CKE Entwickler sagen; Auf alle Fälle haben wir am Ende eine Überreakton der Goggle Tastatur App.
Klasse. Ich dachte das sollte so sein. Grade eine korrigierte Version hinterlegt.
Beat Post author am |
? Jetzt ist die Reihenfolge am Mobile wie zuvor: Content, linke SL, rechte SL. Und: Die Tastatur bleibt auch am Android-Smartphone offen. So muss das sein! ?
Ist das der Weg, den Du zukünftig beschreiten willst? Wenn Ja, dann warte ich auf www.beatsblog.ch auf ein "offizielles" PURE-Update. Wenn Nein, würde ich wohl die nun geänderten pure.js, index.tpl und user.css von PURE-BEAT-Theme aus www.styx.beatsblog.ch in den Live-Blog übernehmen.
Grundsätzlich schon....
Dummerweise habe ich das kleine scriplet auch für das default theme eingesetzt, das es mich immer schon störte, dass das bezüglich Seitenleisten und Mobiles so unflexibel war. Auf diesem default theme beruhen eine ganze Reihe von themes die einfach dessen index.tpl, oder das gleiche Scriptlet nutzen. Zwar sind davon nicht alle wiederum 2-sidebar themes, aber es hat eben doch einige Nachfolgewirkungen. Diese grid CSS Geschichte ist eben auch viel neuer und benötigt aktuellere Browser zur Darstellung, als so ein simples javascript.
Ich finde aber man könnte pure als 2020er Standard Theme durchaus eben auch als solches deklarieren und damit das grid zum Browser Requirement machen. Das war u.a. einer der Gründe warum ich das Konzept the Dude entworfen hatte, um zu zeigen wie man heute damit umgehen kann.
Andererseits würde ich gerne noch herumtesten (und da kämest du ins Spiel) wie man das scriptlet eventuell verändern/verfeinern muss damit Gboard unbeeindruckt bleibt. Desktops lassen sich bestens ohne javascript betreiben, mobiles sind per se darauf angelegt. Ich könnte mir vorstellen, dass es irgendein touch event gibt mit dem man in Formfeldern das scriptlet einfach zur Laufzeit aus dem Spiel nimmt, denn der Ort wo das eine Rolle spielt ist ja extrem klar definiert, oder? Hast du im Backend mal versucht eine ähnliche Reaktion auf Mobiles zu reproduzieren? (Ich glaube es ja eher nicht.)
Beat Post author am |
?? Ich? Mit dem Smartphone im Backend? Nein, noch nie... da brauche ich einen richtigen Bildschirm und vor allem eine richtige Tastatur. Für dieses Mäusekino bin ich einfach zu alt. Das nutze ich höchstens um was zu lesen. Das ist ja auch mit ein Grund, weshalb mir (oder uns) dieser Fehler bisher nicht aufgefallen ist. Denn: Warum sollte ich per Smartphone kommentieren wollen? Ich bin ja schon froh, wenn ich keine WhatsApp- oder SMS-Nachrichten schreiben muss...
A propos "The Dude": Das Theme fand ich eigentlich ziemlich schick und gelungen. Mit ein paar Stunden CSS-Tuning könnte mir das echt gut gefallen.
Beat Post author am |
Für ausgedehntes Mobile-Testing brauchst Du einen Digital-Native Instagram-Influencer, einen Hipster mit Bart ? und vielen Tattoos ⚓, der nach jahrelangem Daumen-Yoga ? alles mit dem Smartphone erledigt.???. Wenn Du den überzeugen kannst, dass er mit einem eigenen Blog mehr Geld ?verdienen kann, dann hast Du gewonnen! ?
Naja, schick ist wohl übertrieben. Ich habe ihn exra ein wenig mausgrau und unscheinbar gestaltet, da der Dude in "The Big Lebowski" ja auch gern in der Ecke sitzt und abhängt.
Er sollte halt einfach untendrunter dem Stand Heute entsprechen und ganz ohne Krimskrams benutzbar bzw leicht anpassbar sein.
Beim Mäusekino geb ich dir klar recht. Allerdings glaube ich, dass es heute durchaus/zunehmend Leute gibt die gänzlich auf Desktops verzichten und alles nur noch über die touch Geräte Sparte erledigen. So ein Tablet ist ja quasi auch ein Mobile, halt in etwas anderen Dimensonen. Die Frage ist, wieviele davon unter 1024px Breite in hochkant bleiben und (mit den erforderlichen Prämissen zur Auslösung des issues) schreibend tätg werden. (☺ und einen Bart, Tatoos und ... besitzen)
Beat Post author am |
Die Frage ist, wieviele davon unter 1024px Breite in hochkant bleiben und (mit den erforderlichen Prämissen zur Auslösung des issues) schreibend tätg werden.
Keine Ahnung. Heute noch Wenige, morgen Mehr, übermorgen Alle? Meine Frau internettet zu 95% mit iPad und iPhone und nur noch zu 5% mit einem Desktop (mit entsprechend grossem Monitor). Meine Mutter (80) 100% Samsung/Android-Pad. Ich verwende 60% mein Power-Notebook, 30% Microsoft Surface Pad/Tablet/Netbook und 10% Android-Mobile. Aber: Ja natürlich: Immer mehr Benutzer (nicht nur solche mit Bart) erledigen immer mehr an immer kleineren Geräten. Deshalb sollte das funktionieren (auch wenn ich Oldtimer das selbst nicht nutze).
Lange Rede, kurzer Sinn: Es muss funktionieren. Ich helfe gerne, bin jedoch kein "echter" Mobile-User. ?
Mit welchem Browser hast du das getestet auf dem Mobile? Kannst du zur Sicherheit dort auch noch mal mit Chrome testen? Und mit dem Safari deiner Frau?
Beat Post author am |
Mit meinem Android HUAWEI P10 und Firefox. Gerade noch mit Chrome getestet, funktioniert auch. Das Handy meiner Frau (iPhone) muss noch arbeiten. ?
Gut. Danke. (Und was machen wir hier? Spielen? ? /spaßmode) Schau halt bei Gelegenheit damit mal rein. Denn Safari trägt nicht umsonst so einen Namen...?
Ich schulde Dir noch eine Antwort von wegen Kommentieren per iPhone. Das funktioniert sowohl bei www.beatsblog.ch (mit js) und auch bei www.styx.beatsblog.ch (ohne js).
Was man aber nicht tun sollte: Den Blog mit einem iPad und Safari im Hochformat betrachten Die statische Titelseite und die Blogdarstellung (/frontpage) sieht noch o.k. aus, doch die Single-Entry-View ist zum ? heulen. Da wird in der linken SL der Content dargestellt und umgekehrt. Die rechte Seitenleiste stimmt zwar, doch sollten bei der Auflösung ja generell keine SL angezeigt werden.
Sobald man etwas nach unten scrollt, korrigiert sich SL und Content, doch die Seitenbreite ist viel zu breit. Dies liegt vermutlich am entrypaging-Plugin, welches weit rechts, ausserhalb allem noch dargestellt wird (und deshalb wird wohl auch die Seite incl. SL dargestellt, weil eine bedeutend grössere Bilschirmbreite angenommen wird).
Ich habe dann das entrypaging-Plugin deaktiviert und siehe da: nun stimmt auch die Darstellung auf dem iPad (ohne SL)
Tja: Das entrypaging-Plugin bremst nicht nur die Single-Entry-View, sondern es zerschiesst auch die Darstellung in einem Safari-Browser. Ich muss das wohl -schweren Herzens- killen. ☠
Ich sagte ja das Safari gerne mit einem auf Safari fährt.... ?
In dem Fall würde ich schätzen dass es mit dem svg Pfeilen nicht zurecht kommt. Wenn du auf die low-level Variante mit den Bilder Pfeilen downgradest sollte auch Safari damit klar kommen. Du weißt was ich meine? Bin gerade zu beschäftigt um selbst nachzuschauen...
Aber ich könnte mir vorstellen, warum das vielleicht vorher mit dem SVG nicht auffiel, denn ich habe ja am 09.Mai das modernizr script in "pure" entfernt. Vielleicht hatte das Safari als Notstütze gedient.
Beat Post author am |
Mit einem weinenden Auge trenne ich mich vom entrypaging-Plugin. Denn seien wir ehrlich: ich dürfte der einzige Mensch sein, der es vermissen wird. Die Nachteile, vor allem der >1sec.-Delay und nun diese Safari-Geschichte haben mich mürbe gemacht. Ich mag nicht mehr daran rumbasteln. HAU WEG die Scheisse! ?
Ich würde mir für solch eine Entscheidung einen geeigneteren [...] Tag aussuchen.
Es ist doch eine tolle Sache und wirklich nett zu haben. Auch ich nutze es ab und an. Und es bietet bestimmt noch Raum für weitere Optimierungen, zB das man nächtlich ein Sammelarray laufen läßt, das tagsüber nur dann erneuert wird, wenn du einen neuen Eintrag schreibst (und selbst das letztere bräuchte man nicht wirklich). Dieses Array würde also vermeiden, dass das entrypaging immer in die entry Generierung hineingrätscht und vielleicht gerade dadurch viel mehr der Schnelligkeit des Proxy-Caches von NGINX nahekommen. Denn so ein array, velleicht sogar optimiert, wäre selbst bei 3000+ Einträgen schneller als die 1s delay die wir jetzt haben.
Ian Styx am |
Ja so war das genau richtig. Ich habe es auch schon überprüft und zur Dokumentation einen kleinen mobile comment hinterlassen.
Mobile Test. Gboard funktioniert wie es soll. ?
Also ist das Problem entweder eine Frage in der Pure CSS, oder in der pure.js, oder in einer der hineingehängten CSS Teile. Ich hätte da zum Beispiel das shariff im Verdacht! Das hängt einen gewaltigen Block in den unteren Bereich des zusammengebundenen serendipity.css builds hinein (und das ja bei dir anders heißt) und hat möglicherweise irgendetwas darinnen, was im Verbunde mit dem pure.js das Verschwinden vom GBoard bei Verwendung beider Seitenleisten auslöst. Aber der Reihe nach. Wir werden - sobald du wieder kannst - das nach und nach untersuchen.
?
Beat Post author am |
Hat das Shariff-Zeugs nicht mit dem imagesidebar-Plugin zu tun? Auf www.styx.beatsblog.ch habe ich nun auf pure-Theme umgestellt und imgasidebar deaktiviert. Leider löst dies das Problem nicht.
Beat Post author am |
Neues pure.js jeweils unter /templates/pure-beat von www.beatsblog.ch, www.styx.beatsblog.ch und www.blog.dokumenzi.ch (hier).
Beat Post author am |
Ne... Shariff hat was mit dem event_social-Plugin zu tun. Dieses ist jedoch auf www.styx.beatsblog.ch gar nicht installiert (auch nicht auf dem Server).
Ian Styx am |
Inzwischen halte ich es für einen "Bug" der GBoard App, die einfach zu übersensibel reagiert auf das resize DOM element Sidebar Verschiebungsscript in Kombination mit dem CKE Skript. In dessen Historie gíbt es immer wieder mal solche Vorkommnisse. Sehr interessant wäre es in diesem Zusammenhang ja zu sehen, ob Apple Geräte ein gleiches Verhalten zeigen.
Wenn du diesen Teil im pure.js daher abschaltest, mit /* inhalt */, sollte es eigentlich wieder funktionieren. Prüfe das mal. (Allerdings hat man dann das Problem das die left sidebar auf unter 1024px Geräten oben bleibt.)
Ich sitze daran etwas anderes zu finden, bzw diese javascript gänzlich abzuschalten und das wie bei dem Dude per CSS und Media Queries zu erschlagen. Leider hätte ein Verzicht auf das doch sehr einfache aber eben so ungemein praktische javascript weitere Nachfolgewirkungen, so das dass nicht so schnell gehen wird. Und heute wahrscheinlich gar nicht mehr.
Ciao
Ian Styx am |
Habe dir zur Nachfolge noch etwas (zum Herumspielen) im backend hinterlassen. ?
Beat Post author am |
Mit dem iPhone 7 meiner Frau klappt es problemlos... ? (gerade auf www.beatsblog.ch getestet)
Beat Post author am |
Stimmt. Habe das auf www.styx.dokumenzi.ch gemacht. Dann funktioniert das Kommentieren mit Android, doch sorry, left sidebar zu Beginn, das geht gar nicht! So etwas mache ich im Live-Blog auf keinen Fall.
Beat Post author am |
O.K. Habe auf www.styx.beatsblog.ch soweit alles implementiert. Kommentieren mit Android funktioniert. Neu wird auf dem Mobile die linke Seitenleiste zum Schluss, also unter der rechten Seitenleiste, angezeigt.
Andersrum war es schon schöner (und irgendwie logischer). Dies vor allem, weil die Plugins der rechten Seitenleiste teilweise nebeneinander und teilweise untereinander dargestellt werden. Das war aber schon vorher so (und scheint so gewollt). Also: Falls dies der Beginn der neuen Lösung darstellt, dann werde ich wohl zukünftig die Inhalte der zwei Seitenleisten austauschen (was ja nur ab 1024px Breite einen Unterschied macht).
Auf www.beatsblog.ch mache ich derzeit noch nichts. Ich warte mal, was Du ausknobelst.
Ian Styx am |
Ok Danke. Das bestätigt, dass es sich um die Kombination der simplen DOM Element Verschiebung javascript mit dem CKE RichTextEditor und eben Gboard handelt. Ob irgendein beteiligtes Scriptteil in einem der beiden letzteren eine klarere Ausnahme für irgendetwas benötigt, sei mal dahingestellt und können vielleicht nur die CKE Entwickler sagen; Auf alle Fälle haben wir am Ende eine Überreakton der Goggle Tastatur App.
Ian Styx am |
Klasse. Ich dachte das sollte so sein. Grade eine korrigierte Version hinterlegt.
Beat Post author am |
? Jetzt ist die Reihenfolge am Mobile wie zuvor: Content, linke SL, rechte SL. Und: Die Tastatur bleibt auch am Android-Smartphone offen. So muss das sein! ?
Ist das der Weg, den Du zukünftig beschreiten willst? Wenn Ja, dann warte ich auf www.beatsblog.ch auf ein "offizielles" PURE-Update. Wenn Nein, würde ich wohl die nun geänderten pure.js, index.tpl und user.css von PURE-BEAT-Theme aus www.styx.beatsblog.ch in den Live-Blog übernehmen.
Ian Styx am |
Grundsätzlich schon....
Dummerweise habe ich das kleine scriplet auch für das default theme eingesetzt, das es mich immer schon störte, dass das bezüglich Seitenleisten und Mobiles so unflexibel war. Auf diesem default theme beruhen eine ganze Reihe von themes die einfach dessen index.tpl, oder das gleiche Scriptlet nutzen. Zwar sind davon nicht alle wiederum 2-sidebar themes, aber es hat eben doch einige Nachfolgewirkungen. Diese grid CSS Geschichte ist eben auch viel neuer und benötigt aktuellere Browser zur Darstellung, als so ein simples javascript.
Ich finde aber man könnte pure als 2020er Standard Theme durchaus eben auch als solches deklarieren und damit das grid zum Browser Requirement machen. Das war u.a. einer der Gründe warum ich das Konzept the Dude entworfen hatte, um zu zeigen wie man heute damit umgehen kann.
Andererseits würde ich gerne noch herumtesten (und da kämest du ins Spiel) wie man das scriptlet eventuell verändern/verfeinern muss damit Gboard unbeeindruckt bleibt. Desktops lassen sich bestens ohne javascript betreiben, mobiles sind per se darauf angelegt. Ich könnte mir vorstellen, dass es irgendein touch event gibt mit dem man in Formfeldern das scriptlet einfach zur Laufzeit aus dem Spiel nimmt, denn der Ort wo das eine Rolle spielt ist ja extrem klar definiert, oder? Hast du im Backend mal versucht eine ähnliche Reaktion auf Mobiles zu reproduzieren? (Ich glaube es ja eher nicht.)
Beat Post author am |
?? Ich? Mit dem Smartphone im Backend? Nein, noch nie... da brauche ich einen richtigen Bildschirm und vor allem eine richtige Tastatur. Für dieses Mäusekino bin ich einfach zu alt. Das nutze ich höchstens um was zu lesen. Das ist ja auch mit ein Grund, weshalb mir (oder uns) dieser Fehler bisher nicht aufgefallen ist. Denn: Warum sollte ich per Smartphone kommentieren wollen? Ich bin ja schon froh, wenn ich keine WhatsApp- oder SMS-Nachrichten schreiben muss...
A propos "The Dude": Das Theme fand ich eigentlich ziemlich schick und gelungen. Mit ein paar Stunden CSS-Tuning könnte mir das echt gut gefallen.
Beat Post author am |
Für ausgedehntes Mobile-Testing brauchst Du einen Digital-Native Instagram-Influencer, einen Hipster mit Bart ? und vielen Tattoos ⚓, der nach jahrelangem Daumen-Yoga ? alles mit dem Smartphone erledigt.???. Wenn Du den überzeugen kannst, dass er mit einem eigenen Blog mehr Geld ?verdienen kann, dann hast Du gewonnen! ?
Ian Styx am |
Naja, schick ist wohl übertrieben. Ich habe ihn exra ein wenig mausgrau und unscheinbar gestaltet, da der Dude in "The Big Lebowski" ja auch gern in der Ecke sitzt und abhängt.
Er sollte halt einfach untendrunter dem Stand Heute entsprechen und ganz ohne Krimskrams benutzbar bzw leicht anpassbar sein.
Beim Mäusekino geb ich dir klar recht. Allerdings glaube ich, dass es heute durchaus/zunehmend Leute gibt die gänzlich auf Desktops verzichten und alles nur noch über die touch Geräte Sparte erledigen. So ein Tablet ist ja quasi auch ein Mobile, halt in etwas anderen Dimensonen. Die Frage ist, wieviele davon unter 1024px Breite in hochkant bleiben und (mit den erforderlichen Prämissen zur Auslösung des issues) schreibend tätg werden. (☺ und einen Bart, Tatoos und ... besitzen)
Beat Post author am |
Keine Ahnung. Heute noch Wenige, morgen Mehr, übermorgen Alle? Meine Frau internettet zu 95% mit iPad und iPhone und nur noch zu 5% mit einem Desktop (mit entsprechend grossem Monitor). Meine Mutter (80) 100% Samsung/Android-Pad. Ich verwende 60% mein Power-Notebook, 30% Microsoft Surface Pad/Tablet/Netbook und 10% Android-Mobile. Aber: Ja natürlich: Immer mehr Benutzer (nicht nur solche mit Bart) erledigen immer mehr an immer kleineren Geräten. Deshalb sollte das funktionieren (auch wenn ich Oldtimer das selbst nicht nutze).
Lange Rede, kurzer Sinn: Es muss funktionieren. Ich helfe gerne, bin jedoch kein "echter" Mobile-User. ?
Ian Styx am |
Mit welchem Browser hast du das getestet auf dem Mobile? Kannst du zur Sicherheit dort auch noch mal mit Chrome testen? Und mit dem Safari deiner Frau?
Beat Post author am |
Mit meinem Android HUAWEI P10 und Firefox. Gerade noch mit Chrome getestet, funktioniert auch. Das Handy meiner Frau (iPhone) muss noch arbeiten. ?
Ian Styx am |
Gut. Danke. (Und was machen wir hier? Spielen? ? /spaßmode) Schau halt bei Gelegenheit damit mal rein. Denn Safari trägt nicht umsonst so einen Namen...?
Ian Styx am |
Ich sagte ja das Safari gerne mit einem auf Safari fährt.... ?
In dem Fall würde ich schätzen dass es mit dem svg Pfeilen nicht zurecht kommt. Wenn du auf die low-level Variante mit den Bilder Pfeilen downgradest sollte auch Safari damit klar kommen. Du weißt was ich meine? Bin gerade zu beschäftigt um selbst nachzuschauen...
Ian Styx am |
Aber ich könnte mir vorstellen, warum das vielleicht vorher mit dem SVG nicht auffiel, denn ich habe ja am 09.Mai das modernizr script in "pure" entfernt. Vielleicht hatte das Safari als Notstütze gedient.
Beat Post author am |
Mit einem weinenden Auge trenne ich mich vom entrypaging-Plugin. Denn seien wir ehrlich: ich dürfte der einzige Mensch sein, der es vermissen wird. Die Nachteile, vor allem der >1sec.-Delay und nun diese Safari-Geschichte haben mich mürbe gemacht. Ich mag nicht mehr daran rumbasteln. HAU WEG die Scheisse! ?
Ian Styx am |
Ich würde mir für solch eine Entscheidung einen geeigneteren [...] Tag aussuchen.
Es ist doch eine tolle Sache und wirklich nett zu haben. Auch ich nutze es ab und an. Und es bietet bestimmt noch Raum für weitere Optimierungen, zB das man nächtlich ein Sammelarray laufen läßt, das tagsüber nur dann erneuert wird, wenn du einen neuen Eintrag schreibst (und selbst das letztere bräuchte man nicht wirklich). Dieses Array würde also vermeiden, dass das entrypaging immer in die entry Generierung hineingrätscht und vielleicht gerade dadurch viel mehr der Schnelligkeit des Proxy-Caches von NGINX nahekommen. Denn so ein array, velleicht sogar optimiert, wäre selbst bei 3000+ Einträgen schneller als die 1s delay die wir jetzt haben.
Der Safari Problematik kann man sicher begegnen.