Weblog Kommentare
alte Vorschaubilder vergrössern
Ian Styx am |
ich will auch gleich die alten serendipityThumb.jpg durch sytxThumb.webp ersetzen.
Das ist keine gute Idee und sicher ein mißverständlicher Verschreiber! Du willst xxx.serendipityThumb.jpg, durch xxx.styxThumb.jpg ersetzen. ? Ditto für die webp Variationen (so da schon welche wären).
Nur zu Information: Normale Upgrader von einem damaligen S9y haben ja .serendipityThumb als Appendix Auszeichnung aktiv.
Wenn diese Auszeichnung in der Konfiguration des Blogs auf styxThumb oder lilaThu geändert wird, wird automatisch eine neue Aktion in der Wartung (Mediatheksaufgaben) aktiv, die es erlaubt, alle bisherigen echten Medien und Medien-Datenbank-Enträge, sowie alle Blog und staticpage Einträge welche jene benutzen zu konvertieren.
[Nachtrag 17. Mai: Wie in den weiteren Kommentaren beschrieben bedeutet "automatisch" hier aber nicht unmittelbar, sondern nur unter der Bedingung, dass mind. bereits ein neues Medium mit dieser neuen Auszeichnung (über Medien hnzufügen) erstellt wurde.]
Das gilt auch, wenn du - der du (durch deine Art der Migration) bereits eine neue, wie bei Neu-Installationen, gesetzte Thumb Auszeichnung benutzt, diese in der Konfiguration zurück auf serendipityThumb stellst. Dann würde dir die Wartung erlauben, alle Medien und Einträge auf diese Auszeichnung zurückzuportieren. Danach könnte man dann genau umgekehrt vorgehen. (Wirf mal einen Blick in die zurgehörige Wartungs Info dazu, wenn du einen anderen Appendixnamen in der Konfiguration gewählt hast.) Wichtig ist also eine konsistente Grundlage für die Konversion.
[Nachtrag 17. Mai: Das mit dem Zurückstellen ist mißverständlich ausgedrückt und bezieht sich auf die Bedingung des vorherigen Nachtrags. Solange alle Einträge einheitlich sind, kann man den thumb Namen in der Konfiguration ändern und anschließend in der Wartung "Konvertiere alte Vorschaubild-Namen" anstoßen.]
Allerdings ist es immer gut, wenn man vor solchen Operationen einen Backup Dump zieht. Achtung: Das sind mind. '_images, '_entries, '_staticpages, '_mediaproperties und (?), sowie auch der ganze /uploads Ordner an sich.
Dabei kann natürlich viel schiefgehen und du müsstest darauf vertrauen, dass ich an alles gedacht habe als ich diesen Konverter schrieb. Ich habe viel getestet und war am Schluß zufrieden. Aber das basierte auf meinen Testinstallationen, die sicherlich nur theoretisch alle kombinatorischen Möglichkeiten und Bedenkungen ausschöpften. Außerdem kann solch ein Skript auch mal Husten haben und was dann...? 
Du siehst, da ist eventuell mehr zu bedenken. Mit beiden Auszeichnungen (alte und neue) gleichzeitzig zu fahren, ist überhaupt nicht schlimm! Die Möglichkeit aber, dass einem die eigene Pedanterie viel größere Probleme einbrockt, ist also gegeben und sollte vorher einfach wohl bedacht sein!
Beat Post author am |
Etwas viel Information auf einmal. ?
Verständnisfrage:
In der beatsblog-Konfiguration steht derzeit: Vorschaubild-Endung = styxThumb
Trotzdem wird im Quelltext des #1003-Beitrags auf .serendipityThumb.jpg referenziert.
Falls (was ich bezweifle) ich Dich richtig verstanden habe, könnte ich jetzt in der Konfiguration eine Vorschaubild-Endung von z.B. beatThumb eintragen. Danach würde mir unter Wartung irgendwas angeboten, was alle diese neuen Vorschaubilder erzeugt und auch noch den Quelltext aller Einträge editiert? Kaum zu glauben.
Ian Styx am |
Da nimmst du richtig an, denn du hast das mit der Bedingung der konsistenten Grundlage wohl nicht richtig gelesen.
Wenn alte Einträge (natürlicherweise) auf .serendiptyThumb stehen und du aber ein neues Block aufgezogen hast das in der Konfiguration bereits das neue Default: styxThumb stehen hat, werden alle neueren Einträge in die Medathek und damit auch die darauf beruhenden neu referenzierten Blogeinträge mit styxThumb ausgezeichnet.
Der Konverter kann aber nur von alle AAA auf alle BBB oder vice versa konvertieren. Deshalb müsstest du - so du unbedingt willst - erst auf serendipityThumb zurück (mit dem Konverter) und dann erst alle auf styxThumb portieren (ebenfalls damit).
Besser?
Kaum zu glauben.
Doch! So ist es gedacht. 
Ian Styx am |
Ich musste gerade selbst noch mal nachschauen. Es ist schon so lang her...
Diese Option im Wartungs Mediatheks Synchronizr wird einem auch erst dann angeboten, wenn tatsächlich bereits zwei verschiedene Thumb Auszeichnungen vorliegen. Ist das nicht der Fall, muss man nicht konvertieren können.
Beat Post author am |
? it's magic ?
Hmmm... zum Glück habe ich einen Testblog...
Doch ich sollte Deinen Hinweis, dass dies eigentlich unnötig und reine Kosmetik/Pedanterie ist, wohl ernstnehmen. ?
Wohl besser, wenn ich das vorerst mal lasse und mich nur um die "with=150px" Angaben kümmere. Wobei... falls durch die oben von Dir beschriebene Aktion nicht nur die serendipityThumb.jpg zu styxThumb.webp umgewandelt werden, sondern auch noch die Vorschaubildgrösse auf die voreingestellten 400px angepasst würde, wäre das durchaus eine Überlegung wert.
Ian Styx am |
Wenn ich (diesbezüglich) nicht eben auch so wäre ... gäbe es das nicht - also ist die Bezeichnung nicht unbedingt nur auf dich gemünzt. ☺
Hier zum nachlesen (für jene ohne)...
ACHTUNG: Diese Option wird erst aktiv, wenn es tatsächlich etwas zu konvertieren gibt.
Sie konvertiert Vorschaubild-Namen, die nicht dem augenblicklichen Namens-Schema: "blahThumb" entsprechen, in der Datenbank, ihrem Speicherort und bereits in Einträgen genutzt, durch das aktuelle Namens-Schema. Dies kann unter Umständen etwas dauern! Es macht nichts, wenn Sie diese Konvertierung nicht vornehmen und das alte Schema einfach so belassen, doch wenn Sie sie - über die "Alle Erneuern" Option neu bilden lassen müssen oder wollen, so muss die Konvertierung zuerst geschehen.
Du meinst "Behalte vorhandene Vorschaubilder nur, wenn diese die richtige Größe haben"?
Dies sollte all jene Vorschaubilder neu generieren (inklusive webp), die eben nicht der neu gesetzten Größe (400px) entsprechen. Einträge brauchen dafür doch nicht neu geschrieben bzw konvertiert werden, oder? (Bin mir gerade nicht sicher wie ich das gehandelt habe.)
NACHTRAG: Du hast aber über die Blogentries geredet, oder?
Beat Post author am |
Im Quelltext des #1003-Beitrags steht als Beispiel:
<a class="serendipity_image_link" href="/uploads/2008/20080713_08.jpg" "F1 = window.open('/uploads/2008/20080713_08.jpg','Zoom','height=715,width=948,top=34,left=45.5,toolbar=no,menubar=no,location=no,resize=1,resizable=1,scrollbars=yes'); return false;"><img src="/uploads/2008/20080713_08.serendipityThumb.jpg" style="border-bottom:0px; border-left:0px; border-right:0px; border-top:0px; float:left; padding-left:5px; padding-right:5px; width:110px" /></a>Ganz am Schluss "with:110px" bezeichnet wohl die Grösse des Vorschaubildes. Nach meinem Verständnis müsste ich -um grössere Vorschaubilder zu erhalten- diesen Wert hier immer auf 400px schreiben.
Ian Styx am |
Um das herauszufinden würde ich folgendes machen. Schreibe einen Testeintrag mit einem Bild das du auf diesem (neuen) Blog zum ersten Male heraufgeladen hast. Jetzt steht darin ja < img blah blah width=400px >, oder? Verdoppele diesen Media include im Quelltext und ändere den zweiten auf 150px. Wie sieht es aus wenn du die Seite im Frontend aufrufst?
Ian Styx am |
Ach nee ist ja klar...
Die Frage ist ja ob überall 110 bzw sein analogon 400 stünde, denn es gibt ja auch hochkant Bilder mit eiinem anderen width da ja die Höhe dann 400 wäre.
Beat Post author am |
Guckst Du: https://styx.beatsblog.ch/2632-Vorschaubildgroesse.html
doch es wird kompliziert... denn ein neues "picture"-Element erzeugt einen ziemlich anderen Quelltext für ein Bild, als dies früher S9Y-Original gemacht hat.
<figure class="serendipity_imageComment_left" style="width: 150px">
<div class="serendipity_imageComment_img"><a class="serendipity_image_link" data-fallback="/uploads/2020/20200512_03.jpg" href="/uploads/2020/.v/20200512_03.webp" title="klein"><!-- s9ymdb:10274 --><picture><source srcset="/uploads/2020/.v/20200512_03.styxThumb.webp" type="image/webp" /><img alt="klein" class="serendipity_image_left" src="/uploads/2020/20200512_03.styxThumb.jpg" style="width:150px" /></picture></a></div>
<figcaption class="serendipity_imageComment_txt">klein</figcaption>
</figure>
Aber... wenn ich wie oben angedeutet, "with=110px" auf "with=400px" ändere, dann wird das Vorschaubild schon in der neuen Grösse angezeigt. Siehe: https://styx.beatsblog.ch/1003-Hoehenmeter-sammeln.html
Beat Post author am |
STOPP!
Ich muss die Komplexität wieder reduzieren, sonst wird das nichts!
Ich mach jetzt mal einen Export der entries-Tabelle von www.styx.beatsblog.ch. Darin ändere ich alle "with=83px" (Hochformat) auf "with=300px" sowie alle "with=110px" (Querformat) auf "with=400px". Dann schaue ich weiter.
Du musst Dir übrigens keine Zeit nehmen für diesen Quark. Es ist eine Art "spielen"... Du kannst Deine Zeit bestimmt sinnvoller nutzen...
Ian Styx am |
Aber... wenn ich wie oben angedeutet, "with=110px" auf "with=400px" ändere, dann wird das Vorschaubild schon in der neuen Grösse angezeigt
Muss heißen "ändern würde", denn siehe https://styx.beatsblog.ch/uploads/2008/20080713_01.serendipityThumb.jpg
zeigt, dass du nur ein 110ner auf 400 unschön aufgebläht hast.
Ganz allgemein gesprochen ist es nicht so wirklich ratsam, einfach sein entries.sql zu nehmen und mit search und replace solche Dinge zu ändern. In der Datenbank stünden sie dann immer noch mit ihrer originalen Größe, mit unübersehbaren Folgen für spätere Zeiten und Aktionen.
Wenn man konvertiert, muss man das durchgehend und durchgehend richtig machen; am besten mit einem skript das keine Ausnahmen zuläßt bzgl Reigenfolge, Dependencies etc.
Beat Post author am |
In der Datenbank stünden sie dann immer noch mit ihrer originalen Größe, mit unübersehbaren Folgen für spätere Zeiten und Aktionen.
In welcher denn? In der styx_images? Soweit ich gesehen habe, stehen dort von den Thumbails keine Grössenangaben.
Als Bastler, lässt sich vieles hinbiegen.Siehe aktuell: https://styx.beatsblog.ch/1003-Hoehenmeter-sammeln.html
Doch wie es Bastler so ansich haben, kratzen sie immer nur an der Oberfläche und falls die Struktur im Hintergrund dadurch Schaden nimmt, merken sie das nicht...
Ian Styx am |
Soweit du nur von Thumbs sprachst hast du natürlich recht!
Ich habe das nur allgemein als Warnung ausgesprochen. Sieht jetzt schon viel besser aus! ?
Ian Styx am |
Kann man denn in (on cl ick weder zusammen führen)
<a class="serendipity_image_link" rel="lightbox[1003]" href="/uploads/2008/20080713_01.jpg" on cl ick="F1 = window.open('/uploads/2008/20080713_01.jpg','Zoom','height=715,width=948,top=34,left=45.5,toolbar=no,menubar=no,location=no,resize=1,resizable=1,scrollbars=yes'); return false;"><img src="/uploads/2008/20080713_01.serendipityThumb.jpg" style="border-bottom:0px; border-left:0px; border-right:0px; border-top:0px; float:right; padding-left:5px; padding-right:5px; width:400px" /></a>nicht gleich das ganze
on cl ick="F1 = window.open('/uploads/2008/20080713_01.jpg','Zoom','height=715,width=948,top=34,left=45.5,toolbar=no,menubar=no,location=no,resize=1,resizable=1,scrollbars=yes'); return false;"Geraffel entfernen und bei image das
style="border-bottom:0px; border-left:0px; border-right:0px; border-top:0px; float:right; padding-left:5px; padding-right:5px; width:400px"auf ein
style="width:400px"reduzieren, bei gleichzeitiger Einfügung von serendipity_image_right in die class="" und analog bei den left floateten Bildern ??
Ian Styx am |
Nur zur Info. Da ja dieser "bug" als Bedingung eine Folge der Nutzung [1] vom Scriptlet, [2] des CKEditors im frontend commentform und [3] der Android Gboard App ist, ist/war meine Sorge gegenüber dem default und anderen themes haltlos, denn ihnen fehlt die Bedingung [2] der genannten. Der Kommentarform (CKE) ist nur "pure" und neu dann auch "The Dude" und ihren Abkömmlingen erlaubt. Und somit ist alles bester Ordnung. ?
Beat Post author am |
Ja, das ist es. In pure funktioniert es seit den letzten Template-Anpassungen ohne Probleme. ? Danke für die rasche Korrektur.
Beat Post author am |
Ich weine dem entrypaging-Plugin immer noch hinterher ?. Im Live-Bolg habe ich es ja vor einem Monat gelöscht und nun schon oft vermisst. Auf dem Testblog (www.styx.beatsblog.ch) ist es noch installiert. Nach jedem Styx- oder Plugin-Update habe ich wieder Geschwindigkeitsmessungen durchgeführt. Doch es bleibt dabei. Der Aufbau einer Single-Entry-Seite dauert (auf dem Manitu-Server) mit dem entrypaging-Plugin über eine Sekunde länger als ohne.
Leider kann ich nicht beurteilen, wie oft überhaupt eine Single-Entry-Ansicht aufgerufen wird. Da ich grundsätzlich keine Erweiterten Beiträge schreibe, dürfte dies wohl relativ selten vorkommen (ein Besucher braucht diese Ansicht ja nur, wenn er kommentieren will).
Hmmm... ich bin hin und her gerissen.... Kannst Du nicht noch ein Wunder aus dem Hut zaubern? ?
Ian Styx am |
Gerne! ? .. wenn ich könnte... und dazu müste ich das Problem aber nachstellen können...
History und Archive verweisen auch auf Einzelansichten, sonst würde die zusätzliche Sekunde ja auch nicht so viel ausmachen, da deine Einträge ja relativ selten kommentiert werden.
Hast du für dein Theme eigentlich theme preview Ansichten in der richtigen Größe? Ich könnte da sonst aushelfen.
Beat Post author am |
Hatte ich mal auf der ToDo-Liste, doch da blieb es auch... War mir irgendwie nie genug wichtig. Ich bin ja der Einzige, der pure-beat benutzt. Es hat doch keinerlei Nachteile, wenn es diese Vorschaubilder nicht gibt, oder?
Ian Styx am |
Ich habe welche..! ?
Keine Nachteile, außer des großen Loches unter themes.
Ian Styx am |
Kannst du mal auf styx.beatsblog das s9ymarkup Plugin deaktivieren (in hidden section schieben und abspeichern). Und dann mal an umterschiedlichen Stellen des Blogs nachmessen, ob sich das mit dem +1 sec entrypaging delay verringert, oder gar verschwindet, oder gleichbleibt?! Oder hatten wir das schon mal untersucht?
Beat Post author am |
Nein, haben wir noch nicht versucht.
Ein erster Schnelltest hat keine wirkliche Veränderung gezeigt.
https://styx.beatsblog.ch/2630-relax-and-enjoy-life.html
Ian Styx am |
Schade!
Ich hatte mir gestern nochmal die entrypaging Zusammenstellung angesehen und konnte einfach nur feststellen, dass das nicht besser geht und schon so weit minifziert ist, dass es nicht diesen delay auslösen kann. Es muss also das Zusammenwirken mit irgendeinem anderen Plugin oder Einstellung sein.