Kommentare von

beats TEST blog

Weblog Kommentare

Styx Media Gallery

Beat Post author am |

DOCH! Das sind die gleichen Bilder! Hier habe ich die Bilder 001...-006... eingefügt. Wenn Du in Deinem Code-Schnipsel weiter nach unten scrollst, dann kommen diese Bilder im Eintrag /2632-Sizilien-Fotos,-die-Top-25.html ganz unten (weil die Nummerierung von 024... bis 001... rückwärts läuft).

Ich komme nicht umhin um anzunehmen, dass Du an der Gallery-Funktion etwas verändert hast, denn in beiden Einträgen habe ich diese benutzt und nun kommen sie Code-mässig anders daher. Wenn ich jetzt nur das einzelne Bild "001_1024_vor_Centuripe.jpg" betrachte dann baut sich der Code im Eintrag /2632-Sizilien-Fotos,-die-Top-25.html wie folgt auf:

EDIT: codeblock gelöscht weil falsch und so kaputt das das ganze Gerüst in Mitleidenschaft geriet. Machs nochmal, Sam!
         Mo., 14. Aug. In deinem Sinne überarbeitet bzw ergänzt

<div class="c3 col serendipity_image_block">[.....]<a  class="serendipity_image_link" data-fallback="/uploads/2020/Sizilien/001_1024_vor_Centuripe.jpg"  rel="lightbox[2632]" href="/uploads/2020/Sizilien/001_1024_vor_Centuripe.jpg" title="001_1024_vor_Centuripe.jpg"><!-- s9ymdb:9465 --><img alt="001_1024_vor_Centuripe.jpg" class="serendipity_image_left" src="/uploads/2020/Sizilien/001_1024_vor_Centuripe.styxThumb.jpg" style="width:400px" /></a></div>

In diesem Beitrag baut sich der Code jedoch so auf:

<div class="c3 col serendipity_image_block">
	[.....]

	<div class="serendipity_imageComment_left" style="width:400px">
	<div class="serendipity_imageComment_img"><a class="serendipity_image_link" data-fallback="/uploads/2020/Sizilien/001_1024_vor_Centuripe.jpg" href="/uploads/2020/Sizilien/.v/001_1024_vor_Centuripe.webp" title="001_1024_vor_Centuripe.jpg "><!-- s9ymdb:9465 --><picture><source srcset="null" type="image/webp" /><img alt="in Paterno, im Hintergrund Centuripe" class="serendipity_image_left" loading="lazy" src="/uploads/2020/Sizilien/001_1024_vor_Centuripe.styxThumb.jpg" style="width:400px" /></picture></a></div>

	<div class="serendipity_imageComment_txt">in Paterno, im Hintergrund Centuripe</div>
	</div>
</div>

Sämtliche .webp und .styxThumb.jpg und .jpg Dateien sind in der Mediathek vorhanden. Daran kann es also nicht liegen.

Achtung! Habe heute nochmal die gleiche Galerie in den Beitrag eingefügt und oh Wunder: Nun funktioniert es so, wie es soll. Keine Ahnung woran es lag/liegt.

Ian Styx am |

Auseinanderklamüser....

1. Es geht/ging um den ganzen Sizilien Ordner mit all seinen Bildern, deshalb kann/konnte mein Beispiel auf eine andere Bildnummer zeigen ohne an der Aussage etwas zu verändern.

2. Es gibt zwei Arten eine Gallery zu erzeugen. Mit picture container, also unter Nutzung von AVIF (optional) und WEBP Variationen und als simple IMG tag gallery mit den Original Bildern.

3. Die ehemals hier erzeugte Galerie auf die du dich beriefst ist eine ohne die zusätzlichen Variationen.

4. Wenn du in der Mediathek auf den info button eines dieser Sizilien Bilder klickst wird dir ja angezeigt:

006_1024_vorTorreSalsa.jpg

  • MIME-Typ: image/jpeg
  • Originalbild: 1024x768
  • Vorschaubild: 400x300
  •  
  • Dateigröße: 398,06 KB
  • Vorschau-Dateigröße: 22,73 KB
  • WebP-Dateigröße: 111,31 KB
  • WebP-Vorschau-Dateigröße: 15,42 KB
  •  
  • Pfad: "2020/Sizilien/"
  • Datum: 10.03.2020 15:31

