Contao Community Documentation - Benutzerbeiträge [de]

GetTemplateGroup

2020-06-11T10:06:53Z

Samson1964: Code für Contao 2-4

[[Category:Dev HOWTOS]]
[[Category:Dev Snippets]]
{{AppliesTo|TLVersion=ab 2.8|Version=ab 2.9}}
Mit der Methode <nowiki>getTemplateGroup</nowiki> ist es in einem Modul möglich, dem Nutzer im Backend die Auswahl von Templates zu ermöglichen, die im Frontend dann verwendet werden sollen. Damit ist es möglich, eigene Templates zu erstellen und zu verwenden. 
Bis Contao 2.8.4 wurden die Templates im Verzeichnis '''templates''' des Moduls gesucht und anschließend im Verzeichnis '''TL_ROOT/templates'''. 
Ab Contao 2.9 wurde auf Grund des Theme-Managers diese Methode erweitert, damit diese nun auch im Template Verzeichnis des Themes gesucht werden. 
Hier nun beide Varianten kurz erläutert. Beide funktionieren dabei in Contao 2.9, die erste nur bis Contao 2.8.4 

=getTemplateGroup in Contao 2.8.x=
In Contao 2.8.x (und früher) spielt es keine Rolle, an welcher Stelle man die Auswahl für ein Template einbaut, dass muss nicht beim Anlegen des Frontend Moduls sein. 
Beispielsweise wird/wurde im Modul Banner unter dem Punkt Inhalte als erstes eine Kategorie angelegt, in dieser dann kam die Template Auswahl. 
Dem Frontend Modul wurde dann eine Kategorie zugewiesen, über diese konnte das Modul dann das gewählte Template erfahren. 

