Weblog Kommentare
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:
- Ich löschte das isp-Plugin im Backend/Plugins
- Unter Wartung/Plugin-Altlastenmanager wird mir "nothing to do" angezeigt
- Auf dem Server ist unter /plugins/ das entsprechende Verzeichnis mit allen Daten noch vorhanden.
- 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
- das Plugin neu (aktuell) ist und NEU nicht gleich ALT ist
- 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
- externe, also additional oder überhaupt lokale Plugins sind und
- 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.
Ian Styx am |
Deshalb steht da auch: "Suche nach Plugin Zombies" - also nach Untoten. ?
Ian Styx 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).
Inzwischen hab ich dich doch erhört. Schon gemerkt? 😉
Beat Post author am |
Ganz ehrlich? Wenn Du es nicht gesagt hättest, hätte ich es wohl nicht bemerkt. 🙄
Habe vorhin im Live-Blog noch einen Beitrag von gestern nachgereicht und dabei auf die Upload-Meldungen geachtet. Stimmt. Die gelben "try to..."-Meldungen sind weg. Gut so! Gefällt! 👍
Ian Styx am |
Und ich hätte es nicht weiter erwähnt, ... wenn nicht heute
Vor genau X Jahren
10.11.20 Styx-Stand V3.2-DE [...]
aufgetaucht wäre. 😊
Ich meine mich zu erinnern ich hätte sie auf nur eine (davon) reduziert (im Bulkmodus)...
Trackback
Ian Styx am |
Was ist mit meinen Fragen? (siehe https://www.blog.dokumenzi.ch/2652-Anmerkungen-zu-V3.1.0.html#c7554 )
Abgesehen von den Fragen sind es mehrere Probleme. Vorab, ich meine es hat nichts mit deinen eventuell vermurksten Manitu Dateisystems-Berechtiguingen zu tun... ?
Wir haben hier den IP Validierungsfilter vorliegen. Er vergleicht hier Äpfel mit Birnen, das heißt eine IPv4 mit einer IPv6, meine ich. Und die sind natürlich nicht gleich! Also arbeitet er ja eigentlich richtig.
Zum Zweiten kommt hinzu, dass die "IPv6" irgendwie verkürzt wurde. Das muss aber auch irgendwie erkannt werden!
Drittens ist das preg_match() bisher nur auf IPv4 Adressenvergleiche eingerichtet. In deiner "IPv6" kommt aber zB im ersten der 6 Bereiche ein a vor, siehe "200a:" das aber ausgefiltert wird. Außerdem benutzen IPv6 Adressen Doppelpunkte, die ebenfalls verschwinden.
Viertens die Sache mit dem http ohne s (aber da ist vielleicht nur deine Pfad URL zum Blog Einstellung noch nicht korrekt gesetzt auf dem LIVE Blog).
Die Frage ist also, warum gethostbyname($parts['host']) eine IPv4 und $_SERVER['REMOTE_ADDR'] eine (verkürzte) IPv6 zurückgeben, obwohl beide Anfragen/Angaben vom selben Server stammen..?
Wenn das alleine nicht schon irgendwie sehr merkwürdig genug ist, kommt eben noch hinzu, warum du als eingeloggter User nicht schon am Anfang der Validierungen von ihnen befreit wirst! Irgend etwas ist also definitiv falsch und zusätzlich gibt es womöglich weiteren Programmierungsbedarf wegen des IPv6 Vergleiches, wenn wir wissen ob das normalerweise überhaupt so vorkommen kann.
(Ist der Logeintrag des entries nur eine Kopie desjenigen hier in den comments, oder ein neuer?)
Ian Styx am |
Du hast im LIVE Blog das Trackback so gesetzt:
(A propos Planung: <a href="/2762-mal-was-Anderes.html">Hier unternahm ich erste Schritte</a>)
Das deutet mithilfe des Logeintrages und des fehlenden s übrigens auf eine nicht korrekt gesetzte URL zum Blog Einstellung (bzw. in der .htaccess).
Hier hast du auch einen relativ zum document root gesetzten link verwendet (also daran alleine kann es nicht liegen):
<p>Hier nun ein <a href="/2485-Film-Festival.html">Link/Trackback auf einen früheren Beitrag</a>.</p>
Mach es doch mal mit der ganzen URL:
(A propos Planung: <a href="https://www.beatsblog.ch/2762-mal-was-Anderes.html">Hier unternahm ich erste Schritte</a>)
so wie es eigentlich gewünscht ist.
Dabei fällt mir auf, dass die Trackback-URL für diesen Eintrag mitsamt ihrem Hilfe und Erklärungs-tooltip-Text verschwunden ist. Es kann sein, dass ich das in "pure" ausversehen weg-optimiert habe und es erst wieder auftaucht, wenn bereits ein Track/Pingback gesetzt ist. Das muss ich mal in Ruhe untersuchen und korrigieren.
[ ich setzte meine Kommentare gerade um!!!! ]
Beat Post author am |
Zu Deinen Fragen:
Was ist mit Trackbacks nur im Zeitfenster erlauben?
Steht auf "Nein"
Hast du das mit dem http ohne s überprüft? Während du den Link reinschreibst?
Ich verlinke intern nur realtiv. Also z.B.: /2762-mal-was-Anderes.html
Hast du irgendwo eine privacy IP Verkürzung eingestellt (zb DSGVO) ?
Ich wüsste nicht wo. Anonymisiere IPs? steht auf "Nein"
Ist spamblock vor diesen Plugins in der Liste?
Ja, spamblock an Pos. 2, DSGVO an Pos. 16.
(Ist der Logeintrag des entries nur eine Kopie desjenigen hier in den comments, oder ein neuer?)
Derjenige im Blogeintrag ist ganz neu. Siehe Timestamp: [2020-09-27 12:00:20]
Beat Post author am |
Habe in der Vergangenheit schlechte Erfahrungen mit absoluten URL's gemacht. Seit Bestehen dieses Blogs wurde die URL schon mindestens 3x verändert. Das führte dazu, dass ich danach quasi händisch alle alten Links umschreiben musste. Deshalb verwende ich seit Dezember 2017 (https://www.beatsblog.ch/2285-nur-fuer-mich...-relativ.html) nur noch realtive Verlinkungen. Das will ich auch nicht ändern.
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.