Kommentare von

beats TEST blog

Weblog Kommentare

Serendipity Styx 3.2.0

Ian Styx am |

Das war gestern als ich den letzten Kommentar verschickt hatte, der in die Moderation geschickt wurde, und ich dabei zufällig die Dev-F12-Konsole offen hatte. Es war ein Fehler des ckeditor javascriptes, welches meinte, irgendetwas nicht gefunden zu haben. Als ich heute Morgen meinen Kommentar schrieb habe ich das nachzustellen versucht, aber alles war in Ordnung.

Im Nachhinein konnte ich mir das nur dadurch erklären, dass du ja gestern das Styx Update gemacht hast, welches auch eine neue Version des assets Editors mitgebracht hat, mein Browser aber noch die vorherige Version aus dem Cache verwendet hat.
Jedenfalls hoffe ich dass es das war.

Edit: Und da dieser Kommentar mit dem Abschicken auch in der Moderation landete, trat der Fehler eben auch erneut auf. Diesmal habe ich dann richtig hingeschaut und gesehen, dass es ein valider und guter Fehler ist. Aber auch nichts schlimmes, eher eine Art von Status Information.
Wenn ein Kommentar abgeschickt wurde, wird ja die Kommentarform und damit auch die textarea nicht angezeigt; aus gutem Grund übrigens. Nun will aber CKE die textarea input form, die eben nicht da ist, mit seinen Rich Text Eigenschaften ersetzen und scheitert.

Ich werde nachher mal einen JS Gegencheck überall nachtragen wo es derart verwendet wird, was mir vorerst einfacher erscheint, als aufwendig eine PHP/Smarty Variable für diesen 1-minütigen Fall zu setzen, die den Javascript Kram für diese Zeit ganz ausblendet.

Ian Styx am |

Gerade erfolgt!
Und zur Übernahme bereit ?, wenn du möchtest.
Ich glaube vorerst aber nicht, dass solch kleine Fehlerchen ein Styx Punkt-Bugfix-Update erfordern, vor allem, wenn sie so gut versteckt sind und nicht wirklich etwas kaputt machen.

Ian Styx am |

Hattest du mein Edit wegen des Fehlers im vorletzten Kommentar eigentlich mitbekommen?
(Das ist nur ein Hinweis, kein muss! ?)

Beat Post author am |

Hallo :wave:

Ja, ich habe Dein Edit gelesen. Dachte jedoch, dass dieser Mini-Fehler für mich bedeutungslos ist.

Vielleicht willst Du Deine Änderungen mal testen ?!? Habe deshalb hier nun V3.4 DEV heruntergezogen und aufgespielt. Kommentare dazu (der Übersichtlichkeit halber) bitte beim entsprechenden Beitrag anfügen. Danke.

Ian Styx am |

Ähem, ? ich sagte doch es wäre nur als Hinweis gemeint, falls ungelesen.
Völlig unnötig da gleich noch ein ganzes Dev build raufzusetzen, vor allem, wenn die eigentliche Datei, in deinem beat  theme, davon gar nicht berührt wird..., oder?!

Beat Post author am |

Gut gemeint ist halt oft das Gegenteil von gut gemacht. ?

Beat Post author am |

Görps!? Heute hat sich auf beatsblog.ch das history-plugin verschluckt. Im history_daylist.dat stand nur:

s:334:"<div class="serendipity_history_info">
    <span class="serendipity_history_date">15.03.06</span>     <a href="/151-Zuercher-Bloggertreffen.html" title="Zürcher Bloggertreffen">Zürcher Bloggertre [...]</a>
</div>
<div class="serendipity_history_outro">Keine Anzeige? Dann wurde an diesem Tag noch nie ein Beitrag geschrieben.</div>
";

Habe das File gelöscht und nun sieht die Anzeige im Live-Blog gleich aus wie hier.

PS: Styx V3.3.1 habe ich hier und auf beatsblog.ch installiert. ?

Ian Styx am |

Ich hatte es gesehen, aber gedacht, dass das mit dem Zeitverschiebungsproblem und deinen Tages-Datierungen zu tun hätte welches ja hier noch ungelöst vor sich hindämmert.

Wenn dem nicht so ist, sollte es aber wohl eher nicht mit der ewigen Schaltjahrgeschichte, sondern entweder

  • mit einer bisher unberücksichtigten Sonderform deiner Eintrags-timestamps, bzw
  • mit einer eventuell diesbezüglichen Veränderung (Differenz) auf dem Server, oder
  • einfach nur mit einem mysteriösen Schluckauf zum Zeitpunkt des Abrufes

