Kommentare von

beats TEST blog

Styx 4.3.2 und PHP 8.2.13

Beat Post author am |

TOP! :applaus:

Beat Post author am |

Auch die heutige Anzeige, 01.03. stimmt. Nun scheint das History-Plugin wirklich perfekt zu funktionieren. Egal ob Schaltjahr oder nicht. 👍

Styx 4.3.0 und PHP 8.2.12

Beat Post author am |

Habe nach dem Update von beatsblog.ch im neuen Backend-Feld "Remote-Systembenachrichtigungen" die erste Meldung gelöscht und daraufhin folgenden Hinweis erhalten:

Warning: Undefined array key 1 in /styx-master/include/admin/overview.inc.php: 97.
Administrative Login Error Warning only - not seen by visitors! Send us a note what happened where and when, please.

Ich teste das hier (anderer Server) auch gleich: Ja, ist hier das Gleiche. Checkbox "Abhaken" ankreuzen, dann Klick auf "Ausblenden" und dann kommt obiger Warnhinweis.

Ian Styx am |

OH Schmerz ... nur einmal .... 😓😬🤬

Aber der eine Eintrag ist weg, oder ?!

Geht der zweite denn auszublenden?

Warum hast du denn nicht beide entfernt? 🙄

Dies Ding hat mich gestern beim release schon geärgert...

Grüsse an die Frau Gemahlin !

Beat Post author am |

Mich irritiert:

Abhaken für: » Ich habe verstanden! Zeige nie wieder! «

Wenn ich nun den zweiten Eintrag lösche, wird mir "nie wieder" ein neuer Beitrag angezeigt?

O.K. den zweiten Beitrag kann ich ohne Warnhinweis löschen. Nun ist jedoch auch kein Backend-Feld "Remote-Systembenachrichtigungen" mehr sichtbar. Ich muss deshalb wirklich annehmen, dass ich nun nie wieder eine Meldung angezeigt erhalte (was vermutlich eine falsche Annahme ist).

Ian Styx am |

Wenn ich nun den zweiten Eintrag lösche, wird mir "nie wieder" ein neuer Beitrag angezeigt?

Nee. Das soll so funktionieren, dass wenn ein neue remote Benachrichtung von mir gesetzt wird, diese von dir als gelesen markiert werden kann. Wenn keine neuen (mehr) da sind soll auch nichts angezeigt werden. Erst dann wieder wenn es tatsächlich eine neue Mitteilung gibt.

Funktioniert auch wenn man beide zugleich ausblendet. Nur einzeln wird es schwierig wie du mit dem array key 1 warnung bereits gesehen hast. Ich kann das bei mir auch nachstellen. Bei mir lässt sich dann allerdings die zweite Nachricht nicht mehr ausblenden.... umso besser wenn es bei dir (und hoffentlich allen anderen klappt).

Da muss ich wohl noch mal tüfteln die nächsten Tage...

Beat Post author am |

Interessant... Auf dem Manitu-Server kann ich die zweite Nachricht auch nicht löschen. Hier (Hosttech) hat es problemlos funktioniert. 🤔

Ein paar Minuten später...

Auf beatsblog.ch habe ich die Meldung nun weggekriegt (nach mehrmaligem Löschen). Auf styx.beatsblog.ch jedoch nicht. Da kann ich x-mal Löschen, die zweite Meldung bleibt bestehen.

Ian Styx am |

sehr strange... 🙄 dieses Verhalten auf deinen Servern.

Ich glaube aber ich habe den eigentlichen Fehler gefunden. Die Nachrichten selbst werden auch nicht gelöscht, denn es sind ja remote RSS Nachrichten. Es gibt sie solange ich sie "sende" bzw vorhalte. Ihre Signatur wird aber über hashes gestored und mit diesen hashes als gelesen betrachtet, wenn du sie entsprechend markiert hast. Nach jeweils sechs Monaten wird aufgeräumt.

