Kommentare von

beats TEST blog

Weblog Kommentare

Styx-Stand: 01.05.2020, 10:58

Ian Styx am |

Zur Erklärung. Vorher hat das Plugin id="mediasidebar" für jedes der angezeigten Bildercontainer geschrieben. Das ist nicht erlaubt. Ein Knoten (ID) muss unique sein.
Ich habe also den Knoten #mediasidebar Container so verschoben, dass er nur noch einmal geschrieben wird und darin die 3 Bilder mit dem neuen container und der neuen Klasse mediasidebaritem aufbewahrt werden.

<div id="mediasidebar">
    <div class="mediasidebaritem">
        <a href="/1131-abgebrochen.html" title="abgebrochen"><img style="border: 0px; width:200px;" src="/uploads/2008/20081109_03.styxThumb.jpg" alt=""></a>
    </div>
</div>

Ich glaube du meinst:

#mediasidebar {
    margin-left: .1rem;
}

...suchen, löschen und bestätigen. ? oder?

Außerdem kannst du jetzt so schreiben

#mediasidebar .mediasidebaritem img {
    border-left: 1px solid #eaeaf4 !important;
    border-top: 1px solid #eaeaf4 !important;
    box-shadow: 3px 3px 3px #b8b8da;
    box-sizing: border-box;
    border-radius: 4px;
    margin-bottom: .5rem;
    margin-left: auto;
    margin-right: auto;
    width: auto !important;
}

 

Beat am |

Danke für die Erklärungen.

#mediasidebar {
    margin-left: .1rem;
}

habe ich entfernt.

Das mit:

#mediasidebar .mediasidebaritem img

hat leider nicht funktioniert. Wenn ich die Bildelemente untersuche, wird mir auch angezeigt, dass die Formatierung für folgende Klassen angewendet wird:

#serendipityRightSideBar img,
.serendipitySideBarContent img

Ian Styx am |

Natürlich, das war ja die Ersetzung von

#serendipityRightSideBar img,
.serendipitySideBarContent img

da dass ja von dir stammte (user.css).

Ian Styx am |

Ich habe gerade gesehen, dass ich einen dummen closing Fehler eingebaut habe. Neue Version ist online!
Ich habe zusätzlich eine Option eingebaut um die styles abzuschalten. Die styles sollte man besser in seine user.css setzen. Aus Kompatibilitätsgründen steht die Option aber per default auf yes. Man muss sie also explizit abschalten.

Beat am |

Unter Plugins > Updates wird keine neue Version des imagesidebar-Plugins angezeigt. Muss ich die neuen Daten manuell downloaden und an die richtige Stelle hochladen?

Ian Styx am |

Sehr merkwürdig. Ich bin gerade etwas ratlos was da wohl passiert ist... Habe nochmal einen version bump auf 1.18 gemacht.

Aber auch der geht nicht. Ich meine die xml Dateien sind in Ordnung.
Vielleicht ein Infekt, ein coronaler ? Wir müssen mal auf morgen hoffen.

Beat am |

Heute hat es geklappt. ?

Nachtrag: Komisch, auf www.beatsblog.ch wird mir das neue Plugin nicht angeboten. Werde es morgen nocheinmal versuchen.

Ian Styx am |

Ich bin auch wirklich erstaunt. Ich habe/hatte das Verhalten hier auch, in 2 Blogs sogar. Einer ging gestern nicht, aber heute.
Der andere - gerade entdeckt - steht auf Version 1.14. und wird nicht zum Update angezeigt. Vielleicht muss ich ZARATHUSTRA als Upgrade task mal wieder aktivieren. Es passiert manchmal, und ist damit nicht wirklich transparent "warum eigentlich" (*), dass lokale Plugin Einträge in der pluginlist Tabelle mit der ihrer upgrade_version nicht korrekt eingetragen werden, obwohl die remote Version des Plugins aus der XML Datei korrekt erfasst ist. Und so bleiben sie als Zombies unbeachtet. In dem Fall hilft nur: - manuelles Eintragen in der DB (*), - oder eben Zarathustra, - oder löschen per Spartacus und physikalisches löschen des Plugins per FTP (o.Ä.) und dann eine Neuinstallation über Spartacus.

(*) Wenn man die Datei aufruft und eventuell sogar speichert, wird ein modified date generiert, dass zum Aus-checken über Spartacus auch eine Rolle spielt. Dies Phänomen hatte ich hier lokal im Verdacht, als ich das mit dem "Warte bis Morgen" sagte.

(*) phpmyadmin sql tab