==Tabellen Angaben==
Zum Abspeichern benötigt man natürlich ein Feld in der jeweiligen Tabelle. Hier ein Auszug aus dem Banner Modul. 
Für die Kategorie: 
<source lang="mysql">
CREATE TABLE `tl_banner_category` (
`id` int(10) unsigned NOT NULL auto_increment,
`tstamp` int(10) unsigned NOT NULL default '0',
...
`banner_template` varchar(32) NOT NULL default '',
...
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
</source>

Für das Frontend Modul in tl_module:
<source lang="mysql">
CREATE TABLE `tl_module` (
...
`banner_categories` varchar(255) NOT NULL default '',
...
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
</source>

Dieses Felder müssen nun über die DCA Datei gesteuert werden.

==DCA Angaben==
In der DCA, hier "tl_banner_category.php", erfolgte nun im Abschnitt "fields" dieser Teil: 
<source lang="php">
'banner_template' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_banner_category']['banner_template'],
'default' => 'mod_banner_list_all',
'exclude' => true,
'inputType' => 'select',
'options' => $this->getTemplateGroup('mod_banner_list_'),
'eval' => array('tl_class'=>'w50')
),
</source>
Hier ist nun ein Select Feld zu sehen, welches als Default das Template "mod_banner_list_all" nimmt. Gesucht werden Templates, welche mit "mod_banner_list_" beginnen und mit ".tpl" enden. Die Endung kann dabei hier nicht angegeben werden. 
In dem Fall wird vom Framework zuerst im Verzeichnis "templates" vom Modul gesucht, anschließend im Verzeichnis "TL_ROOT/templates". Liegen im letzterem Templates mit gleichem Namen werden diese bevorzugt. Damit wurde die Möglichkeit geschaffen, updatesichere Templates auch für Module anzulegen, die keine Auswahlmöglichkeit bieten. 
Der Name wird nach Auswahl und Speicherung in der Datenbank abgelegt und kann nun vom Frontend Modul ausgelesen werden.

Zuvor muss im Frontend Modul natürlich die Kategorie abgelegt werden, dazu auch hier eine DCA Field Angabe: 
<source lang="php">
/**
* Add fields to tl_module
*/
$GLOBALS['TL_DCA']['tl_module']['fields']['banner_categories'] = array
(
'label' => &$GLOBALS['TL_LANG']['tl_module']['banner_categories'],
'exclude' => true,
'inputType' => 'checkbox',
'foreignKey' => 'tl_banner_category.title',
'eval' => array('multiple'=>true, 'mandatory'=>true)
);
</source>
Hier als Checkbox, da es die Möglichkeit geben sollte, mehrere Kategorien zu wählen.

==Frontend Modul==
Das Frontend Modul schaut nun per SQL nach, welches Template verwendet werden soll. Um beim Beispiel Banner Modul zu bleiben: erst wird die Kategorie ermittelt und damit dann das Template. 
Wenn der Name des Templates vom Default abweicht, muss innerhalb der eigenen Methode "compile" das neue Template aktiviert werden. 
Hier mal kurze Code Sequenzen, die das Ganze etwas deutlicher machen sollten. 
<source lang="php">
class ModuleBanner extends Module
{

/**
* Template
* @var string
*/
protected $strTemplate = 'mod_banner_list_all'; // Das Default Template wie in der DCA definiert
....
/**
* Generate module
*/
protected function compile()
{
// Contao legt checkbox Felder als serialisiertes Array ab in der DB (darin die IDs der Kategorien)
$this->arrBannerCategories = deserialize($this->banner_categories, true);

...
$objBanners = $this->Database->prepare("SELECT TLB.id FROM tl_banner AS TLB "
. " LEFT JOIN tl_banner_category ON (tl_banner_category.id=TLB.pid)"
. " WHERE pid IN(" . implode(',', $this->arrBannerCategories) . ")"
// und noch viel mehr, aber hier nicht wichtig :-)
->execute();
...

//Wenn nötig, dann neues Template aktivieren
if (($objBanners->banner_template != $this->strTemplate) && ($objBanners->banner_template != ''))
{
$this->strTemplate = $objBanners->banner_template;
$this->Template = new FrontendTemplate($this->strTemplate);
}

}

}
</source>
So bekommt also das Frontend Modul über einige Ecken den Namen des Templates.

Natürlich kann man die Template Auswahl direkt im Frontend Modul machen. Das und die Änderung für Contao 2.9 zeigt der nächste Abschnitt.

=getTemplateGroup in Contao 2.9.x=
In Contao 2.9 ist es möglich in der Theme Konfiguration ein eigenes Template Verzeichnis zu definieren. Technisch gesehen ist es ein Unterverzeichnis von "TL_ROOT/templates". Da diese Templates sich auf das Theme beziehen, muss auch die Auswahl innerhalb eines ermittelbaren Themes erfolgen. Am einfachsten gehts das direkt im Frontend Modul. (Diese werden ja nun innerhalb eines Themes angelegt)

==Tabellen Angaben==
Hierzu braucht nur im Modul ein Feld angelegt werden. 
<source lang="mysql">
--
-- Table `tl_module`
--
CREATE TABLE `tl_module` (
`banner_template` varchar(32) NOT NULL default '',
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
</source>

==DCA Angaben==
In der DCA, hier "tl_module.php", erfolgte nun im Abschnitt "fields" dieser Teil: 
<source lang="php">
$GLOBALS['TL_DCA']['tl_module']['fields']['banner_template'] = array
(
'label' => &$GLOBALS['TL_LANG']['tl_module']['banner_template'],
'default' => 'mod_banner_list_all',
'exclude' => true,
'inputType' => 'select',
//'options' => $this->getTemplateGroup('mod_banner_list_'), // Das wäre die alte Variante
'options_callback' => array('tl_module_banner', 'getBannerTemplates')
);
</source>
Die alte Variante (hier auskommentiert) ist hier auch dargestellt, welche wie oben beschrieben funktionieren würde. 
Bei der neuen Variante ist zu sehen, dass ein "options_callback" nötig ist. Grund ist, dass die Methode "getTemplateGroup" einen optionalen zweiten Parameter neuerdings versteht. Dieser Parameter ist die Theme-ID. Da diese aber hier nicht zur Verfügung steht, holt man sich diese per callback: 
<source lang="php">
class tl_module_banner extends Backend
{
/**
* Template over theme id
*/
public function getBannerTemplates(DataContainer $dc)
{
if (version_compare(VERSION.BUILD, '2.9.0', '>=')) {
return $this->getTemplateGroup('mod_banner_list_', $dc->activeRecord->pid);
} else {
return $this->getTemplateGroup('mod_banner_list_');
}
}
}
</source>
Hier wieder zu sehen, beginnt die Suche nach Templates mit "mod_banner_list_". Hier wird nun in folgender Reihenfolge gesucht:
# Verzeichnis templates des Moduls
# Verzeichnis TL_ROOT/templates (nicht rekursiv!)
# Im Template Verzeichnis des Themes, z.b. TL_ROOT/templates/mein_theme/meine_templates
{{Achtung|Werden gleichnamige Template Dateien gefunden, wird nur das zuletzt gefundene angezeigt bezogen auf die oben gezeigten Reihenfolge. Das Theme Verzeichnis hat also die höchste Priorität.}}

Im obigen Beispiel wurde noch ein Versionsvergleich eingebaut. Somit arbeitet diese Methode sowohl in Contao 2.8 als auch in Contao 2.9.

==Frontend Modul==
Das Frontend Modul bekommt hier durch das Framework die Felder aus tl_module automatisch, dazu braucht es also keine SQL Abfrage. Daher verkürzt sich die Sache sehr. 
Hier mal kurze Code Sequenzen, die das Ganze etwas deutlicher machen sollten. 
<source lang="php">
class ModuleBanner extends Module
{
/**
* Template
* @var string
*/
protected $strTemplate = 'mod_banner_list_all'; // Default wie in DCA definiert

/**
* Generate module
*/
protected function compile()
{
....
if (($this->banner_template != $this->strTemplate) && ($this->banner_template != ''))
{
$this->strTemplate = $this->banner_template;
$this->Template = new FrontendTemplate($this->strTemplate);
}
....
}
}
</source>

=getTemplateGroup ab Contao 4.8 (abwärtskompatibel)=
<source lang="php">
public function getTemplates($dc)
{
if(version_compare(VERSION.BUILD, '2.9.0', '>=') && version_compare(VERSION.BUILD, '4.8.0', '<'))
{
// Den 2. Parameter gibt es nur ab Contao 2.9 bis 4.7
return $this->getTemplateGroup('mail_trainerlizenzen_', $dc->activeRecord->id);
}
else
{
// Ohne 2. Parameter bis Contao 2.8 und ab Contao 4.8
return $this->getTemplateGroup('mail_trainerlizenzen_');
}
}
</source>

=getTemplateGroup in Contao 2.9.x und CE=
Bei Content Elementen in Artikel sieht das Ganze wieder komplizierter aus. Das Grundprinzip ist aber das gleiche. Es wird über Artikel und Seitenstruktur ermittelt, in welchem Theme sich dieses CE befindet und mit der Theme ID wird dann wie bei der Modul Variante wieder nach Templates gesucht. 

Hier beispielsweise ein Auszug aus dem DCA der Contao-internen Galerie:

<source lang="php">
public function getGalleryTemplates(DataContainer $dc)
{
// Ermitteln der Seiten ID
$objArticle = $this->Database->prepare("SELECT pid FROM tl_article WHERE id=?")
->limit(1)
->execute($dc->activeRecord->pid);

// Vererbung der Seiteneigenschaften
$objPage = $this->getPageDetails($objArticle->pid);

// Ermitteln der Theme ID
$objLayout = $this->Database->prepare("SELECT pid FROM tl_layout WHERE id=?")
->limit(1)
->execute($objPage->layout);

// Alle verfügbaren Galerie-Templates anzeigen
return $this->getTemplateGroup('gallery_', $objLayout->pid);
}
</source>

----
--[[Benutzer:BugBuster|BugBuster]] 14:23, 15. Jul. 2010 (CEST)

Datenbank Klasse verwenden

2019-08-20T09:42:37Z

Samson1964: /* Datensätze lesen */

{{stub}}

= Informationen zur Datenbank-Klasse =

Contao bietet für Entwickler eine Klasse an, um mit der Datenbank zu kommunizieren. Diese sollte beim Entwickeln von Erweiterungen unbedingt verwendet werden!

* [http://api.contao.org/Library/_libraries---Database.php.html Dokumentation der Klasse]

Die Datenbank-Klasse bietet mehrere Vorteile:
* Die Daten werden "gesäubert" und störende Zeichen maskiert
* Ein Objekt der Klasse Database_Result wird zurückgegeben. Dieses enthält alle Informationen zum Query
* Ersparnis von Schreibarbeit

= Operationen auf der Datenbank =

Die Beispiele setzen voraus, dass zuvor das Datenbank-Modul geladen wurde:

<source lang="php">
$this->import('Database');
</source>

== Datensätze lesen ==

'''Lesen von Datensätzen ohne Bedingung'''

<source lang="php">
$result = $this->Database->prepare("SELECT * FROM tl_log")->execute();
</source>

'''Ausgeben der Datensätze'''

<source lang="php">
echo $result->numRows; // Anzahl der gefundenen Datensätze ausgeben
echo $result->id; // ID des 1. Datensatzes ausgeben
// Und alle anderen ID's ausgeben
while($result->next())
{
echo $result->id;
}
</source>

'''Lesen von Datensätzen mit Bedingung'''

<source lang="php">
$result = $this->Database->prepare("SELECT * FROM tl_log WHERE id=?")->execute(1);
$result = $this->Database->prepare("SELECT * FROM tl_log WHERE id=? OR id=?")->execute(1, 5);
</source>

Die Fragezeichen sind Wildcards. Sie werden der Reihenfolge nach von den Parametern der execute-Funktion ersetzt. Dabei werden die parameter escaped, also für die Datenbank aufbereitet.
Das schützt allerdings '''nicht''' vor boshaften Benutzereingaben. Diese sollten immer mit der Input-Klasse verarbeitet werden!

'''Lesen von Datensätzen mit Limit'''

<source lang="php">
$result = $this->Database->prepare("SELECT * FROM tl_log")->limit(30)->execute();
$result = $this->Database->prepare("SELECT * FROM tl_log")->limit(30, 40)->execute();
</source>

Das erste Beispiel liest die (ersten) 30 Datensätze, die mit der Suchbedingung (hier alle Datensätze) übereinstimmen. Das zweite Beispiel liest die 30 Datensätze ab Datensatz Nr. 40.

== Datensätze schreiben ==

Datensätze können auch über die Datenbank-Klasse geschrieben werden. Es gibt dafür zwei Möglichkeiten.

'''Einzelne Werte per Wildcard setzten'''

<source lng="php">
$this->Database->prepare("UPDATE tl_log SET source = ? WHERE id=?")->execute('BE', 12345);
</source>

'''Mehrere Werte per set-Methode setzten'''
<source lng="php">
$set = array('tstamp' => time(), 'source' => 'BE', 'action' => 'GENERAL');
$this->Database->prepare("UPDATE tl_log %s WHERE id=?")->set($set)->execute(12345);
</source>

Diese Methode funktioniert natürlich auch mit einem INSERT-Statement. Hier das Beispiel, wo Sie anschließend auch gleich die ID des neuen Datensatzes bekommen:

<source lng="php">
$set = array('tstamp' => time(), 'source' => 'BE', 'action' => 'GENERAL');
$objInsert = $this->Database->prepare("INSERT INTO tl_log %s")->set($set)->execute();
echo $objInsert->insertId;
</source>

== Das Ergebnis auswerten ==

= Tipps & Tricks =
* [[SQL Like Abfrage in doppelten Prozentzeichen]]

[[Category:Dev HOWTOS]]

Benutzer:Samson1964/URL's generieren

2018-08-18T17:39:04Z

Samson1964: /* Funktion addToUrl */

Für eigene Erweiterungen stellt der Core folgende Funktionen zur Verfügung:

= Funktion addToUrl =

Als aktuelle Seite wird in allen Beispielen eine Seite mit dem Alias '''test''' angenommen.

== Variante 1 ==

<source lang="php">
$this->addToUrl('foo=bar');
</source>

Vor Contao 3.2.8 war das Ergebnis: '''test.html?foo=bar''' 
Seit Contao 3.2.8 ist das Ergebnis: '''test/foo/bar.html''' 
Siehe dazu auch [https://github.com/contao/core/issues/6736 github.com/contao/core/issues/6736].

Die bessere Schreibweise ab Contao 3.5 ist

<source lang="php">
\Frontend::addToUrl('foo=bar');
</source>

Benutzer:Samson1964/URL's generieren

2018-08-18T17:34:20Z

Samson1964: Die Seite wurde neu angelegt: „Für eigene Erweiterungen stellt der Core folgende Funktionen zur Verfügung: = Funktion addToUrl = Als aktuelle Seite wird in allen Beispielen eine Seite mi…“

Für eigene Erweiterungen stellt der Core folgende Funktionen zur Verfügung:

= Funktion addToUrl =

Als aktuelle Seite wird in allen Beispielen eine Seite mit dem Alias '''test''' angenommen.

== Variante 1 ==

<source lang="php">
$this->addToUrl('foo=bar');
</source>

Vor Contao 3.2.8 war das Ergebnis: '''test.html?foo=bar'''
Seit Contao 3.2.8 ist das Ergebnis: '''test/foo/bar.html'''
Siehe dazu auch [https://github.com/contao/core/issues/6736].

Benutzer:Samson1964

2018-08-18T17:24:57Z

Samson1964:

'''Nick:''' Samson1964 
'''Realer Name:''' Frank Hoppe 
'''Geburtstag:''' 19.09.1964 
'''Wohnort:''' Berlin 
'''Arbeit''': Angestellter 
'''Tätigkeit:''' Webmaster beim [http://www.schachbund.de/ Deutschen Schachbund] 
'''Hobbies:''' Programmieren (BASIC, Perl, PHP, C, CSS, HTML), Schach, Fotografieren 
'''Private Website:''' [http://www.schachbulle.de/ Schachbulle] 
'''Websites als Webmaster:''' [https://www.schachbund.de/ Deutscher Schachbund], [https://www.berlinerschachverband.de Berliner Schachverband] 
'''Bisher benutzte CMS:''' [http://www.phpcms.de/ phpCMS], [http://wpde.org/ WordPress], [http://mozilo.de/ moziloCMS], [http://www.joomla.de/ Joomla!], Limbo, [http://pivotx.net/ PivotX], Contao und testweise [http://www.drupal.de/ Drupal] 
'''Forum:''' [https://community.contao.org/de/member.php?10642-Samson1964 Samson1964]

Ich benutze Contao seit Mai 2013 und will damit die neue Webpräsenz des Deutschen Schachbundes umsetzen. Bisher setze ich hier auf das altbewährte phpCMS und PivotX - beides ohne MySQL-Datenbank.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-11-08T14:19:56Z

Samson1964: /* Anpassung von C3-Erweiterungen auf die C4-Umgebung */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 und PHP 7 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache eines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Kopieren von system/modules ==

Für jede der Erweiterungen in diesem Verzeichnis von Contao 3 habe ich über Google auf packagist.org entsprechende Bundles gesucht. Da bei Domainfactory die Installation eines solchen Bundles mit dem Contao Manager nicht möglich ist, mußte ich immer auf die Shell ausweichen. Der Befehl muß natürlich im Ordner web ausgeführt werden, wo die Datei contao-manager.phar.php gespeichert ist.
<source lang="php">
php contao-manager.phar.php composer require BUNDLENAME
</source>
Bei der Installation mußte ich auf diverse Fehlermeldungen reagieren:
* Bundle nicht kompatibel mit Contao 4 -> einfach die C3-Erweiterung nach system/modules kopieren
* Bundle kann erforderliche externe Bundles nicht installieren -> C3-Erweiterung in system/modules von Contao 4 löschen, danach Installation wiederholen
* Bundle craffft/contao-calendar-ical-bundle läßt sich nicht installieren -> "dev-master" im Shell-Aufruf anhängen (mit den Hochkommata!)
Den zweiten Fall bekam ich bei der Installation von terminal42/contao-leads auf den Monitor. Da ich vorher bereits die Erweiterungen Haste und multicolumnwizard aus meiner C3-Installation nach system/modules kopiert hatte, wollte der Composer die C4-Bundles von Haste und multicolumnwizard nicht installieren.

Nach jeder Installation bzw. jedem Kopiervorgang leerte ich den Cache und erstellte die Symlinks neu, um danach zu überprüfen, ob insbesondere die C3-Erweiterungen funktionieren. Fehlermeldungen im Zusammenhang mit der PHP7-Kompatibilität konnte sofort beseitigen, die schwierigeren Fälle hob ich mir für später auf.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

= Anpassung von C3-Erweiterungen auf die C4-Umgebung =

Weiterleitungen auf die main.php funktionieren in Contao 4 nicht mehr:
<source lang="php">
$backlink = 'main.php?do=erweiterung&act=edit&id='.$id.'&rt='.REQUEST_TOKEN;
header('Location:'.$backlink);
</source>

== Erweiterung [timelinejs] ==

Für diese Erweiterung gibt es kein C4-Bundle. Ich kopierte deshalb die C3-Version in meine C4-Installation, doch die Erweiterung lief weder im FE noch im BE. Ursache waren die fehlenden Abhängigkeiten [dca_rules] und [metapalettes]. Von letzterer Erweiterung gibt es ein C4-Bundle, das sich aber über die Shell nicht installieren ließ - ganz am Ende, als schon ich auf die Erfolgsmeldung wartete, kam ein Timeout. Ich habe deshalb von beiden Erweiterungen die C3-Versionen kopiert.

== Erweiterung [chronik] ==

Das ist eine selbstprogrammierte Erweiterung zur Verwaltung von historischen Ereignissen. Im FE bekam ich einen 404-Fehler. Ursache ist ein Fehler in meiner URL-Umschreibung. Insbesondere komme ich hier mit dem Developer-Modus noch nicht klar. Im Contao-Forum gibt es hierzu ein [https://community.contao.org/de/showthread.php?68635-Strukturierte-URL-s-mit-app_dev Thema].

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-11-08T05:52:39Z

Samson1964: /* Kopieren von system/modules */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-11-08T05:52:03Z

Samson1964: /* Kopieren von fehlenden Dateien */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 und PHP 7 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache eines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Kopieren von system/modules ==

Für jede der Erweiterungen in diesem Verzeichnis von Contao 3 habe ich über Google auf packagist.org entsprechende Bundles gesucht. Da bei Domainfactory die Installation eines solchen Bundles nicht möglich ist, mußte ich immer auf die Shell ausweichen. Der Befehl muß natürlich im Ordner web ausgeführt werden, wo die Datei contao-manager.phar.php gespeichert ist.
<source lang="php">
php contao-manager.phar.php composer require BUNDLENAME
</source>
Bei der Installation mußte ich auf diverse Fehlermeldungen reagieren:
* Bundle nicht kompatibel mit Contao 4 -> einfach die C3-Erweiterung nach system/modules kopieren
* Bundle kann erforderliche externe Bundles nicht installieren -> C3-Erweiterung in system/modules von Contao 4 löschen, danach Installation wiederholen
* Bundle craffft/contao-calendar-ical-bundle läßt sich nicht installieren -> "dev-master" im Shell-Aufruf anhängen (mit den Hochkommata!)
Den zweiten Fall bekam ich bei der Installation von terminal42/contao-leads auf den Monitor. Da ich vorher bereits die Erweiterungen Haste und multicolumnwizard aus meiner C3-Installation nach system/modules kopiert hatte, wollte der Composer die C4-Bundles von Haste und multicolumnwizard nicht installieren.

Nach jeder Installation bzw. jedem Kopiervorgang leerte ich den Cache und erstellte die Symlinks neu, um danach zu überprüfen, ob insbesondere die C3-Erweiterungen funktionieren. Fehlermeldungen im Zusammenhang mit der PHP7-Kompatibilität konnte sofort beseitigen, die schwierigeren Fälle hob ich mir für später auf.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

= Anpassung von C3-Erweiterungen auf die C4-Umgebung =

Weiterleitungen auf die main.php funktionieren in Contao 4 nicht mehr:
<source lang="php">
$backlink = 'main.php?do=erweiterung&act=edit&id='.$id.'&rt='.REQUEST_TOKEN;
header('Location:'.$backlink);
</source>

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-11-08T05:49:38Z

Samson1964: /* Datenbestand */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 und PHP 7 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Kopieren von system/modules ==

Für jede der Erweiterungen in diesem Verzeichnis von Contao 3 habe ich über Google auf packagist.org entsprechende Bundles gesucht. Da bei Domainfactory die Installation eines solchen Bundles nicht möglich ist, mußte ich immer auf die Shell ausweichen. Der Befehl muß natürlich im Ordner web ausgeführt werden, wo die Datei contao-manager.phar.php gespeichert ist.
<source lang="php">
php contao-manager.phar.php composer require BUNDLENAME
</source>
Bei der Installation mußte ich auf diverse Fehlermeldungen reagieren:
* Bundle nicht kompatibel mit Contao 4 -> einfach die C3-Erweiterung nach system/modules kopieren
* Bundle kann erforderliche externe Bundles nicht installieren -> C3-Erweiterung in system/modules von Contao 4 löschen, danach Installation wiederholen
* Bundle craffft/contao-calendar-ical-bundle läßt sich nicht installieren -> "dev-master" im Shell-Aufruf anhängen (mit den Hochkommata!)
Den zweiten Fall bekam ich bei der Installation von terminal42/contao-leads auf den Monitor. Da ich vorher bereits die Erweiterungen Haste und multicolumnwizard aus meiner C3-Installation nach system/modules kopiert hatte, wollte der Composer die C4-Bundles von Haste und multicolumnwizard nicht installieren.

Nach jeder Installation bzw. jedem Kopiervorgang leerte ich den Cache und erstellte die Symlinks neu, um danach zu überprüfen, ob insbesondere die C3-Erweiterungen funktionieren. Fehlermeldungen im Zusammenhang mit der PHP7-Kompatibilität konnte sofort beseitigen, die schwierigeren Fälle hob ich mir für später auf.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

= Anpassung von C3-Erweiterungen auf die C4-Umgebung =

Weiterleitungen auf die main.php funktionieren in Contao 4 nicht mehr:
<source lang="php">
$backlink = 'main.php?do=erweiterung&act=edit&id='.$id.'&rt='.REQUEST_TOKEN;
header('Location:'.$backlink);
</source>

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-30T16:29:13Z

Samson1964: /* Installation von C4-Erweiterungen */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Kopieren von system/modules ==

Für jede der Erweiterungen in diesem Verzeichnis von Contao 3 habe ich über Google auf packagist.org entsprechende Bundles gesucht. Da bei Domainfactory die Installation eines solchen Bundles nicht möglich ist, mußte ich immer auf die Shell ausweichen. Der Befehl muß natürlich im Ordner web ausgeführt werden, wo die Datei contao-manager.phar.php gespeichert ist.
<source lang="php">
php contao-manager.phar.php composer require BUNDLENAME
</source>
Bei der Installation mußte ich auf diverse Fehlermeldungen reagieren:
* Bundle nicht kompatibel mit Contao 4 -> einfach die C3-Erweiterung nach system/modules kopieren
* Bundle kann erforderliche externe Bundles nicht installieren -> C3-Erweiterung in system/modules von Contao 4 löschen, danach Installation wiederholen
* Bundle craffft/contao-calendar-ical-bundle läßt sich nicht installieren -> "dev-master" im Shell-Aufruf anhängen (mit den Hochkommata!)
Den zweiten Fall bekam ich bei der Installation von terminal42/contao-leads auf den Monitor. Da ich vorher bereits die Erweiterungen Haste und multicolumnwizard aus meiner C3-Installation nach system/modules kopiert hatte, wollte der Composer die C4-Bundles von Haste und multicolumnwizard nicht installieren.

Nach jeder Installation bzw. jedem Kopiervorgang leerte ich den Cache und erstellte die Symlinks neu, um danach zu überprüfen, ob insbesondere die C3-Erweiterungen funktionieren. Fehlermeldungen im Zusammenhang mit der PHP7-Kompatibilität konnte sofort beseitigen, die schwierigeren Fälle hob ich mir für später auf.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

= Anpassung von C3-Erweiterungen auf die C4-Umgebung =

Weiterleitungen auf die main.php funktionieren in Contao 4 nicht mehr:
<source lang="php">
$backlink = 'main.php?do=erweiterung&act=edit&id='.$id.'&rt='.REQUEST_TOKEN;
header('Location:'.$backlink);
</source>

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-30T15:24:52Z

Samson1964: /* Kopieren von system/modules */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Kopieren von system/modules ==

Für jede der Erweiterungen in diesem Verzeichnis von Contao 3 habe ich über Google auf packagist.org entsprechende Bundles gesucht. Da bei Domainfactory die Installation eines solchen Bundles nicht möglich ist, mußte ich immer auf die Shell ausweichen. Der Befehl muß natürlich im Ordner web ausgeführt werden, wo die Datei contao-manager.phar.php gespeichert ist.
<source lang="php">
php contao-manager.phar.php composer require BUNDLENAME
</source>
Bei der Installation mußte ich auf diverse Fehlermeldungen reagieren:
* Bundle nicht kompatibel mit Contao 4 -> einfach die C3-Erweiterung nach system/modules kopieren
* Bundle kann erforderliche externe Bundles nicht installieren -> C3-Erweiterung in system/modules von Contao 4 löschen, danach Installation wiederholen
* Bundle craffft/contao-calendar-ical-bundle läßt sich nicht installieren -> "dev-master" im Shell-Aufruf anhängen (mit den Hochkommata!)
Den zweiten Fall bekam ich bei der Installation von terminal42/contao-leads auf den Monitor. Da ich vorher bereits die Erweiterungen Haste und multicolumnwizard aus meiner C3-Installation nach system/modules kopiert hatte, wollte der Composer die C4-Bundles von Haste und multicolumnwizard nicht installieren.

Nach jeder Installation bzw. jedem Kopiervorgang leerte ich den Cache und erstellte die Symlinks neu, um danach zu überprüfen, ob insbesondere die C3-Erweiterungen funktionieren. Fehlermeldungen im Zusammenhang mit der PHP7-Kompatibilität konnte sofort beseitigen, die schwierigeren Fälle hob ich mir für später auf.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-30T15:20:35Z

Samson1964: /* Kopieren von system/modules */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Kopieren von system/modules ==

Für jede der Erweiterungen in diesem Verzeichnis von Contao 3 habe ich über Google auf packagist.org entsprechende Bundles gesucht. Da bei Domainfactory die Installation eines solchen Bundles nicht möglich ist, mußte ich immer auf die Shell ausweichen. Der Befehl muß natürlich im Ordner web ausgeführt werden, wo die Datei contao-manager.phar.php gespeichert ist.
<source lang="php">
php contao-manager.phar.php composer require BUNDLENAME
</source>
Bei der Installation mußte ich auf diverse Fehlermeldungen reagieren:
* Bundle nicht kompatibel mit Contao 4 -> einfach die C3-Erweiterung nach system/modules kopieren
* Bundle kann erforderliche externe Bundles nicht installieren -> C3-Erweiterung in system/modules von Contao 4 löschen, danach Installation wiederholen
* Bundle craffft/contao-calendar-ical-bundle läßt sich nicht installieren -> "dev-master" im Shell-Aufruf anhängen (mit den Hochkommata!)
Den zweiten Fall bekam ich bei der Installation von terminal42/contao-leads auf den Monitor. Da ich vorher bereits die Erweiterungen Haste und multicolumnwizard aus meiner C3-Installation nach system/modules kopiert hatte, wollte der Composer die C4-Bundles von Haste und multicolumnwizard nicht installieren.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-30T15:20:10Z

Samson1964: /* Kopieren von system/modules */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Kopieren von system/modules ==

Für jede der Erweiterungen in diesem Verzeichnis von Contao 3 habe ich über Google auf packagist.org entsprechende Bundles gesucht. Da bei Domainfactory die Installation eines solchen Bundles nicht möglich ist, mußte ich immer auf die Shell ausweichen. Der Befehl muß natürlich im Ordner web ausgeführt werden, wo die Datei contao-manager.phar.php gespeichert ist.
<source lang="php">
php contao-manager.phar.php composer require PAKETNAME
</source>
Bei der Installation mußte ich auf diverse Fehlermeldungen reagieren:
* Bundle nicht kompatibel mit Contao 4 -> einfach die C3-Erweiterung nach system/modules kopieren
* Bundle kann erforderliche externe Bundles nicht installieren -> C3-Erweiterung in system/modules von Contao 4 löschen, danach Installation wiederholen
* Bundle craffft/contao-calendar-ical-bundle läßt sich nicht installieren -> "dev-master" im Shell-Aufruf anhängen (mit den Hochkommata!)
Den zweiten Fall bekam ich bei der Installation von terminal42/contao-leads auf den Monitor. Da ich vorher bereits die Erweiterungen Haste und multicolumnwizard aus meiner C3-Installation nach system/modules kopiert hatte, wollte der Composer die C4-Bundles von Haste und multicolumnwizard nicht installieren.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-30T15:15:42Z

Samson1964: /* Kopieren von system/modules */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Kopieren von system/modules ==

Für jede der Erweiterungen in diesem Verzeichnis von Contao 3 habe ich über Google auf packagist.org entsprechende Bundles gesucht. Da bei Domainfactory die Installation eines solchen Bundles nicht möglich ist, mußte ich immer auf die Shell ausweichen. Der Befehl muß natürlich im Ordner web ausgeführt werden, wo die Datei contao-manager.phar.php gespeichert ist.
<source lang="php">
php contao-manager.phar.php composer require PAKETNAME
</source>
Bei der Installation mußte ich auf diverse Fehlermeldungen reagieren:
* Bundle nicht kompatibel mit Contao 4 -> einfach die C3-Erweiterung nach system/modules kopieren
* Bundle kann erforderliche externe Bundles nicht installieren -> C3-Erweiterung in system/modules von Contao 4 löschen, danach Installation wiederholen
* Bundle craffft/contao-calendar-ical-bundle läßt sich nicht installieren -> "dev-master" im Shell-Aufruf anhängen (mit den Hochkommata!)

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-30T15:05:18Z

Samson1964: /* Migration */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Kopieren von system/modules ==

Für jede der Erweiterungen in diesem Verzeichnis von Contao 3 habe ich über Google auf packagist.org entsprechende Bundles gesucht. Da bei Domainfactory die Installation eines solchen Bundles nicht möglich ist, mußte ich immer auf die Shell ausweichen.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-23T17:57:13Z

Samson1964: /* CSS-Dateien von Erweiterungen werden nicht gefunden */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Schuld ist wahrscheinlich ein nichtgenerierter Symlink. Hier hilft ein Aufruf von "Symlinks neu erstellen" in der Systemwartung im C4-Backend. Siehe dazu auch: [https://www.marcosimbuerger.ch/contao-kurzanleitungen-details/contao-3-erweiterung-in-contao-4-installieren.html Contao 3 Erweiterung in Contao 4 installieren]

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-23T17:39:39Z

Samson1964: /* Cache löschen */

{{stub}}
[[Category:Installation und Updates]]

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<source lang="php">
mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]
</source>

Import einer MySQL-Datenbank:
<source lang="php">
mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]
</source>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Migration =

Auf das Kopieren der Dateien aus system/modules hatte ich vorerst verzichtet. Stattdessen nutze ich den Debugmodus (app_dev.php) und arbeite dort die schweren Fehler ab. Erweiterungen, wo es C4-Versionen gibt, stalliere ich über die Shell. Wo es nicht klappt - bei simple_columns kommt vom Composer eine Fehlermeldung, weil die Version nicht paßt - kopiere ich aus system/modules die Erweiterung.

Da ich auch im assets-Ordner mehrere eigene Dateien gespeichert habe, kopierte ich auch diese in den assets-Ordner von C4.

== Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... ==

Alle Erweiterungen und ggfs. auch die Templates sollten auf das Benutzen der String-Klasse von Contao überprüft werden. Die Aufrufe der String-Klasse müssen durch StringUtil ersetzt werden.

== CSS-Dateien von Erweiterungen werden nicht gefunden ==

Trotz Cacheleeren will der Server partout keine CSS-Dateien aus public-Verzeichnissen o.ä. von Erweiterungen laden. Es kommt immer eine 404-Fehlermeldung. Liegt es an nicht richtigen Symlinks?

= Debugmodus =

Im Gegensatz zu C3 läßt sich der Debugmodus nicht mehr im Backend aktivieren. In C4 wird der Debugmodus über die app_dev.php aufgerufen. Glen Langer (BugBuster) hat dazu eine kleine [https://contao.ninja/contao-4-login-fuer-app_dev-php-setzen.html Anleitung] online gestellt, da der Zugang zu app_dev.php geschützt ist. Der dort angegebene Befehl
<source lang="php">
php vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD
</source>
muß im Root der Contao-Installation ausgeführt werden!

= Cache löschen =

In C3 mußte man dazu in die System-Einstellungen gehen und den Cache deaktivieren. In C4 muß der Cache manuell geleert werden. Das geht mit verschiedenen Befehlen über die Shell:
<source lang="php">
php app/console cache:clear --env=prod --no-debug
php app/console cache:clear --env=dev --no-debug
php bin/console cache:clear --env=prod --no-debug
php vendor/bin/contao-console cache:clear --env=dev --no-debug
</source>
Welcher Befehl der richtige ist, hängt von der verwendeten Version ab: Managed Edition oder Standard Edition.

Man kann natürlich die Ordner unter var/cache per FTP o.ä. auch direkt löschen.

Eine interessante Variante habe ich auf [http://forum.premium-contao-themes.com/forum/customelements-vorlagen-pool-aa/7882-contao-4-4-internen-prod-cache-leeren-beim-laden dieser Webseite] gefunden:
<source lang="php">
\Files::getInstance()->rrdir('var/cache/prod', true);
</source>
soll in die system/config/initconfig.php eingetragen werden. Dann wird bei jedem Laden der Seite der produktive Cache gelöscht.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

== Shell-Installation ==

Einige Beispielaufrufe:
<source lang="php">
php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
php contao-manager.phar.php composer require contao-legacy/simple_columns
php contao-manager.phar.php composer update derhaeuptling/contao-mega-menu
php contao-manager.phar.php composer update contao/core-bundle
php contao-manager.phar.php composer require bugbuster/contao-banner-bundle
</source>

Bitte dabei beachten:
* Der Aliasaufruf "php" am Anfang funktioniert nur, weil ich dieses Alias mit PHP 5.6 verknüpft habe. Standardmäßig ist "php" mit PHP 4.4.9 verknüft.
* Der Befehl muß im web-Verzeichnis ausgeführt werden.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-23T17:34:37Z

Samson1964: /* Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T18:45:34Z

Samson1964: /* Cache löschen */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T18:45:09Z

Samson1964: /* Debugmodus */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T18:39:17Z

Samson1964: /* Migration */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T09:18:11Z

Samson1964: /* Debugmodus */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T09:14:31Z

Samson1964: /* Fehlermeldung: Fatal error: Cannot use 'String' as class name as it is reserved ... */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:55:55Z

Samson1964: /* Shell-Installation */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:55:29Z

Samson1964: /* Installation von C4-Erweiterungen */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:44:15Z

Samson1964: /* Migration */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:39:48Z

Samson1964: /* Vorbereitung Datenbank */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:37:04Z

Samson1964:

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:15:27Z

Samson1964: /* Vorbereitung Datenbank */

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:12:53Z

Samson1964: Samson1964 verschob die Seite Benutzer:Samson1964/Migration Contao 3 zu 4 nach Installation Contao 4 und Migration Contao 3 bei Domainfactory: Neu erstellt

Benutzer:Samson1964/Migration Contao 3 zu 4

2017-10-22T08:12:53Z

Samson1964: Samson1964 verschob die Seite Benutzer:Samson1964/Migration Contao 3 zu 4 nach Installation Contao 4 und Migration Contao 3 bei Domainfactory: Neu erstellt

#WEITERLEITUNG [[Installation Contao 4 und Migration Contao 3 bei Domainfactory]]

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:11:49Z

Samson1964:

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:10:08Z

Samson1964: /* Installation von C4-Erweiterungen */

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<code>mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]</code>

Import einer MySQL-Datenbank:
<code>mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]</code>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung ab. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T08:09:20Z

Samson1964:

= Migration einer umfangreichen Contao-3.5-Installation zu Contao 4.4 =

Umziehen soll die sehr umfangreiche Installation des Deutschen Schachbundes mit mehreren Subdomains. Ausgangspunkt ist Contao 3.5 mit PHP 5.6. Ziel ist Contao 4.4 mit PHP 7.1, alles auf einem ManagedServer bei Domainfactory.

== Datenbestand ==

Die Datenbank enthält über 8 Millionen Datensätze, darunter Daten von zahlreichen selbstprogrammierten Erweiterungen, die alle noch nicht mit C4 getestet wurden. Die Multidomaininstallation umfaßt 5 Subdomains mit über 1.600 Seiten und über 13.000 Nachrichten, um nur einige Eckdaten zu nennen. Die Datenbank ist insgesamt etwa 1,6 GB groß.

== Systemvoraussetzungen für Contao 4 ==

Standardmäßig funktioniert die Installation von C4 bei Domainfactory nicht, egal in welchem Tarif man sich befindet. Benutzer mit Shell- und php.ini-Zugriff können ihren Webspace allerdings auf so eine Installation vorbereiten. Dazu gehören:

* Aktivierung der intl-Erweiterung durch Benutzung von PHP Extended. PHP in der Standardedition ist unbrauchbar für C4. Die intl-Erweiterung wird von Symfony benötigt, ohne das Contao nicht läuft.
* Umstellung der Konsole von PHP 4.4.9 auf mindestens PHP 5.6. Das ist nötig um Composer ausführen zu können.
* Erhöhung von memory_limit in der php.ini auf einen Wert von mindestens 1,5 bis 2 GB. Das ist nötig um Composer ausführen zu können.

== Vorbereitung Webspace ==

Es mußte ein leeres Verzeichnis, z.B. webseiten/contao4 angelegt werden und darin ein Verzeichnis web. Auf das Verzeichnis webseiten/contao4/web mußte eine (Sub-)Domain geroutet werden. Per FTP kann danach in das Verzeichnis webseiten/contao4/web die Datei contao-manager.phar hochgeladen werden. Um diese aufrufen zu können, muß die Endung php an diese Datei angehangen werden.

== Vorbereitung Datenbank ==

Ein Backup der Datenbank über phpMyAdmin ist aufgrund der Größe unmöglich. Mit dem MySQLDumper ist es zwar machbar, mir aber zuletzt nicht gelungen. Mittendrin bot mir der Browser die aufgerufene PHP-Datei zum Download an. Offensichtlich hatte sich der Server bei der Interpretierung von PHP-Dateien vertan. Über die Shell hat es schließlich geklappt:

Export einer MySQL-Datenbank:
<code>mysqldump [Datenbankname] -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 > [Datei]</code>

Import einer MySQL-Datenbank:
<code>mysql -u[Datenbank-Benutzer] -p[Datenbank-Passwort] --default-character-set=utf8 [Datenbankname] < [Datei]</code>

Wichtig dabei ist die Angabe des Zeichensatzes! Sonst hat man statt Umlauten nur Hieroglyphen auf der Seite.

== Installation ==

Mit http://domain/contao-manager.phar.php kann nun die Installation gestartet werden. Der Contao-Manager (CM) stürzt beim ersten Mal immer mit einer Fehlermeldung ab. Nach einem Refresh läuft er aber fortan sauber durch und auch die Installation läuft sauber durch.

Nach der Installation durch den CM muß C4 nun noch mit dem Installtool fertiggestellt werden. Das wird direkt aus dem CM oder mit http://domain/contao/install aufgerufen. Zuvor sollte die C3-Datenbank in die C4-Datenbank importiert worden sein.

== Kopieren von fehlenden Dateien ==

Der Inhalt des files-Ordners aus C3 muß nach webseiten/contao4/files kopiert werden. In zeitlich vertretbaren Rahmen und wenn man das Dateidatum behalten möchte ist das nur über die Shell möglich. Hier gebe ich "mc" ein, was den Midnight Commander startet. Mit dem habe ich nun die rund 44 GB Daten aus files kopiert, was auch so 2-3 Stunden dauerte.

Das Kopieren des templates-Ordners nach webseiten/contao4/templates dauerte ähnlich lange. Das lag daran, weil ich dort den Cache ines externen PHP-Skriptes gespeichert habe, wo sich mehrere 10.000 Dateien in kurzer Zeit ansammeln.

Auf das Kopieren von system/modules nach webseiten/contao4/system/modules habe ich vorerst verzichtet. Hier ist es wahrscheinlich besser nach Erweiterungsversionen für C4 zu suchen und diese über den CM zu installieren.

= Installation von C4-Erweiterungen =

Bei Domainfactory ist das leider nur über die Shell möglich. Der CM stürzt mit dem von ihm aufgerufenen Composer immer mit einer Zu-wenig-Arbeitsspeicher-Meldung. Dabei spielt es keine Rolle, was man in der php.ini zu stehen hat! Domainfactory läßt für Shellaufrufe, die von einem PHP-Skript kommen, nur einen begrenzten Arbeitsspeicher zu, den man nicht beeinflussen kann. Selbst bei einem ManagedServer nicht.

Installation Contao 4 und Migration Contao 3 bei Domainfactory

2017-10-22T07:42:37Z

Samson1964: Neu

Logdateien schreiben

2017-07-26T08:12:46Z

Samson1964: Die Seite wurde neu angelegt: „Category:Dev HOWTOS == Schreiben von Logdateien == Bei der Erweiterungsentwicklung und auch später ist es sinnvoll Ausgaben in Logdateien zu schreiben. …“

[[Category:Dev HOWTOS]]

== Schreiben von Logdateien ==

Bei der Erweiterungsentwicklung und auch später ist es sinnvoll Ausgaben in Logdateien zu schreiben. Contao bietet dafür eine einfache Funktion, die fast überall im PHP-Code genutzt werden kann:

<source lang="php">
log_message('Text','logdatei.log');
log_message(print_r($array,true),'logdatei2.log');
</source>

Systemwartung: Cachebereinigung nutzen

2017-07-25T19:16:22Z

Samson1964: Aus Benutzernamensraum verschoben und Kategorie ergänzt

[[Category:Dev HOWTOS]]

== Allgemeine Informationen ==

Unter System -> Systemwartung bietet das Contao-Backend die Möglichkeit der Bereinigung von Tabellen und Verzeichnissen. Darüberhinaus gibt es noch eine benutzerdefinierte Möglichkeit der Bereinigung. Hier ein Screenshot aus einem Backend einer Contao-3.5.28-Installation:

[[Datei:Systemwartung_bild1.jpg]]

Um die Bereinigung in eigenen Erweiterungen zu nutzen, muß die config/config.php bearbeitet werden.

== Tabellen bereinigen ==

<source lang="php">
$GLOBALS['TL_PURGE']['tables']['meine_erweiterung'] = array
(
'callback' => array('Namensraum\Klasse','purgeCache'),
'affected' => array('tl_tabelle1','tl_tabelle2')
);
</source>
Die Callback-Funktion wird nur ausgeführt, wenn das Häkchen gesetzt und die Bereinigung damit gestartet wurde. Bei der bloßen Anzeige der Systemwartung passiert noch nichts. Mit dem Bereinigen an sich hat die Callback-Funktion nichts zu tun, aber kann man z.B. in Logdateien schreiben oder irgendetwas anderes machen. 
Für die in affected angegebenen Tabellen ermittelt Contao die Anzahl der Einträge und den Speicherplatz und zeigt diese Informationen im Backend an, siehe Screenshot oben.

== Verzeichnisse bereinigen ==

<source lang="php">
$GLOBALS['TL_PURGE']['folders']['meine_erweiterung'] = array
(
'callback' => array('Namensraum\Klasse','purgeCache'),
'affected' => array('assets/meincache','system/cache/auchmeincache')
);
</source>
Die Callback-Funktion wird nur ausgeführt, wenn das Häkchen gesetzt und die Bereinigung damit gestartet wurde. Bei der bloßen Anzeige der Systemwartung passiert noch nichts. Mit dem Bereinigen an sich hat die Callback-Funktion nichts zu tun, aber kann man z.B. in Logdateien schreiben oder irgendetwas anderes machen. 
Für die in affected angegebenen Verzeichnisse ermittelt Contao die Anzahl der Dateien und zeigt diese Informationen im Backend an, siehe Screenshot oben.

== Benutzerdefiniert bereinigen ==

<source lang="php">
$GLOBALS['TL_PURGE']['custom']['meine_erweiterung'] = array
(
'callback' => array('Namensraum\Klasse','purgeCache')
);
</source>
Die Callback-Funktion wird nur ausgeführt, wenn das Häkchen gesetzt und die Bereinigung damit gestartet wurde. Bei der bloßen Anzeige der Systemwartung passiert noch nichts. In der Callback-Funktion müssen Sie im Gegensatz zu den beiden anderen Möglichkeiten alles selbst machen, also auch Ihre Bereinigungsaufgaben. Ein affected-Array wird bei custom nicht benötigt.

Der zweite Screenshot zeigt zwei benutzerdefinierte Bereinigungsfunktionen:

[[Datei:Systemwartung_bild2.jpg]]

Um in die Anzeige ein paar Detailinformationen zur bevorstehenden Bereinigung zu bekommen, muß man etwas tricksen:

== Sprachvariablen ==

In der Datei languages/de/tl_maintenance.php können die deutschen Übersetzungen für die Anzeige abgespeichert werden. Für das Beispiel im zweiten Screenshot sieht das so aus:
<source lang="php">
$GLOBALS['TL_LANG']['tl_maintenance_jobs']['dewis'] = array('DeWIS-Cache leeren','Löscht den Cache der DeWIS-Abfrage. Dieser Cache kann in den Backend-Einstellungen dauerhaft deaktiviert werden.');
// Ausgabe ergänzen
$GLOBALS['TL_LANG']['tl_maintenance_jobs']['dewis'][0] .= \Samson\DeWIS\DeWIS::calcCache();
</source>
Die Funktion calcCache ist bei mir für die Detailinformationen zuständig. Die werden einfach an das Label rangehangen.

Benutzer:Samson1964/Systemwartung: Cachebereinigung nutzen

2017-07-25T19:15:28Z

Samson1964: Samson1964 verschob die Seite Benutzer:Samson1964/Systemwartung: Cachebereinigung nutzen nach Systemwartung: Cachebereinigung nutzen

#WEITERLEITUNG [[Systemwartung: Cachebereinigung nutzen]]

Systemwartung: Cachebereinigung nutzen

2017-07-25T19:15:27Z

Samson1964: Samson1964 verschob die Seite Benutzer:Samson1964/Systemwartung: Cachebereinigung nutzen nach Systemwartung: Cachebereinigung nutzen

== Allgemeine Informationen ==

Unter System -> Systemwartung bietet das Contao-Backend die Möglichkeit der Bereinigung von Tabellen und Verzeichnissen. Darüberhinaus gibt es noch eine benutzerdefinierte Möglichkeit der Bereinigung. Hier ein Screenshot aus einem Backend einer Contao-3.5.28-Installation:

[[Datei:Systemwartung_bild1.jpg]]

Um die Bereinigung in eigenen Erweiterungen zu nutzen, muß die config/config.php bearbeitet werden.

== Tabellen bereinigen ==

<source lang="php">
$GLOBALS['TL_PURGE']['tables']['meine_erweiterung'] = array
(
'callback' => array('Namensraum\Klasse','purgeCache'),
'affected' => array('tl_tabelle1','tl_tabelle2')
);
</source>
Die Callback-Funktion wird nur ausgeführt, wenn das Häkchen gesetzt und die Bereinigung damit gestartet wurde. Bei der bloßen Anzeige der Systemwartung passiert noch nichts. Mit dem Bereinigen an sich hat die Callback-Funktion nichts zu tun, aber kann man z.B. in Logdateien schreiben oder irgendetwas anderes machen. 
Für die in affected angegebenen Tabellen ermittelt Contao die Anzahl der Einträge und den Speicherplatz und zeigt diese Informationen im Backend an, siehe Screenshot oben.

== Verzeichnisse bereinigen ==

<source lang="php">
$GLOBALS['TL_PURGE']['folders']['meine_erweiterung'] = array
(
'callback' => array('Namensraum\Klasse','purgeCache'),
'affected' => array('assets/meincache','system/cache/auchmeincache')
);
</source>
Die Callback-Funktion wird nur ausgeführt, wenn das Häkchen gesetzt und die Bereinigung damit gestartet wurde. Bei der bloßen Anzeige der Systemwartung passiert noch nichts. Mit dem Bereinigen an sich hat die Callback-Funktion nichts zu tun, aber kann man z.B. in Logdateien schreiben oder irgendetwas anderes machen. 
Für die in affected angegebenen Verzeichnisse ermittelt Contao die Anzahl der Dateien und zeigt diese Informationen im Backend an, siehe Screenshot oben.

== Benutzerdefiniert bereinigen ==

<source lang="php">
$GLOBALS['TL_PURGE']['custom']['meine_erweiterung'] = array
(
'callback' => array('Namensraum\Klasse','purgeCache')
);
</source>
Die Callback-Funktion wird nur ausgeführt, wenn das Häkchen gesetzt und die Bereinigung damit gestartet wurde. Bei der bloßen Anzeige der Systemwartung passiert noch nichts. In der Callback-Funktion müssen Sie im Gegensatz zu den beiden anderen Möglichkeiten alles selbst machen, also auch Ihre Bereinigungsaufgaben. Ein affected-Array wird bei custom nicht benötigt.

Der zweite Screenshot zeigt zwei benutzerdefinierte Bereinigungsfunktionen:

[[Datei:Systemwartung_bild2.jpg]]

Um in die Anzeige ein paar Detailinformationen zur bevorstehenden Bereinigung zu bekommen, muß man etwas tricksen:

== Sprachvariablen ==

In der Datei languages/de/tl_maintenance.php können die deutschen Übersetzungen für die Anzeige abgespeichert werden. Für das Beispiel im zweiten Screenshot sieht das so aus:
<source lang="php">
$GLOBALS['TL_LANG']['tl_maintenance_jobs']['dewis'] = array('DeWIS-Cache leeren','Löscht den Cache der DeWIS-Abfrage. Dieser Cache kann in den Backend-Einstellungen dauerhaft deaktiviert werden.');
// Ausgabe ergänzen
$GLOBALS['TL_LANG']['tl_maintenance_jobs']['dewis'][0] .= \Samson\DeWIS\DeWIS::calcCache();
</source>
Die Funktion calcCache ist bei mir für die Detailinformationen zuständig. Die werden einfach an das Label rangehangen.

Systemwartung: Cachebereinigung nutzen

2017-07-25T19:15:01Z

Samson1964: /* Allgemeine Informationen */

Datei:Systemwartung bild2.jpg

2017-07-25T18:44:51Z

Samson1964:

Datei:Systemwartung bild1.jpg

2017-07-25T18:44:30Z

Samson1964:

Systemwartung: Cachebereinigung nutzen

2017-07-25T18:42:15Z

Samson1964: Die Seite wurde neu angelegt: „==Allgemeine Informationen== Unter System -> Systemwartung bietet das Contao-Backend die Möglichkeit der Bereinigung von Tabellen und Verzeichnissen. Darüber…“

Dateien in die Datenbank importieren

2016-08-11T07:58:57Z

Samson1964: Die Seite wurde neu angelegt: „Category:Admin HOWTOS Category:Dev HOWTOS Category:Dev Snippets {{AppliesTo |Version=ab 3.2 }} == Anleitung == Beim Import von fremden Inhalten m…“

[[Category:Admin HOWTOS]]
[[Category:Dev HOWTOS]]
[[Category:Dev Snippets]]
{{AppliesTo
|Version=ab 3.2
}}

== Anleitung ==

Beim Import von fremden Inhalten müssen auch oft Dateien importiert bzw. in das datenbankgestützte Dateisystem von Contao eingebunden werden. Das geht mit dem nachfolgendem PHP-Code recht einfach.

Die Datei die eingebunden wird, muß vorhanden sein!

Die Funktion ''addResource'' erstellt einen neuen Eintrag in der Tabelle tl_files. Anschließend kann mit dem Zugriff auf das erstellte Objekt, die UUID in den eigenen Import integriert werden.

== Code für eigene Importklasse ==

<source lang="php">
$objFile = \Dbafs::addResource('files/bild.jpg');
$uuid = $objFile->uuid;
</source>

DCA: List-Array

2016-03-16T18:54:58Z

Samson1964: Die Seite wurde neu angelegt: „{{stub}} = DCA: List-Array $GLOBALS['list'] = Category:Dev HOWTOS Category:Dev Snippets {{AppliesTo|TLVersion=ab 3|Version=ab 3}} Ich sammle an dieser …“

{{stub}}
= DCA: List-Array $GLOBALS['list'] =
[[Category:Dev HOWTOS]]
[[Category:Dev Snippets]]
{{AppliesTo|TLVersion=ab 3|Version=ab 3}}
Ich sammle an dieser Stelle Codeschnipsel zum DCA, sowohl zu dokumentierten als auch undokumentierten Variablen.

== ['label'] ==

=== ['label']['fields'] ===

<source lang="php">
'fields' => array('benutzer:tl_member.CONCAT(firstname," ",lastname," (",username,")")', 'status', 'vereine')
</source>

Legt fest welche Felder in der Auflistung angezeigt werden. 
Im Beispiel wird zuerst ein Feld '''benutzer''' [[DCA_Field_Mapping|gemappt]]. Der darin stehende Wert entspricht der id der Tabelle tl_member. Zurück geliefert wird mittels CONCAT ein String aus mehreren Feldern von tl_member.

Felder die aus Arrays bestehen (z.B. select) und mehr als einen Wert zurückliefern, lassen sich nicht mappen.

=== ['label']['showColumns'] ===

Undokumentiert. Auflistung der Datensätze mit gleichmäßig ausgerichteten Spalten und Spaltenüberschriften. Erwartet: false/true

--[[Benutzer:Samson1964|Frank Hoppe]] ([[Benutzer Diskussion:Samson1964|Diskussion]]) 19:54, 16. Mär. 2016 (CET)

MultiColumnWizard

2016-03-11T20:48:10Z

Samson1964: /* Verfügbare MultiColumnWizard Eval-Optionen */ Beispielcode ergänzt

[[en:MultiSelectWizard]]
[[Category:Extensions]]
{{ExtInfo
| DevSite=http://www.men-at-work.de
| ExtVersion=3.0.0
| Version=2.10+
| ERLink=http://www.contao.org/erweiterungsliste/view/MultiColumnWizard.html
| TrackerLink=https://github.com/menatwork/MultiColumnWizard/issues
}}

Der MultiColumnWizard ist ein Widget zur Abbildung von mehreren Feldern ''gleichen'' und/oder ''unterschiedlichen'' Typs (''Inputtype'') in einem DCA-Element. Die einzelnen Felder des MCW werden im Backend spaltenweise geführt und sind als Gruppe zeilenweise erweiterbar. Die Anordnung entspricht einem multidimensionalen Array der Form ''array[Zeilen][Felder]'', das als serialisiertes Array in der Datenbank abgelegt wird. Das Widget ist quasi identisch zu [[MultiTextWizard]] oder [[MultiSelectWizard]]. Es erweitert die Funktionalitäten für beliebige Widgets.

=Aussehen=
Die Extension kann für jede Art von Inputtype verwendet werden, eine Mischung der einzelnen Typen ist kein Problem.
[[Datei:MultiColumnWizard.jpg|MultiColumnWizard|frame|center]]

=Verwendung=
Es gibt zwei Verwendungsmöglichkeiten. Entweder direkt mit der Angabe von "columnFields" im "eval"-Array oder mit einem Callback.

==Angabe mit columnFields==

<source lang="php">
$GLOBALS['TL_DCA']['tl_theme']['fields']['templateSelection'] = array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['templateSelection'],
'exclude' => true,
'inputType' => 'multiColumnWizard',
'eval' => array
(
'columnFields' => array
(
'ts_client_os' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_client_os'],
'exclude' => true,
'inputType' => 'select',
'options' => array
(
'option1' => 'Option 1',
'option2' => 'Option 2',
),
'eval' => array('style' => 'width:250px', 'includeBlankOption'=>true, 'chosen'=>true)
),
'ts_client_browser' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_client_browser'],
'exclude' => true,
'inputType' => 'text',
'eval' => array('style'=>'width:180px')
),
'ts_client_mobile' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_client_mobile'],
'exclude' => true,
'inputType' => 'checkbox',
'eval' => array('style'=>'width:40px')

),
'ts_extension' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_extension'],
'inputType' => 'text',
'eval' => array('mandatory'=>true, 'style'=>'width:115px')
),
)
),
'sql' => "blob NULL"
);
</source>
Das ''''chosen'=>true''' im eval vom Select Feld (ts_client_os) ist für Contao 2.11 wichtig, da sonst die Anzeige nicht korrekt funktioniert. Für Contao 2.10 ist das nicht nötig, stört aber nicht und ist somit kompatibel für beide Versionen. Das SQL-Feld ist nur nötig, wenn es keine database.sql gibt.

==Angabe mit Callback==
<source lang="php">
$GLOBALS['TL_DCA']['tl_table']['fields']['anything'] = array
(
'label' => &$GLOBALS['TL_LANG']['tl_table']['anything'],
'exclude' => true,
'inputType' => 'multiColumnWizard',
'eval' => array('mandatory'=>true,'columnsCallback'=>array('Class', 'Method'))

);
</source>

Wobei natürlich der Return-Wert genau das selbe Array sein muss, wie bei der "columnFields"-Variante.

==Verfügbare MultiColumnWizard Eval-Optionen==

{| cellpadding="20" cellspacing="0"
|-
| '''Schlüssel''' || '''Wert''' || '''Beschreibung''' || '''Beispiel'''
|-
| columnPos || Gruppenname ''string'' || Gruppiert Felder und zeigt Sie untereinander an. ||
|-
| maxCount || Menge ''integer'' || Legt die maximale Anzahl an Felder fest, die angelegt werden dürfen. || <source lang="php">$GLOBALS['TL_DCA']['tl_example']['fields']['mcwExample']['eval']['maxCount'] = 4;</source>
|-
| minCount || Menge ''integer'' || Legt die minimale Anzahl an Felder fest, die angelegt werden dürfen. || <source lang="php">$GLOBALS['TL_DCA']['tl_example']['fields']['mcwExample']['eval']['minCount '] = 2;</source>
|-
| valign || Position ''string'' || Legt die vertikale Position der Zelle in der Tabelle fest. || <source lang="php">$GLOBALS['TL_DCA']['tl_example']['fields']['mcwExample']['eval']['valign'] = 'top';</source>
|-
| buttonPos || Position ''string'' || Legt die vertikale Position der Zelle, in der sich die Buttons befinden, fest. || <source lang="php">$GLOBALS['TL_DCA']['tl_example']['fields']['mcwExample']['eval']['buttonPos'] = 'bottom';</source>
|-
| buttons || Buttonnamen ''associative array'' || Legt fest, mit welchem Icon die 4 Buttons "up", "down", "copy", "delete" dargestellt werden. Dabei ist der Buttonname der Schlüssel und der Pfad zum Icon der Wert. Wird ein Wert für einen Button explizit auf ''false'' gesetzt, so wird dieser versteckt. || <source lang="php">$GLOBALS['TL_DCA']['tl_example']['fields']['mcwExample']['eval']['buttons'] = array('copy' => false, 'delete' => false, 'up' => 'myUpIcon.png');</source>
|}

==Unterstützte Contao Eval-Optionen==
Diese Eval-Optionen werden für die "Kindwidgets" - oder besser "komponierten Widgets" - unterstützt.

{|
|-
| '''Schlüssel''' || '''Status'''
|-
| nospace || ''Ungetestet''
|-
| multiple || Unterstützt
|-
| size || Unterstützt
|-
| rgxp || Unterstützt
|-
| style || Unterstützt
|-
| tl_class || Unterstützt
|-
| preserveTags || Unterstützt
|-
| allowHtml || Unterstützt
|-
| trailingSlash || ''Ungetestet''
|-
| mandatory || Unterstützt
|-
| spaceToUnderscore || Unterstützt
|-
| includeBlankOption || Unterstützt
|-
| maxlength || Unterstützt
|-
| minlength || Unterstützt
|-
| chosen || Unterstützt
|}

==Hinweise==
===options_callback===
Im Beispiel oben wird für das Select Feld ein Optionsliste direkt definiert über 'options'. Das geht auch über 'options_callback'. Im Gegensatz zum Core wird der Methode jedoch kein Datacontainer $dc übermittelt.

Beispiel für eine Liste abhängig von der Contao Version: 
<source lang="php">
'ts_client_os' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_client_os'],
'exclude' => true,
'inputType' => 'select',
'options_callback' => array('tl_theme', 'getOptions'),
'eval' => array('style' => 'width:250px', 'includeBlankOption'=>true, 'chosen'=>true)
),
</source>

Nun wie üblich im DCA die Klasse mit der Methode: 
<source lang="php">
class tl_theme extends Backend
{
/**
* Return options
* @return array
*/
public function getOptions()
{
$arrOptions = array(
'option1' => 'Option 1',
'option2' => 'Option 2',
'option3' => 'Option 3',
);
//option3 not in Contao 2.10
if (version_compare(VERSION, '2.11', '<'))
{
$arrOptions = array(
'option1' => 'Option 1',
'option2' => 'Option 2',
);
}
return $arrOptions;
}
}
</source>

MultiColumnWizard

2016-03-11T19:55:43Z

Samson1964: /* Angabe mit columnFields */ sql

[[en:MultiSelectWizard]]
[[Category:Extensions]]
{{ExtInfo
| DevSite=http://www.men-at-work.de
| ExtVersion=3.0.0
| Version=2.10+
| ERLink=http://www.contao.org/erweiterungsliste/view/MultiColumnWizard.html
| TrackerLink=https://github.com/menatwork/MultiColumnWizard/issues
}}

Der MultiColumnWizard ist ein Widget zur Abbildung von mehreren Feldern ''gleichen'' und/oder ''unterschiedlichen'' Typs (''Inputtype'') in einem DCA-Element. Die einzelnen Felder des MCW werden im Backend spaltenweise geführt und sind als Gruppe zeilenweise erweiterbar. Die Anordnung entspricht einem multidimensionalen Array der Form ''array[Zeilen][Felder]'', das als serialisiertes Array in der Datenbank abgelegt wird. Das Widget ist quasi identisch zu [[MultiTextWizard]] oder [[MultiSelectWizard]]. Es erweitert die Funktionalitäten für beliebige Widgets.

=Aussehen=
Die Extension kann für jede Art von Inputtype verwendet werden, eine Mischung der einzelnen Typen ist kein Problem.
[[Datei:MultiColumnWizard.jpg|MultiColumnWizard|frame|center]]

=Verwendung=
Es gibt zwei Verwendungsmöglichkeiten. Entweder direkt mit der Angabe von "columnFields" im "eval"-Array oder mit einem Callback.

==Angabe mit columnFields==

<source lang="php">
$GLOBALS['TL_DCA']['tl_theme']['fields']['templateSelection'] = array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['templateSelection'],
'exclude' => true,
'inputType' => 'multiColumnWizard',
'eval' => array
(
'columnFields' => array
(
'ts_client_os' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_client_os'],
'exclude' => true,
'inputType' => 'select',
'options' => array
(
'option1' => 'Option 1',
'option2' => 'Option 2',
),
'eval' => array('style' => 'width:250px', 'includeBlankOption'=>true, 'chosen'=>true)
),
'ts_client_browser' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_client_browser'],
'exclude' => true,
'inputType' => 'text',
'eval' => array('style'=>'width:180px')
),
'ts_client_mobile' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_client_mobile'],
'exclude' => true,
'inputType' => 'checkbox',
'eval' => array('style'=>'width:40px')

),
'ts_extension' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_extension'],
'inputType' => 'text',
'eval' => array('mandatory'=>true, 'style'=>'width:115px')
),
)
),
'sql' => "blob NULL"
);
</source>
Das ''''chosen'=>true''' im eval vom Select Feld (ts_client_os) ist für Contao 2.11 wichtig, da sonst die Anzeige nicht korrekt funktioniert. Für Contao 2.10 ist das nicht nötig, stört aber nicht und ist somit kompatibel für beide Versionen. Das SQL-Feld ist nur nötig, wenn es keine database.sql gibt.