zu tun haben. Kannst du mal die genauen Datierungen der Einträge rausfischen und dann auch nochmal den Zeitunterschied des Servers in der Backend Konfiguration (siehe auch den info Kasten) überprüfen?

Bei meiner damaligen entries testdata Installation wegen der Zeitgeschichte - die ich Gott sei Dank noch nicht gelöscht hatte - ist das heutige Ergebnis sofort:

Do, 15.03.2018 17:09 Inneres Feuer
Sa, 15.03.2014 23:59 Rikscha + eTukTuk
So, 15.03.2009 17:47 pampig
Sa, 15.03.2008 23:59 Irchel Hometrails
Do, 15.03.2007 21:34 Bewegungssucht
Mi, 15.03.2006 23:27 Biketeile - Trouvaille
Mi, 15.03.2006 17:10 Zürcher Bloggertreffen

Ich würde zu letzterem tendieren...

Beat Post author am |

Hier die Zeitstempel der Beiträge vom 15.03. auf beatsblog.ch:

Do, 15.03.2018 17:09 Inneres Feuer
Sa, 15.03.2014 22:59 Rikscha + eTukTuk
So, 15.03.2009 17:47 pampig
Sa, 15.03.2008 22:59 Irchel Hometrails
Do, 15.03.2007 21:34 Bewegungssucht
Mi, 15.03.2006 22:27 Biketeile - Trouvaille
Mi, 15.03.2006 17:10 Zürcher Bloggertreffen

Eingestellte Zeitzome ist GMT +1 (ein Testkommentar zeigte die richtige Uhrzeit).

Ich glaube wirklich, dass dies ein "undefinierbarer Rülpser" war. War ja doch sehr seltsam, dass nur ein einziger Beitrag angezeigt wurde.

Ian Styx am |

Oder, da ja der nächstfolgende Eintrag einer jener zurückgesetzten ist, eben darauf beruhen. Ohne das sehr sehr detailliert zu überprüfen kann man das jedenfalls nicht ganz auschließen. (Nur so als keep in mind für spätere Vorkommnisse.)

Beat Post author am |

Heute wurde auf www.beatsblog.ch nur ein Beitrag, aus dem Jahr 2020, angezeigt. Habe das history_daylist.dat (00:02:41) gelöscht und beim Refresch der Seite wurden dann korrekt alle Beiträge des 06.04. angezeigt.

Habe alle früheren Beiträge überprüft. Es gab nur einen (2007), der zu der Sorte "von 23:59 auf 22:59 Uhr" zurückgestellt gehört.

Das soll nur ein Festhalten sein. Zeitweise "wackelt" das Plugin halt etwas. Interessanterweise wackelt es nur auf dem Live-Blog und hier nicht.

Ian Styx am |

Tja ... mitunter etwas spocky ? ... und wir hatten ja damals schon den Verdacht das die träge Reaktionszeit da auch eine Rolle spielen könnte.

Styx-Stand V3.2-DEV (09.11.2020, 15:42)

Ian Styx am |

Konntest wohl doch nicht abwarten...?! ?
Zur Info: So eine DEV Version von mittendrin kann mitunter etwas "holprig" werden, wenn du mitten in einen flow hineingerätst, wo die Dinge sich noch nicht ganz zurechtgeruckelt haben.

Beat Post author am |

Ich packs jetzt einfach mal hier rein, obwohl es zur aktuellen Version 3.1 gehört.

Du warst ja recht fleissig und gefühlt jeden dritten Tag gab es wieder ein paar Plugins, die man updaten konnte. Ich kann's nun nicht genau sagen, doch ich denke, dass es irgendwas mit dem imageselectorplus-Plugin zu tun hat (wovon ich keinen blassen Schimmer mehr habe, weshalb ich das installiert habe und wozu ich es wirklich brauche).

Also wenn ich nun Bilder in die Mediathek hochlade, kommen zwar noch die gelben/orangen Hinweise "Try to...", doch die grünen (Erfolgs-)Hinweise kommen nun nicht mehr. Das finde ich etwas schade. Ich kriege so den Eindruck, dass "das System" versucht etwas zu machen, jedoch keine "Vollzugsmeldungen" mehr. Es scheint jedoch alles richtig zu funktionieren und die Bilder sind dann auch in der Mediathek verfügbar.

Ist Dir das so bewusst (und muss das so sein)?

Ian Styx am |

Tja tatsächlich, es ist alles da ... nur keine grünen Success messages. Das muss ich erstmal rausfinden... (grübel).. Waren die wirklich vorher schon da obwohl das isp++ dazwischenhockt?