Wie du richtig bemerkst ist heute alles vorhanden. Gestern als ich dieses schrieb fehlte überall die WebP-Vorschau-Dateigröße: x,y KB . Und der Variations Button wurde deshalb auch nicht angezeigt. Ich nehme also mal an du hast inzwischen das Media Wartungstool und/oder dein FTP Programm benutzt, denn ich habe nichts gemacht außer einmal das Problem nachzustellen und in diesem entry die null herauszunehmen (alles ohne speichern). Und solch ein Zauberkram gibts nicht wie wir schon mal feststellten. 😀 Überprüfe mal per FTP im Sizilien/.v/ Ordner, wann die diesbezüglichen webp THUMB Dateien produziert (last modified) wurden.

5. Wie du außerdem wahrscheinlich bereits festgestellt hast sind deine beiden code Felder leer bzw werden nicht angezeigt. Ich kann also nicht sehen auf was du dich da beziehst. Das ist ein merkwürdiger BUG des codesnippet mit CKE an dem ich auch schon herumfummele seit ich es bemerkt habe. Denn der switch zwischen Source und RT mode funktioniert tadellos, nicht aber der Umweg über abspeichern und Neuaufruf desselben Eintrags im RT Editor der den inneren Teil des codes entfernt und wenn man diesen dann erneut abspeichert weil man es auf die Schnelle nicht bemerkt hat ist alles diesbezügliche weg. Wenn man aber das erste abspeichern sozusagen untouched beläßt wird in der Ausgabe (hier als Kommentar) auch alles korrekt ausgegeben. Ich denke also du hast den Kommentar nochmals bearbeitet und dir ist dieselbe Unaufmerksamkeit passiert wie mir als ich das zum ersten Mal feststellte. (Seitdem passe ich immer auf und kopiere mir sicherheitshalber den Teil bevor ich nochmals editiere.)

Es betrifft auch nur code mit tag Elementen. sonstiger code bleibt erhalten. Insofern glaube ich einfach an einen dicken bug im leider nicht mehr weiter entwickelten CKE 4 Editor.

Edit: Inzwischen habe ich herausgefunden dass das eventuell an einer Sicherheitsmaßnahme von mir liegt und somit Styx-seitig zumindest "verbessert" werden kann. Da ich an dieser Stelle schon länger nichts mehr gefummelt habe muss dieses Verhalten schon ein bisschen länger bestehen. Wenn ich mir dann einigermaßen sicher bin, mache ich mal einen diesbezüglichen Vorschlag. 😅

Ian Styx am |

Habe gerade deinen https://www.blog.dokumenzi.ch/2690-Styx-Media-Gallery.html#c8461 Kommentar repariert der in/durch seinen ersten code Block so kaputt war, dass Frontend und Backend in Mitleidenschaft gerieten. Bevor ich das WIE erklärt hätte wäre zu viel Zeit vergangen, deshalb habe ich kurz eingegriffen. Der Kommentar konnte im Backend zB nicht mehr über die Buttons bearbeitet werden deshalb musste ich cheaten und einen anderen Kommentarlink kopieren; ihn aber mit den richtigen IDs belegen. Dann ging es. Es ging darum dass ein Teil des Code Blocks plötzlich außerhalb desselben zu finden war und das ganze HTML Gerüst verbog.

Wie du siehst ist der zweite code Block auch nicht das was du da hineingestellt hast. Also auch der müsste im Zuge der Reparatur repariert werden.

EDIT:  Mo., 14. Aug. habe nun verstanden welche code Blöcke gemeint waren und sie in deinem Kommentar eingefügt.

Ian Styx am |

Nur zur Ergänzung. Ich habe gestern im Vorgriff die Null Geschichte schon repariert, weil ich das genau so bei mir lokal nachstellen konnte. Ich habe also bereits vorhandenen Bildern mit Variationen kurzfristig das Variations Thumb entfernt und hatte dann genau das gleiche Galerie Ergebnis wie du - ebenso auch meine Mediatheks Feststellungen. Insofern bin ich mir auch ziemlich sicher, dass das gestern bei dir auch noch der Fall war. Und deshalb zwischenzeitlich etwas geschehen ist das die Thumbs repariert hat.

Ian Styx am |

Bist du schon soweit gekommen das noch mal durchzulesen und dem auf den Grund zu gehen?
Das mit dem Wasserglas kann ich immer noch nicht recht glauben...

Beat Post author am |

Ich habe Deine Kommentare gelesen, jedoch nicht wirklich verstanden 😏. Ich bin auch ein schlechter Fehlersucher und wenn etwas (wieder) so funktioniert wie ich es mir erhoffe (oder wie es soll), dann bin ich eigentlich zufrieden...

Was ich aber bestätigen kann, ist folgendes:

Bei den ersten (missglückten) Versuchen fehlten im Verzeichnis /uploads/2020/Sizilien/.v alle Dateien mit der Endung *.styxThumb.webp. Diese habe ich mir dann vom Live-Blog hierhin kopiert und danach hat es funktioniert.

