Contao Camp 2019 in München - Save the date!
Ergebnis 1 bis 4 von 4

Thema: Contao 4.7 Installation kopieren

  1. #1
    Contao-Urgestein
    Registriert seit
    22.10.2013.
    Beiträge
    7.778
    User beschenken
    Wunschliste

    Standard Contao 4.7 Installation kopieren

    Ich habe gerade eine Kopie einer Contao 4.7 Installation erstellt, die ab morgen eine alte 3.5 Installation ersetzen soll. Dabei ist etwas passiert, was ich nicht verstehe, aber die Kopie sieht erst mal gut aus. Gemacht habe ich Folgendes:

    1. Datenbankbackup mit BackupDB
    2. In einer etwas älteren DB alle Tabellen einer Contao 3.5 Installation gelöscht
    3. Mit phpMyAdmin das DB-Backup importiert
    4. Alle Dateien der bestehenden Contao 4.7 Installation mit rsync -av in ein anderes Unterverzeichnis kopiert
    5. In der Kopie die Datenbankzugangsdaten geändert
    6. Andere Subdomain ins web-Verzeichnis der Kopie geleitet
    7. Contao-Manager der Kopie aufgerufen
    8. Cache gelöscht mit Contao-Manager
    9. Pakete aktualisiert, mehr als 40 Updates
    10. Installtool aufgerufen über Manager.


    Soweit alles erwartungsgemäß verlaufen, aber jetzt bekam ich eine Unmenge an notwendigen Aktualisierungen der Datenbank angezeigt. Ich dachte schon es ist die falsche Datenbank eingebunden, aber war nicht so. Hauptsächlich waren es Änderungen der Collation, drop index aber wohl auch andere Änderungen. Ich weiss es leider nicht mehr genau. Woher kann so etwas kommen? In der Datenbank waren vor dem Import alle Tabellen gelöscht. Von den unerwartet vielen Updates kam es auch nicht, ich habe danach ein Update der Originalinstallation gemacht, danach wurde an der Original-DB nichts geändert vom Installtool. Beides MySQL Datenbanken, keine MariaDB. PHP-Versionen sind identisch identisch (geht bei Webgo eh nicht anders, aber auch im Contao-Manager jeweils gecheckt). Ich verstehe das nicht wirklich. Aber immerhin scheint die Kopie perfekt zu funktionieren.

    Werde heute nachmittag nochmal die Datenbanken vergleichen zwecks Kollation und eventuell auch in der DB der Kopie nochmal alle Tabellen löschen und das Backup nochmal einspielen um zu sehen ob es vielleicht daran liegt.

  2. #2
    Contao-Urgestein Avatar von mlweb
    Registriert seit
    10.07.2011.
    Beiträge
    3.962
    Partner-ID
    7421

    Standard

    War die für die ein DB in der config.yml vielleicht noch was eingetragen wegen nicht vorhandenem innodb_large?
    Für Dinge die man mit html5 und css3 lösen kann, braucht man kein javascript.
    Immer dran denken: Contao-Check zum Testen der Servervoraussetzungen (Contao 2, Contao 3 und Contao 4) und zum Prüfen einer bestehenden Installation (bis Contao 3.5)

  3. #3
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Vienna, Austria
    Beiträge
    20.049
    User beschenken
    Wunschliste

    Standard

    Läuft die Kopie am selben Server wie das Original?

  4. #4
    Contao-Urgestein
    Registriert seit
    22.10.2013.
    Beiträge
    7.778
    User beschenken
    Wunschliste

    Standard

    Zitat Zitat von mlweb Beitrag anzeigen
    War die für die ein DB in der config.yml vielleicht noch was eingetragen wegen nicht vorhandenem innodb_large?
    Nein.
    Zitat Zitat von Spooky Beitrag anzeigen
    Läuft die Kopie am selben Server wie das Original?
    Ja, beide bei Webgo im selben Platin-Paket. Die Datenbank für die Kopie ist allerdings deutlich älter als die des Originals. Die gibt es bestimmt schon seit mehr als einem Jahr. Und sie wurde zuvor von einer Contao 3.5 Installation benutzt. Nach der ganzen Aktion haben beide Datenbanken dieselbe komische Kollation (latin1_swedish_ci?), da scheint man auch nichts daran machen zu können. Alle Tabellen sind aber bei beiden DBs jetzt InnoDB mit Kollation utf8mb4_unicode_ci. Ich spiele mal das Backup des Originals nochmal ein und schaue mir dann die Tabellen an vor Lauf des Installtools, habe da einen leisen Verdacht.

    Edit: Done, Verdacht bestätigt. Nach dem Import des mit BackupDB erstellten Dumps haben die Tabellen eine Kollation utf8mb4_general_ci. Das wird dann wohl vom Installtool in utf8mb4_unicode_ci geändert. Also Installtool gestartet und tatsächlich:

    Code:
    DROP INDEX alias ON tl_article
    DROP INDEX start_stop_published_sorting ON tl_article
    ALTER TABLE tl_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
    ...
    Der von BackupDB erzeugte Dump des Originals dazu sieht so aus:
    Code:
    ... 
    SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
    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 utf8 */;
    
    #---------------------------------------------------------
    # Table structure for table 'tl_article'
    #---------------------------------------------------------
    CREATE TABLE `tl_article` (
      `id` int(10) unsigned NOT NULL auto_increment,
      `pid` int(10) unsigned NOT NULL default '0',
      `sorting` int(10) unsigned NOT NULL default '0',
      `tstamp` int(10) unsigned NOT NULL default '0',
      `title` varchar(255) NOT NULL default '',
      `alias` varchar(128) COLLATE utf8mb4_bin NOT NULL default '',
      `author` int(10) unsigned NOT NULL default '0',
      `inColumn` varchar(32) NOT NULL default '',
      `keywords` mediumtext NULL,
      `showTeaser` char(1) NOT NULL default '',
      `teaserCssID` varchar(255) NOT NULL default '',
      `teaser` mediumtext NULL,
      `printable` varchar(255) NOT NULL default '',
      `cssID` varchar(255) NOT NULL default '',
      `published` char(1) NOT NULL default '',
      `start` varchar(10) NOT NULL default '',
      `stop` varchar(10) NOT NULL default '',
      `protected` char(1) NOT NULL default '',
      `groups` blob NULL,
      `guests` char(1) NOT NULL default '',
      `customTpl` varchar(64) NOT NULL default '',
      PRIMARY KEY  (`id`),
      KEY `alias` (`alias`),
      KEY `pid_start_stop_published_sorting` (`pid`, `start`, `stop`, `published`, `sorting`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=56;
    ...
    Ist das jetzt ein Fehler in BackupDB, der Hosting-Konfiguration oder geht das einfach nicht anders?
    Geändert von tab (15.05.2019 um 13:30 Uhr)

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Lesezeichen

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •