In der typo3conf/localconf.php oder der speziellen RealURL-Konfigurationsdatei:

// Allgemeine Konfiguration
$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array(
 //realurl konfiguration...
);
$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT']['pagePath']['rootpage_id'] = 1;//id der Hauptseite
 
// Domain 2
$TYPO3_CONF_VARS['EXTCONF']['realurl']['www.domain2.de'] = $TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'];
$TYPO3_CONF_VARS['EXTCONF']['realurl']['www.domain2.de']['pagePath']['rootpage_id'] = 76;//id der Hauptseite von Domain 2

Jetzt noch in der Listenansicht der Hauptseite der 2. Domain ein Domain Record anlegen mit dem Wert “www.domain2.de” und im besten Fall funktioniert es nun schon.

Lösung Teil 2

Doch bei mir lag ein anderes Problem vor. Ich hatte mit der Konfigurationsdatei rumgespielt und es klappte dennoch nicht. Stattdessen die Fehlermeldung:

“ID was outside the domain”

Das lag daran, dass ich zwischenzeitlich versehentlich mal die “rootpage_id” meiner ersten Domain (_DEFAULT) auch auf den Wert der 2. gesetzt hatte. Um dieses Problem zu lösen, muss nach der Änderung aus Teil 1 zusätzlich für beide Seitenbäume (1. und 2. Domain!)  das ID-to-path mapping gelöscht werden!

Das geschieht unter “Info->Speaking URL Management->ID-to-path mapping” Hier die Rekursion auf unendlich stellen und auf den kleinen Mülleimer über der Kopfzeile klicken. Fertig!

pro TYPO3*:

“Die Templates sind völlig standardisierte W3C-konforme Templates, [...] man kann per Point & Click durch einen Wizard gehen und so innerhalb von Minuten sein komplettes Template mappen.”

“[...] ist das System bei richtigem Einsatz [...] automatisch upgradebar, was es in großen Umgebungen sehr beliebt bei den IT-Abteilungen macht”

“TYPO3  4.x hat klare Roadmaps und einen fest definierten sechsmonatigen Release-Zyklus für Major Releases und derzeit läuft ja auch schon parallel ein Rewrite des gesamten Systems (5.x Codename Phoenix)”

“TYPO3 hat vor allem diese Entscheidung zu einer Enterprise-Architektur schon vor drei Jahren getroffen, das heißt hier ist schon ein klarer Vorsprung zu vermerken.”

pro Drupal*:

“Man kann nun mit dem fantastischen Views-Modul „Views“ (Auswahl und Präsentation von Inhalten) von jeder möglichen Mischung der Entities bauen. Noch besser: Views können von jeder erdenklichen Daten-Quelle gebaut werden”

“Drupal ist Pionier in Sachen Semantic Data”

“Drupals Bedienungskonzept unterscheidet nicht besonders stark zwischen Front- und Back-End. [...] Um einen Inhalt zu editieren, muss man nur dahin navigieren – wenn der Benutzer die entsprechende Freigaben hat, kann er editieren. Simpel aber effektiv”

“Im Drupal 7 Release-Zyklus geht der ganze Core-Code durch ein „integrated testing framework“. Dies wird demnächst ein „distributed CI performance testing network“ werden, welches dann auch alle Community-Module testen wird.”

contra TYPO3*:

“TYPO3 und Extensions wird ab und an vorgeworfen, zu komplexen und schwierigen Code zu haben. Das trifft auch auf einige Module zu [...]“

contra Drupal*:

“Um in Drupal annähernd die Features von TYPO3 darzustellen, brauche ich ca. 60 Drupal-Module, mit zig Abhängigkeiten.”

“Drupals Standard-Templating-System ist eine Mischung aus HTML und PHP”

contra beide*:

“Andererseits werden Frameworks immer die beste Lösung sein für Systeme, die wirklich einzigartig sind oder nicht von den großen Vorleistungen eines CMS wie Drupal oder TYPO3 profitieren können.”

* alle Zitate: CMS-Battle: TYPO3 vs Drupal – Wettkampf über 20 Runden » t3n News

Mein Fazit