Worum es diese Dateien hier nicht gegeben hat und warum die Vorschaubilder im Beitrag /2632-Sizilien-Fotos,-die-Top-25.html auch zuvor schon richtig dargestellt wurden, entzieht sich meinem Verständnis.

🤔 Vielleicht braucht es kein *.styxThumb.webp, wenn die Bildeigenschaften für Kommentar, TITLE und ALT leer sind? Im Quellcode von /2632-Sizilien-Fotos,-die-Top-25.html gibt es nämlich Null Treffer bei der Suche nach *.webp

Ian Styx am |

... Diese habe ich mir dann vom Live-Blog hierhin kopiert und danach hat es funktioniert.

Yepp. Das war die fehlende Information! 👏

Die Variationen dienen nur dazu einem Browser, der einen picture container gesendet bekommt, aufgrund seiner Möglichkeiten auswählen zu lassen, welches Format er darstellen kann. Da AVIF besser komprimiert als WebP und damit noch kleiner (in KB) ist, steht es on top. Danach WebP und als letztes da original image (format). Mit irgendwelchen Atributen haben sie überhaupt nichts am HUT ⛑, denn diese stehen und werden auch immer von anderen Stellen ausgelesen, entweder im img tag oder außerhalb des eigentlichen picture containers. So kann auch ein Attribut, gesetzt oder nicht, keinerlei Bedeutung für das Vorhandensein der Bild-Variationen haben. So eine Schrumpfung auf bis zu ~10% des Originals beschleunigt Webseiten Ausgaben aber ungemein. Die einzige Kondition für die Einfügung von Variationen ist, dass sie 1. existieren und 2. kleiner sind als das nächstfolgende fallback image.

Beat Post author am |

Mir erklärt das aber immer noch nicht, weshalb ich hier 2020 eine Gallery ohne .webp-Thumbs erstellen konnte, wenn dies aktuell nicht mehr möglich ist.

Ian Styx am |

warum die Vorschaubilder im Beitrag /2632-Sizilien-Fotos,-die-Top-25.html auch zuvor schon richtig dargestellt wurden, entzieht sich meinem Verständnis.

Zur Sicherheit erkäre ich das nochmal en Detail. Dieser alte Beitrag arbeitet mit einer Bilder Galerie OHNE picture container. Das was du siehst sind also die Original jpg Dateien durch das img tag ( thumb oder nicht spielt keine Rolle ). Dein Auge sieht ja nicht ob es ein avif/webp/jpg Format ist. Das kann man nur an der URL erkennen.

Obige Galerie mit dem null Fehler arbeitet aber MIT picture container, hatte aber durch den ungeklärten Unfall (wahrscheinlich per FTP) der fehlenden webP (thumbs) keine solchen File URLs zum einfügen und nahm dann durch eine bis dahin nicht abgefangene javascript Eigenheit ein NULL Typ, also NULL für nicht existent, als einen "null" string stattdessen. Der Browser suchte also einen string wie "https//blog.dokumenzi.ch/null" als angegebenes webp file. Die URL ist existent, aber eben nix dahinter. Deshalb wurde das Bild leer angezeigt und du sahst bzw siehst stattdessen die ALT Attribute. Hättest du das null im schon gespeicherten entry Source (per CKE) entfernt, so wäre auch das Bild (scheinbar) angezeigt worden, allerdings nur der fallback, also das jpg thumb file, da ja dann die eigentliche webp url leer gewesen wäre. Auch jetzt würde durch die Wegnahme des null nur das fallback wirken. Ansonsten müsstest du, wie dann noch mal am 12. Aug. gemacht, die Galerie nochmal erstellen. Diese hatten/haben aber Zugriff auf die nun übertragenen WebP und nun kompletten thumb files und konnten/können nun alles korrekt darstellen.

Ah ich sehe gerade deine Folgefrage. Sie wird durch das hier beantwortet! 😀

Ian Styx am |

Hmmmm. Vielleicht aber auch nicht, denn du hakst an der Sache "..nicht möglich wenn nicht existent", oder?

Das ist grundsätzlich richtig, aber trifft diesen Fall nur bedingt. Denn die "full size" webp Variationen existierten ja, nur ihre thumbs nicht. Deshalb lief alles seinen gewohnten Gang, bis es auf die geschilderte javascript Eigenheit traf und damit ein Fall aufdeckte der bisher nicht bedacht war.

EDIT: Im Zuge dessen habe ich deinen Kommentar mit den vermurksten code Blöcken gerade eben nochmal überarbeitet. Hoffentlich in deinem Sinne. Jetzt können wir uns wenigstens zur Klärung verschiedenster Tatbestände darauf berufen. 🤗