==Angabe mit Callback==
<source lang="php">
$GLOBALS['TL_DCA']['tl_table']['fields']['anything'] = array
(
'label' => &$GLOBALS['TL_LANG']['tl_table']['anything'],
'exclude' => true,
'inputType' => 'multiColumnWizard',
'eval' => array('mandatory'=>true,'columnsCallback'=>array('Class', 'Method'))

);
</source>

Wobei natürlich der Return-Wert genau das selbe Array sein muss, wie bei der "columnFields"-Variante.

==Verfügbare MultiColumnWizard Eval-Optionen==

{| cellpadding="20" cellspacing="0"
|-
| '''Schlüssel''' || '''Wert''' || '''Beschreibung''' || '''Beispiel'''
|-
| columnPos || Gruppenname ''string'' || Gruppiert Felder und zeigt Sie untereinander an. ||
|-
| maxCount || Menge ''integer'' || Legt die maximale Anzahl an Felder fest, die angelegt werden dürfen. || <source lang="php">$GLOBALS['TL_DCA']['tl_example']['fields']['mcwExample']['eval']['maxCount'] = 4;</source>
|-
| minCount || Menge ''integer'' || Legt die minimale Anzahl an Felder fest, die angelegt werden dürfen. || <source lang="php">$GLOBALS['TL_DCA']['tl_example']['fields']['mcwExample']['eval']['minCount '] = 2;</source>
|-
| valign || Position ''string'' || Legt die vertikale Position der Zelle in der Tabelle fest. || <source lang="php">$GLOBALS['TL_DCA']['tl_example']['fields']['mcwExample']['eval']['valign'] = 'top';</source>
|-
| buttonPos || Position ''string'' || Legt die vertikale Position der Zelle, in der sich die Buttons befinden, fest. ||
|-
| buttons || Buttonnamen ''associative array'' || Legt fest, mit welchem Icon die 4 Buttons "up", "down", "copy", "delete" dargestellt werden. Dabei ist der Buttonname der Schlüssel und der Pfad zum Icon der Wert. Wird ein Wert für einen Button explizit auf ''false'' gesetzt, so wird dieser versteckt. || <source lang="php">$GLOBALS['TL_DCA']['tl_example']['fields']['mcwExample']['eval']['buttons'] = array('copy' => false, 'delete' => false, 'up' => 'myUpIcon.png');</source>
|}