Ich habe Erfahrungen mit beiden CMS sowie mit WordPress gesammelt, und ich arbeite auch noch immer mit beiden CMS. Es handelt sich bei TYPO3 und Drupal um zwei völlig unterschiedliche Herangehensweisen, wobei die allgemeinen Anforderungen an Internetseiten der vergangenen Jahre deutlich für Drupal sprechen. Das will ich begründen.

Drupal hat keine Baum-Struktur für den Seitenaufbau

Bei Drupal ist ähnlich wie bei WordPress die Seite erst einmal leer und kann relativ wenig. Die Seitenstruktur ist nicht wie bei TYPO3 als Baum dargestellt. Der Baum hat zwar Vorteile (z.B. drag and drop Seiten verschieben), drängt den Admin jedoch erst mal gedanklich in die Richtung, dass die Seite eine Ordner-Struktur in die Tiefe hat. Diese Verschachtelung von Webseiten hat aber abgenommen. Youtube hat vor Jahren schon gezeigt, dass man Unmengen an Content ohne tiefe Verschachtelung darstellen kann. Dagegen wirkt so manche Universitäts-Webseite mit TYPO3 überfüllt und träge.

Stattdessen hat Drupal CCK, Taxonomien und Views

Die Strukturierung der Inhalte bei Drupal kann sowohl in Menüs als auch auf andere Weise geschehen. Wo TYPO3-Nutzer immer wieder auf tt_news zurückgreifen, um auch andere Arten von Objekten zu kategorisieren, ist es in Drupal schnell möglich, eigene Objekttypen (Content Types) mit dem Content Construction Kit (CCK) zu erstellen, diese dann durch jede Art von Taxonomien (Kategorien und/oder Tags) zu kennzeichnen, und dann mit “Views” auf komplexeste Art zu sortieren und als Listen, RSS-Feeds oder wie auch immer auszugeben. Views kann zudem noch auf externen Content irgendwo im Netz zugreifen, so auch demnächst sogar per SPARQL.

Was TYPO3 unbedingt ändern sollte

TYPO3 hat auch Vorteile, und das sind die Dinge wie TemplaVoila, Typoscript, der Dateimanager, was jedoch schon vor Jahren erfunden wurde und bestimmt auch die Entscheidung vieler für TYPO3 als CMS bedingt hat. MVC-Struktur ist toll, aber das ist eben nur eine Voraussetzung des Systems für gute Arbeit, jedoch noch kein gute Arbeit an sich. Es sind nicht viele Dinge, die TYPO3 ändern muss, um an Drupal dran zu kommen. Die Lösung sind meiner Meinung nach 3 Erweiterungen. Wer sich an der Entwicklung beteiligen will bzw. diese sponsoren möchte, der melde sich bitte bei mir!

1. Taxonomy

Taxonomien, also Tags und Kategorien dürfen nicht weiter an einzelnen Module und Inhaltstypen gebunden sein. Man muss sie aus dem Backend egal welchem Inhaltstyp zuordnen können, also allen Dingen, die auch in der Listenansicht auffindbar sind.

1. User Content Types

Es muss endlich eine Extension her, die das Erstellen von angepassten Inhaltstypen ermöglicht. Das darf nicht weiterhin tt_news sein. Dazu gehören dann auch bestimmte Felder wie Bild, Datei, Link, Upload sowie Verknüpfung zu allen anderen Content Types.

3. Views

Man braucht etwas anderes als Typoscript, um diverse Content Types sowie sonstige Inhalte aus der Datenbank auszugeben. Das Views-Modul bei Drupal ist absolut vorbildlich mit dem, was alles möglich sein kann. Hieran sollte man anknüpfen und eine ähnliche Erweiterung entwickeln.

Diese drei Module sind meiner Meinung nach die Grundvoraussetzung für flexible Seitengestaltung in TYPO3.

Für Hinweise, welche TYPO3-Extensions diese Möglichkeiten bereits bieten, sowie für Vorschläge, was man sonst noch von Drupal lernen kann, bin ich offen. Schreibt einfach Kommentare auf diese Seite.

Indexed Search – Metatags ignorieren  – typo3-tutorials.org

Ab der TYPO3-Version 4.2 lässt sich das indiziieren von Meta-Tags in der Extension indexed_search endlich per TS-Setup abschalten. Man muss nicht mehr wie in den Versionen zuvor im Quelltext der Extension hardcoden. Hier das TS-Setup:

config.index_metatags =
page.config.index_metatags =