Ian Styx am |

Ich habe dir was hinterlassen (bzgl. des re-edit bugs mit den code Blöcken).

Beat Post author am |

Gemacht.

Ian Styx am |

Danke. Text zur Info ergänzt.

Ian Styx am |

Edit2 und neu

Beat Post author am |

unklar

Ian Styx am |

schau nochmal...

Ian Styx am |

ping

Beat Post author am |

Einzig logische Antwort: pong! 😉

Ian Styx am |

p😁ing

Beat Post author am |

Ich bin da noch eine Antwort schuldig.

Der besagte Kommentar wurde von mir im Backend zerschossen. Das merkte ich aber erst nach dem Speichern. Und dann nahm ich mir nicht die Zeit um das zu korrigieren.

Styx 4.2-beta1 und PHP 8.2.8

Beat Post author am |

To keep track, the recommended way for upgrade is to fetch a new fresh template copy for your copy themes, if have. You can find detailed notes in the changelog.

Ich dachte eigentlich, dass mir bei jedem Upgrade die neusten Dateien des Pure-Templates automatisch aufgespielt werden. Ist dem nicht so? Muss ich diesen Templates-Ordner manuell downloaden und auf meinen Server kopieren?

  * Better distinguish between HTML (comment) form color modes storage sets
    using themes SESSION storage [ pure ] and LOCAL storage [ b53 ] and all
    other themes without, for the default behaviour.
    COPY THEMERS: Follow the themes js file change.

Das heisst, ich muss das neue /templates/pure/pure.js überprüfen und ev. Änderungen in mein templates/pure-beat/pure.js übernehmen.

  * Add [ boot ] pool and [ pure ] combined light/dark mode assets
     _assets/highlight/github-pool.min.css
     _assets/highlight/github-pure.min.css
    for highlight js code, differed by the used dark mode prefix.
    COPY THEMERS: Improve you copy files, please.

 ? 🤔 ? Kein Plan. Was muss ich diesbezüglich tun?

 

PS: Sowohl bei Hosttech, wie auch bei Manitu, erhalte ich nach dem Update des CKEditors und auch nach dem Starten des Serendipity-Udaters jeweils eine weisse Seite. Soweit kein Problem, weil ein erneutes Aufrufen des Backend-Links sofort die richtige (nachfolgende) Seite anzeigt.

PPS: Das neue sY9-Favicon der Verwaltungsoberfläche ist in der hellen Standard-Einstellung des Browsers unsichtbar, weil weisser Adler auf weissem Grund. Hier wäre ein Grauton vermutlich besser, was bei Standard- und Dark-Mode Ansicht sichbar wäre.

Ian Styx am |

Ui das ging ja fix... 😀

Eigentlich bedeutet das nur, dass für COPY themes die entsprechenden template oder js Dateien, die du verändert hast und die du deswegen in dein COPY theme übernommen hattest, empfohlen wird, die neueren Daten aus dem Original theme NEU zu übernehmen und deine individuellen Änderungen wieder einzupflegen, Das ist meist einfacher als mit den Veränderungen Schritt zu halten und diese in dein copy template zu übernehmen. Gerade weil du das ja auch nur unvollständig aus dem letzten Update gemacht hattest (siehe Comment ID).

Wenn es nur eine kleine Sache ist kann man natürlich auch nur die Veränderung übernehmen, oder man hat einen DIFF um die Unterschiede anzuzeigen. Aber meist hat man wohl seine eigenen Änderungen irgendwo dokumentiert und kann diese somit leichter in ein neues template fetch einpflegen als mit dem anderen Weg.

Ian Styx am |

Das Styx favicon ist bei mir weiß auf grau im nicht aktiven Zustand und weiß auf dunkelgrau im aktiven Zustand. So soll es sein. Ist das bei dir anders? Auch mit anderen Browsern? Kannst du das irgendwie gezielt ablichten, wenn anders?

Das mit der "weißen" Seite ist wohl eher ein cache issue (ich denke das hatten wir schon mal besprochen)

Beat Post author am |

Ich habe Edge, Chrom und Firefox. Alle in der normalen/weissen Grundeinstellung. Bei allen sehe ich bei den Favoriten nun kein Favicon. Bei Mouse-over (die Zeile wird grau unterlegt) sehe ich, das weisse sYx.

Ja, die Geschichte mit der weissen Seite hatten wir schon länger/öfter. Ich dachte, früher war das nur bei einem der zwei Server. Wollte damit einfach nur erwähnen, dass dies immer noch so ist und nun auf beiden Servern (egal ob mit ngix oder nicht) auftritt. Mich stört das nicht.