Habe soeben Serendipity Styx 3.0-alpha4 installiert. Mir ist klar, dass eine alpha-Version noch ziemlich fehlerbehaftet sein kann. Es ist also eine reine Testumgebung.
Dies ist ein erster Testeintrag mit Bild. Dazu wurde in der Mediathek unter /uploads das Verzeichnis /Test erzeugt. Ansonsten ist das System jungfräulich.
Für den Admin-Benutzer stellte ich den WYSIWYG-Editor auf "vollstämdig" um. Zusätzlich installierte ich das Plugin CKEditor Plus um die aktuelle Version des Editors zu kriegen (V4.13.0).
Obwohl es eine Neuinstallation ist, wird im Wartungsbereich angezeigt, dass es nicht vollständig mit UTF-8-MB4 betrieben werden kann. Ich kann die Ursache der Meldung nicht nachvollziehen. Der Zeichensatz im Blog ist auf UTF-8 eingestellt, die Verbindung zu der DB ist mit Zeichensatz/Kollation der MySQL-Verbindung auf utf8mb4_general_ci eingerichtet und alle DB-Tabellen sind neu und demzufolgen mit utf8mb4 erstellt. Beim DB-Server handelt es sich um Server-Version: 10.2.27-MariaDB. Ich weiss also nicht, wie ich diese Meldung wegkriegen könnte (das Gleiche stellte ich schon bei der stabilen Version 2.9.2 fest).
Ian Styx am :
Die Datenbank muss bei Zeichensatz/Kollation der MySQL-Verbindung mit utf8mb4_unicode.ci erstellt werden. Nicht ..._general.ci.
Ich habe schon etliche lokale bzw Server Installationen begleitet/durchgeführt und seit der Einführung dieser Erweiterung auf Styx nie Probleme damit gehabt.
Bist du auch sicher dass du wirklich mysqli verwendest (siehe Konfiguration) und dein PHP das auch supported (siehe phpinfo())?
Beat Menzi am :
eingesetzte PHP-Version = 7.3.12
https://www.styx.dokumenzi.ch/phpinfo.php
Ian Styx am :
Dein Problem liegt wahrscheinlich daran, dass du wie schon erwähnt, entweder nicht MySQLi, bzw nicht wirklich die angegebene 10.2.27-MariaDB verwendest. Checke das mal genau. Auch kann es sein, dass du vielleicht kein https://mariadb.com/kb/en/library/mysql_upgrade/ gemacht hast, wenn das ein upgrade einer älteren Mysql (Oracle) Version war.
Beat Menzi am :
-- phpMyAdmin SQL Dump
-- version 4.9.0.1
-- https://www.phpmyadmin.net/
--
-- Host: localhost:3306
-- Erstellungszeit: 03. Dez 2019 um 14:59
-- Server-Version: 10.2.29-MariaDB-10.2.29+maria~jessie
-- PHP-Version: 7.1.14
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET AUTOCOMMIT = 0;
START TRANSACTION;
SET time_zone = "+00:00";
/!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT /;
/!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS /;
/!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION /;
/!40101 SET NAMES utf8mb4 /;
--
-- Datenbank: `styx3`
--
CREATE DATABASE IF NOT EXISTS `styx3` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci COLLATE utf8mb4_general_ci;
USE `styx3`;
COMMIT;
/!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT /;
/!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS /;
/!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION /;
Ich kann das DEFAULT CHARACTER SET und COLLATE nicht selber auf utf8mb4_unicode_ci umstellen. Dafür fehlt mir die Berechtigung. Ich könnte den Support anmailen, ob sie das für mich ändern. Muss dann beides auf utf8mb4_unicode_ci gestellt werden? Ist das alles?
Ian Styx am :
Standardmäßig wird utf8mb4_general_ci benutzt. Während dieses den UCA (Unicode Collation Algorithm, Unicode-Sortierfolgenalgorithmus) nicht unterstützt, ist er bei utf8mb4_unicode_ci fast vollständig implementiert. Ergo geht es hier (nur) um minimale Geschwindigkeitsprobleme auf Hochleistungssystemen. Das betrifft uns aber nicht, deshalb ist _unicode.ci vorzuziehen.
Die phpinfo sieht auf die Schnelle auch ok aus... die Datei solltest du aber unverzüglich entfernen! Das sind keine Infos die man öffentlich ausstellen sollte.
Das einzige was mir auffällt ist, das dein Server Nginx als HTTP-Server verwendet. Auch wird noch Debian (8) Jessie als Server (s.o.) ausgewiesen. Jessie ist alt! Selbst sein Nachfolger ist seit dem Frühjahr vom aktuellen Debian (10) Buster abgelöst. Wie dein Provider dort solch neuen Versionen (Maria/PHP) ermöglicht hat, über offizielle oder inoffizielle backports, ist möglichweise auch der Grund, warum es bei deinem Problem irgendwo hakt, denn bestimmte Systemteile werden schon seit längerem nicht mehr mit Updates versorgt.
Näheres kann dir also nur dein Provider beantworten und das womöglich auch nicht, denn es könnte ein Kompilierungsproblem, zb mit MariaDB und irgendwelchen Dependecies zu neueren Unicode Versionen, sein... Am besten ziehst du also auf einen neuen Server um.
Viel Erfolg.
Beat Menzi am :
Nochmals Danke!
Grundsätzlich möchte ich den Provider nicht wechseln. Das Angebot läuft sehr stabil, schnell und recht günstig. Ja, die phpinfo-Datei habe ich gleich wieder gelöscht. Ich wollte Dir Einblick gewähren und das braucht es nun ja nicht mehr.
Ich meine, es wäre ja schön, wenn auch bei mir Serendipity Styx vollständig auf utf8mb4 funktionieren würde, doch so wie es jetzt ist, sehe ich (als Laie) auch keine funktionalen Nachteile.
Das Ziel ist, meinen aktuellen Blog, www.bbbeat.ch, der derzeit auf Serendipity 2.3.2 läuft auf die stabile Styx Edition 3.0 zu migrieren. Bis V3.0 stabil läuft, habe ich Zeit zum testen (mein Blog ist über 13 Jahre alt, hat etwa 2'500 Beiträge und mehr als 3'000 Bilder). Da kann etwas Testen zur Vorbereitung nicht schaden...
Meine Haupt-Motivation für die Migration ist vor allem der korrekt implementierte CKEditor. Dieser macht mir unter Normal-Serendipity doch immer wieder Ärger und die Entwickler machen keine Anstalten um diese Probleme anzugehen.
Beat Menzi am :
Ian Styx am :
Vielleicht sitzt du nur einer Verwechslung auf.... (an der ich mich anschließend ein bißchen beteiligt habe, als ich die Unterschiede zwischen general und nicode beschrieb).
Die Datenbank muss/sollte als utf8mb4_unicode.ci Zeichensatz/Kollation der MySQL-Verbindung erstellt werden, erst dann ist sie fähig entsprechend befüllt zu werden und den Tabellen die richtige Kollation mitzugeben. Der Styx Installer prüft also die Datenbank in die er installieren soll und nimmt dann entsprechend ein utf8mb4 fähiges install script oder nur das alte utf8mb4 script. Das ergibt den Zustand.
Beat Post author am :
Ich muss also damit leben, bis der Hoster das ändert. Bis jetzt habe ich noch kein Mail geschickt, mit der Frage, ob Sie das für mich auf utf8mb4_unicode_ci umstellen. Das sollte ich wohl mal machen. In der Hoffnung, dass dies keine negativen Auswirkungen auf meinen Live-Blog hat.
Ian Styx am :
utf8mb4 benötigt andere Indizes (soetwas wie das Register einer Tabelle), bzw andere Größen derselben, weil mb4 Zeichen mehr Platz belegen! So wird aus einer ehemaligen varchar 255 Zeichen (Indize) Feldlänge eine varchar 191 Feldlänge, damit mb4 seinen Platz hat.
Ob mysql in derselben Datenbank, die mit/auf utf8mb4_unicode oder utf8mb4_general erstellt/migriert wurde, zwischen alten Tabellen mit altem utf8mb4_general und neuen Tabellen mit utf8mb4_general ohne irgendwelche Probleme hin und her wechseln kann, kann ich nicht sagen. Ich würde es wahrscheinlich nicht unbedingt versuchen. Die Stabilität des Live Blogs geht vor! (Außer man hat vollständige und absolut funktionierende Backups und kann zur Not ein paar Tage auf den öffentlichen Betrieb verzichten.)
Ian Styx am :
Eigentlich müsste sie es können, denn ich habe schon viele ältere Systeme mit der Wartungsfunktion erfolgreich migriert, ohne vorher an der Datenbank default Kollation irgendetwas geändert zu haben. Was ich nur nicht weiß ist, ob man migrierte bzw neu erstellte und alte gleichzeitig in derselben DB ohne Probleme bespielen kann.
Ian Styx am :
Ich schließe hier einfach mal eine weitere Beobachtung zu deinem Jessie System und Styx 3.0 an, die ich im Laufe der Tage erlebt habe und die im Hintergrund für Verwirrung sorgt, siehe Post Author Threads.
Nachdem du mir die Login Daten gegeben hattest, habe ich, wie ich es gewöhnlich mache, gleich die Daten speichern Methode nutzen wollen, um mich nicht immer wieder neu anmelden zu müssen. (Nicht die Browser Meldung Login Daten speichern!)
Am nächsten Start war das Login weg. Da dachte ich noch an irgendeine Indifferenz. Es ist mir jetzt aber schon zwei oder drei Mal passiert, so dass ich von einem Systemfehler ausgehe. Das Login nutzt (ohne es jetzt allzuweit öffentlich zu erklären) die höchstentwickelte Stufe/Methode der openSSL Verschlüsselung. (Da war auch schon unterhalb von 3.0 so, hatte aber fallbacks, die ich in 3.0 entfernt habe - siehe unter anderem auf https://ophian.github.io/blog). Hier scheint es etwas zu geben, was dein altes Jessie nicht kann, denn das Login mit "Daten speichern" fällt klammheimlich (und das ist OK so) auf das normale Session basierte Login zurück. Deshalb muss man sich immer wieder neu anmelden, was eben auch für den "Post Author" relevant sein könnte.
Ganz allgemein ist Styx Testing auf diesem System also ok, wenn man/du von den Merkwürdigkeiten bezüglich utf8mb4, PHP ohne webp und fehlender neuerer openSSL Unterstützung (oder was auch immer im Hintergrund für Verwirrung sorgt - denn gut möglich ist es, dass es wieder dein PHP ist, dass durch die ungenügende Systemgrundlage nicht ordentlich kompiliert wurde/werden konnte) weiß bzw. absieht. Nicht aber für den künftigen Produktivbetrieb!
Puh