Ach entschuldige, das linkt ja auf s9y.dokumenzi.. Das ist nicht Styx! Die haben sich auch irgendwann mal danach an einer Galerie probiert... Das Ergebnis sieht man eben auch, alles etwas unausgegoren und unfertig.
Styx ist komplett anders!
Beat Post author am |
... ein gequältes Lächeln... die hohe Kunst des Editing wird mir verschlossen bleiben... ich habe dankbar Deine Anweisung übernommen.
.post_content hr {
visibility: collapse;
}
... mit kleineren Vorschaubildern hätte ich diese Probleme nicht. Ich habe noch immer Mühe mit diesen übergrossen Vorschaubildern. Ein wirklicher Vorteil hat sich mir bisher noch nicht erschlossen.
Besser wäre 2020 / 01 / chinese_new_year.jpg. So dass die Struktur sich an Jahr / Monat (auch weil so schön kurz) orientiert, die eigentlichen Bilder aber semantisch benamt sind. Ab einer gewissen Menge hilft das sehr, weil man zB besser suchen kann, etc.. ?
Beat Post author am |
Häh? Kürzer als 20200125.jpg geht wohl nicht. 2020=Jahr, 01=Monat, 25=Tag. Mehr Ordnung brauche ich nicht. Ist Blog-Logik, strikt der Zeit unterworfen. Ich sehe überhaupt keinen Vorteil von sprechenden Bildnamen.
Ich nehme das mal als leicht grummeligen Einwurf im Fieberwahn.. ?
Was du vorher (und das Problem haben wir ja beseitigt) an den größeren Thumb Bildern bemängelt hast, dass sie auf kleineren Devices - solange die Breite des Gerätes nicht kleiner war - genau so groß blieben und damit der rechts/links umflossene Text "verlorenging", hattest/hast du doch andererseits und analog mit diesen Minis auch, wenn du einen Desktop benutzt. Dann sind sie zu mini und scalen sich auch nicht hoch, was ja verlustbehaftet wäre. Scalen geht eben nur abwärts gut. Aufwärts geht immer mehr Information verloren. Deshalb nutzt man nicht das untere Darstellungs Ende als thumb, sondern einen guten Mittelweg. Da haben wir uns mit Serendipity 2.0 damals auf 400 entschieden. wo vielleicht auch 360 gereicht hätten. Damit kann man leben. Das ist das Eine. Das andere ist, dass alle features (wie zb, die Galerie) und alle Mediatheks und andere Bildansichten des Systems auf die normal Vorgabe 400px abgestimmt sind. Sicher, es geht auch irgendwie mit weniger. Aber man hat Verluste, die bedeutend schwerer wiegen, als sich von "vorsintflutlichen" Miniansichten zu trennen.
Beat Post author am |
? Ja, ja... Fieber und Trennungsschmerz... ?
Ich bin halt vielleicht etwas festgefahren. Nach etwa 8 Jahren mit 150px und nochmal 8 Jahren mit 200px Vorschaubildern brauche ich halt etwas Zeit um mich an die neuen 400px Thumbs zu gewöhnen. Aber: Ich bemühe mich... ?
Doch! 2020 / 0125.jpg, oder sogar 20 / 0125.jpg. ? Aber darum ging es auch nicht. Du hast 20200125.jpg im 2020 Order, also strukturell 2020 / 20200125.jpg. Ordner sind OK, Namen nicht so sehr, zB nach eniger Zeit, wenn einem oder anderen 20200125.jpg nichts (mehr) sagt. Auf den Fall habe ich hingewiesen und gemeint, dass es dann einfacher für die Suche usw wäre, ohne dass man sich immer erst die Vorschau ansehen muss um zu sehen was das eigentlich war. Aber das macht jeder so wie er will und wie es ihm passt.
zB nach eniger Zeit, wenn einem oder anderen 20200125.jpg nichts (mehr) sagt. Auf den Fall habe ich hingewiesen und gemeint, dass es dann einfacher für die Suche usw wäre, ohne dass man sich immer erst die Vorschau ansehen muss um zu sehen was das eigentlich war.
Ich verstehe Deine Worte - den Sinn dahinter aber nicht.
In meinem Blog gibt es mittlerweile über 3'000 Bilder. Trotzdem habe ich bisher noch nie (länger) nach einem Bild gesucht. Die Bilder stehen ja immer im Kontext zu einem Blogbeitrag. Falls, und ich betone: Falls, ich also je nach einem bestimmten Bild suchen würde, bemühe ich die Blogsuche mit den relevanten Suchbegriffen und werde innert Sekunden fündig. Ein Rechtsklick aufs Bild und schon kann ich die Grafikinfo ansehen. Ich habe bisher noch nie, nie, nie ein Bild in der Mediathek gesucht. Und ehrlich: Ich sehe auch kein Grund weshalb ich das tun sollte. Es dürfte etwas anderes sein, wenn in die Mediathek weitere Bilder hochgeladen werden, die nicht in Beiträge eingebunden werden. Das mache ich aber nicht. Das ist ja mein Blog und nicht meine Media-Cloud.
Wir scheinen diesbezüglich einfach andere Ansichten zu haben. Das können wir auch einfach mal so im Raum stehen lassen.
Ich habe gerade mit einem eleganten Kniff das Verschachtelungs und overlap Problem gelost. Damit ist die Benutzung von hr Elementen und ihres collapses hinfällig. ?
Beat Post author am |
Falls dieser elegante Kniff in den Download-Daten vom 05.02. von 20:18 Uhr enthalten ist, so überzeugt mich das Resultat nicht wirklich.
Vorschaubilder werden nun nicht mehr umflossen, sondern der Fliesstext bleibt immer gleich breit (fliesst also nicht mehr unter das Bild). Siehe z.B. https://www.beatsblog.ch/2595-schoene,-neue-Raeder.html
Wenn ich hr lösche, verschachteln sich die Bilder wieder wie zuvor. Deshalb habe ich nach einem Test die hr's wieder eingesetzt und kann Dir darum kein Beispiel-Link angeben.
Gefixt. Sollte jetzt sogar das image overlap Problem auch mit lösen, also bitte mal im user.css das https://www.blog.dokumenzi.ch/2630-Bilder.html#c6452 wieder löschen und nachkontrollieren.
Beat Post author am |
Danke!
Habe postcontent: inline-block aus der user.css gelöscht. Zusammen mit den neuen Daten sieht es jetzt ganz gut aus! ?
Ja das sieht jetzt alles gut aus und es macht viel Spaß durch deine alten und neuen Einträge zu surfen!
Ich wünschte ich hätte solch erworbene Kraft um solche Touren zu machen. Das muss klasse sein! Toll!
Was mir dabei auffiel ist, dass die entries Liste auf beatsblog jetzt ziemlich flüssig läuft, egal wie weit man in die Vergangenheit geht und dort eventuell vielleicht sogar noch nie war. Die Einzelseiten allerdings haben immer noch diesen furchbaren Jetlag. Bist du dem schon auf die Spur gekommen?
https://www.beatsblog.ch/2402-Tag-11-nach-Levanto.html 50 Anfragen 1,37 MB / 704,81 KB übertragen Beendet: 5,35 s DOMContentLoaded: 4,56 s load: 4,94 s
Auf der entries Liste Seite ist das beispielsweise
44 Anfragen 1,54 MB / 1,24 MB übertragen Beendet: 1,93 s DOMContentLoaded: 1,18 s load: 1,88 s
Schon ein ziemlich relevanter Unterschied.
Beat Post author am |
? Danke für die Blumen! ?
Bezüglich Geschwindigkeit: Ich habe vorgestern Abend in der Blog-Konfiguration die GZIP-Kompression eingeschaltet. Zusätzlich implementiere ich in .htaccess die APCU-Module:
Module mod_deflate.c
Module mod_expires.c
Module mod_headers.c
Das hat dann doch einen guten Boost gebracht. Wenn dann keine grösseren Änderungen mehr anstehen, werde ich auch noch .js und .css minimieren.
Der von Dir genannte Artikel (nach Levanto) ist einer dieser Artikel, in denen das Garmin-iframe eingebunden ist. Das braucht ziemlich Zeit, bis es geladen ist. (Auch deshalb werde ich diese iframes nicht mehr direkt einbinden, sondern auf die Garmin-Seite verlinken). Habe übrigens gerade gemerkt, dass das iframe nicht angezeigt wird (im Seitenquelltext wird es aber erwähnt), Komisch.
Soweit bin ich also ganz zufrieden. ?
A propos .htaccess -> Ich konnte meine Fotoalben nicht ansprechen und bemühte deswegen den Manitu-Support. Das war die Antwort:
welche alle .html-Dateien, auch die des Fotoalbums, wieder "zurückgeleitet" werden. Ich habe diese Regel soeben einmal durch ein vorangestelltes "#" deaktiviert.
Aktuell wird das Fotoalbum korrekt ausgeliefert. Können Sie bestätigen, dass die "restlichen" Komponenten Ihre Website weiterhin funktionieren?
Interessanterweise macht diese Zeile hier, auf dem hosttech-Server, überhaupt kein Problem und das einzige installierte Fotoalbum (TREK 1120) läuft problemlos. Auf dem Manitu-Server muss aber allem Anschein nach diese Zeile raus. Na ja, nun funktioniert es.
Zudem sind nun alle Uploads-Verzeichnisse mit 770er-Berechtigungen (und es funktioniert).
Also ehrlich... ich bin kein Freund von solchen Sachen, der Mehrwert durch eine geringere Größe wiegt IMHO nicht auf dass sie zwangsläufig unleserlich werden, außerdem sollte schon gzip für pressierte Ladung sorgen. Schau dir einfach mal die load Zeiten eines solchen stylesheets bzw js files ohne und mit einer minify Kompression an. Sie ist meist zu vernachlässigen. Und es ist nur komprimierte Luft. ?
Das mit der htaccess ist interessant. Hast du wirklich überprüft ob diese drei zusätzlichen Module an sich für eine essentielle Beschleuning sorgen?
Das auskommentierte Rule in der Styx htaccess ist nicht ratsam! In Unterordnern, die nicht Serendipity sind - also beispielsweise /touren/ - legt man einfach eine neue .htaccess an mit RewriteEngine OFF an
<IfModule mod_rewrite.c>
RewriteEngine Off
</IfModule>
und der Fall ist erledigt.
Beat Post author am |
Also ich testete auf: https://tools.pingdom.com/ die Seite: https://www.beatsblog.ch/categories/BLOG
ohne apcu: 57 Requests, 1,6MB Page Size, 1,35s Load time, Performance-Grade = C73
mit apcu: 57 Requests, 1,4MB Page Size, 1,27s Load time, Performance-Grade = B86
Mit Google PageSpeed Insight (die gleiche Seite):
ohne apcu: Mobile= 76, Desktop= 94
mit apcu: Mobile= 81, Desktop= 96
Nicht wirklich essentiell, doch immerhin. ?
Danke für die Hinweise zur .htaccess - ich habe das jetzt wie von Dir vorgeschlagen umgesetzt und es scheint zu funktionieren. ?
https://www.beatsblog.ch/2386-hoch-und-breit.html (ohne Garmin und auch nicht viel besser) 48 Anfragen 1,31 MB / 526,83 KB übertragen Beendet: 5,48 s DOMContentLoaded: 4,58 s load: 4,82 s
Ich sags mal so - das müsst eine Angelegenheit von 0.50s sein, wenns hoch kommt mt allem Schnickschnack 1 - 1.5s.
Beat Post author am |
Es sieht so aus, wie wenn jede Single-Entry-View über 4 Sek. benötigt, bis sie vollständig geladen ist. Indexseiten brauchen im Schnitt um die 1,5 Sekunden. Das ist ziemlich verwirrend, denn die Index-Seite zeigt ja eigentlich 10 Single-Entries (ich habe ja keine erweiterten Beiträge).
Das ist unschön, doch ich weiss auch nicht, was ich dagegen tun kann.
Beat Post author am |
Habe mal den Manitu-Support angeschrieben:
Ich bin etwas verwundert, wie lange die Antwortzeiten für Seitenaufrufe meines Blogs benötigen. Ich habe verschiedene Seiten getestet, die Resultate sind immer in etwa gleich. Zur Dokumentation hier eine Beispielmessung mit Vergleich:
I just tested https://www.beatsblog.ch/2531-TREK-1120-1-Jahr.html with the Full Page test in Pingdom Tools. This specific test was done on February 7. The web page took 4470 ms to load, used 55 requests, and weighed in at 849.6 KB. The Google Page Speed performance grade for this web page is 85/100. There’s a ton of more information you can check out here: https://tools.pingdom.com/#5c080910c4400000
Nachfolgend eine Vergleichsmessung der identischen Seite bei meinem alten Hostinganbieter:
I just tested https://www.blog.dokumenzi.ch/2531-TREK-1120-1-Jahr.html with the Full Page test in Pingdom Tools. This specific test was done on February 7. The web page took 696 ms to load, used 52 requests, and weighed in at 809.6 KB. The Google Page Speed performance grade for this web page is 79/100. There’s a ton of more information you can check out here: https://tools.pingdom.com/#5c080887c5c00000
Von 696 ms zu 4470 ms ist doch ein riesiger Unterschied. Können Sie vielleicht eruieren, woher diese Verzögerungen kommen?
Als kleiner Hinweis, dass es sich dabei um identische Blog und Versionssysteme aber unterschiedliche HTTP-Server mit leichtem nginx cache Vorteil handelt, wäre vielleicht noch zuträglich gewesen - ansonsten bin ich gespannt. Vor 2 Stunden hatte ich mal geschaut wer die anderen 35 User auf dem Server sind. Viele davon sind noch gar nicht aktiv, andere nutzen es einfach als nextcloud Server. So allgemein dürfte es also nicht am Betrieb oder fehlenden Ressourcen liegen.
Beat Post author am |
Manitu ist momentan relativ ratlos. Es ist aber auch komisch, dass die Verzögerung nur in der Single-Entry-Ansicht auftritt.
Sie wollen jetzt selbst eine Serendipity-Styx-Edition Testinstallation aufbauen um der Sache besser auf den Grund gehen zu können.
Ian Styx am |
Ach entschuldige, das linkt ja auf s9y.dokumenzi.. Das ist nicht Styx!
Die haben sich auch irgendwann mal danach an einer Galerie probiert... Das Ergebnis sieht man eben auch, alles etwas unausgegoren und unfertig.
Styx ist komplett anders!
Beat Post author am |
... ein gequältes Lächeln... die hohe Kunst des Editing wird mir verschlossen bleiben... ich habe dankbar Deine Anweisung übernommen.
... mit kleineren Vorschaubildern hätte ich diese Probleme nicht. Ich habe noch immer Mühe mit diesen übergrossen Vorschaubildern. Ein wirklicher Vorteil hat sich mir bisher noch nicht erschlossen.
Ian Styx am |
Nochmal zur Ordnung in der Mediathek.
Jahr 2020 ist gut, 20200125.jpg ist nicht so gut.
Besser wäre 2020 / 01 / chinese_new_year.jpg. So dass die Struktur sich an Jahr / Monat (auch weil so schön kurz) orientiert, die eigentlichen Bilder aber semantisch benamt sind. Ab einer gewissen Menge hilft das sehr, weil man zB besser suchen kann, etc.. ?
Beat Post author am |
Häh? Kürzer als 20200125.jpg geht wohl nicht. 2020=Jahr, 01=Monat, 25=Tag. Mehr Ordnung brauche ich nicht. Ist Blog-Logik, strikt der Zeit unterworfen. Ich sehe überhaupt keinen Vorteil von sprechenden Bildnamen.
Ian Styx am |
Ich nehme das mal als leicht grummeligen Einwurf im Fieberwahn.. ?
Was du vorher (und das Problem haben wir ja beseitigt) an den größeren Thumb Bildern bemängelt hast, dass sie auf kleineren Devices - solange die Breite des Gerätes nicht kleiner war - genau so groß blieben und damit der rechts/links umflossene Text "verlorenging", hattest/hast du doch andererseits und analog mit diesen Minis auch, wenn du einen Desktop benutzt. Dann sind sie zu mini und scalen sich auch nicht hoch, was ja verlustbehaftet wäre. Scalen geht eben nur abwärts gut. Aufwärts geht immer mehr Information verloren. Deshalb nutzt man nicht das untere Darstellungs Ende als thumb, sondern einen guten Mittelweg. Da haben wir uns mit Serendipity 2.0 damals auf 400 entschieden. wo vielleicht auch 360 gereicht hätten. Damit kann man leben.
Das ist das Eine.
Das andere ist, dass alle features (wie zb, die Galerie) und alle Mediatheks und andere Bildansichten des Systems auf die normal Vorgabe 400px abgestimmt sind. Sicher, es geht auch irgendwie mit weniger. Aber man hat Verluste, die bedeutend schwerer wiegen, als sich von "vorsintflutlichen" Miniansichten zu trennen.
Beat Post author am |
? Ja, ja... Fieber und Trennungsschmerz... ?
Ich bin halt vielleicht etwas festgefahren. Nach etwa 8 Jahren mit 150px und nochmal 8 Jahren mit 200px Vorschaubildern brauche ich halt etwas Zeit um mich an die neuen 400px Thumbs zu gewöhnen. Aber: Ich bemühe mich... ?
Ian Styx am |
Doch! 2020 / 0125.jpg, oder sogar 20 / 0125.jpg. ?
Aber darum ging es auch nicht. Du hast 20200125.jpg im 2020 Order, also strukturell 2020 / 20200125.jpg. Ordner sind OK, Namen nicht so sehr, zB nach eniger Zeit, wenn einem oder anderen 20200125.jpg nichts (mehr) sagt. Auf den Fall habe ich hingewiesen und gemeint, dass es dann einfacher für die Suche usw wäre, ohne dass man sich immer erst die Vorschau ansehen muss um zu sehen was das eigentlich war. Aber das macht jeder so wie er will und wie es ihm passt.
Ian Styx am |
Brav! ?
Beat Post author am |
Ich verstehe Deine Worte - den Sinn dahinter aber nicht.
In meinem Blog gibt es mittlerweile über 3'000 Bilder. Trotzdem habe ich bisher noch nie (länger) nach einem Bild gesucht. Die Bilder stehen ja immer im Kontext zu einem Blogbeitrag. Falls, und ich betone: Falls, ich also je nach einem bestimmten Bild suchen würde, bemühe ich die Blogsuche mit den relevanten Suchbegriffen und werde innert Sekunden fündig. Ein Rechtsklick aufs Bild und schon kann ich die Grafikinfo ansehen. Ich habe bisher noch nie, nie, nie ein Bild in der Mediathek gesucht. Und ehrlich: Ich sehe auch kein Grund weshalb ich das tun sollte. Es dürfte etwas anderes sein, wenn in die Mediathek weitere Bilder hochgeladen werden, die nicht in Beiträge eingebunden werden. Das mache ich aber nicht. Das ist ja mein Blog und nicht meine Media-Cloud.
Wir scheinen diesbezüglich einfach andere Ansichten zu haben. Das können wir auch einfach mal so im Raum stehen lassen.
Ian Styx am |
Ich habe gerade mit einem eleganten Kniff das Verschachtelungs und overlap Problem gelost. Damit ist die Benutzung von hr Elementen und ihres collapses hinfällig. ?
Beat Post author am |
Falls dieser elegante Kniff in den Download-Daten vom 05.02. von 20:18 Uhr enthalten ist, so überzeugt mich das Resultat nicht wirklich.
Vorschaubilder werden nun nicht mehr umflossen, sondern der Fliesstext bleibt immer gleich breit (fliesst also nicht mehr unter das Bild). Siehe z.B. https://www.beatsblog.ch/2595-schoene,-neue-Raeder.html
Wenn ich hr lösche, verschachteln sich die Bilder wieder wie zuvor. Deshalb habe ich nach einem Test die hr's wieder eingesetzt und kann Dir darum kein Beispiel-Link angeben.
Ian Styx am |
Ops, ? ich sehe es. War wohl ein Schnellschuss! Schade!
Entferne das overflow in #content p solange.
Ian Styx am |
Gefixt. Sollte jetzt sogar das image overlap Problem auch mit lösen, also bitte mal im user.css das https://www.blog.dokumenzi.ch/2630-Bilder.html#c6452 wieder löschen und nachkontrollieren.
Beat Post author am |
Danke!
Habe postcontent: inline-block aus der user.css gelöscht. Zusammen mit den neuen Daten sieht es jetzt ganz gut aus! ?
Ian Styx am |
Ja das sieht jetzt alles gut aus und es macht viel Spaß durch deine alten und neuen Einträge zu surfen!
Ich wünschte ich hätte solch erworbene Kraft um solche Touren zu machen. Das muss klasse sein! Toll!
Was mir dabei auffiel ist, dass die entries Liste auf beatsblog jetzt ziemlich flüssig läuft, egal wie weit man in die Vergangenheit geht und dort eventuell vielleicht sogar noch nie war. Die Einzelseiten allerdings haben immer noch diesen furchbaren Jetlag. Bist du dem schon auf die Spur gekommen?
https://www.beatsblog.ch/2402-Tag-11-nach-Levanto.html
50 Anfragen
1,37 MB / 704,81 KB übertragen
Beendet: 5,35 s
DOMContentLoaded: 4,56 s
load: 4,94 s
Auf der entries Liste Seite ist das beispielsweise
44 Anfragen
1,54 MB / 1,24 MB übertragen
Beendet: 1,93 s
DOMContentLoaded: 1,18 s
load: 1,88 s
Schon ein ziemlich relevanter Unterschied.
Beat Post author am |
? Danke für die Blumen! ?
Bezüglich Geschwindigkeit: Ich habe vorgestern Abend in der Blog-Konfiguration die GZIP-Kompression eingeschaltet. Zusätzlich implementiere ich in .htaccess die APCU-Module:
Das hat dann doch einen guten Boost gebracht. Wenn dann keine grösseren Änderungen mehr anstehen, werde ich auch noch .js und .css minimieren.
Der von Dir genannte Artikel (nach Levanto) ist einer dieser Artikel, in denen das Garmin-iframe eingebunden ist. Das braucht ziemlich Zeit, bis es geladen ist. (Auch deshalb werde ich diese iframes nicht mehr direkt einbinden, sondern auf die Garmin-Seite verlinken). Habe übrigens gerade gemerkt, dass das iframe nicht angezeigt wird (im Seitenquelltext wird es aber erwähnt), Komisch.
Soweit bin ich also ganz zufrieden. ?
A propos .htaccess -> Ich konnte meine Fotoalben nicht ansprechen und bemühte deswegen den Manitu-Support. Das war die Antwort:
Interessanterweise macht diese Zeile hier, auf dem hosttech-Server, überhaupt kein Problem und das einzige installierte Fotoalbum (TREK 1120) läuft problemlos. Auf dem Manitu-Server muss aber allem Anschein nach diese Zeile raus. Na ja, nun funktioniert es.
Zudem sind nun alle Uploads-Verzeichnisse mit 770er-Berechtigungen (und es funktioniert).
Ian Styx am |
Also ehrlich... ich bin kein Freund von solchen Sachen, der Mehrwert durch eine geringere Größe wiegt IMHO nicht auf dass sie zwangsläufig unleserlich werden, außerdem sollte schon gzip für pressierte Ladung sorgen. Schau dir einfach mal die load Zeiten eines solchen stylesheets bzw js files ohne und mit einer minify Kompression an. Sie ist meist zu vernachlässigen. Und es ist nur komprimierte Luft. ?
Das mit der htaccess ist interessant. Hast du wirklich überprüft ob diese drei zusätzlichen Module an sich für eine essentielle Beschleuning sorgen?
Das auskommentierte Rule in der Styx htaccess ist nicht ratsam!
In Unterordnern, die nicht Serendipity sind - also beispielsweise /touren/ - legt man einfach eine neue .htaccess an mit RewriteEngine OFF an
und der Fall ist erledigt.
Beat Post author am |
Also ich testete auf: https://tools.pingdom.com/ die Seite: https://www.beatsblog.ch/categories/BLOG
Mit Google PageSpeed Insight (die gleiche Seite):
Nicht wirklich essentiell, doch immerhin. ?
Danke für die Hinweise zur .htaccess - ich habe das jetzt wie von Dir vorgeschlagen umgesetzt und es scheint zu funktionieren. ?
Ian Styx am |
https://www.beatsblog.ch/2386-hoch-und-breit.html (ohne Garmin und auch nicht viel besser)
48 Anfragen
1,31 MB / 526,83 KB übertragen
Beendet: 5,48 s
DOMContentLoaded: 4,58 s
load: 4,82 s
Ich sags mal so - das müsst eine Angelegenheit von 0.50s sein, wenns hoch kommt mt allem Schnickschnack 1 - 1.5s.
Beat Post author am |
Es sieht so aus, wie wenn jede Single-Entry-View über 4 Sek. benötigt, bis sie vollständig geladen ist. Indexseiten brauchen im Schnitt um die 1,5 Sekunden. Das ist ziemlich verwirrend, denn die Index-Seite zeigt ja eigentlich 10 Single-Entries (ich habe ja keine erweiterten Beiträge).
Das ist unschön, doch ich weiss auch nicht, was ich dagegen tun kann.
Beat Post author am |
Habe mal den Manitu-Support angeschrieben:
Ian Styx am |
Als kleiner Hinweis, dass es sich dabei um identische Blog und Versionssysteme aber unterschiedliche HTTP-Server mit leichtem nginx cache Vorteil handelt, wäre vielleicht noch zuträglich gewesen - ansonsten bin ich gespannt. Vor 2 Stunden hatte ich mal geschaut wer die anderen 35 User auf dem Server sind. Viele davon sind noch gar nicht aktiv, andere nutzen es einfach als nextcloud Server. So allgemein dürfte es also nicht am Betrieb oder fehlenden Ressourcen liegen.
Beat Post author am |
Manitu ist momentan relativ ratlos. Es ist aber auch komisch, dass die Verzögerung nur in der Single-Entry-Ansicht auftritt.
Sie wollen jetzt selbst eine Serendipity-Styx-Edition Testinstallation aufbauen um der Sache besser auf den Grund gehen zu können.
Abwarten...
Ian Styx am |
Man darf gespannt sein. ?