Vielleicht ist die Sache auch nur temporär bis es sowieso nur noch Styx 5 gibt... Ich brauchte aber eine (direktere) Mitteilungsmöglichkeit außerhalb des Styx Blogs falls ich gewisse Entscheidungen für Styx 5 zu treffen habe die für das Upgrade wichtig werden...

Beat Post author am |

Ohh 🤓 Im pure-Theme gibt es im "pager" nun auch im einen go-to-top-Button 👍. Da müsste ich mal die beiden Javascript-Dateien vergleichen, denn -wenn ich mich recht erinnere- habe ich im pure-beat-Theme nur wegen meinem go-to-top-Button eine eigene pure.js.

Wenn ich auf das eigene Design des Buttons verzichten kann, könnte ich dann ja auch die eigene pure.js löschen und müsste bei Theme-Updates nicht mehr darauf achten...

Schade nur, dass die Position des Buttons fix und auch nur schwer zu erkennen ist. Gerade auf dem Mobile übersieht man den sehr einfach, weil nach dem Pager halt noch nicht das Seitenende ist, sondern direkt danach die Seitenleisten folgen und man noch ziemlich weit nach unten scrollen kann.

Beat Post author am |

Ich brauchte aber eine (direktere) Mitteilungsmöglichkeit außerhalb des Styx Blogs falls ich gewisse Entscheidungen für Styx 5 zu treffen habe, die für das Upgrade wichtig werden...

Das verstehe ich und finde den Ansatz auch wirklich gut.

Ian Styx am |

Oh man das getickere hat mich in den Wahnsinn getrieben...

Ich habe dir was hinterlassen. 😀 bzw morgen (erst) denn jetzt muss ich dringend mal aufhören....

Ian Styx am |

ping ...

Ian Styx am |

Ich kann mir auch vorstellen dass das eventuell mit deinem Blau nicht ganz so harmoniert. Aber darauf konnte ich keine Rücksicht nehmen. Im Original Dark mode oder light mode ist es gut zu sehen (finde ich) und dennoch möglichst schlicht. Vielleicht für dich per CSS in der Farbe änderbar?

Die Frage der Platzierung war relativ leicht. Ich bekomme eine mehr oder minder lange Artikel Liste und wische oder scrolle sie herunter. Diese endet in der Seiten footer Seiten Navigation. Das auf mobiles danach noch der Seitenleisten Teil folgt (möglicherweise) ist eher nebensächlich.
Auch musste es auf der Einzelartikelansicht auch in den Artikelfooter (wenn der angezeigt wird).

Beat Post author am |

Habe geantwortet.

Ian Styx am |

ebenso... Danke!

Beat Post author am |

Interessant. Seit heute (oder gestern?) werden im Backend von beatsblog.ch wieder die zwei Meldungen der "Remote-Systembenachrichtigungen" angezeigt. Hier jedoch nicht. 🤔

Ian Styx am |

Das sollte eigentlich nicht geschehen ... außer irgendeine Aktion löscht die diesbezüglichen hash storages in der options Tabelle.

Vielleicht lag es ja daran, dass sie bei den ersten Versuchen nicht richtig gespeichert waren und jetzt irgendwie als neu aufgesetzt wurden, oder, dass die Kopie des XML unter templates_c/... durch einen Server Prozess (zb neues Dateisystem oder so)  getouched wurde und damit ein neues last modified Datum bekam. 🤔

Mach sie einfach wieder weg und beobachte dann mal ob es eventuell in ein zwei Monaten wieder auftritt.

Bist du erfolgreich mt dem Butler?

Beat Post author am |

😀 Hier sind im Backend nun die zwei Meldungen auch wieder aufgetaucht.

Ian Styx am |

Ist mir momentan einfach schleierhaft...  Ich kann nur hoffen, dass das eine Regression der ersten Versuche ist.

Bei mir ist soetwas noch nicht aufgetreten bislang... und die 6 Monate sind auch noch nicht um...🤨

Beat Post author am |

Ist ja kein wirkliches Problem. Lösche die Meldungen und werde hier wieder berichten, falls sie erneut auftauchen. 👋

