Nein, das Script ist scheinbar ok.
Hast Du schön gefunden, das kann mir eine Hilfe sein. Nur musste ich dann doch kurz laut lachen, selbstverständlich ist es ein Riesenbug(!) im Script, nur die Antwort ist eben auch so typisch IBM-like: "It's not a bug, it's a feature". Aber immerhin habe ich jetzt Sicherheit, dass ich nicht irgendeinen Knopf im Adminbereich übersehen habe und ich habe zumindest eine Richtung, wo ich den Bug finden muss.
Das könnte übrigens auch die Ursache für den anderen Bug sein, nämlich dem ärgerlichen "Verschwinden" der Boardbezeichnungen, wenn man als Admin ein bestehendes Board überarbeitet - da ist dann auch (scheinbar zufällig) oft die Bezeichnung "leer" und man muss die manuell neu eintragen. Ich rate mal, dass das der gleiche Zusammenhang ist.
Grundsätzlich ist das (s.o.) ein sehr schwerer Fehler im Script und eigentlich ist das ein Unding, dass SMF das Forum in diesem Zustand ausliefert, das hat im Leben keinen beta-Test gehabt und hätte nie Release Candidat werden dürfen (nicht für ISO Character Sets).
Bei der Installation hat man die Auswahl, ob man eine UTF8 oder eine ISO-8856-1 Version installieren möchte. Nach meiner persönlichen Erfahrung laufen im Zweifel die UTF8 Versionen schlechter und außerdem ist ISO-8856-1 der angesagte Zeichensatz für Westeuropa. Man sollte UTF8 nur dann benutzen, wenn man eine internationale Seite betreibt, wo beispielsweise auch chinesische Zeichen gewünscht werden. Das ist bei uns ja nicht der Fall und gerade weil ich die Probleme mit UTF8 kenne, habe ich mich dagegen entschieden. Das Grundproblem ist interner Art, weil die Berechnung von Stringlängen in PHP bei UTF-codierten Strings fehlerhaft ist, so wird das Wort "Käse" als Stringlänge den Wert 5 (statt 4) erhalten, weil bei UTF8 für viele Sonderzeichen (aber eben nicht für alle) intern 2 Byte belegt werden, was PHP aber nicht berücksichtig und dann 5 herauskommt. Ist etwas kompliziert für Laien, aber ich will es trotzdem versuchen, zu erklären und warum ich mich für ISO-8856-1 entschieden habe. Und jetzt läuft ausgerechnet bei SMF die UTF8 Version besser - auch skurril.
Und der "Workaroung" der vorgeschlagen wird, das ist der absolute Hit: man solle im nachhinein die komplette Installation auf UTF8 umstellen, inkl. der angelaufenen Datenbank. Und macht keinen Hehl daraus, dass das in die Hose gehen kann.... Halleluja! Wie bekloppt sind die eigentlich?!
Also entweder gibt SMF nur noch UTF8 Versionen frei, oder sie müssen diesen Fehler beheben (was ich bezweifle). Aber so geht es gar nicht - keine Warnung, kein Hinweis bei Installation und nachher ist ein fetter und bekannter Bug drin. Das ist typisch für "Script-Kiddies", die keine Ahnung davon haben, was verantwortungsvolle Produktpolitik bedeutet. Klar, ist Freeware, ich habe keinerlei Ansprüche, aber wenn ich das gewusst hätte, hätte ich ein anderes Script gewählt (wir hatten sehr gute Alternativen zur Auswahl).
Nun ist das ganze ja dennoch erträglich, ich werde es so halten, wie ich es angekündigt habe: irgendwann werde ich mal debuggen und schauen, was ich finden kann. Mit Deiner wertvollen Vorarbeit habe ich zumindest schon einmal ein Indiz. Wobei in dem Problemreport der Anwender PHP6 benutzt - ich bin mir nicht im klaren, ob das SMF Team weiß, dass dieser Bug bereits in PHP5 auftaucht. Übrigens wäre dieses Support Board durchaus der richtige Ort, den Fehler mitzuteilen, da könnte man jetzt anfügen, dass das auch schon unter PHP5 passiert. Wenn die Antwort so dämlich bleibt, müssen die sich den Vorwurf gefallen lassen, eine Version herauszugeben, die nicht einmal alpha-Stadium besitzt - kann man eigentlich einstampfen.
Grüße
Rainer
Thema: Benachrichtigung über PN per Mail (Gelesen 6747 mal)
