Freitag, 5. März 2021
Styx Version 3.4-DEV (05.03.2021, 10:16)
aktueller Entwicklungsstand
Trackback-URL für diesen Eintrag
Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2657-Styx-Version-3.4-DEV-05.03.2021,-1016.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Beat Post author am :
PHP8?
Ich habe gesehen, dass Du die Styx-Edition schon weitgehend für PHP8 vorbereitet hast. Manitu bietet die neuste PHP-Version bereits an. Ich könnte also meinen Live-Blog auf PHP8 umstellen.
Hier, bei Hosttech, ist PHP8 noch nicht verfügbar.
Soll ich noch warten, bis PHP8 bei Hosttech verfügbar wird, damit ich das zuerst hier, auf der Testumgebung, umstellen kann? Oder kann ich unabhängig davon, www.beatsblog.ch bereits auf PHP8 anheben?
?? - Frohe Ostern!
Ian Styx am :
Frohe Ostern auch! ?☘
Der Frühling hat sich leider verkrochen..
Styx und PHP 8 ist ready to use. Und überall, meine ich.
Höchstens in ein paar alten Plugins schlummern eventuell noch ein paar Fallen, aber die benutzt du meines Wissens nicht. Und wenn, könnten wir sie vermutlich schnell erledigen.
Wie steht es denn mit deinen Rückkehrplänen? Hat hosttech inzwischen die verkündete Migration vollzogen?
Beat Post author am :
Auf Eis gelegt. Zu faul um das wirklich anzupacken.
Habe beide Hostings um ein Jahr verlängert (und "das Problem" so vor mir hergeschoben).
Proaktive Infos von Seiten Provider sind links wie rechts inexistent. Dass Manitu bereits PHP8 anbietet, habe ich auch nur zufällig bemerkt.
Zum Glück kostet Webhosting heutzutage nur mehr kleines Geld. So kann ich mir hier den Luxus leisten, zwei überdimensionierte Hostings zu bezahlen ?.
Na dann! Schau' mer mal!
www.beatsblog.ch = Betrieben mit Serendipity Styx 3.3.1 und PHP 8.0.1
Beat Post author am :
Wenn ich in einem Fenster ins Backend eingeloggt bin und in einem anderen Fenster den Blog aufrufe, erscheint oben folgender Warnhinweis:
Warning: Undefined array key "id" in /home/sites/site100015826/web/styx-master/plugins/serendipity_event_social/serendipity_event_social.php: 178.
Administrative Login Error Warning only - not seen by visitors! Send us a note what happened where and when, please.
Beat Post author am :
Wenn ich das sharebuttons-Plugin deaktiviere, verschwindet diese Fehlermeldung.
Es scheint jedoch so, dass irgendwo noch ein anderer Fehler schlummert.
Während ich im Backend eingeloggt bin, kann in einem anderen Fenster im Frontend kein Menü aufgerufen werden, welches eine Kategorie auflistet, wie z.B. /categories/BLOG oder /categories/Link. Die Menülinks auf statische Seiten funktionieren. Nur die auf categories nicht. (Content-Encoding-Fehler)
Sobald ich ausgeloggt bin, verschwinden alle diese Fehler wieder.
Beat Post author am :
Der für mich einzige, sichtbare Fehler der bleibt, ist, dass der Link "Suche" eine leere Seite zurückgibt.
PS: Ich lass das mal so stehen. Habe heute Nachmittag noch anderes vor und werde abends nochmal reinschauen.
Ian Styx am :
Ah, eben erst gesehen, dass du noch etwas geschrieben hattest.
Ja das ist wohl so wie bei mir... Das könnte vielleicht mit dem social zusammenhängen oder eben noch auf einen weiter Initialisierungfehler hindeuten.
Ansonsten kippe mal den Quelltext Inhalt der Statischen Suche Seite (aus der backend form) mal hier in einen code snippet container. Vielleicht kann ich daraus etwas schließen. Oder ist das hier genau gleich? Dann könnte ich auch hier selbst nachschauen.
Ian Styx am :
Was steht auf der genannten Seite in dem placeholder part in
anstelle meiner hier eingefügten Fragezeichen?
Ian Styx am :
Wenn das so ist wie hier, hast du das gesuchte input Feld wahrscheinlich in deiner index.tpl oder entries tpl Datei stehen. Im Placeholder steht wahrscheinlich eine Smarty {CONST.XXXX} Variable, die in deinem Theme aber nicht definiert ist. Am einfachsten schreibst du dort einfach placeholder="such mich" oder so rein.
Schon PHP 7.4 war mit undefinierten Variablen/Konstanten nicht mehr einverstanden, konnte aber mit einem angehängten |default:"" von ausgeworfenen Fehlermeldungen abgehalten werden. PHP 8 ist da nochmals strikter geworden und verbittet sich auch letzteren workaround.
Beat Post author am :
In meinem Theme gibt es eine plugin_staticpage.tpl Datei. Darin steht u.A.:
Habe nun "{$CONST.TWOK11_PLACE_SEARCH}" ersetzt durch "Blogsuche". Nun funktioniert die Suche-Seite wieder. Vielen Dank!
Ian Styx am :
Natürlich die staticpage template Datei, recht so! War wohl ein weng abwesend...
Falls du noch mehr solche Erscheinungen hast bzw verwendest, inbesondere wenn sie auf 2k11 oder ein anderes Theme in Namen verweisen kann man die auch noch mal untersuchen.
Ian Styx am :
Dem social habe ich schon eben ein Update verpasst.
Einmal Spartacus neu abspeichern und dann neu nach Plugin Updates suchen.
Zum anderen Problem kann ich das nur etwas anders nachvollziehen. Bei mir gehen alle Navigationslinks bis auf die Suche. Dort gibt es nur eine weiße Seite mit unvollständigem Quelltext.
Wenn du eingeloggt an einer dieser Stellen in den Seitenquelltext hineingehst und mit F3 nach "error" suchst, siehst du womöglich wo der versteckte Fehler liegt. Wahrscheinlich ist es ebenso eine unitialisierte Variable.
Beat Post author am :
Habe sharebuttons aktualisiert. Der Fehler hat sich nun um ein paar Zeilen verschoben:
Ian Styx am :
Update ist online.
Woll'n mal sehen wer am Ende den längeren Atem hat...?
Beat Post author am :
Jetzt sieht es gut aus. Ich kriege zumindest kein WARNING mehr. Deshalb habe ich sharebuttons nun wieder aktiviert.
Ian Styx am :
Wegen Warnings musst du nix deaktivieren. Sie zeigen nur das man etwas verbessern kann und das Warning über die Ursache wird auch nur dir als Administrator angezeigt. Kein anderer bekommt es zu Gesicht.
Beat Post author am :
Noch ein Fehler in einem Plugin:
und
Ian Styx am :
Ist gefixt! ?
Beat Post author am :
Jep! Danke!
PS: Das entrypaging-Plugin scheint mit PHP8 auch nicht ganz klar zu kommen.
Vom Beitrag "Osterschmaus" kann man nur zum vorherigen Beitrag "Wettergeschichten" und nicht zum aktuelleren Beitrag "Heimwerken" blättern.
Muss los! Schönen Abend!
Ian Styx am :
Ebenso!
Komisch das mit dem entrypaging. Dazu fällt mir gerade so gar nichts ein und es gibt ja auch keinen Error oder ein Warning, oder? Mal sehen ob dies merkwürdige Verhalten morgen einfach weg ist.
Ian Styx am :
Bei mir ist es nun weg.
Kann es sein dass da irgendeine Verzögerung läuft, die zB mit der Zeitumstellung zu tun hat? ?
Beat Post author am :
Ja, bei mir ist es auch weg.
Habe gestern (erst) die Systemzeit auf Sommerzeit angepasst. Wer weiss, vielleicht hatte es wirklich etwas damit zu tun.
Thema erledigt.
Ian Styx am :
Ich habe da auch noch etwas ... Mir wird immer das eigentlich versteckte Biene Captcha Abfrage Feld angezeigt auf dem LIVE Blog und zwar nur mit Mozilla, und nicht mit Chromium. Ich kann mich nur nicht erinnern ob das vorher auch schon so war. Und mir fällt nichts wirlich fehlerhaftes diesbezüglich auf.
Beat Post author am :
Bei mir flackert das nur kurz auf (unter 1sec.). Wenn man nicht schon direkt das Kommentarformular im Blickfeld hat (was meist nicht der Fall ist) nimmt man das nicht wahr (hier genau gleich, ob mit Firefox oder Chrome).
Ian Styx am :
Das wäre ja gut, denn dann läge es nur an meinem Firefox.
Du warst aber nicht eingeloggt bei der Überprüfung, nicht wahr?!
Beat Post author am :
? Nein, ich war nicht eingeloggt. Denn (siehe unten) derzeit kann ich nicht eingeloggt sein und in einem anderen Fenster auf dem Blog rumsurfen. ?
Ian Styx am :
stimmt ?
Beat Post author am :
Soweit so gut.
Ich habe aber immer noch das ärgerliche Problem, dass ich seit PHP8 nicht mehr in einem Fenster eingeloggt sein kann und in einem zweiten Fenster gleichzeitig meinen Blog darstellen kann. Sobald ich im Frontend auf einen Menüpunkt klicke, erhalte ich eine blanke Seite.
Das ist so bei Firefox und bei Google Chrome.
Meist schreibe ich einen Beitrag und veröffentliche diesen. Dann lese ich ihn in einem zweiten Fenster und korrigiere im Backend (im anderen Fenster) die Schreibfehler im Beitrag.
Aktuell muss ich z.B. mit Firefox das Backend bedienen und mit Chrome das Frontend. Beides im selben Browser funktioniert einfach nicht (zumindest bei mir).
Ian Styx am :
Dann geh mal auf dieser weißen Seite in den Browser Quelltext. Vielleicht gibt das Aufschluß und es ist so ähnlich wie bei dem Search Feld.
Wenn der auch komplett weiß ist, ist das ein "white Page of death" und der Fehler wurde im Server error Log geloggt. Hättest du darauf Zugriff?
Beat Post author am :
Ich kann mir gar keinen Quelltext anzeigen lassen. In Firefox erhalte ich folgende Mitteilung:
In Chrome ist die Seite dann völlig leer.
Im web.err.log auf dem Server wird nichts aufgezeichnet. So blöd es klingt, es sieht eher wie ein Browser-interner Fehler aus, denn mit einem zweiten Browser kann ich problemlos auf die Seite zugreifen und alle Menüs durchklicken, während ich mit dem ersten Browser im Backend eingeloggt bin.
Ian Styx am :
Das ist vielleicht gar nicht mal so blöd. Einen PHP oder compile Fehler kann man also schon mal auschließen.
Deaktiviere in der globalen Konfiguration mal die gzip Komprimierung. Ich meine die hattest du angestellt und ich meine ebenfalls schon mal erzählt zu haben dass das ganz merkwürdige Fehler verursachen kann, die ich häufiger gehabt habe und das deshalb immer auf AUS habe.
Versuch macht klug! ☺
Beat Post author am :
Guter Tipp! ?
Ohne GZIP-Komprimierung geht es wieder mit zwei Fenstern im selben Browser.
Folgende Warnung wird angezeigt:
Ian Styx am :
Aha! Super!
Zum Beispiel ruft man ja sein Blog per category normalerweise so auf:
domain.org/blog/categories/12-feature
Das ergäbe über das routing:
$matches[0] wäre dann categories/12-feature
$matches[1] wäre dann 12
aber dieser key 1 fehlt ja bei dir .. da du die permalink ID bei categories %id entfernt hast!
Geh nun mal in include/functions_routing.inc.php in Zeile 306
und ändere die Zeile:
mal in
Vielleicht hilft das.
Edit: Dateiname korrigiert
Beat Post author am :
Immer diese eigenwilligen User! ?
Falls Du mich testen wolltest... ich änderte functions_routing.inc.php und nicht functions_permalinks.inc.php
Ta,ta,ta ? Da ist kein Warnhinweis mehr! ? Super!
Muss ich das jetzt als Beat-Änderung bei Updates im Auge behalten oder kannst Du das in einer nächsten Version abfangen?
Ian Styx am :
Hatte ich auch gerade gesehen und schon editiert. Ansonsten hast du den Test bestanden!! ?
Ja ich werde das übernehmen. Ich musste nur mal hören ob es auch wirkt!
Beat Post author am :
Ups... Bei der Einzelbeitragsansicht werden folgende zwei Warnungen angezeigt:
Ian Styx am :
Fixes für routing und social sind online!
Beat Post author am :
Du bist ja von der ganz schnellen Truppe! ? ?
Sharebuttons konnte ich updaten und ich kann bestätigen, dass die Warnhinweise weg sind. ?
Für das Routing warte ich wohl auf das nächste Update.
Ian Styx am :
Watt wech ist, ist wech!! ?
Beat Post author am :
War eine tolle Test-Session! Danke und einen schönen Abend.
Ian Styx am :
Cheerio!
Besonders ist das ich (so schnell) auf das GZIP als Grund gekommen bin...?
Ian Styx am :
Nur so noch als Anmerkung. GZIP ist nicht etwa buggy oder so, es ist halt nur empfindlich, bzw in seinen Browser-Aussagen wenig aussagekräftig, denn wenn ein durch das gzip versteckter Bug des Systems auftritt, der das System zum Stillstand bringt, und der dann auch noch vor dem verschickten Seiten encoding (so wie geschehen) geworfen wird, gibt es halt solche Fehlermeldungen und Folgen. Wenn man dann nicht sofort drauf kommt, ist der Aufwand für das Herausfinden meist viel größer als der Nutzen den die gzip Einstellung im Übrigen bringen mag.
Beat Post author am :
Habe gzip deaktiviert und kann damit leben, dass Google und Andere meinen Blog als langsam einstufen. Einerseits ist es fraglich was gzip gebracht hat und andererseits ist mein Blog ja ein privater Spielplatz. Da verliere ich keine Kunden, wenn die Seite etwas langsamer aufbaut ?.
So wie es aber war (mit blanken Seiten in einem zweiten Fenster) ist es für mich einfach nicht brauchbar. Und ich denke auch, dass es sehr schwierig ist, den auslösenden Fehler zu finden.
Ian Styx am :
Gzip war nicht der Fehler, sondern hat nur verhindet, dass man den eigentlichen Verursacher zu Gesicht bekommt, weil es die zu schickenden Daten in einem gezippten Format verpackt. Es bedeutet Extra Arbeit auf Server und Empfänger - ist aber auf dem Weg etwas schneller, da kleiner. Eingegossene Fehler aus Prä-Prozessen sind nicht unmittelbar sichtbar. Das habe ich immer vor Augen, wenn ich über Sinn oder Unsinn nachdenke. Den Rest muss man selbst entscheiden.
Beat Post author am :
Info: Mir ist soeben aufgefallen, dass das imagesidebar-Plugin auf www.beatsblog.ch nun (auch) nicht mehr bei jedem Refresh die Bilder wechselt. Früher konnte ich unter "Rotate image time" einstellen was ich wollte, das blieb auf der Manitu-Installation, ohne Wirkung. Nun greift diese Einstellung und die Bilder wechseln erst nach 2 Minuten.
Ich habe keine Ahnung, ob dies etwas mit dem Wechsel auf PHP8.0.1 zu tun hat. Ich weiss nur, dass ich nichts an den Einstellungen geändert habe.
Ich weiss auch nicht, ob ich das nun gut finde oder nicht. Wenn ich mich recht erinnere hast Du diese Einstellung vorgeschlagen um die Ladezeit bei der Einzelbeitragsdarstellung zu verringern.
Ian Styx am :
Stimmt. Ich kann mich erinnern es gestern auch schon mal kurz meinte gesehen zu haben, nur hatte ich nicht direkt diesen Schluss gezogen weil ich mit anderem beschäftigt war.
Ich kann mir eigentlich nicht vorstellen, dass das direkt mit PHP 8 zusammenhängt, außer es wäre ein Bug oder ein Fehler im Plugin (oder anderswo) der verhindert das die 0 Einstellung interpretiert wird.
Du hattest aber die Sommerzeit umgestellt, sagtest du. Das ist eine Einstellung. Wenn du in der Konfiguration für Zeitunterschied des Servers bist und auf die Info drückst kannst du an der gezeigten Uhrzeit sehen ob deine Einstellung stimmt.
An die besagten 2 Minuten kann ich mich nicht recht erinnnern... empfohlen habe ich dir aber eine gwisse Zeitspanne ganz bestimmt. Hast du die imagesidebar rotate time mit 0 nochmal explizit abgespeichert? Dann dürfte dieser delay nicht vorkommen!
Beat Post author am :
Oh. Ich scheine mich unklar ausgedrückt zu haben.
Vielleicht ändere ich das später wieder auf 0. Hab's kurz getestet. Das Plugin funktioniert absolut richtig. Wenn ich auf 0 stelle, wechseln die Bilder. Doch (s.o.) ich lass es jetzt mal auf 2.
Ian Styx am :
Ah oh uh ... dann ist ja gut ?
Beat Post author am :
Kannst Du -bei Gelegenheit-mal ein Blick in das google_sitemap-Plugin werfen? Wenn ich da auf den Einstellungsbutton klicke erhalte ich eine weisse Seite (ohne Quelltext) und keine Konfigurationsoberfläche.
Ian Styx am :
Kannst du mir sagen dass das etwa je funktioniert hat? Dürfte eigentlich nicht... wenigstens nach dem einen gefundenen Fehler. Der andere ist explizit PHP 8 spezifisch.
Update ist online.
Beat Post author am :
Update eingespielt und die Konfigurationsoberfläche ist wieder sichtbar. ?
Ich kann es nicht mit Sicherheit sagen, doch ich gehe schon davon aus, dass die Konfig-Oberfläche früher erreichbar war. Die angezeigten Einstellungen scheinen doch beatsblog-spezifisch und die Sitemap wurde auch immer geschrieben.
Ich wollte die Einstellungen überprüfen, weil ich seit Februar das Problem habe, dass die Google Searchkonsole beatsblog nicht mehr verifizieren kann (obwohl die entsprechende Google-Datei im Blog-Root abgelegt ist).
Beat Post author am :
Wenn ich im Dashboard auf "Entwurfs-Einträge" klicke, erhalte ich folgende Warnungen:
Ian Styx am :
Moin Beat
Mit einem release Styx 3.3.1? Hier passiert das aber nicht, oder?! (Jedenfalls bei mir nicht!)
Also nehme ich an es ist vielleicht wohl auf dem LIVE blog.
Hast du dort oder hier jemals in den entries die Sortierung benutzt?
Vierlleicht liegt es nur daran, dass dort noch nie entsprechende keys gesetzt und dann entsprechend weiter getragen wurden.
Setze bzw speichere einmal die Sortierung und schaue dann ob es nochmal notiert wird.
(Deinen kompletten Path Teil /h...XXXX...web/ kannst du übrigens entfernen wenn du solches hier postest.)
Beat Post author am :
Morgen.
Ja, die Meldung stammt aus dem Live-Blog mit V3.3.1 und PHP8.0.1
Auf die Warnung bin ich nur durch Zufall gestossen, weil ich gestern Abend einen Beitrag begann, den ich erst heute Morgen fertigschrieb. Deshalb klickte ich im Dashboard auf "Entwurfs-Einträge". Normalerweise mache ich sowas über "Einträge bearbeiten". (und so rum gibt es keine Warnungen).
Weiss ich nicht. Wie sollte ich das tun?
Wie mache ich das konkret?
Bin jetzt ein paar Stunden weg. Um die Mittagszeit kann ich das dann gerne tun.
Ian Styx am :
In der entries Liste gibt es oben drei Buttons: Filter, Sortierung, Edit. Nimm den Sortierungsbutton (Pfeil unten/oben). Wenn sich das Sortierungsformular öffnet, eiinfach mit Grün Los abspeichern. Fertig!
Wenn dies einmal gesetzt ist sollte das auch nicht wieder angemeckert werden, sonst wäre das hier ja auch so.
Wenn du das bestätigst, kann ich trotzdem eine erstmalige Initialisierung einbauen.
Beat Post author am :
? Hat geholfen. Die Warnungen sind jetzt weg. Danke für den Tipp!
Ian Styx am :
Ist erfolgt. Danke für die Überprüfung.
Ian Styx am :
Spannend ist ja dein Baufortschritt... Und wie ich sehe bastelst du doch gerne...! ?
Dabei stieß ich auf den Brigitte History Artikel und war höchst verwundert, dass dieser das pure Layout zerschießt. Ich nehme an es liegt an diesen eigentümlichen <font><font ... Einfügungen, die da eigentlich gar nichts verloren haben und die die Beziehungen der class selectors massiv stören. Vielleicht schaust du mal in den Artikel.
Beat Post author am :
physisch ist mir basteln lieber, als virtuell. ? Offline, kann man die Probleme ansehen und/oder anfassen. Das macht es einfacher.
Das mit dem "für Brigitte" Beitrag war etwas dubios, denn im Quelltext fand ich keine <font>-Anweisungen. Egal. Ich habe ihn etwas umformatiert/umgetextet, gespeichert und nun funktioniert alles so, wie es soll. Danke für den Hinweis. ?
Ian Styx am :
Die hat dir der CKEditor wahrscheinlich einfach schon bereinigt! Denn es lag daran, dass eines dies font tags nicht geschlossen war und somit von CKE ACF weggeputzt wurde.
Beat Post author am :
Habe heute im Live-Blog die statische Seite "Stichworte" aktualisiert. Beim erneuten Abspeichern wurde mir folgende Warnung angezeigt:
Ian Styx am :
Danke! ?
Beat Post author am :
Ups! Der Update des "Statische Seiten"-Plugins hat etwas verbockt. Im Live-Blog, wie auch hier, kriege ich die Anzeige von wegen "Dieses Blog hat noch keine Datenschutzerklärung erstellt, es muss in der Plugin-Konfiguration konfiguriert werden."
Das dsgvo_gdpr Plugin war jedoch bereits im Einsatz und ist auch entsprechend konfiguriert. Da habe ich nichts verändert und finde auch keine Einstellung, wie ich diese Meldung wieder weg kriegen würde.
Im Live-Blog habe ich das dsgvo_gdpr Plugin nun deaktiviert. Die Startseite (statische Seite) wird mir dennoch nicht angezeigt, obwohl die Einstellung "Diese Seite als Startseite definieren" auf Ja steht.
Ian Styx am :
Du sagst es! Kudos! ?
Das ich das nicht gesehen hatte... echt Mist! ?
Update ist online. ?
Beat Post author am :
Alles wieder heil. ? Danke.
Ian Styx am :
??
Ian Styx am :
Guten Morgen,
Ich glaube ich sagte es schon einmal:
Die einzigen Cookies die du verwendest sind essentielle, da du nicht trackst. Insofern ist dieses ganze DSGVO cookie banner Geraffel völlig unnötig und vertreibt die Leser. Außerdem vertreibst du nichts und alles ist Privat. Insofern kann dir auch keiner etwas. Ich persönlch würde es abstellen.
Beat Post author am :
O.K. Überzeugt. Habs gelöscht. ?
Beat Post author am :
Oh. Was Neues. Beim Speichern eines Beitrags mit einem Trackback auf einen uralten Beitrag:
Es wird dann auch kein Trackback eingetragen.
Beat Post author am :
Sorry! Habe gerade bemerkt, dass ich eine falsche Trackback-Adresse eingegeben habe. Daher wohl die Warnung. Mit der richtigen URL hat es einwandfrei geklappt. Asche auf mein Haupt.
Ian Styx am :
Pfui! ?
Ian Styx am :
Erinnerst du ob es nach dem Warning noch irgendwelche trackback spezifischen Informationsausgaben gab? zb. "URI enthielt keine Daten", oder so..? Wie kamst du dann drauf dass deine Adresse falsch war? Bzw musst du ja nur "https://www.beatsblog.ch" eingegeben haben, denn schon ein einziges zusätzliches "/" wäre dann ja schon der "path" key gewesen.
Beat Post author am :
Herausgefunden habe ich es durch einen Klick auf den Link (im Frontend), der dann im Nirwana endete. Bei der Überprüfung des Quelltextes merkte ich, dass ich statt: /1712-letzter-Arbeitstag.html eben //1712-letzter-Arbeitstag.html eingegeben habe. Der berühmte Slash zuviel...?
Ian Styx am :
Hmm, dann wäre path aber immer noch gefüllt gewesen...
Ich versuche herauszufinden ob ich das extra abfangen muss mit einer Info Meldung oder ob eine solche nicht sowieso kommt, in etwa: "URI enthielt keine Daten", deshalb meine Frage.
Ian Styx am :
Sag mal, topfen die deinen dokumenzi Server gerade um?
Denn erst gab es einen Zertifikatsfehler, dann dauerte es ellenlang für einen bestimmten Eintrag und noch komischer ist, dass alle emojis durch ? ersetzt wurden. (in den Kommentaren jedenfalls)
Beat Post author am :
Du merkst auch alles. ?
Beat Post author am :
Es sieht so aus, als ob die (vor der Migration) erzeugten UTF8mb4-Emojis nicht zurückkommen. Ich sehe da immer noch die ?
Warten wir den Tag mal ab. ?
Ian Styx am :
Oder mal nachfragen. Sieht nach einem Migrations-Konzept-Fehler aus.
Beat Post author am :
Habe den Support deswegen angeschrieben.
Ian Styx am :
Ich addiere das mal hier lieber, wegen dem "Migrations Konzept" Fehler. Du solltest untersuchen, ob deine Datenbank jetzt iegendwie anders eingestellt ist, zb nicht mehr auf Kollation utf8mb4_unicode_520_ci steht. Hast du da Vergleichsmöglichkeiten? Wegen der ? Fragezeichen als replacement für die 4-Byte Zeichen. Vielleicht haben sie zur Migration einfach einen dump der Datenbank gemacht (mit unvollständigen Voreinstellungen bzgl. des vollen unicode Satzes) und es dann so auf dem neuen Server installiert. Irgendwie sowas vielleicht. Denn manche wenige emojis in älteren Kommentaren sind erhalten geblieben, die Menge die zum erweiterten Raum gehört allerdings nicht.
Beat Post author am :
Die haben mich richtig gut verstanden... ?
Ohne es genau untersucht zu haben behaupte ich jetzt einfach mal, dass nur noch die Emojis sichtbar sind, die ich via Plugin selbst erstellt habe. Alle "alten" utf8mb4-Emojis sind weg. Ich werde mal auf die Datenbank sehen. Vielleicht finde ich ja anhand Deiner Hinweise etwas raus...
Beat Post author am :
Der hosttech-Support hat zumindest einen gewissen Unterhaltungswert ?:
?? nächster Versuch...
... übrigens: Die Umstellung auf "FPM" hat die Emojis auch nicht zurückgebracht.
Ian Styx am :
Geht denn jetzt mail()?
Emojis migration kann auch nix mit FastCGI oder FPM zu tun haben. Das ist eindeutig eine falsche Konvertierung beim Umzug (wahrscheinlich nur 3-Byte statt 4-Byte.
Ian Styx am :
Nachfrage: Geht mail() denn jetzt mit der FPM Umstellung?
Beat Post author am :
? Nein. Nach wie vor keine E-Mails.
Habe soeben das mailtest.php noch einmal hochkopiert und getestet. Resultat: "Message accepted" doch weit und breit kein E-Mail. ?
Die super Helpdesk-Mitarbeiter sind der Überzeugung, dass etwas mit meinem Script nicht stimmt. Und dies obwohl ich Ihnen den Quelltext zugeschickt habe und sie das ganz einfach selbst testen könnten. Doch sie wollen anscheinend nicht.
Mir ist das (hier beim Testblog) nicht so wichtig. Ich warte, bis Ihnen andere Kunden damit auf die Füsse treten.
Ian Styx am :
Ob das allerdings die richtige Taktik ist bei essentiellen Dingen, bezweifle ich. Vielleicht tritt das bei anderen ja nicht auf, und ist vielleicht alleine auf dein Mailkonto beschränkt... PHP mail() scheint zu funktionieren, denn sonst würdest du kein accepted angezeigt bekommen. Alleine die über /usr/sbin/sendmail -t -i versendete eMail verirrt sich irgendwo im System (anzunehmenderweise).
Beat Post author am :
Ich konnte nichts Auffälliges finden. Bis ich dann in der DB-Übersicht über folgenden Hinweis gestolpert bin:
Webserver
Ich werde jetzt mal kurz auf PHP7.4.16 umstellen und checken, ob die früheren Emojis wieder auftauchen.
Beat der Dummi-Tester am :
? Nö. Mit PHP7.4.16 kommen die Emojis auch nicht zurück.
Ich poste jetzt mal unter "falschem Namen" um herauszufinden, ob die "keine E-Mail-Benachrichtigung" etwas mit PHP8 zu tun hat.
Beat Post author am :
? Auch nicht. Keine Mail-Benachrichtigung mehr. Weder mit PHP7.4.16 noch mit 8.0.3. Habe den Mailaccount selbst auch überprüft. Der funktioniert ansonsten problemlos.
Werde jetzt wieder auf PHP8.0.3 umstellen und danach Feierabend machen.
Danke für Deine Unterstützung und ein schönes Wochenende!
PS:
Weils auf www.beatsblog.ch funktioniert könnte ich in Versuchung geraten und hier die V3.4-alpha2 durch die offizielle V3.3 zu ersetzen...
Ian Styx am :
Also deine gefundenen Hinwese haben damit mehr oder minder nichts zu tun.
Interessant wäre, welche Datenbank sie jetzt benutzen und in welcher Version genau; also ob Mysql (7.x/8.x) oder MariaDB (10.3.x/10.4.x/10.5.x) und ebenso wie genau sie deine Datenbank Tabellen auf den neuen Server migriert haben; per Datei copy, per SQL dump, etc.? (Haben sie doch, oder?)
Um die fehlende Mail-Benachrichtigung kümmere ich alsbald. Ich muss erst mal ein paar Vorbereitungen treffen damit ich das lokal überhaupt debuggen kann.
Ian Styx am :
Die Serendipity Styx Edition hat übrigens gerade ein eigenes "Discussion Forum" bekommen: ?
https://github.com/ophian/styx/discussions
falls uns hier mal die Luft ausgeht... ?
Beat Post author am :
Habe vorhin https://styx.beatsblog.ch/ upgedated. Wenn ich eingeloggt bin und in einem zweiten Fenster den Blog mit der satischen Titelseite ansehe, erhalte ich ganz unten folgenden Hinweis:
Wenn ich den Blog aufrufe (https://styx.beatsblog.ch/categories/BLOG) erscheint ganz oben folgende Mitteilung:
Ich glaube, das hatten wir schon und ich könnte diese Meldung wegkriegen, wenn ich die functions_routing.inc.php vom Live-Blog übernehmen würde.
Nachtrag: Yep! mit der geänderten functions_routing.inc.php ist der zweite Warnhinweis weg. ?
Ian Styx am :
Danke. Mache ich heute Abend.
Ian Styx am :
Done! ?
Beat Post author am :
Plugin-Update durchgeführt. Bestätige gerne, dass die Warnung nun weg ist. ?
Beat Post author am :
Habe vorhin nach dem Schreiben eines Blogbeitrags zufälligerweise auf "Vorschau" geklickt. Da ist dann folgender Hinweis erschienen:
Hatten wir das nicht schon?
Ian Styx am :
Ich glaube nicht... Erledigt! 🙏