Vorlagen speichern nicht

[xmurrix]

...Wenn ich die anderen Einstellungen mache und dann den Setup bekomme ich ab der zweiten Seite eine weiße Seite...

Dann müsste doch etwas in den Log-Dateien (data/logs/errorlog.txt oder data/logs/setuplog.txt) stehen.

Vermutlich ist irgendwo ein Syntaxfehler, z. B. der Datei "data/config/{ENVIRONMENT}/config.php"?
Wie sieht denn deine DB-Konfiguration in der config.php aus, meine ist wie folgt, und die funktioniert auch im setup:

Code: Alles auswählen

$cfg['db'] = array(
    'connection' => array(
        'host'     => '**********', // (string) The host where your database runs on
        'database' => ''*********', // (string) The database name which you use
        'user'     => ''*********', // (string) The username to access the database
        'password' => ''*********', // (string) The password to access the database
        'charset'  => 'utf8', // (string) The charset of connection to database
        'options' => array(
            MYSQLI_INIT_COMMAND => "SET SESSION sql_mode='';"
        ),
    ),
    'haltBehavior'    => 'report', // (string) Feasible values are 'yes', 'no' or 'report'
    'haltMsgPrefix'   => (isset($_SERVER['REQUEST_URI'])) ? $_SERVER['REQUEST_URI'] . ' ' : '',
    'enableProfiling' => false,    // (bool) Flag to enable profiling
);

[Peer]

Habe es mit deinem abgeglichen und entsprechnd angepasst

Hier der Errorlog

Code: Alles auswählen

 [2020-09-01 16:58:24] Warning: "Database failure: 1062 (Duplicate entry '0' for key 'PRIMARY') - /setup/index.php?c=db&step=9 ALTER TABLE `con_system_prop` CHANGE COLUMN `idsystemprop` `idsystemprop` int(11) NOT NULL DEFAULT '0' PRIMARY KEY
" at reportHalt() [class.db.driver.handler.php(1013)]
	reportHalt() called in file class.db.driver.handler.php(985)
	halt() called in file class.db.driver.handler.php(705)
	query() called in file functions.database.php(232)
	dbUpgradeTable() called in file include.db.controller.php(51)
	include() called in file index.php(47)

[01-Sep-2020 16:58:24 Europe/Berlin] PHP Warning:  Database failure: 1062 (Duplicate entry '0' for key 'PRIMARY') - /setup/index.php?c=db&step=9 ALTER TABLE `con_system_prop` CHANGE COLUMN `idsystemprop` `idsystemprop` int(11) NOT NULL DEFAULT '0' PRIMARY KEY
 in /var/www/web13/htdocs/2020/contenido/includes/functions.general.php on line 1547

Jetzt die nächste Tabelle wo es mit der 0 ein Problem wird.

Der Setup läuft immer und dann kurz vorm Ende bleibt der Balken stehen

[xmurrix]

In der Tabelle "con_system_prop" gibt es wohl einen Eintrag mit der ID 0. Bei einer neuen Installation sollte das nicht der Anpassung in der config.php nicht vorkommen. Ich würde das also manuell prüfen und ggf. die Id korrigieren.

Am Ende des Setups werden viele SQL-Statements erzeugt und an die Datenbank geschickt. Es kann sein, dass hier die DB irgendwann dicht macht. Aber auch dafür sollte es einen Eintrag in der errorlog.txt geben.

[Peer]

Moin,

also an den MySQL - Einstellung scheint es nicht zuliegen.

Folgende PHP Einstellungen sind nicht aktiv
igbinary, pcntl, redis, sodium, xmlrpc

Kann es sein das diese der Grund sein kann?

Ich habe jetzt alle Daten abgleichen lassen zwischen, diesem Projekt und einem anderen Projekt wo es funktioniert.

[xmurrix]

...Folgende PHP Einstellungen sind nicht aktiv
igbinary, pcntl, redis, sodium, xmlrpc

Kann es sein das diese der Grund sein kann?...

Das sind alle Erweiterungen, deren Funktionen meines Wissens nicht in CONTENIDO verwendet werden.

Die letzte Fehlermeldung betraf die Tabelle con_system_prop, du kannst ja folgendes probieren:

Code: Alles auswählen

SELECT * FROM con_system_prop WHERE idsystemprop = 0;

Wenn diese Abfrage einen Datensatz liefert, dann ist es das Problem. Es sollte in der Tabelle kein Eintrag mit der Id 0 existieren. Das musst du manuell lösen, einfach dem Datensatz die nächst höhere freie ID geben. Datensätze in der Tabelle con_system_prop werden in der Regel nicht in anderen Tabellen referenziert, daher sehe ich hier kein Problem, wenn man die Id korrigiert. Bei anderen Tabellen sieht das aber anders aus.

Bei einer Neuinstallation sollten solche Probleme nicht vorkommen, sofern die für CONTENIDO nötigen Anpassungen am SQL-Modus vorgenommen wurden. Wenn man das Setup auf einer zuvor installierten CONTENIDO Version erneut ausführt, kann es halt solchen Probleme nicht automatisch geradebiegen.

Ich würde vorschlagen, CONTENIDO komplett neu zu installieren, sofern die Probleme mit der Datenbank weiterhin bestehen.

[Peer]

