Diskussion zu Topics 0.9rc

[chio]

Das Gewusel mit topics_rss ist ein Erbe von Ralf, ich habe das eigentlich nie beachtet.
Kann auch gut sein, dass sich da drinnen noch etliche weitere (mysql) Bug-chen finden.
Interessiert RSS noch irgendjemanden? Sollte man das überhaupt rausnehmen? Ich nutze das nie, deswegen fallen mir Fehler da drin nicht so nebenher auf.

Fehler in der install.php
Jo, da kopiert einer vom anderen, und Fehler verbreiten sich immer weiter. MIttlerweile ist Topics eines der wenigen Module, die überhaupt noch gelegentlich aktualisiert werden - ergo: Ich kopiere schon meine eigenen Fehler, welche denn sonst noch.... Ganz schlecht.
Kannst du mir da nicht ein bissel helfen bei der install.php? Du hast das im kleinen Finger, ich muss mir das alles zusammengoogeln..

Die falschen Voreinstellungen:
Deswegen fällt auch das "Zeitzonen-Problem" so stark auf. Ich ändere mal die Voreinstellungen.

EDIT:
Ich habe die Voreinstellungen nachgecheckt. Die stimmen - was ich sehe - schon so. Standardmäßig ist die Einstellung auf "news", also Datum editiertbar, nach Datum sortiert. Die Einstellung "Eventkalender" zeigt natürlich nur Einträge in der Zukunft, das zeitlich nächste zuerst.

[shadowcat]

Die meisten Probleme macht ja mysql strict, das haben die meisten noch gar nicht. Kommt aber so langsam. Ich glaube, ab irgendeiner Version kann man das gar nicht mehr abschalten.

Es gibt im wesentlichen zwei Möglichkeiten:

1. Man ändert die Tabellendefinitionen, wie oben mit den ALTER-Angaben. Wenn Spalten offensichlich leer sein dürfen (wenn sie beim ersten Einrichten nicht belegt werden, kann man das schlußfolgern), kann man sie auch auf NULL setzen statt auf NOT NULL. Ansonsten muß man halt Standardwerte angeben. Das geht aber beim Typ TEXT nicht.

2. Man ändert die SQL-Statements. Das ist natürlich aufwendiger.

Der Fehler mit dem Droplet kommt ja aus der selben Ecke, also eigentlich kein Grund, es rauszunehmen. Ich habe gesehen, daß da mein Code aus dem Droplets-Modul für WB drin steht (wb_unpack_und_dingens), da einfach bei der Spalte 'id' -> NULL angeben und bei 'modified_by' -> 1 (=admin). Ich weiß gar nicht, ob es das Feld im Standard-WB überhaupt gibt... Ich installier ja immer sofort 'mein' Droplets.

[shadowcat]

Hm, modified_by wird mit $admin->get_user_id() ermittelt, da sollte eigentlich was Sinnvolles rauskommen. Muß ich mal gucken.

[shadowcat]

Das ist wohl eine Lücke in unserer WB-Kompatibilitäts-Schicht. Die Funktion $admin->get_user_id() liefert nichts zurück, weil sie schlichtweg nicht existiert. Das ist im Modul nicht zu lösen, jedenfalls nicht, wenn man BlackCat nicht explizit berücksichtigen will. Korrektur dann in 1.1.1 oder 1.2, je nachdem, was zuerst da ist.

Edit: https://github.com/webbird/BlackCatCMS/issues/278

[chio]

Gibt es andere (kompatible) Möglichkeiten, die Nummer des aktuellen Users zu finden? Da machen ja viele Module davon gebrauch.
Muss ja nicht genau das sein..

Es gibt noch eine weitere Leiche im Keller, die schon ein wenig zu riechen beginnt...

Hat mit der Variablen
$serializedelimiter = "¬ª"; (ursprünglich definiert in module_settings.default.php / module_settings.php)
zu tun, zb:
view.topic.php, ca Zeile 54:

Code: Alles auswählen

$setting_pnsa_string = $settings_fetch['pnsa_string'].$serializedelimiter.$serializedelimiter.$serializedelimiter.$serializedelimiter; //Add some empty 

Kommt an mehren Stellen so ähnlich vor.

Die Felder im Reiter "Siehe auch, Vorherige/Nächste" stehen alle in einem DB-Feld 'pnsa_string', eben durch $serializedelimiter getrennt. Ich hielt das damals für eine gute Idee. Leider kommt es bei der Migration immer wieder vor, dass der delimiter nicht korrekt übertragen wird und damit alle Teile in allen Feldern stehen, unsepariert.
Was kann man da machen? Was für einen Delimiter sollte man stattdessen verwenden? Gibt es da Standards?

[shadowcat]

Wofür ist das denn gut?

Die ID bekommst Du auch aus der Session. Die alte Funktion $admin->get_user_id() macht nix anderes.

// Get the current users id
function get_user_id() {
return $this->get_session('USER_ID');
}

// Get SESSION data
function get_session($field) {
return (isset($_SESSION[$field]) ? $_SESSION[$field] : null);
}

class.wb.php

Edit: In class.wb.php sind die bei uns auch noch drin, das Problem ist, daß $admin auf CAT_Backend verweist und dort eben nur die Funktionen aus der alten class.admin.php verkapselt sind. Das hängt auch damit zusammen, daß das bei WB ein wenig undurchschaubar ist - gleichnamige Funktionen in class.wb.php und class.admin.php und functions.php und und und...

[chio]

Wofür ist das denn gut?
Die ID bekommst Du auch aus der Session. Die alte Funktion $admin->get_user_id() macht nix anderes.

Ja, aber meinereins niedriges Volk wird angehalten, nie direkt auf die Session zuzugreifen, sondern dafür die entsprechenden WB-Funktionen zu nutzen. Ob das jetzt die "offizielle Funktion" ist, weiß ich nicht. Irgendwo gibt es auch die Konstante USER_ID, aber die ist glaube ich ganz, ganz pfui.

[shadowcat]

Ist doch Blödsinn, WB macht ja auch nix anderes. Daß das pfuibäh ist, hat mal irgendwer gesagt, und seitdem ist das Gesetz. Mußt Du nun selber entscheiden.

Du könntest das hier versuchen:

Code: Alles auswählen

$user_id = $admin->get_user_id();
if($user_id=='') $user_id = 1;

Damit ist $user_id immer gesetzt, auch wenn das dann bei BC nicht so ganz korrekt ist. User ID 1 sollte der Superadmin sein, und den gibt's eigentlich immer. Sobald wir für BC eine Korrektur haben, ist alles wieder im Lot, weil dann $admin->get_user_id() wieder was liefert. Letztlich ist das ja unser Problem, nicht Deins.

Das "Wofür ist das gut" bezog sich auf dem Delimiter.

[chio]

Das "Wofür ist das gut" bezog sich auf dem Delimiter.

Da sind einfach mehrere "Felder" in einem DB-Feld gespeichert. Dazu braucht man ein Delimiter. Den habe ich mit "¬ª" scheinbar schlecht gewählt. Gibts da was besseres? Einen üblichen Standard?

[shadowcat]

Mach ein Array und nimm serialize().