styx_master

Testumgebung

Sonntag, 15. Dezember 2019

Donnerstag, 12. Dezember 2019

SPAM-Attacke

Dieser Blog wurde von SPAM-Robotern entdeckt. Seit gestern Abend sind über 50 SPAM-EMails eingegangen. Um mich vor solchen Aktionen zu schützen installierte ich die SPAM-Ereignis-Plugins Biene und Bayes.

Die erstendrei Ereignis-Plugins in der Liste der installierten Plugins sind nun:

  1. Spamschutz Biene (Honeypot, Verstecktes Captcha) (serendipity_event_spamblock_bee)
  2. Spamschutz (serendipity_event_spamblock) (-> bestehend im Kern)
  3. Spamschutz Bayes (serendipity_event_spamblock_bayes)

Dienstag, 10. Dezember 2019

Montag, 9. Dezember 2019

Samstag, 7. Dezember 2019

Freitag, 6. Dezember 2019

nur noch ein kleines Problem

Der Styx-Testblog hat Fortschritte gemacht. Soweit läuft jetzt alles ziemlich rund. Auch das Theme konnte ich nach meinen Vorstellungen anpassen. Da ist eigentlich nur noch eine Sache...

Wenn ich mich im Backend anmelden will, erhalte ich folgende Fehlermeldung:

Fatal error: Uncaught Error: Call to a member function assign() on null in /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/serendipity_admin.php:104 Stack trace: #0 {main} thrown in /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/serendipity_admin.php on line 104

Auf Linie 104 steht:

$serendipity['smarty']->assign('pin_entries', $pinids);

Ich habe diese Zeile einfach auf gut Glück mal gelöscht und siehe da, ich komme wieder ins Backend hinein. Da wird auch keine Fehlermeldung angezeigt.

Donnerstag, 5. Dezember 2019

Migration S9Y -> Styx

Einen ersten Versuch mit Styx 2.9.2 habe ich Anfang November unternommen und hier beschrieben.

Heute wiederholte ich das Vorgehen mit Styx 3.0-alpha4. Das (zwischenzeitliche) Ergebnis kann man hier sehen.

Kurze Zusammenfassung des Vorgehens:

  • Download der neusten Files und Erstellen einer neuen Installation
  • Installieren aller Plugins, die ich im Live-Blog benutze (identisch konfigurieren)
  • DB-Dump zur Sicherung
  • Exportieren verschiedener DB-Tabellen des Live-Blog
  • Importieren der Tabellen in die Neuinstallation (Kollakationen anpassen)
  • Test-Mediadaten per FTP übertragen (2019)
  • Testen (z.B. Thumnails erneuern, Fehler suchen)
  • Glücklich sein

Hier ein Screenshot der Tabellen, die ich ex- und importiert habe:

Mit der categorytemplates-Tabelle hatte ich ein paar Probleme. Deshalb habe ich wieder die Originaltabelle verwendet. Im Backend kriege ich unter "Einträge bearbeiten" noch ein paar Fehlermeldungen angezeigt. Eine (negative) Auswirkung davon konnte ich zwar nicht feststellen, doch auch da muss ich noch genauer hinsehen. -> Das hat sich erledigt. Eben weil ich die leere Original-categorytemplate-Tabelle verwendete, kamen diese Fehlermeldungen. Nachdem ich alle Kategorien geöffnet und gespeichert habe, waren die Fehlermeldungen weg (und die Tabelle befüllt).

Grundsätzlich bin ich sehr zufrieden. Alle 2504 Beiträge und 1672 Kommentare sind integriert und werden richtig dargestellt!

Im Live-Blog verwende ich ein abgeändertes Next-Template, welches ich dann in die Neuinstallation kopiert habe. Interessanterweise kriege ich das aber nicht richtig lauffähig. Es sieht so aus, als ob style.css nicht geladen wird. Da muss ich mich noch im Detail darum kümmern (deshalb ist jetzt das Next-Standard-Template im Einsatz).

Die Seitenleisten nicht noch nicht gleich wie im Live-Blog, doch das ist eine Kleinigkeit und das stört mich aktuell auch nicht.

Jetzt, nach zwei Versuchen denke ich langsam, dass dies das richtige Vorgehen ist. So habe ich eine frische Installation, mit allen Daten aus meinem fast 14 Jahre alten Blog.

Mittwoch, 4. Dezember 2019

umtf8mb4-Emoji

Im Backend - Eintrag bearbeiten werden die Emoji noch angezeigt.

Im Frontend, im Eintrag erscheinen danach nur noch ? (Fragezeichen). Siehe letzter Beitrag.

Kommentare werden nicht in die DB geschrieben, wenn im Textfeld ein umtf8mb4 Emoji eingefügt wird. Oder ich vermute mal: Jedes Zeichen, welches nicht in utf8_general_ci enthalten ist.

?

utf8mb4

Die letzten Kommentare zum ersten Beitrag wurden (wieso auch immer) nicht angefügt. Ich sehe die Kommentare nicht in der Admin-Oberfläche, als Mail wurden sie mir (Admin) jedoch zugeschickt. Um die Diskussion weiterführen zu können, dieser neue Eintrag.

Hier der letzte Kommentar von Ian Styx (04.12.19, 11:30 CET):

OK. Über die Sicherheit sollte man sich aber trotzdem Gedanken machen. Je länger, desto mehr. (Wenn das mit dem Jessie System stimmt.)

Dazu fällt mir gerade noch ein, dass du auch mal testweise an dieser genauen Stelle deines eigenen files ein  echo '< pre >'.print_r($data['dbUtf8mb4_migrate']['errors'],1).'< /pre >'; (leerzeichen in den pretags entfernen) einfügen könntest, um zu sehen, ob irgendwelche error Ausgaben, und seien es nur leere, zurückgegeben wird. Dann würde dbUtf8mb4_simulated anschließend auf false gesetzt, was zu deiner gelben Fehlermeldung in der Wartung führt.

Und ja, es geht hier hauptsächlich nur um die erweiterte Unterstützung für (unicode) Emojis a la ? und ? etc. ... UND - wie man hier sieht - ist deine DB schon korrekt auf UTF8mdb4 eingestellt, sonst würden die Emojis nicht angezeigt und anschließender Text nicht mehr dargestellt.

O.K. Habe ich gemacht. Stelle aber keine Veränderung fest. Wenn ich in der Administrationsoberfläche auf Wartung klicke, sind die gelben Warnhinweise immer noch da.

Interessante Beobachtung: Im Editor (Eintrag bearbeiten) werden die Emojis noch richtig dargestellt. In der oben dargestellten Blockquote des Beitrags erscheinen aber nur noch ? Fragezeichen. Das hat sich auch nicht geändert, nachdem ich im Editor alle (unnötigen) Text-Style-Anweisungen entfernt habe.