Donnerstag, 30. April 2020
alle Blog-Bilder des Jahres 2019
Seit ich das Seitenleisten-Plugin "Drei Zufallsbilder" einsetze fällt mir auf, wie viele tolle Bilder es hier bereits gibt und wie einfach dass man die vergisst.
Ich überlege mir deshalb, eine Art Foto-Archiv anzulegen. Darin sollen alle Bilder des Blog, nach Jahren sortiert, angezeigt werden. Eine erste Idee ist, jeweils einen Blogeintrag zu erstellen und mit der "Styx Media Gallery" alle Bilder eines Jahres einzubinden. Diesen Beitrag kann man jeweils auf den 31.12. des jeweiligen Jahres datieren.
Ich teste das hier einmal mit dem Jahr 2019, indem ca. 250 Fotos hochgeladen wurden. Mir ist dabei schon klar, dass die Ladezeit eines solchen Beitrags entsprechend lange dauern wird. Trotzdem... ein Testblog ist ja dazu da um zu testen...
Hmmm... Die Galeriefunktion scheint auf 48 Bilder pro Galerie beschränkt zu sein. Sobald ich in der Auswahl auf die Folgeseite wechsle, verliere ich die Selektion der vorangegangenen Seite. Um nicht X Beiträge zu schreiben wersuche ich nun einfach, innerhalb des gleichen Beitrags eine neue Galerie einzubinden.
Ja, das geht soweit. Das heisst, ich muss vor Anwendung der Galeriefunktion die Darstellungsart (Upload-Datum) richtig wählen und dann so viele Galerien hintereinander in einen Beitrag einbauen, wie Gesamtzahl der Bilder / 48.
Der nächste Versuch also mit dem ersten Bild des Jahres 2019 beginnend und möglichst genau 48 Bilder auswählen. Ah ne, das geht nicht. Mir werden maximal 48 Bilder zur Auswahl gegeben und sobald ich ein paar Bilder ausschliesse, reduziert sich dementsprechend die Darstellung. Ich kann mir nicht (wie in der Mediathek) 96 Bilder anzeigen lassen und dann 48 davon auswählen.
Die Darstellung oben ist nun nach Zeilen und nicht nach Spalten sortiert. Dies fand ich als Übersicht und im Hinblick auf die Lightbox einfach sinniger. Nur... bei meiner Monitorauflösung werden jetzt nur zwei Bilder (260px) nebeneinader dargestellt, was nicht sehr schön ist. Die Darstellung nach Spalten (weiter oben) ist schon schöner und skaliert auch besser. Wobei ich auch sagen muss: In der Mobile-Ansicht gibt es keinen Unterschied, weil dort so oder so nur ein Bild (pro Zeile) dargestellt wird.
Muss mir das noch einmal überlegen... Wen (ausser mir) so eine Galerie überhaupt interessieren könnte, ob sich der Aufwand lohnt, denn über 3'000 Bilder bedeuten 3'000/48= > 62 Galerien in 15 Beiträgen (Jahren).
Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2640-alle-Blog-Bilder-des-Jahres-2019.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ian Styx am :
Huch... ist denn schon Neujahr..?
Sie sind ein Witzbold, mein Herr ⛄
Das scheint nicht nur so ... sondern ist auch so! Steht groß in der zugehörigen Erklärbox.
Warum, kannst du dir nun sicher denken..! ☺
Aber wie man sieht, man kann für jede Restriktion eine entsprechende Umgehung finden. Man muss das aber ja nicht nur einmal im Jahr machen und damit vielleicht alle überfordern, sondern kann das ja in Themen aufteilen, oder vierteljählich rückblicken, oder oder. Nicht wahr?!
Beat Post author am :
Du bist zu früh mit kommentieren. ? Bin noch in der Findungsphase... ?
Beat Post author am :
Nein, kann ich nicht. Also: Warum?
Ian Styx am :
Ja, ..habe ich schon gemerkt...! ?
Rein technisch kannst du also zwei 48iger Galerien auch miteinander verknüpfen, in dem du im Qellcode das letzte end-div aus der ersten Galerie entfernst und das startende div der zweiten ebenso. Und schwupps hast du 96. etc.
Nur muss man die Kapazitäten des eigenen Servers und die der Besucher PCs/Geräte nicht überschätzen. Schon deshalb hielt ich es für eine geeignete Idee so eine Begrenzung einzuführen. Selbst mit den optimierten webp Dateien. Für mehrere tausend ist das sowieso nicht geeignet und sollte vielleicht besser in eine dafür optimierte Galerie verlinkt werden.
Ian Styx am :
Pro Bild ca 50Kb x 48 mit ein bisschen Spirenzchen macht locker 2,5 Megabyte, Und das nur in einem Artikel unabhängig vom Load der ganzen Seite.
Beat Post author am :
Ich verstehe, was Du meinst. Wenn ich diesen Beitrag hier (mit 113 Bildern) via pingdom.com teste, sieht das im Moment so aus:
Find ich jetzt nicht erschreckend... Aber Du hast schon recht. Vielleicht sollte ich die Idee besser mit einer JAlbum-Galerie lösen. Ich fands halt einfach schön, dass man sofort alle Bilder sieht. Ich fühle mich davon auch nicht überfordert.
(Phua! Ist diese Server-Umgebung SCHNELL! Auf www.beatsblog.ch braucht ein einzelner Beitrag immer noch so um die 2 Sekunden).
Aber ja, ich überlege noch weiter...
Ian Styx am :
Ja das ist durchaus mal zumutbar, vor allem wenn man sich dabei auf den erweiterten Entrag beschränkt und die entrypaging Geschichte mal außen vor läßt.
Ich muss als Entwickler eben nur mehr Fälle bedenken und zu vermeiden suchen, den Eindruck zu erwecken, man könne hier mal eben so ein Foto Blog hochziehen weil die Möglichkeiten unbegrenzt sind. Es ist ja nicht nur die Auslieferung, sondern auch die Vorhaltung in der Mediathek und die Zusammenstellung für den Beitrag, die eine Rolle spielen. Für eventuelle Optimierungen oder Änderungen bräuchte ich echt mehr fundierte Meinungen und Szenarien.
Ian Styx am :
Ich will aber natürlich auch nicht den Eindruck erwecken, man solle sie alldieweil überhaupt nicht nutzen ... denn natürlich freue ich mich wenn sie benützt wird, weil sie einen echten Mehrwert bietet, schön aussieht. sich exzellent verhält usw. - ja, dafür habe ich sie gebaut - nur (eben) mit Bedacht und im Maße. ?
Dann ist alles GUT!
Schönen ersten Mai. ?
Beat Post author am :
Nach "einmal drüber schlafen" bin ich von der Jahres-Galerie-Idee nicht mehr so überzeugt. Aktuell denke ich, dass man so oder so nicht verhindern kann, dass Bilder in Vergessenheit geraten. Und wie angesprochen, ist eine Darstellung von über 100 Bildern in einem Blogeintrag auch icht mehr übersichtlich.
Die Idee tauchte ja im Zusammenhang mit dem Seitenleisten-Plugin "Drei Zufallsbilder" auf. Vielleicht erweitere ich diese auch einfach mal auf fünf Bilder...
Ian Styx am :
Ähem .... das ist ja nur ein Gimmick - das im Übrigen viel Leistung zieht.
Ich würde persönlich eher auf eine gecachte Lösung setzen, bei der sidebar, also weg von dynamischen Requests. Zum Beispiel ein Bild der Woche oder so; und/oder vielleicht ergänzen durch einen monatlichen Blogbeitrag mit den 12-24 schönsten Bildern. Andererseits hast du ja immer Bildeinträge in deinen Entries. So könnte man weekly oder monthly summaries schreiben und mit kleinen Galerien aufpeppen...
Beat Post author am :
Jetzt tust Du diesem Plugin aber unrecht! Ich finde das so wertvoll, wie das History-Plugin darüber. Die Funktionalität (bei jedem Refresh neue Bilder, Verlinkung von Bild zu Artikel) gefällt mir wirklich sehr gut. Von mir aus könnte man das Plugin von allen Zusatzfunktionen (andere Quellen, hotlinked items, eigene styles, etc.) befreien um es etwas zu verschlanken. Aber ansonsten: Top! Für mich ist das mehr als nur ein Gimmick.
Zu den anderen gecachten/statischen Ideen denke ich: Eher Nein. Ist mir zuviel Aufwand. Aufgrund der Galerie-Restriktionen dachte ich mal über Quartalsbeiträge nach, doch schon das ist mir zu aufwendig. Deshalb hatte ich zu Beginn Jahresbeiträge im Fokus.
Auf www.beatsblog.ch lasse ich von jetzt an mal 5 Bilder über das Seitenleisten-Plugin anzeigen. Das Thema ist für mich noch nicht abgeschlossen, doch ich muss erst mal herausfinden (spüren), was ich wirklich will...
Ian Styx am :
Nicht das wir uns mißverstehen, ich mag sie auch - (in Maßen). ? Sie ziehen halt einfach Leistung; das war es was ich sagen wollte.
Ich finde, dass auf beatsblog die Einzeleinträge jetzt doch schon ziemlich flott laden, obwohl ja das entrypaging aktiv ist. Dabei fiel mir ein, dass ich neulich Nacht darüber nachgedacht habe, ob es (der delay) nicht auch eine Frage der Position des Plugin (in der Pluginliste) sein könnte. Je weiter oben, desto besser, würde ich sagen. Hatten wir darüber schon mal nachgedacht und es auf Validität überprüft?
Beat Post author am :
Nein, darüber haben wir noch nicht nachgedacht. Ich habe das Plugin nun mal an 3. Stelle, direkt nach den zwei Anti-SPAM-Plugins plaziert. Eine erste Messung brachte aber nur einen marginalen Unterschied zu Tage, welcher auch auf anderes zurückzuführen sein könnte.
Meine Laienmeinung ist ja immer noch: Wenn es hier (hosttech) schnell geht und dort (manitu) eben nicht, dann liegt es an der Infrastruktur. Da hier nginx cacht, dachte ich, dass ich auf www.beatsblog.ch mal den "experimental" Cache einschalte um zu sehen, ob das etwas bringt. Leider funktioniert der Blog dann nicht mehr und ich erhalte folgende Fehlermeldung:
Ian Styx am :
Immerhin hast du dadurch einen Fehler aufgespürt!
Ich habe ein Update der lib gemacht und den Fehler dann noch mal per Hand einzeln hoffentlich erschlagen.
Ich würde sagen, der Nutzen dieses experimentellen Caches ist zweifelhaft, insbesondere für das genannte Problem. Dieser Cache soll ja Datenbankanfragen cachen. Das macht aber gerade da überhaupt keinen Sinn, wo jeder Folgerequest eine veränderte Datenbankquery benötigt. Das läßt sich so nicht cachen, außer innerhalb der Datenbank selbst, was sowieso und schon viel besser erledigt wird.
Ich würde jetzt mit einem Gesamtupdate von 3.0 auf mein bald folgendes (beta/rc) Release warten, vielleicht so um den 10-12. Mai herum.
Zur Infrastruktur ... ist es doch eben so, dass so viel anderes überall wo bisher getestet nicht läuft, bis auf NGINX auf dokumenzi (das über so eine Art proxy cache verfügt) und wahrscheinlich nur deshalb so viel schneller ist, weil es alle Kombinationen von Request Anfragen im Cache irgendwie vorhält. Ansonsten haben wir überall halbwegs aktuelle MariaDB Installationen und als einzigen Unterschied die verschiedenen Traces zum und vom Server. Das kann, wenn nicht vieles im Argen liegt, keine solch signifikanten Unterschiede ausmachen. Vielleicht ist es eben so, dass keine der anderen Testszenarios die ich benutzen kann, über ein solche Historie von Einträgen verfügt und diese eben doch eine Rolle spielen.