==Unterstützte Contao Eval-Optionen==
Diese Eval-Optionen werden für die "Kindwidgets" - oder besser "komponierten Widgets" - unterstützt.

{|
|-
| '''Schlüssel''' || '''Status'''
|-
| nospace || ''Ungetestet''
|-
| multiple || Unterstützt
|-
| size || Unterstützt
|-
| rgxp || Unterstützt
|-
| style || Unterstützt
|-
| tl_class || Unterstützt
|-
| preserveTags || Unterstützt
|-
| allowHtml || Unterstützt
|-
| trailingSlash || ''Ungetestet''
|-
| mandatory || Unterstützt
|-
| spaceToUnderscore || Unterstützt
|-
| includeBlankOption || Unterstützt
|-
| maxlength || Unterstützt
|-
| minlength || Unterstützt
|-
| chosen || Unterstützt
|}

==Hinweise==
===options_callback===
Im Beispiel oben wird für das Select Feld ein Optionsliste direkt definiert über 'options'. Das geht auch über 'options_callback'. Im Gegensatz zum Core wird der Methode jedoch kein Datacontainer $dc übermittelt.

Beispiel für eine Liste abhängig von der Contao Version: 
<source lang="php">
'ts_client_os' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_theme']['ts_client_os'],
'exclude' => true,
'inputType' => 'select',
'options_callback' => array('tl_theme', 'getOptions'),
'eval' => array('style' => 'width:250px', 'includeBlankOption'=>true, 'chosen'=>true)
),
</source>