SELECT * FROM `styx_pluginlist` WHERE class_name LIKE '%imagesidebar'

 

Ian Styx am |

Manchmal (oder immer) ist v.e.r.s.t.e.h.e.n einfach nur g.e.n.a.u.e.s Hinsehen! (Und dann ein Versuch es zu beschreiben, was ich hiermit einfach mal ins Blaue hinein tue...)
Ich habe inzwischen den Verdacht dass es sich hier um einen grundsätzlichen bzw sogar 2 oder mehr Bugs handelt.

Früher wurde das Spartacus Plugin Update handling fein säuberlich getrennt, zwischen event und sidebar Plugins. Mit Serendipity (S9y) 2.1-dev kam ein  Add "update all"-button to plugin update page commit hinzu, der diese Trennung gewissermaßen aufhob. Irgendwo ist da vergessen worden (lokale) sidebar plugin Einträge explizit auch als solche wieder auszuweisen, denn die lokalen stehen, bei mir (und das ist möglicherweise speziell, denn ich arbeite als Developer naturgegebenermaßen viel mit lokalen Plugins), soweit ich sehe, alle auf event, was definitiv falsch ist.

SELECT * FROM `styx_pluginlist` WHERE class_name LIKE 'serendipity_plugin%' AND pluginlocation = 'local' AND plugintype = 'event'

Warum tritt dieses Verhalten aber nur manchmal auf?
Weil es u.a. auch viele Kombiplugins gibt, deren update eben auch mir dem falschen Eintrag funktioniert.

Noch früher in 2.0 wurden interne (unechte) Plugins zu echten (physikalischen) Plugins und dann auch noch umbenannt. Diese hatten - soweit ich mich recht erinnere - keinen Eintrag als plugintype. In der Folge wanderten ein paar davon auch noch nach remote, also additional_plugins. Leute, die nie mit Plugins im physischen Sinne (touch) zu tun haben, werden vielleicht auch nie mit diesem Problem behelligt werden. Irgendwo in diesem Zusammenhang kommt es also zu einem Fehleintrag, ob dann individuell oder generell für alle diesbezüglichen ist da noch die Frage, oder sogar mehreren Folgebugs.

Interessant nun aber ist, installiert man ein echtes und neues Sidebar Plugin (zb sidebarlogo) über Spartacus, so ändern sich sofort alle eben noch als 'event' plugintype ausgewiesen lokalen sidebar Plugins in die richtige Form 'sidebar'. Ich würde deshalb raten, dies einmal zu tun. Danach kann man das Plugin auch wieder über Spartacus löschen und sicherheitshalber auch physikalisch per FTP. Nun müsste bei nächsten run des XML files oder sogar schon jetzt das imagesidebar update erscheinen, oder es liegt noch ein weiterer Bug vor (ich vermute letzteres).

Mit dem Infekt hatte ich also gar nicht mal so unrecht! ?
Es ist etwas hakelig schon jetzt ein Updateversuch zu wagen, da ich noch mehr die Aktiionsbeziehungen zwischen Synchronisierungen, Spartacus- und Pluginlist-Aktionen und Updates hinterfragen muss.

Beat am |

Interessant nun aber ist, installiert man ein echtes und neues Sidebar Plugin (zb sidebarlogo) über Spartacus, so ändern sich sofort alle eben noch als 'event' plugintype ausgewiesen lokalen sidebar Plugins in die richtige Form 'sidebar'. Ich würde deshalb raten, dies einmal zu tun. Danach kann man das Plugin auch wieder über Spartacus löschen und sicherheitshalber auch physikalisch per FTP. Nun müsste bei nächsten run des XML files oder sogar schon jetzt das imagesidebar update erscheinen, oder es liegt noch ein weiterer Bug vor (ich vermute letzteres).

  1. Ich habe auf www.beatbsblog.ch das sidebarlogo-Plugin installiert. Danach wurde mir bei "Plugins updaten" kein Plugin vorgeschlagen (auch das imagesidebar nicht).
  2. Dann löschte ich das sidebarlogo-Plugin wieder (via S9Y). Auch dann kein Update-Vorschlag.
  3. Dann löschte ich per FTP das Verzeichnis "serendipity_plugin_sidebarlogo". Noch immer kein Update-Vorschlag.

Ich stütze also Deine Vermutung, dass noch ein anderer Bug vorliegt.

Ian Styx am |

Tja, das war leider zu erwarten... Noch dümmer ist, das nach der "Plugins updaten" Synchronisierung mit dem aktuellen XML File wieder 'event' eingetragen wird, wie ich inzwischen herausgefunden habe und was jedenfalls die Geographie des Bugs sehr viel näher bestimmt.

