Weblog Kommentare
Styx Version 3.4-DEV (05.03.2021, 10:16)
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 |
Wie steht es denn mit deinen Rückkehrplänen? Hat hosttech inzwischen die verkündete Migration vollzogen?
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 ?.
Styx und PHP 8 ist ready to use.
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 |
Sobald ich ausgeloggt bin, verschwinden alle diese Fehler wieder.
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 |
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.
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
<input id="serendipityQuickSearchTermField" name="serendipity[searchTerm]" type="search" placeholder="????">
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.:
<input id="serendipityQuickSearchTermField" name="serendipity[searchTerm]" type="search" placeholder="{$CONST.TWOK11_PLACE_SEARCH}" value="">
Habe nun "{$CONST.TWOK11_PLACE_SEARCH}" ersetzt durch "Blogsuche". Nun funktioniert die Suche-Seite wieder. Vielen Dank!
Beat Post author am |
Habe sharebuttons aktualisiert. Der Fehler hat sich nun um ein paar Zeilen verschoben:
Warning: Undefined variable $twitter_via_tag in /home/sites/site100015826/web/styx-master/plugins/serendipity_event_social/serendipity_event_social.php: 164.
Administrative Login Error Warning only - not seen by visitors! Send us a note what happened where and when, please.
Ian Styx am |
PlesK und Gentoo Linux sind zwei verschiedene Paar Stiefel. Das erstere ist eine eingekaufte Software für die Userverwaltung, ein AdministrationsBackend auf das du als Kunde ja auch Zugang erhälst, in PHP geschrieben. Das geben sie natürlich auch preislich weiter.
Das zweite ist das zugrundeliegende Server Linux OS. Bei hosttech wahrscheinlich eher ein anderes.
Ian Styx am |
und last but not least ?
Bitte!
Ian Styx am |
Ja damit:
https://www.blog.dokumenzi.ch/2658-Styx-3.4-alpha2-und-PHP-8.0.3.html#c7844 (Minus Klammer als Edit3 ?)
Und die haben wir ja jetzt auch wieder außer Kraft gesetzt, so dass der Fehler eigenltich wiederkommen müsste.
Beat Post author am |
O.K. AdapterOpCache.php erneut angepasst.
Und dann hat es wieder in Zeile 36 geknallt ?. Habe dann diesen Teil gelöscht:
also quasi einen Schritt zurück.
Ian Styx am |
Sehr apart ... macht aber auch Sinn - danke - jetzt kann ich es dann wohl selbst weiter anpassen, wir werden bei dir vorerst bei
bleiben. Aber eigentlich bräuchten wir eine Art Rückgabe als in etwa
für die Genauigkeit. Ich werde den voku Author mal befragen.
Ian Styx am |
Mir schwant gerade was ...setze mal in die functions.inc das hier ein.
und zwar vor das $opcache = true;//....
In der Seitenausgabe müsste dann soetwas wie bool true / bool true stehen...
Ian Styx am |
Puh OK habs gesehen. Kann wieder weg.
Ist alles in Ordnung!
Beat Post author am |
So gefällt es mir auch besser. ?
Beat Post author am |
Habe im Live-Blog soeben einen Beitrag geschrieben und darin einen Trackback gesetzt. Als ich diesen im Backend bewilligen wollte, habe ich wohl irgend einen falschen Knopf gedrückt (war schon müde und kann mich nicht mehr erinnern, worauf ich geklickt habe).?
Darauf erhielt ich folgende Anzeige:
Der Trackback wurde nicht gelöscht. Ich konnte ihn danach problemlos bewilligen.
Ian Styx am |
Oh Danke! committet.
Beat Post author am |
Ah, hier war es:
Wie durch Zauberhand funktioniert nun PHP-Mail auch mit PHP 8.0.5
Ich habe nichts gemacht. Es scheint, dass Hosttech den Fehler (im Stillen) korrigiert hat.
Wie auch immer: Problem erledigt! 👍
PS: Vielleicht war es auch ein PHP-Problem, denn damals war V8.0.3 aktiv und nun V8.0.5 (auch wieder ohne eine Aktion von meiner Seite).
Ian Styx am |
Eher das Erstere, würde ich sagen. Aber besser spät als nie! 😀