Nun wie üblich im DCA die Klasse mit der Methode: 
<source lang="php">
class tl_theme extends Backend
{
/**
* Return options
* @return array
*/
public function getOptions()
{
$arrOptions = array(
'option1' => 'Option 1',
'option2' => 'Option 2',
'option3' => 'Option 3',
);
//option3 not in Contao 2.10
if (version_compare(VERSION, '2.11', '<'))
{
$arrOptions = array(
'option1' => 'Option 1',
'option2' => 'Option 2',
);
}
return $arrOptions;
}
}
</source>

Datenbank Klasse verwenden

2016-03-08T10:40:39Z

Samson1964: /* Datensätze schreiben */ + insertid

{{stub}}

= Informationen zur Datenbank-Klasse =

Contao bietet für Entwickler eine Klasse an, um mit der Datenbank zu kommunizieren. Diese sollte beim Entwickeln von Erweiterungen unbedingt verwendet werden!

* [http://api.contao.org/Library/_libraries---Database.php.html Dokumentation der Klasse]

Die Datenbank-Klasse bietet mehrere Vorteile:
* Die Daten werden "gesäubert" und störende Zeichen maskiert
* Ein Objekt der Klasse Database_Result wird zurückgegeben. Dieses enthält alle Informationen zum Query
* Ersparnis von Schreibarbeit

= Operationen auf der Datenbank =

Die Beispiele setzen voraus, dass zuvor das Datenbank-Modul geladen wurde:

<source lang="php">
$this->import('Database');
</source>

== Datensätze lesen ==

'''Lesen von Datensätzen ohne Bedingung'''

<source lang="php">
$result = $this->Database->prepare("SELECT * FROM tl_log")->execute();
</source>

'''Ausgeben der Datensätze'''

<source lang="php">
echo $result->numRows; // Anzahl der gefundenen Datensätze ausgeben
echo $result->id; // ID des 1. Datensatzes ausgeben
// Und alle anderen ID's ausgeben
while($result->next())
{
echo $result->id;
}
</source>

'''Lesen von Datensätzen mit Bedingung'''

<source lang="php">
$result = $this->Database->prepare("SELECT * FROM tl_log WHERE id=?")->execute(1);
$result = $this->Database->prepare("SELECT * FROM tl_log WHERE id=? OR id=?")->execute(1, 5);
</source>

Die Fragezeichen sind Wildcards. Sie werden der Reihenfolge nach von den Parametern der execute-Funktion ersetzt. Dabei werden die parameter escaped, also für die Datenbank aufbereitet.
Das schützt allerdings '''nicht''' vor boshaften Benutzereingaben. Diese sollten immer mit der Input-Klasse verarbeitet werden!

== Datensätze schreiben ==

Datensätze können auch über die Datenbank-Klasse geschrieben werden. Es gibt dafür zwei Möglichkeiten.

'''Einzelne Werte per Wildcard setzten'''

<source lng="php">
$this->Database->prepare("UPDATE tl_log SET source = ? WHERE id=?")->execute('BE', 12345);
</source>

'''Mehrere Werte per set-Methode setzten'''
<source lng="php">
$set = array('tstamp' => time(), 'source' => 'BE', 'action' => 'GENERAL');
$this->Database->prepare("UPDATE tl_log %s WHERE id=?")->set($set)->execute(12345);
</source>

Diese Methode funktioniert natürlich auch mit einem INSERT-Statement. Hier das Beispiel, wo Sie anschließend auch gleich die ID des neuen Datensatzes bekommen:

<source lng="php">
$set = array('tstamp' => time(), 'source' => 'BE', 'action' => 'GENERAL');
$objInsert = $this->Database->prepare("INSERT INTO tl_log %s")->set($set)->execute();
echo $objInsert->insertId;
</source>

== Das Ergebnis auswerten ==

= Tipps & Tricks =
* [[SQL Like Abfrage in doppelten Prozentzeichen]]

[[Category:Dev HOWTOS]]

Datenbank Klasse verwenden

2016-03-08T09:56:54Z

Samson1964: /* Datensätze schreiben */ INSERT-Beispiel ergänzt

{{stub}}

= Informationen zur Datenbank-Klasse =

Contao bietet für Entwickler eine Klasse an, um mit der Datenbank zu kommunizieren. Diese sollte beim Entwickeln von Erweiterungen unbedingt verwendet werden!

* [http://api.contao.org/Library/_libraries---Database.php.html Dokumentation der Klasse]

Die Datenbank-Klasse bietet mehrere Vorteile:
* Die Daten werden "gesäubert" und störende Zeichen maskiert
* Ein Objekt der Klasse Database_Result wird zurückgegeben. Dieses enthält alle Informationen zum Query
* Ersparnis von Schreibarbeit

= Operationen auf der Datenbank =

Die Beispiele setzen voraus, dass zuvor das Datenbank-Modul geladen wurde:

<source lang="php">
$this->import('Database');
</source>

== Datensätze lesen ==

'''Lesen von Datensätzen ohne Bedingung'''

<source lang="php">
$result = $this->Database->prepare("SELECT * FROM tl_log")->execute();
</source>

'''Ausgeben der Datensätze'''

<source lang="php">
echo $result->numRows; // Anzahl der gefundenen Datensätze ausgeben
echo $result->id; // ID des 1. Datensatzes ausgeben
// Und alle anderen ID's ausgeben
while($result->next())
{
echo $result->id;
}
</source>

'''Lesen von Datensätzen mit Bedingung'''

<source lang="php">
$result = $this->Database->prepare("SELECT * FROM tl_log WHERE id=?")->execute(1);
$result = $this->Database->prepare("SELECT * FROM tl_log WHERE id=? OR id=?")->execute(1, 5);
</source>

Die Fragezeichen sind Wildcards. Sie werden der Reihenfolge nach von den Parametern der execute-Funktion ersetzt. Dabei werden die parameter escaped, also für die Datenbank aufbereitet.
Das schützt allerdings '''nicht''' vor boshaften Benutzereingaben. Diese sollten immer mit der Input-Klasse verarbeitet werden!

== Datensätze schreiben ==

Datensätze können auch über die Datenbank-Klasse geschrieben werden. Es gibt dafür zwei Möglichkeiten.

'''Einzelne Werte per Wildcard setzten'''

<source lng="php">
$this->Database->prepare("UPDATE tl_log SET source = ? WHERE id=?")->execute('BE', 12345);
</source>

'''Mehrere Werte per set-Methode setzten'''
<source lng="php">
$set = array('tstamp' => time(), 'source' => 'BE', 'action' => 'GENERAL');
$this->Database->prepare("UPDATE tl_log %s WHERE id=?")->set($set)->execute(12345);
</source>

Diese Methode funktioniert natürlich auch mit einem INSERT-Statement:

<source lng="php">
$set = array('tstamp' => time(), 'source' => 'BE', 'action' => 'GENERAL');
$this->Database->prepare("INSERT INTO tl_log %s")->set($set)->execute();
</source>

== Das Ergebnis auswerten ==

= Tipps & Tricks =
* [[SQL Like Abfrage in doppelten Prozentzeichen]]

[[Category:Dev HOWTOS]]

Klasse Formular

2016-03-08T08:02:19Z

Samson1964: /* Setzen von Default Werten */ Erklärung hinzugefügt

[[Category:Dev HOWTOS]]
[[Category:Dev Snippets]]

'''Github:''' https://github.com/psi-4ward/Formular

= Beispiel =

Die Klasse ''Formular'' erstellt Formulare aus DCA-Arrays:

<source lang="php">
// Die DCA-Definition
$dca = array
(
'Kontaktdaten' => array
(
'label' => 'Ihre Kontaktdaten',
'inputType' => 'headline'
),
'vorname' => array
(
'label' => 'Vorname',
'inputType' => 'text',
'default' => 'vorname',
'eval' => array('mandatory'=>true,'helpmessage'=>'Ihr Vorname')
),
'nachname' => array
(
'label' => 'Nachname',
'inputType' => 'text',
'default' => 'nachname',
'eval' => array('mandatory'=>true,'helpmessage'=>'Ihr Nachname')
),
'datum' => array
(
'label' => 'Datum',
'inputType' => 'text',
'default' => date('d.m.Y'),
'eval' => array('datepicker'=>$this->getDatePickerString(),'cleardefault'=>false)
),

'email' => array
(
'label' => 'E-Mail',
'inputType' => 'text',
'eval' => array('mandatory'=>true,'rgxp'=>'email')
),
'telefon' => array
(
'label' => 'Telefon',
'inputType' => 'text',
'eval' => array('mandatory'=>true)
),
'kategorie' => array
(
'label' => 'Kategorie',
'inputType' => 'checkbox',
'options' => array('Option1','Option2','Option3','Option4'),
'eval' => array('multiple' => true, 'mandatory' => true),
),
'land' => array
(
'label' => 'land',
'inputType' => 'select',
'options' => array('1','2','3','4'),
'reference' => array('1'=>'Peru','2'=>'Kenia','3'=>'Italien','4'='Kamerun'),
'eval' => array('multiple' => true, 'mandatory' => true),
),
'bemerkung' => array
(
'label' => 'Bemerkung',
'inputType' => 'textarea',
'eval' => array('rte'=>'tinyMCE')
),
'submit' => array
(
'label' => 'speichern',
'inputType' => 'submit'
)
);

// Instantierung mit der FormularID meinKontaktformular
$frm = new Formular('meinKontaktformular');

// Übergabe des DCA-Arrays
$frm->setDCA($dca);

// Konfiguration
$frm->setConfig('generateFormat','<div>%label %field %error </div>');
$frm->setConfig('attributes',array('tableless'=>true));

// Formular wurde abgeschickt und ist korrekt
if($frm->isSubmitted() && $frm->validate())
{
var_dump($frm->getData());
}

// Ausgabe des Formulars
echo $frm->parse();
</source>

=Konfiguration=

Es gibt einige Parameter um die Erstellung des Formulars zu beeinflussen.
Grundlegend muss zwischen '''parse()''' und '''generate()''' unterschieden werden, wobei parse() die Methode generate() impliziert.
Formular::parse() bettet den Output von generate() in das ''Template'' ein.

==Parameter==
Die Konfiguration der Klasse Formular kann über '''Formular::setConfig($param,$value)''' geändert werden.

* str '''formTemplate''': Wird das Formular über parse() gerendert wird dieses Template benutzt. Vorgabe: form
* str '''class''': Zusätzliche Klassenangabe
* str '''action''': action-Attribut des <form> Tags. Vorgabe: Environment->request
* str '''method''': method-Attribut des <form> Tags. Vorgabe: post
* str '''generateFormat''': String mit Platzhaltern welche für jedes Widget durch deren Elemente ersetzt werden. Vorgabe "%parse"
%parse Widget::parse()
%label Widget::generateLabel()
%field Widget::generate()
%error Widget::getErrorAsHTML()
%errorPlain Widget::getErrorAsString()
* array '''attributes''': Array mit Attributen für die Widget::parse() Methode. Z.B. array('tableless'=>true)

===Setzen von Default Werten===

Um bei Select-, Radio-, Checkbox-Feldern die Standardwerte vorzubelegen kann man sich dem Magical-Setter bedienen:

Beispiel:
<source lang="php">
$frm->kategorie = array('Option1','Option2');
</source>

kategorie ist der Name des Feldes. Das übergebene Array sind die als Standard anzunehmenden Werte aus dem Array options dieses Feldes.

===Anwendungsbeispiel Filter===

Will man einen mehrseitigen Filter mit der Klasse Formular erstellen und die Kriterien beim Blättern (Pagination) erhalten, kann man diese über get paramater (hinzugefügt über addToUrl()) wieder setzen:
<source lang="php">
$frm->kategorie = \Input::get('kategorie');
$frm->branche = \Input::get('branche');
$frm->bundesland = \Input::get('bundesland');
</source>

==Systemweite Konfiguration==
Die Formular-Klasse versucht Konfigurationsoptionen aus $GLOBALS['TL_FORM'] zu lesen.
<source lang="php">
$GLOBALS['TL_FORM'] = array
(
'class' =>'myFormular',
'generateFormat' => '<div class="formField">%label %error %field</div>',
'formTemplate' => 'myFormularTemplate'
)
</source>

=Interaktion mit Erweiterungen=

==cleardefault==

[http://www.contao.org/erweiterungsliste/view/cleardefault.de.html Cleardefault] löscht den Standardwert sobald das Textfeld den Fokus bekommt.
Ist die Erweiterung installiert werden alle Textfelder und Textareas mit diesem Verhalten versehen. Über das @eval@ Array kann es für ein
einzelnes Feld angepasst werden:

<source lang="php">
$dca = array(
'datum' => array
(
'label' => 'Datum',
'inputType' => 'text',
'default' => date('d.m.Y'),
'eval' => array('cleardefault'=>false)
)
);
</source>
''' 'cleardefault'=>false''' deaktiviert das Löschen des Standardwertes für das Feld '''datum'''.

==helpmessage==

[http://www.contao.org/erweiterungsliste/view/helpmessage.de.html Helpmessage] blendet per Javascript Hilfsnachrichten für das Feld ein.
Die Nachricht wird im '''eval''' Array hinterlegt. Falls über die Klasse '''FormularTL_DCA''' eine Tabelle gerendert wird, werden die Hilfstexte aus den Contao-Sprachdateien der Tabelle übernommen.

<source lang="php">
$dca = array(
'datum' => array
(
'label' => 'Datum',
'inputType' => 'text',
'default' => date('d.m.Y'),
'eval' => array('helpmessage'=>'Das Datum muss im Format DD.MM.YYYY sein')
)
);
</source>

==formcheck==

[http://www.contao.org/erweiterungsliste/view/formcheck.de.html Formcheck] validiert ein Formular per Javascript auf der Clientseite.
Falls die Erweiterung (ab Version 1.3!) installiert ist funktionierte diese ohne weitere Konfiguration.

Klasse Formular

2016-03-08T07:58:42Z

Samson1964: /* Beispiel */ select-Beispiel eingefügt

[[Category:Dev HOWTOS]]
[[Category:Dev Snippets]]

'''Github:''' https://github.com/psi-4ward/Formular

= Beispiel =

Die Klasse ''Formular'' erstellt Formulare aus DCA-Arrays:

<source lang="php">
// Die DCA-Definition
$dca = array
(
'Kontaktdaten' => array
(
'label' => 'Ihre Kontaktdaten',
'inputType' => 'headline'
),
'vorname' => array
(
'label' => 'Vorname',
'inputType' => 'text',
'default' => 'vorname',
'eval' => array('mandatory'=>true,'helpmessage'=>'Ihr Vorname')
),
'nachname' => array
(
'label' => 'Nachname',
'inputType' => 'text',
'default' => 'nachname',
'eval' => array('mandatory'=>true,'helpmessage'=>'Ihr Nachname')
),
'datum' => array
(
'label' => 'Datum',
'inputType' => 'text',
'default' => date('d.m.Y'),
'eval' => array('datepicker'=>$this->getDatePickerString(),'cleardefault'=>false)
),

'email' => array
(
'label' => 'E-Mail',
'inputType' => 'text',
'eval' => array('mandatory'=>true,'rgxp'=>'email')
),
'telefon' => array
(
'label' => 'Telefon',
'inputType' => 'text',
'eval' => array('mandatory'=>true)
),
'kategorie' => array
(
'label' => 'Kategorie',
'inputType' => 'checkbox',
'options' => array('Option1','Option2','Option3','Option4'),
'eval' => array('multiple' => true, 'mandatory' => true),
),
'land' => array
(
'label' => 'land',
'inputType' => 'select',
'options' => array('1','2','3','4'),
'reference' => array('1'=>'Peru','2'=>'Kenia','3'=>'Italien','4'='Kamerun'),
'eval' => array('multiple' => true, 'mandatory' => true),
),
'bemerkung' => array
(
'label' => 'Bemerkung',
'inputType' => 'textarea',
'eval' => array('rte'=>'tinyMCE')
),
'submit' => array
(
'label' => 'speichern',
'inputType' => 'submit'
)
);

// Instantierung mit der FormularID meinKontaktformular
$frm = new Formular('meinKontaktformular');

// Übergabe des DCA-Arrays
$frm->setDCA($dca);

// Konfiguration
$frm->setConfig('generateFormat','<div>%label %field %error </div>');
$frm->setConfig('attributes',array('tableless'=>true));

// Formular wurde abgeschickt und ist korrekt
if($frm->isSubmitted() && $frm->validate())
{
var_dump($frm->getData());
}

// Ausgabe des Formulars
echo $frm->parse();
</source>

=Konfiguration=

Es gibt einige Parameter um die Erstellung des Formulars zu beeinflussen.
Grundlegend muss zwischen '''parse()''' und '''generate()''' unterschieden werden, wobei parse() die Methode generate() impliziert.
Formular::parse() bettet den Output von generate() in das ''Template'' ein.

==Parameter==
Die Konfiguration der Klasse Formular kann über '''Formular::setConfig($param,$value)''' geändert werden.

* str '''formTemplate''': Wird das Formular über parse() gerendert wird dieses Template benutzt. Vorgabe: form
* str '''class''': Zusätzliche Klassenangabe
* str '''action''': action-Attribut des <form> Tags. Vorgabe: Environment->request
* str '''method''': method-Attribut des <form> Tags. Vorgabe: post
* str '''generateFormat''': String mit Platzhaltern welche für jedes Widget durch deren Elemente ersetzt werden. Vorgabe "%parse"
%parse Widget::parse()
%label Widget::generateLabel()
%field Widget::generate()
%error Widget::getErrorAsHTML()
%errorPlain Widget::getErrorAsString()
* array '''attributes''': Array mit Attributen für die Widget::parse() Methode. Z.B. array('tableless'=>true)

===Setzen von Default Werten===

Um bei Select, Radio, Checkbox -Feldern die Standardwerte vorzubelegen kann man sich dem Magical-Setter bedienen:

Beispiel:
<source lang="php">
$frm->kategorie = array('Option1','Option2');
</source>

===Anwendungsbeispiel Filter===

Will man einen mehrseitigen Filter mit der Klasse Formular erstellen und die Kriterien beim Blättern (Pagination) erhalten, kann man diese über get paramater (hinzugefügt über addToUrl()) wieder setzen:
<source lang="php">
$frm->kategorie = \Input::get('kategorie');
$frm->branche = \Input::get('branche');
$frm->bundesland = \Input::get('bundesland');
</source>

==Systemweite Konfiguration==
Die Formular-Klasse versucht Konfigurationsoptionen aus $GLOBALS['TL_FORM'] zu lesen.
<source lang="php">
$GLOBALS['TL_FORM'] = array
(
'class' =>'myFormular',
'generateFormat' => '<div class="formField">%label %error %field</div>',
'formTemplate' => 'myFormularTemplate'
)
</source>

=Interaktion mit Erweiterungen=

==cleardefault==

[http://www.contao.org/erweiterungsliste/view/cleardefault.de.html Cleardefault] löscht den Standardwert sobald das Textfeld den Fokus bekommt.
Ist die Erweiterung installiert werden alle Textfelder und Textareas mit diesem Verhalten versehen. Über das @eval@ Array kann es für ein
einzelnes Feld angepasst werden:

<source lang="php">
$dca = array(
'datum' => array
(
'label' => 'Datum',
'inputType' => 'text',
'default' => date('d.m.Y'),
'eval' => array('cleardefault'=>false)
)
);
</source>
''' 'cleardefault'=>false''' deaktiviert das Löschen des Standardwertes für das Feld '''datum'''.

==helpmessage==

[http://www.contao.org/erweiterungsliste/view/helpmessage.de.html Helpmessage] blendet per Javascript Hilfsnachrichten für das Feld ein.
Die Nachricht wird im '''eval''' Array hinterlegt. Falls über die Klasse '''FormularTL_DCA''' eine Tabelle gerendert wird, werden die Hilfstexte aus den Contao-Sprachdateien der Tabelle übernommen.

<source lang="php">
$dca = array(
'datum' => array
(
'label' => 'Datum',
'inputType' => 'text',
'default' => date('d.m.Y'),
'eval' => array('helpmessage'=>'Das Datum muss im Format DD.MM.YYYY sein')
)
);
</source>

==formcheck==

[http://www.contao.org/erweiterungsliste/view/formcheck.de.html Formcheck] validiert ein Formular per Javascript auf der Clientseite.
Falls die Erweiterung (ab Version 1.3!) installiert ist funktionierte diese ohne weitere Konfiguration.