Wenn du nicht warten kannst musst du imagesidebar in Spartacus löschen und dann ebenfalls den physischen Ordner und dann einfach neu über Spartacus installieren. Dann sollte es gehen.

Beat am |

Öm, Nein. Im Vordergrund (Frontend) funktioniert es auch auf www.beatsblog.ch wie es soll und das ist für mich wichtig. Im Hintergrund mag es vielleicht noch nicht so gut sein, wie die aktuelle Version. Ich kann locker zuwarten, bis Du alles aussortiert und geradegebogen hast. ?

Beat am |

Heute hat der Update von serendipity_plugin_imagesidebar auf V1.19 sowohl hier, wie auch auf www.beatsblog.ch, einwandfrei funktioniert. ?

Ian Styx am |

Strange strange und das bei den Fehlern. ... Selbst die verhalten sich nicht konsequent logisch! ?

Bis du sicher? Denn die imageshaben immer noch "border: 0px; width:200px;" als inline style. Das müsste bei der no styles option eigentlich weg sein.

Ian Styx am |

Gerade noch eins gefunden; die 1.20 ist unterwegs. ?

Beat am |

Bis du sicher? Denn die imageshaben immer noch "border: 0px; width:200px;" als inline style. Das müsste bei der no styles option eigentlich weg sein.

Habe gerade kontrolliert. Version ist 1.19, Set #mediasidebar and image inline styles steht auf Nein. Drei Zeilen weiter unten habe ich aber Image width auf 200px eingestellt.

In meiner user.css gibt es keine Einträge zu #mediasidebar. Wie oben geschrieben style ich die Bilder über:

#serendipityRightSideBar img,
.serendipitySideBarContent img

Ian Styx am |

Es dreht(e) sich um inline styles ?

<img style="border: 0px; width:200px;" src="/uploads/2011/20110721_01.styxThumb.jpg" alt="">

 

Beat am |

Habe soeben auf V1.20 upgedated. Nun sind die inline-styles weg. ?

Nur: Jetzt hängt mein 3px Bild-Schatten rechts aus dem Plugin raus und ich schaffe es einfach nicht mit margin-right das zu korrigieren. Liegt das daran, dass ich eben nicht die Klasse #mediasidebaritem anspreche? Das habe ich zwar auch probiert...

Ian Styx am | 

.mediasidebaritem img {
  width: 98%; // oder
  width: 200px; // o.so
}

Du weiißt aber, dass du mit #serendipityRightSideBar img, .serendipitySideBarContent img jedes Bild in der sidebar bestimmst, nicht wahr?! Auch zb die xml feed Bilder oder das Logo. Deshalb musstest du die rules für letzteres auch wieder zurückrufen, mit #serendipityRightSideBar .serendipity_image_center. Einfacher, simpler und klarer ist es eine CSS Anweisung nur für das eigentliche Ziel bzw Zielguppe zu schreiben.

Belässt du es aber so wie jetzt, so musst du die Prioritäten beachten, wenn du eine generelle Anweisung mit einer detailierteren überschreibst:

#serendipityRightSideBar .mediasidebaritem img,
.serendipitySideBarContent .mediasidebaritem img {
  width: 98%; // oder
  width: 200px; // o.so
}

Auch ist beides ziemlich doppelt gemoppelt, also entweder .serendipitySideBarContent img (für alle images in allen sidebars) oder #serendipityRightSideBar img nur für rechte occurences. Du siehst also, dass die schon einmal angemerkte Konzentration (#mediasidebar .mediasidebaritem img) auf dein eigentliches Ziel wesentlich besser wäre.

Ian Styx am |

Noch besser wäre aber

.mediasidebaritem img {
    width: auto;
    max-width: 98%;
}

da du ja nicht nur gleichformatige Bilder anzeigen lässt.

Beat am |

Tja, machmal brauche ich etwas länger, bis ich es verstehe... ?

Habe nun das "rightsidebar img"-Zeug aus der user.css geschmissen und .mediasidebaritem img verwendet. Und siehe da... es funktioniert, wie gewünscht. ?

Danke für die Geduld! ?

Ian Styx am |

Jetzt musst du nur noch das " !important" in "border: 1px solid #b8b8da !important;" entfernen.?

Beat am |

Gemacht! Danke! ?

Ian Styx am |

und #serendipityRightSideBar .serendipity_image_center {....} in

.serendipity_plugin_html_nugget .serendipity_image_center {
    border: 0 none;
    box-shadow: none;
}

ändern.