Aktuell kann Contao 4 nur über Composer installiert werden.
git clone -b develop https://github.com/contao/standard-edition.git cd standard-edition curl -sS https://getcomposer.org/installer | php php composer.phar install
curl -sS https://getcomposer.org/installer | php php composer.phar create-project contao/standard-edition contao4 4.0.0
Übersetzungen lassen sich mit Hilfe des Transifex-Clients installieren.
for i in $(ls -d vendor/contao/*-bundle); do \ cd $i; \ tx pull -l de; \ cd -; \ done;
Damit Symfony im Browser aufgerufen werden kann, muss der Webserver entsprechend angepasst werden.
/webapp.phpDer Ordner /web enthält bereits eine .htaccess-Datei mit den Standard-Einstellungen*.
Weitere Informationen für alle gängigen Webserver gibt es auf
symfony.com.
* Erst nach dem Release der RC hinzugekommen.
In Contao 3 gibt es für jede Route einen Entry-Point, also eine PHP-Datei wie z.B.
contao/main.php. In Symfony gibt es jedoch nur einen Entry-Point (web/app.php) und
die Routen müssen konfiguriert werden.
Informationen zum Symfony-Routing gibt es auf symfony.com.
Die Datei web/app_dev.php ist ein zweiter Entry-Point, der automatisch den Debug-Mode
aktiviert.
Im Debug-Mode lädt Symfony den Web-Profiler, der detaillierte Informationen über die Applikation liefert.
Die Funktion dump() wird in Contao 4 auf das Debug-Bundle gemappt und integriert ihre Ausgabe
direkt in den Web-Profiler.
Die Funktion ist nur vorhanden, wenn sich der Kernel im Debug-Modus befindet (standardmäßig beim
Aufruf der Applikation über app_dev.php).
Bundles sind First-Class-Objekte in Symfony, die den benötigten Glue-Code enthalten, um Ressourcen in die Applikation zu integrieren.
Auch Contao 4 besteht jetzt aus Symfony-Bundles, die im Ordner /vendor/contao liegen.
contao/core-bundlecalendar-bundle, comments-bundle,
faq-bundle, listing-bundle, news-bundle und
newsletter-bundleWeitere Informationen: Bundles erstellen und Bundles Best-Practice
Extensions werden Bundles
Wir empfehlen euch folgende Ordnerstruktur:
src/
.../ <-- neue PHP-Klassen nach PSR-4
Resources/
config/
contao/ <-- der bisherige Contao-Code
public/ <-- öffentliche Ressourcen
DemoBundle.php
tests/
.../ <-- die Unit-Tests für die neuen Klassen
bootstrap.php
CHANGELOG.md
composer.json
phpunit.xml.dist
README.md
<-- Transifex-Konfiguration
<-- Bisherige Contao-Dateien
<-- Öffentliche Ressourcen
<-- Bundle-Klasse
namespace Contao\CalendarBundle;
use Symfony\Component\HttpKernel\Bundle\Bundle;
/**
* Configures the Contao calendar bundle.
*
* @author Leo Feyer <https://github.com/leofeyer>
*/
class ContaoCalendarBundle extends Bundle
{
}
Bundles müssen im App-Kernel registriert werden:
// app/AppKernel.php
public function registerBundles()
{
// Reihenfolge beachten, falls Ressourcen überschrieben werden sollen
$bundles = [
new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
new Contao\CoreBundle\ContaoCoreBundle(),
new Contao\CalendarBundle\ContaoCalendarBundle(),
];
// ...
return $bundles;
}
Extensions installieren
Alte Erweiterungen, die noch keine Bundles sind und noch in /system/modules liegen, können
ebenfalls installiert werden.
/system/modules kopieren*app/console contao:symlinks* Die Installation mittels Composer ist in Arbeit.
** Nur notwendig, wenn die
Erweiterung einen öffentlichen Unterordner beinhaltet.
Um alte Erweiterungen im App-Kernel zu registrieren, steht die Klasse ContaoModuleBundle
zur Verfügung:
// app/AppKernel.php
use Contao\CoreBundle\HttpKernel\Bundle\ContaoModuleBundle;
public function registerBundles()
{
$bundles = [
new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
new Contao\CoreBundle\ContaoCoreBundle(),
new ContaoModuleBundle('repository', $this->getRootDir()),
];
// ...
return $bundles;
}
Refactoring
Der bisherige Contao-Code sollte nach und nach refactored werden, bis der Ordner
src/Resources/contao irgendwann leer ist.
Fabien Potencier, der Erschaffer von Symfony, hat die Symfony Best-Practices für das Arbeiten mit dem Framework veröffentlicht.
/tests anstatt in /src/TestsDie Best-Practices gelten für die Entwicklung einer App mit Symfony. Die Entwicklung eines
Vendor-Bundles weicht an manchen Stellen ab (z.B. liegen die Bundle-Ressourcen in
/vendor/**/src/Resources anstatt in /app/Resources).
Wir empfehlen den "fat models, thin controllers"-Ansatz.
Es gibt unzählige Tools zur Qualitätskontolle in PHP.
Es gibt Webservices, die diese Tools bereitstellen und euren Code automatisch prüfen (kontinuierliche Integration). Die meisten sind kostenlos für Open-Source-Projekte.
Das Symfony Request-Respone-Konzept sieht es vor, dass jeder Controller entweder ein Response-Objekt zurückgibt oder eine Exception wirft.
In Contao wurde die Antwort an den Client jedoch bisher durch die Methode Template::output()
erzeugt, welche in Contao 4 nun veraltet ist und in einer zukünftigen Version entfernt wird.
Template::getResponse()throw new ResponseException(new Response($str))/contao/core-bundle/src/Exception/*.phpDas Contao Core-Bundle enthält mehrere Markdown-Dateien mit Informationen für Entwickler:
UPGRADE.md: nicht rückwärtskompatible ÄnderungenDEPRECATED.md: veraltete Ressourcen, die demnächst entfernt werden
Weitere Entwickler-Informationen gibt es auf docs.contao.org.
Beginnend mit Contao 4 verwenden wir semantische Versionierung.
Nicht jeder rückwärtsinkompatible Änderung ist auch eine API-Änderung!
@internal gekennzeichnet sindTemplates sind explizit nicht Teil der API und können sich daher auch in Minor- oder Bugfix-Versionen ändern, selbst wenn dadurch Stylesheet-Anpassungen notwendig werden.
Noch Fragen?
Vielen Dank für die Aufmerksamkeit