Beat Post author am |

Heute, also 50 Tage später, erhalte ich auf beatsblog.ch wieder diese zwei "Remote-Systembenachrichtigungen" angezeigt.🤔

PS: Das History-Plugin macht sich am heutigen Schalttag sehr gut 👍. Mal schauen, ob es morgen 01.03. auch richtig anzeigt.

Ian Styx am |

Und ich kann dir zustimmen, denn ich habe es selbst gesehen auf einem anderen Blog - gerade vor ein paar Tagen erst, auch so um den Dreh von anderthalb bis zwei Monaten, bei mir lokal aber noch nie und auch nicht auf anderen remote Blogs und ich kann mit dieser Zeitspanne im Code auch nicht wirklich etwas anfangen.... Ich habe in Styx 4.4.0 einen Versuchsfix drinnen... wir werden es bemerken. Wahrscheinlich aber werde ich diese zwei Einträge sowieso bald löschen, denn sie sind ja inzwischen auch überholt. 😏

4294967295 Kommentare

Ian Styx am |

Ich auch nicht! 😲Nun bin ich wieder munter.

Erstmal über diese Zahl: https://de.numberworld.info/4294967295

Sie ist bedeutsam, denn sie bezeichnet das 32-Bit-Integer-Limit bei Computern. Laut Wikipedia:

4 294 967 295 (oder hexadezimal FFFF,FFFF16) ist der größte positive Wert, welcher in einem vorzeichenlosen 32-Bit Integer gespeichert werden kann, und hat dadurch eine besondere Bedeutung in Programmiersprachen und Rechnerarchitekturen, wenn negative Ganzzahlen nicht vorkommen können. So beispielsweise bei Speicheradressen und Indizes.

Computer mit einer 32-Bit-Architektur haben einen 32-Bit breiten Adressbus und (meist) auch 32-Bit breite CPU-Register und können daher maximal 232 Bytes adressieren. Dies entspricht 4 GiB (4 Gibibyte, meist fälschlich als 4 Gigabyte angegeben).

So kann sie als Fehlermeldung verschiedenster Art daherkommen zB., wenn die primary data Zahl bei MySQL Tabellen ihr Limit erreicht hat. Oder auch wenn Festplattenindizes überlaufen bzw an ihr Limit kommen, in Shell Zusammenhängen, usw.

Wie solches überhaupt geschehen kann - und das gerade hier - ist mir ein Rätsel...

-1 in two's complement signed number format (assuming 4 bytes long integers) is 0xffffffff which is the maximum unsigned value that can be stored in the 4 bytes. Two's complement format is used by almost all computers used nowadays (including your PC, Mac and any mobile phone)

Your shell is displaying the program return value as unsigned integer. The decimal representation of the 0xffffffff hex number is 4294967295

Laut dem hier haben wir es also mit einer return Rückgabe als unsigned integer zu tun. Warum gerade hier in einem 14 Jahre alten Blogeintrag... und nicht auch woanders ist mir schleierhaft. Gar ob plötzlich oder schon lange so...?

Am besten gibst du die Angelegenheit auch mal an den Support weiter ... aber schon komisch, denn laut den verschiedenen URLs hast du ja dasselbe auf Manitu und auf deine CH Servern, beides unterschiedliche Systeme mit unterschiedlichen Gegebenheiten. Sie beruhen aber beide auf dem selben Urzustand der Mysql Tabellen, nicht wahr?

Wie bist du darauf gekommen? Bzw hast das gefunden? Reiner Zufall?

Hast du schon weitergeforscht ob das auch in anderen alten Beiträgen auftaucht?

Hast du noch alte Tabellenbackups in denen du überprüfen kannst wieviel Kommentare dieser Eintrag hatte, oder ob da eventuell -1 drinnen steht, oder ob die Struktur der primary ID eine andere ist als andere serendipity comments Tabellen? (Reine Schüsse ins Blaue, meinerseits.)

Soweit erstmal....