WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => Modules => Topic started by: dbs on June 03, 2019, 04:57:03 PM
-
Hallo, auf einer MariaDB 10.x ist topics nicht mehr zu gebrauchen für neue Einträge.
Wird wohl am STRICT liegen.
Topic hinzufügen gibt zwar grüne Bestätigung, aber von da aus geht es dann nicht weiter bzw man sieht nur noch das Backend Menü. Darunter ist alles weiß.
Wenn bei STRICT und INSERT INTO in der add_topic.php wirklich jedes Feld angegeben werden muss, dann sind die dort vorhandenen 8 Angaben genau 27 zu wenig. Vielleicht hat das aber schon jemand durch gemacht? Oder kennt einen Link zur Lösung?
Gruß
Frank
-
Wenn bei STRICT und INSERT INTO in der add_topic.php wirklich jedes Feld angegeben werden muss, dann sind die dort vorhandenen 8 Angaben genau 27 zu wenig
nicht jedes Feld, "nur" jedes ohne eine default-Definition in der install.php, allerdings verwendet topics ja mehrere Tabellen, so das 27 vielleicht doch hin kommt oder nicht ausreichend ist.
Ich habe hier eine Vers 0.9.4.2, was ist denn aktuell?
-
Hatte eine dunkle Erinnerung an Dietmars Worte ... text muss, ansonsten varchar wenn kein default wert. Spart ein paar.
Funktioniert hier nicht mit v0.9.1 und 0.9.4.1. Ein Blick in die add_topic.php müsste reichen.
-
0.9.0 ist wohl die letzte, die hier promoted wurde, alles andere dann bei den Kollegen und keine Ahnung, was davon hier noch läuft
Willst du es selber richten, mach dir in der Install.php hinter jedem Insert eine Fehlerkontrolle nach diesem Muster
if (!$database->query($SQL)){
$admin->print_error($database->get_error());
}
der grün markierte Teil muß jeweils zur Definition vor dem Insert passen, also hier
$SQL = "CREATE TABLE IF NOT EXISTS....
Weiterleitung in den WB-Optionen auf -1 und dann manueller Install und Stück für Stück
in der mod_topics wären das diese Felder
. '`groups_id` VARCHAR(255) NOT NULL DEFAULT \'\',' //new field
. '`modified_by` VARCHAR(255) NOT NULL DEFAULT \'\','
. '`authors` VARCHAR(255) NOT NULL DEFAULT \'\',
. '`title` VARCHAR(255) NOT NULL DEFAULT \'\','
. '`short_description` VARCHAR(255) NOT NULL DEFAULT \'\','
. '`description` VARCHAR(255) NOT NULL DEFAULT \'\','
. '`keywords` VARCHAR(255) NOT NULL DEFAULT \'\','
. '`picture` VARCHAR(255) NOT NULL DEFAULT \'\','
. '`is_master_for` VARCHAR(255) NOT NULL DEFAULT \'\','
. '`see_also` VARCHAR(255) NOT NULL DEFAULT \'\','
die fehlen
aber in den anderen Tabellen fehlen auch welche
Zusätzlich müßte man die Scripte durchschauen, z.b. bei jedem INSERT
Alternativ: Modul anhängen
-
Müssten noch ein paar mehr sein. Damit gehts.
<?php // nur bunt
$Sql = 'INSERT INTO `'.TABLE_PREFIX.'mod_'.$tablename.'` SET '
. '`section_id`= '.$section_id.' , '
. '`page_id`= '.$page_id.', '
. '`groups_id` = \'\', '
. '`active`= 1, '
. '`posted_first`= '.$t.', '
. '`posted_by`= '.$theuser.', '
. '`modified_by`= \'\', '
. '`authors`= '.$theuser.', '
. '`position`= '.$position.', '
. '`link` = \'\', '
. '`title` = \'\', '
. '`short_description`= \'\', '
. '`description`= \'\', '
. '`keywords`= \'\', '
. '`picture`= \'\', '
. '`is_master_for`= \'\', '
. '`content_short`= \'\', '
. '`content_long`= \'\', '
. '`content_extra`= \'\', '
. '`commenting`= '.$commenting.', '
. '`see_also`= \'\', '
. '`tagcloud`= \'\', '
. '`rating_base`= \'\', '
. '`txtr1`= \'\', '
. '`txtr2`= \'\', '
. '`txtr3`= \'\', '
. '`pnsa_cache` = \'\' ';
// $database->query($Sql);
if (!$database->query($Sql)){
$admin->print_error($database->get_error());
}
-
In der save_topic.php wird mir gerade etwas schwindlig.
Wenn ich die Lust verliere das zu korrigieren, hab ich zum Glück schon vereinbart ein anderes Modul zu nehmen (OFA) und die Einträge zu übertragen.
Vielleicht sollte man da ein transfer-script basteln. :-)
-
wobei OFA vom Code her das gleiche Problem ist wie Bakery und topics. Die Probleme, die Manu hier aufgezeigt hat (https://forum.WebsiteBaker.org/index.php/topic,31488.msg220325.html#msg220325), gelten da ja auch. Ein kleines 10-Dateien-Modul läßt sich da noch schnell fixen, aber die komplexeren Sachen wie OFA, Download- oder Foldergallery oder gar ProCalendar, das wird schon sehr umfangreich
-
Ja OFA ist da auch nicht perfekt. Zumindest bricht es nicht mit weißer Seite ab.
Duplizieren klappt nicht. Aber sonst ist mir da noch nichts aufgefallen.
-
Duplicating in OFA works like it should do. What errors do you encounter?
-
Hi, you can't duplicate a item if your database work in strict mode.
In save_item.php line 603 (Insert new row into database) are some values missing.
scheduling, link and description. Therefore saving is aborted. You go back without a duplicated item.
If you are not in strict mode OFA works like it should.
-
save_item.php line 603 (Insert new row into database) are some values missing.
replace the originalcode
$database->query('INSERT INTO `'.TABLE_PREFIX.'mod_'.$mod_name.'_items` (`section_id`, `page_id`, `position`) VALUES ('.(int)$section_id.', '.(int)$page_id.', '.(int)$position.')');
with this code
// Insert new row into database
$sql = 'INSERT INTO `'.TABLE_PREFIX.'mod_'.$mod_name.'_items` SET '
. '`section_id` = '.(int)$section_id.', '
. '`page_id` = '.(int)$page_id.', '
. '`title` = \'\', '
. '`link` = \'\', '
. '`description` = \'\', '
. '`position` = '.(int)$position.', '
. '`scheduling` = \'\', '
. '`main_image` = \'\', '
. '`modified_when` = \''.time().'\', '
. '`modified_by` = '.(int)$admin->get_user_id().' ';
// Check if there was a db error
if (!$database->query($sql)){
$admin->print_error($database->get_error());
}
-
Habe jetzt topics versucht auf strict anzupassen.
Im Prinzip funktioniert es bei install, upgrade, verschieben, duplizieren usw..
In topics 0.7 gab es mal 3 Felder mehr, irgendwas mit rating. Wer das noch hat, könnte auf ein strict-Problem stoßen.
Müsste man eigentlich von Hand oder bei install entfernen.
Bin erstmal froh so weit zu sein. Weitere Tests sind gern gesehen.
Anhang im späteren Post ...
-
Was bastelt ihr denn jetzt schon wieder?
Eine Spezial Version des wbce-moduls für wb? Und was, wenn's Mal ein Update gibt?
-
Alle Module MÜSSEN über kurz oder lang im Strict-Modus laufen.
Das hat NIX mit WB zu tun!
WB ist darauf vorbereitet, und deshalb ist es wenig sinnvoll Module nicht anzupassen.
Wenn's denn notwendig wird halt auch bei 'nem Update zu wiederholen.
Ist dann aber nicht problematisch, da der Code ja dann vorliegt.
Nedenn Gruß aus Hammaburch, Evaki.
-
Wer sagt das? Der 138. Guru von hinten?
Wenn's soweit ist, kann man ja geordnet machen.
-
Wer sagt das? Der 138. Guru von hinten?
Hehe, der ist gut.
Aber mal Quatsch beiseite. Seit dem letzten Jahr haben etliche Provider auf v5.7 umgeschaltet, wo denn strict default ist. Nun hat man bei WB die Chance ergriffen, schon mal früher als sonst anzusetzen, also moglichen Problemen diesbezüglich aus dem Weg zu gehen, und dann ist es auch nicht gut? Ich selbt bin froh, wegen so'nem Schei... nicht mehr aus meinem Anwenderkreis angeprochen zu werden, außer wenn's mal'n uralt-Module trifft.
Den Kram zieht man einmalig durch, un jut is.
MfG. Evaki
-
Wie geschrieben
Topic hinzufügen gibt zwar grüne Bestätigung, aber von da aus geht es dann nicht weiter bzw man sieht nur noch das Backend Menü. Darunter ist alles weiß.
Wenn der User mich dann anruft, kann ich nichts von Gurus erzählen, sondern muss handeln.
-
Man kann's doch auch anders herum betrachten.
Du lieferst ein schönes Modul, wo WB-Anwender sich drüber freuen, und hier macht jemand einen auf strict. Also profitieren doch alle davon.
Versteh' ehrlich gesagt das Problem nicht.
Ist doch noch eine der wenigen Chancen miteinander konstruktiv umzugehen.
MfG. Evaki
-
Hatte mir leider meine Online Änderungen beim Upgrade Test zunichte gemacht.
War eigentlich verwendungstauglich, aber das Upgrade hatte die Änderungen nicht drin. *grrr*
Neuer Tag - Neues Glück.
-
Basis ist ein topics 0.9.4.1
Wer Probleme mit Topics und strict hat kann die Version mal testen.
Hab so viel gemacht bis bei mir keine Probleme mit Strict mehr auftraten. Aber jeder arbeit ja anders.
Es ist audrücklich eine Testversion, deshalb die Versionsnummer auch nicht erhöht. Neuere WB's können gleiche Modul-Versionsnummern quasi drüberinstallieren. So kann man auch wieder seine alte original Version 0.9.4.1 danach installieren, falls nichts mehr geht.
Sicher wurde etwas übersehen oder ist zu viel geändert.
Wäre ganz gut, wenn Uwe auch mal drüberschaut.
-
Wäre ganz gut, wenn Uwe auch mal drüberschaut.
nimm mal den Anhang in letzten Post wieder raus bitte, der Install funktionierte garnicht
Type = TEXT darf kein DEFAULT VALUE mehr haben
Date-Format = '0000-00-00' ist kein valider default-Wert mehr
kommt aber noch mehr
P.S.: hat wohl funktioniert, weil die Tabellen vor der Aktivierung des Strict-Mode erstellt wurden (vermute ich)
-
War eine Neuinstallation. Wußte nicht, dass nach Deinstallation noch Tabellen übrig bleiben (3 Stück).
Aber auch nach Löschen der Tabellen und Neuinstallation hab ich hier keine Porbleme mit dem Modul.
Ist dein Strict Mode stricter als strict?
-
Ist dein Strict Mode stricter als strict?
ich denke schon, aber auch nicht so strict wie das vom User "Paulchen" :oops:
Es kommt auf die Mysql-Version an. Die beiden genannten Punkte waren ja früher erlaubt bzw wurden nicht beanstandet
-
Du meinst sicher die install.php. Ja, komisch, damit hatte ich keine Probleme.
Aber richtig, darin ist nicht alles wie es sein sollte für strict. Da hat meine MariaDB wohl paar Anweisungen bekommen. Werd ich mal prüfen.
-
So, jetzt mit Tastatur..
Zu MySQL-Strict
Ich betreue ein paar Hundert Websites bei unterschiedlichsten Hostern - wo eben die Kunden so sind.
Kein EINZIGER davon hat den Strikt Mode im Angebot, geschweige denn zwingend.
Ich habe auch nie etwas gehört, dass da was kommen würde.
Und da gibt es auch gute Gründe dafür:
Der Strikt Mode hat nur sehr theoretische Vorteile, in der Praxis keine. (Geschwindigkeit? Nein. Sicherheit? Nein)
Dafür hat man in der Praxis (als Hoster) den massiven Nachteil, dass man dauernd Kunden am Telefon hat, denen man die theoretischen Vorteile NICHT klar machen kann.
Und zum Thema:
Topics ist ein Core-Modul von WBCE und wird auch vom WBCE-Team gepflegt. Colinax macht das.
Wenn ihr Topics auf SQL-Strikt ändern wollt, dann haltet euch bitte an die Gepflogenheiten: Nehmt Kontakt auf, verwendet die neueste Version und gebt sie dann wieder so zurück, dass sie auch mit WBCE funktioniert. Wir sind ja keine Berserker hier.
Noch wissenswertes:
Topics löscht bei einer Deinstallation die Tabellen nicht, sondern benennt sie um. Das ist so, weil da sehr viel Inhalt drin sein kann und nicht jeder Trottel mal alles löschen können soll.
Auch Topics mit mehr Inhalt werden nicht gelöscht, sondern bekommen eine negative section_id
Die alten Felder mit rating sind obsolet, das ist über den Gedanken nie hinaus gekommen.
-
@Chio: Bist du Guru 139?
Der User sucht sich seine MySQL Version nicht aus. Wenn die nun strict ist, hilft es nicht weiter, dass du nur Kunden ohne strict hast und strict strikt ablehnst.
SELECT @@GLOBAL.sql_mode;zeigt mir:
STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Da fehlt wohl einiges was bei Uwe oder Paulchen aktiv ist. Der Hoster hat es wohl etwas entschärft. Vielleicht sollte er noch STRICT_TRANS_TABLES rausnehmen. Aber ergibt der strict mode dann noch Sinn?
-
SQL_MODE_STRICT Ja oder Nein ist bei logischer Betrachtung eine völlig überflüssige Diskussion.
Wir ProgrammiererInnen haben keinen Einfluss darauf, was auf welcher Datenbank eingestellt ist.
Da jedoch ein Strict gecodetes Programm problemlos auf einer Nicht-Strict Datenbank läuft (was umgekehrt eben nicht der Fall ist), bleibt nur eine einzige logische Schlussfolgerung:
Wir coden grundsätzlich in Strict, alles funktioniert auf allen Datenbanken und wir freuen uns...
Nicht-Strict Coder ärgern sich halt immer wieder aufs Neue über immer wieder das gleiche Problem.. (soll gegen Langeweile helfen)
-
Für mich ist eigentlich das ausschlaggebend, was Evaki oben schon schrieb - ab v5.7 ist strict per default active.
Neben ein paar ausländischen Kunden, deren Hoster bei den Softwareupdates nicht so fix sind wie z.b. unsere großen deutschen Provider, hab ich nur einen, der bei einem kleinen Anbieter ist und selbst der hat Strict. Bei den großen" Deutschen wie 1&1, Strato, Host Europe oder auch AllInkl ist es etwa 50/50, die meisten haben es mit den Updateorgien im letzten Herbst bekommen.
Solang ich den Code kenne, was nun mal Open Source mit sich bringt, ist es sicherheitstechnisc h kein Vorteil. Da sucht man sich die Felder halt im Script zusammen und gut ist.
Ist der DB-Aufbau aber nicht bekannt, dann kommt man mit z.b. einem einfachen Insert, wie ihn viele add.php älterer Module haben, nicht mehr weit
-
Du meinst sicher die install.php.
Jepp
Aber richtig, darin ist nicht alles wie es sein sollte für strict.
Droplet eintragen bzw, wenn schon vorhanden, updaten hatte auch nicht funktioniert. Weiter bin ich noch nicht, kämpfe noch mit der Grafikkarte
-
Der User sucht sich seine MySQL Version nicht aus. Wenn die nun strict ist, hilft es nicht weiter, dass du nur Kunden ohne strict hast und strict strikt ablehnst.
Der User = Kunde sucht sich sehr wohl seine SQL-Version aus. Genauso wie er sich aussucht, ob der SafeMode ON oder OFF ist (war)
Oder ob UploadMaxFilesize (fix und unveränderbar) auf 2 Mb gestellt ist, wie ich es unlängst erleben durfte.
Er sucht es sich aus, indem er den AuthCode verlangt und ab auf nimmer wiedersehen.
SQL Strict spielt nur dort eine Rolle, wo User und Hoster die selbe Person sind, und das wird auch so bleiben: SQL Strict gibt es seit 12 Jahren und die Verbreitung ist immer noch sehr speziell.
Aber das ist mir wurscht, das ist Sektenkram.
Ich will nur vermeiden, dass es plötzlich eine unkompatible und alte WB-Version von Topics gibt.
Man kann das Ding jederzeit umbenennen: Modulverzeichnis, info.php, search.php (der Function-Name) und die Tabellen-Namen: "topics" ersetzen durch DirName. Man kann nur nicht Dieses und Topics auf der gleichen Seite haben.
-
Schönen guten Abend.
Ich will nur vermeiden, dass es plötzlich eine unkompatible und alte WB-Version von Topics gibt.
Wie soll das gehen, wenn Dein Code unbehelligt bleibt, und nur die DB-strict-Regeln befolgt werden, die sich dann erst recht durch Kompatibilität auszeichnen.
Ich habe hier jaaaanz doll 'ne Ahnung, daß dieser Disput ausschließlich auf einem Mißverständnis beruht.
p.s. Am Wochenende gibt's mal wieder Kaiserschmarrn. Die Seele fühlt sich geschmeichelt. Mit wenigen Mitteln so etwas zu zaubern... - Gut, können muß man's natürlich.
MfG. Evaki
-
Dieser "Sektenkram" breitet sich aber überall aus, ob jetzt bei den Forks oder anderen Systemen, die Anfragen in den Supportforen häufen sich.
Ich hab auch nicht wenige Kunden, wo die Webspaceverwaltung ein Teil ihres Paketes ist, Telefon, Internet, IPTV, EMailpostfächer. Für Gewerbetreibende, die vielleicht auch noch Dienstleister beauftragen, soll deine AuthCode und Tschüss-Variante kein Thema sein, wohl aber auch nicht mehr unbedingt kostenlos.
-
Ich wollte ja auch nur eine strict Variante der 0.9.4.1 zur Soforthilfe und zum Test für die 0.9.4.1 hier rein setzen.
Das hat sich erstmal erledigt, weil mein strict nur light war und niemandem anderen geholfen hätte.
Handwerkliche Fehler kämen noch dazu.
Bei CE erwarte ich keine Anpassungen für strict.
-
Das hat sich erstmal erledigt, weil mein strict nur light war und niemandem anderen geholfen hätte.
Handwerkliche Fehler kämen noch dazu.
seh ich nicht so. Wie oben schon gesagt, ist es eher eine Frage der vorhandenen MySQL-Version.
In der Anlage die geänderte Datei install.php, gezippt, läuft unter MySQL-Strict und auch im non-strict-mode, sollte also für niemanden zum Schaden sein
geändert:
- die Feldtypen BLOB und TEXT haben kein DEFAULT VALUE, darum entfernt
- der Insert/Replace fürs Droplet war unvollständig bzw unsauber gecodet
Andere Sachen habe ich bisher nicht gefunden, das Anlegen von Seiten, Topics, Comments, oder Settings funktioniert, ich weiß aber nicht, wo da überall etwas geändert wurde
-
In der save_settings hatte ich 2 werte aus dem darüberliegenden auskommentierten vergessen zu übernehmen.
Glaube topics_per_page und use_timebased_publi shing.
In deiner install sieht das DEFAULT NULL bei DATE ungewöhnlich aus. Sollte da nicht sowas wie '2000-01-01 00:00:00' stehen?
-
SELECT @@GLOBAL.sql_mode;zeigt mir:
STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Da fehlt wohl einiges was bei Uwe oder Paulchen aktiv ist. Der Hoster hat es wohl etwas entschärft. Vielleicht sollte er noch STRICT_TRANS_TABLES rausnehmen. Aber ergibt der strict mode dann noch Sinn?
man schaue sich die unterschiedlichen DEFAULT VALUES in den Versionen 5.7.4 - 5.7.8 an, das wird mit jeder Version strenger -> https://dev.mysql.com/doc/refman/5.7/en/server-options.html#option_mysqld_sql-mode
Unterschiede gibt es dann auch noch zwischen Windows und Linux. Das früher übliche TEXT NOT NULL DEFAULT \'\' würde unter Windows einen error, unter Linux eine Warnung erzeugen
In deiner install sieht das DEFAULT NULL bei DATE ungewöhnlich aus. Sollte da nicht sowas wie '2000-01-01 00:00:00' stehen?
NULL oder '0' ist die Kurzform. (siehe Mysql - "You can also do this using the values '0' or 0, which are easier to write" (https://dev.mysql.com/doc/refman/5.7/en/date-and-time-types.html)) PHPmyAdmin nutzt da z.b. die Wortform NULL
-
Ok, verstanden, NULL ist auch besser als ein sinnloses Datum.
Schau mal in deine install.php z283 (ein Semikolon zu viel).
Werd es wohl nur lokal testen können mit stricterem Strict Mode.
-
Schau mal in deine install.php z283 (ein Semikolon zu viel).
nicht gesehen :oops: :oops:
die ganze Zeile 283 kann raus, die ID im Droplet kommt per Auto_Increment
genau wie diese Zeile 289, die ist nun überflüssig
$id = $found;
-
Ok, entfernt.
Ein Test lokal mit mysql 5.7.11 und sql_mode=
ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
verlief fehlerlos.
Was hat Paulchen da alles in seinem mode?
-
save_item.php line 603 (Insert new row into database) are some values missing.
replace the originalcode
Excellent. I can confirm that this solves the problem with the duplicate-function in OFA using MySQLi in STRICT mode.
-
<offtopic>
Für "Notfälle" kann man auch noch in v5.7.x "non strict" aktivieren.
Wer hostet, kann mit zwei DB ("non strict"/"strict") auf unterschiedlichen Ports operieren.
<ironie>
So kann man größere Kunden (mit Kohle) halten, denen beim Sterben zuschauen, und dann den Zeigefinger erheben "Ham'wer Euch doch jesacht." Für diese abgründige Freude lohnt sich vielleicht "non strict"
</ironie></offtopic>
Ich kenn die Roadmap bei MySQL nicht, wenn's so läuft wie bei PHP, ist dann irgendwann Schluß.
Zum Ende des Jahres wird es möglicherweise nirgendwo mehr php kleiner als 7.3 geben.
MfG. Evaki
-
....
Ein Test lokal mit mysql 5.7.11 und sql_mode=
ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
verlief fehlerlos.
Was hat Paulchen da alles in seinem mode?
Ich wundere mich schon eine ganze Weile, dass mein Strict-Mode so gnadenlos sein soll :-)
Ich erhalte auf den Befehl
SELECT @@GLOBAL.sql_mode;folgende Ausgabe:
STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
also weniger strict, als bei dir - sofern ich aller richtig gemacht habe.
-
what..... :-o :-o :-o
schaust du bitte mal noch ins InfoFenster von WB, was da als PHP- und Mysql-Version steht?
-
Gerne doch:
PHP-Version: 7.3.6
Server-Version: 10.3.10-MariaDB-1:10.3.10+maria~bionic [STRICT]
-
Dank dir!
-
Dann solten wir ja für zukünftige Tests gut aufgestellt sein. Das meiste ist jedenfalls abgedeckt.