Hallo xmurrix,

danke für deinen Einsatz.

Ich habe gestern noch einmal alles auf einen anderen Server gespielt. Versucht es zu installieren. Immer in den Error-Log geschaut.
Wenn dort ein Tabelle angezeigt wurde mit einem 0 Wert habe ich diesen korrigiert.

Hat etwas gedauert aber war dann komplett - Install hat auch super geklappt.

Dann wieder alles zurück auf den Server wo das Projekt laufen soll - Tada wieder alles verkack.

Die werte mit 0 wurden wieder in die Datenbank geschrieben ...

[xmurrix]

Hallo Peer,

bist du dir sicher, dass in der config.php auch der SQL-Modus wie folgt aussieht?

Code: Alles auswählen

    MYSQLI_INIT_COMMAND => "SET SESSION sql_mode='';"

Bei einer Neuinstallation, in der es noch keine config.php gibt, funktioniert das nicht. Hier kann man in der "contenido/classes/db/class.db.driver.mysqli.php", am Ende der Funktion connect(), also noch vor dem "return $dbHandler;" folgende Zeile einbauen?

Code: Alles auswählen

@mysqli_query($dbHandler, "SET SESSION sql_mode=''");

Vielleicht lässt sich ja der SQL-Modus nicht ändern, das kannst du in der DB-Administration wie folgt testen:

Code: Alles auswählen

SET SESSION sql_mode='';
SHOW VARIABLES LIKE 'sql_mode';

Nach dem Setzen des SQL-Modus auf den leeren Wert sollte es auch leer bleiben.


CONTENIDO ändert beim Setup die Tabellen bei der Installation mit folgender Anweisung

Code: Alles auswählen

ALTER TABLE `con_system_prop` CHANGE COLUMN `idsystemprop` `idsystemprop` int(11) NOT NULL DEFAULT '0' PRIMARY KEY

Das "DEFAULT '0'" sollte meines Erachtens bei Primärschlüsselfeldern nicht gesetzt werden. Dieser Punkt sollte auch gelöst werden, d. h. man sollte das in CONTENIDO ggf. korrigieren.


Welche MySQL Version genau läuft den bei dem Server und bei welchem Provider?

[Peer]

Moin die Herren,

danke für eure Hilfe. Fehler wurde gefunden, es lag an den PHP einstellung. Es wurden dadurch fehlerhafte Datensätze in die DB geschrieben.

Der Provider hat diese nun korrigiert.

Danke

Gruß

Peer

[xmurrix]

Guten Morgen,

...Fehler wurde gefunden, es lag an den PHP einstellung...

Sehr gut, dass es am Ende geklappt hat. Kannst du der CONTENIDO-Gemeinde auch mitteilen, welche PHP Einstellung das Problem war und wie es gelöst wurde?

Das würde anderen CONTENIDO-Benutzern, die das gleiche Problem haben sollten, unheimlich viel an Arbeit ersparen.

Grüße
xmurrix

[homtata]

Ich komme bei einem Upgrade von 4.9.12 auf 4.10.1 bei HostEurope leider auch nicht weiter. Auf dem Webpack läuft eine mysql 8.0.19 (deren grundsätzliche Verbreitung HostEurope gestoppt hat nach einem Fehler), und trotz aller Anpassungen in der config.php und einer config.local.php hänge ich am Schritt "Systemüberprüfung" mit der Fehlermeldung "MYSQL läuft im strict-Modus", und NICHTS will sich ändern, egal was ich versuche. Ich kann das nicht überspringen, der nächste Schritt wird nicht freigegeben.
Ideen?

[xmurrix]

Hallo homtata,

Ich komme bei einem Upgrade von 4.9.12 auf 4.10.1 bei HostEurope leider auch nicht weiter. Auf dem Webpack läuft eine mysql 8.0.19 (deren grundsätzliche Verbreitung HostEurope gestoppt hat nach einem Fehler), und trotz aller Anpassungen in der config.php und einer config.local.php hänge ich am Schritt "Systemüberprüfung" mit der Fehlermeldung "MYSQL läuft im strict-Modus", und NICHTS will sich ändern, egal was ich versuche. Ich kann das nicht überspringen, der nächste Schritt wird nicht freigegeben.
Ideen?

ich habe mir das Setup noch einmal genauer angesehen, die bisherigen Tipps von mir zur Lösung waren nicht richtig. Da diese Probleme zur Zeit vermehrt auftreten, habe ich mich entschieden, einen eigenen Beitrag dazu zu schreiben:
viewtopic.php?f=115&t=44136

Ich hoffe, dass die Anleitung darin für dich und andere hilfreich sein wird.

Gruß
xmurrix

[rethus]

@xmurrix 4 president!

Thanx.

Die Fehlermeldungen in der errorlog.txt kommen in der Regel durch strikten SQL-Modus des MySQL-Servers.

Das kann man in CONTENIDO wie folgt lösen. Erstelle, falls nicht vorhanden, eine Konfigurationsdatei "data/config/{ENVIRONMENT}/config.local.php" und schreibe folgendes rein:

Code: Alles auswählen

$cfg['db']['connection']['options'] = [
    MYSQLI_INIT_COMMAND => "SET SESSION sql_mode='';"
];

Gruß
xmurrix