Das Plugin imageselectorplus braucht man nur, wenn man

  • ganze Bilderorder per Zip hochladen und entpacken lassen will
  • QuickBlog verwenden will
  • eine spezielle (ältere) Art von Galerie-Kommandos (mediainsert Galerien) oder
  • jhead nutzen will, um EXIF-Daten zu erhalten.

Eigentlich alles nicht mehr nötig, da die Galerien von Styx 3 sowieso besser sind, und man schon länger mehrere Dateien zugleich hochladen kann.

Beat Post author am |

Leider finde ich den entsprechenden Kommentar nicht mehr, denn vor einiger Zeit fragte ich mal, weshalb zuerst die gelben und danach die grünen Hinweise nach dem Hochladen kommen. Aus meiner Sicht hätten die grünen gereicht (und wenn etwas schief gelaufen wäre, dann halt rote (Error-Messages).

Du hast dann geantwortet, dass dies so beabsichtigt ist (also beides: zuerst gelb, dann grün).

Leider kann ich nicht genau sagen, ab genau welchem Update die grünen Meldungen verschwunden sind.

Anderes Thema: Das imageselectorplus-Plugin werde ich demzufolge mal deaktivieren. Wenn ich keine negativen Auswirkungen feststelle, kann ich es dann ja bedenkenlos löschen.

Beat Post author am |

?

Habe hier das imageselectorplus-Plugin gelöscht. Danach ein Bild hochgeladen. Nun kommen wieder zuerst die gelben und dann die grünen Hinweise.

Es scheint (zumindest mir) so, dass "der Fehler" durch einen der letzten Updates dieses Plugins gekommen ist.

Ian Styx am |

Vielleicht habe ich auch etwas heile gemacht im isp ... und das ist nun das Resultat! ?

Ian Styx am |

Fixed. Danke!

Beat Post author am |

Gerne.

Ich habe es auch gefixt... ? Habe dieses Plugin nun hier und im Live-Blog gelöscht. Die von Dir beschriebenen Anwendungsfälle gibt es bei mir nicht und ich konnte mich auch nicht erinnern, weshalb ich das je installiert habe. Also: Weg damit! ?

Beat Post author am |

Was mich nun direkt zu der nächsten Frage bringt:

  1. Ich löschte das isp-Plugin im Backend/Plugins
  2. Unter Wartung/Plugin-Altlastenmanager wird mir "nothing to do" angezeigt
  3. Auf dem Server ist unter /plugins/ das entsprechende Verzeichnis mit allen Daten noch vorhanden.
  4. Ich lösche das Verzeichnis per FTP

Ist dies alles so gewollt?

Ich würde es begrüssen, wenn der Plugin-Altlastenmanager ein nicht mehr aktives/installiertes Plugin erkennt und es zur (physischen) Löschung vorschlägt. So könnte ich mir das manuelle Löschen via FTP ersparen und wüsste, dass alle physisch vorhandenen Verzeichnisse unter /plugins/ auch aktiv genutzte Plugins sind.

Ian Styx am |

Ich meine das liegt daran, dass

  1. das Plugin neu (aktuell) ist und NEU nicht gleich ALT ist
  2. und das es ALTlastenmanager heißt

Ich habe das gemacht, nicht um generell aufzuräumen, denn aktuelle Plugins muss man ja nicht noch einmal übers Internet holen, sondern um tatsächlich alte Plugins loszuwerden, die dort einfach nur vor sich hin gammelten und bei einer (Neu) Installation dann doch bevorzugt installiert wurden. ?

Beat Post author am |

Ah, ok. Hätte ich also bis nach dem nächsten Update des isp-Plugins gewartet, dann wäre es danach im Altlastenmanager angezeigt worden und so hätte ich es dann direkt löschen können.

Gute Sache! ?

Ian Styx am |

Ja, hoffentlich.. oder auch nicht! ? Jedenfalls bei denjenigen, die

  1. externe, also additional oder überhaupt lokale Plugins sind und
  2. deren upgrade Versionsnummer entweder leer ist bzw nicht auf die neuere Spartacus 'upgrade_version' verweist.

Es soll also nur dem Fall dienen, nicht unbenutzte Plugins im Stack zu haben, die eine neuere Version online haben und davon nichts wissen. Und das trifft meist nur auf Upgrader von älteren Blogs zu.

Alle diesbezüglichen Fixes seit dem 2.9er Zweig sollten soetwas künftig verhindern, solange es sich um Spartacus installerte Plugins handelt.