TypoScript

Verwendung des ApplicationContext in TYPO3

caticonslite_bm_alt

TYPO3 bietet die Möglichkeit die Applikation in unterschiedlichen Kontexten (z.B. Development, Staging und Production) laufen zu lassen. Hierfür wird mittels Webserver-Konfiguration die Environment-Variable „TYPO3_CONTEXT“ gesetzt. Ein mögliche Variante zum Setzen des Kontexts befindet sich in der .htaccess-Beispieldatei aus dem typo3_src-Ordner, in angepasster und optimierter Form sieht dies wie folgt aus:

RewriteRule .? - [E=TYPO3_CONTEXT:Production]
RewriteCond %{HTTP_HOST} =staging.webentwickler.at
RewriteRule .? - [E=TYPO3_CONTEXT:Production/Staging]
RewriteCond %{HTTP_HOST} =dev.webentwickler.at
RewriteRule .? - [E=TYPO3_CONTEXT:Development]

Im o.g. Beispiel wird standardmäßig der TYPO3_CONTEXT bzw. in weiterer Folge der ApplicationContext auf „Production“ gesetzt. Für den Hostnamen „staging.webentwickler.at“ wird der Kontext „Production/Staging“ und für „dev.webentwickler.at“ der Kontext „Development“ gesetzt.

Der somit gesetzt Kontext kann nun in TypoScript bzw. direkt im Programmcode verwendet werden. Grundsätzlich wäre es  möglich den Kontext via Environment-Variable abzufragen, darauf sollte aber verzichtet werden und stattdessen die vom TYPO3-Core bereitgestellten Wrapper-Methoden verwendet werden, da es z.B. bei der Verwendung von php_fpm zu veränderten Environment-Variablen (REDIRECT_-Präfix, z.B.: REDIRECT_TYPO3_CONTEXT) kommen kann. In TypoScript verwendet man:

[applicationContext = Development]
	plugin.tx_webentwickler.settings.email = test@dev.webentwickler.at
[global]

Im PHP-Code (hier: „AdditionalConfiguration.php“):

if (\TYPO3\CMS\Core\Utility\GeneralUtility::getApplicationContext() == 'Development') {
	$GLOBALS['TYPO3_CONF_VARS']['SYS']['displayErrors'] = 1;
}

In einer sauber programmierten Anwendung sollte es grundsätzlich so sein, dass sämtliche Konfigurationen in TypoScript vorgenommen werden und somit die Verwendung der Methode getApplicationContext() im Programmcode nicht erforderlich sein, sondern ausschließlich auf die Konfigurationsdatei beschränken sollte.

Weitere Informationen zur Verwendung findet man in der TypoScript Reference unter Condition reference/applicationContext.

Upgrade auf Gridelements 3

caticonslite_bm_alt

Die Aktualisierung von Gridelements 1.x auf Version 3.x ist mit wenigen Schritten erledigt.

1. Upgrade von Gridelements:

Im Extension Manager, via Git oÄ die bestehende Version auf Gridelements 3 aktualisieren. Im TYPO3 Frontend erscheint nun folgender Fehler, der sich mit dem nächsten Schritt beseitigen lässt:

Fatal error: Class 'tx_gridelements_pi1' not found in /home/typo3cms-project/public_html/typo3_src/typo3/sysext/core/Classes/Utility/GeneralUtility.php on line 4364

2. Anpassen der TypoScript-Template Integration:

Der Pfad der TypoScript-Dateien hat sich geändert, daher müssen unter Web > Template abhängig von der verwendeten Konfiguration entweder die statischen Templates erneut hinzugefügt oder eventuelle „INCLUDE_TYPOSCRIPT“-Anweisungen angepasst werden – z.B. in den TypoScript-Constants:

#<INCLUDE_TYPOSCRIPT: source="FILE:EXT:gridelements/static/gridelements/constants.txt">
<INCLUDE_TYPOSCRIPT: source="FILE:EXT:gridelements/Configuration/TypoScript/constants.txt">

und im Typoscript-Setup:

#<INCLUDE_TYPOSCRIPT: source="FILE:EXT:gridelements/static/gridelements/setup.txt">
<INCLUDE_TYPOSCRIPT: source="FILE:EXT:gridelements/Configuration/TypoScript/setup.txt">

3. Update der Datenbank:

Die Speicherung der in Gridelements enthaltenen Contentelemente hat sich mit Gridelements 2 ebenfalls geändert. Damit diese Elemente nicht doppelt (im Gridelements-Container und von TYPO3 selbst) ausgegeben werden, müssen die Records in der Datenbank angepasst werden (Datenbank-Backup erstellen!):

UPDATE tt_content SET colPos = -1 WHERE tx_gridelements_container > 0;

Individuelle Rahmen für Content Elemente

caticonslite_bm_alt

Um Inhaltselementen (engl. Content Elements) in TYPO3 ein individuelles Aussehen zu verpassen (z.B. Überschrift und Text in einer abweichenden Farbe), hat man die Möglichkeit vordefinierte Rahmen zu verwenden oder auch eigene festzulegen. Die Einstellung „Einrückung und Rahmen“ (engl. „Indentation and Frames„) befindet sich in den Eigenschaften jedes (Standard-)Inhaltselements auf der Registerkarte „Erscheinungsbild“ (engl. „Appearance„). Damit die Einstellung dargestellt wird, muss „Zweite Optionspalette anzeigen“ (engl. „Show secondary options (palettes)„) am Ende in den Eigenschaften aktiviert sein.

Abhängig davon, welcher Wert für „Einrückung und Rahmen“ ausgewählt wird, werden unterschiedliche CSS-Klassen im HTML-Quelltext ausgegeben. Die vordefinierte Option „Standardframe“ führt beispielsweise zur Ausgabe der CSS-Klasse „csc-default“.

Um einen individuellen Rahmen festzulegen, fügt man im PageTS folgende Zeilen ein:

TCEFORM.tt_content {
	section_frame.addItems.101 = Individueller Rahmen
	section_frame.addItems.102 = Weiterer individueller Rahmen
}

Die Zahlen „101“ und „102“ stehen in diesem Beispiel für die IDs der Rahmen (um nicht unbeabsichtigt vordefinierte Rahmen zu überschreiben sollten Zahlen größer als 100 gewählt werden), „Individueller Rahmen“ und „Weiterer individueller Rahmen“ für die Beschreibungen, die als Optionen angezeigt werden. Anstelle einer hardcodierten Beschreibung, wie in diesem Fall, ist der Verweis auf eine Sprachdatei empfehlenswert (z.B.: „section_frame.addItems.101 = LLL:EXT:webentwickler_at/Resources/Private/Language/locallang_ttc.xlf:section_frame.I.101“).

Im TypoScript-Setup muss noch das gewünschte Verhalten festgelegt werden:

tt_content.stdWrap.innerWrap.cObject {
	101 =< tt_content.stdWrap.innerWrap.cObject.default
	101.20.10.value = csc-frame csc-frame-individual
 
	102 = TEXT
	102.value = <div class="another-individual-frame">|</div>
}

In diesem Beispiel erfolgt das Rendering des Rahmens „[101] Individueller Rahmen“ analog zu den vordefinierten Rahmen und es können sämtliche css_styled_content-Eigenschaften (z.B. „Oberer Abstand“ (engl. „Top Margin“)) verwendet werden. Für „[102] Weiterer individueller Rahmen“ ist dies nicht der Fall und es wird ausschließlich o.g. HTML-Tag als Rahmen verwendet.

Frontend Page Rendering Template anpassen

caticonslite_bm_alt

In TYPO3 lässt sich so gut wie alles konfigurieren, auch das Page Rendering Template lässt sich anpassen. Dieses Template legt die HTML-Struktur der Seite fest, d.h. an welche Position Titel, JavaScript, CSS, etc. eingefügt werden. Der Template-Pfad lässt sich im TypoScript-Setup mit der Anweisung „config.pageRendererTemplateFile“ setzen, das Standard-Template ist unter „typo3/sysext/cms/tslib/templates/tslib_page_frontend.html“ zu finden.

Möchte man beispielsweise nur Conditional Comments einfügen, um den Browser zu identifizieren und CSS-Hacks zu vermeiden  (siehe Blog-Eintrag von Paul Irish), so kann man entweder Hooks im PageRenderer (typo3/sysext/core/Classes/Page/PageRenderer.php) oder auf die TypoScript-Konfigurationsoptionen im PageGenerator (typo3/sysext/frontend/Classes/Page/PageGenerator.php) zurückgreifen. Um den HTML-Tag zu erweitern lässt sich beispielsweise „config.htmlTag_stdWrap“ verwenden.

Mehrsprachigkeit in TYPO3 konfigurieren

caticonslite_bm_alt

Um Mehrsprachigkeit in TYPO3 zu aktivieren sind mehrere Schritte erforderlich. Der hier dargestellte Weg zeigt eine mögliche Variante auf, besonders hinsichtlich RealURL sind viele unterschiedliche Konfigurationen möglich.

1. Sprache im Backend aktivieren:

Im Modul „Web > Liste“ (engl. „Web > List“) wählt man die Rootseite mit der ID „0“ (Seite mit vorangestelltem TYPO3-Symbol) aus. Nun fügt man einen neuen Datensatz vom Typ „Alternative Seitensprache“ (engl. „Website language“) ein und füllt die erforderlichen Felder aus. Die hier festgelegten Werte haben keinerlei Relevanz für die weitere Konfiguration, sondern dienen nur der Unterscheidung für Benutzer. Nach dem Speichern sucht man sich die Objekt-ID(s) im Modul „Web > Liste“ der angelegten Sprachen heraus, z.B. indem man mit der Maus auf die gewünschte Flagge zeigt. Die Standardsprache ist nicht anzulegen und hat implizit die ID 0 – in diesem Fall ist dies „Deutsch“. Als alternative Sprachen wurden „English“ mit der ID 1 und Italiano mit der ID 2 angelegt.

2. TypoScript-Setup:

config {
	linkVars = L(0-2)
	uniqueLinkVars = 1
	defaultGetVars.L = 0
	language = de
	locale_all = de_AT.UTF-8
	sys_language_uid = 0
	htmlTag_langKey = de
}
[globalVar = GP:L = 1]
	config {
		language = en
		locale_all = en_GB.UTF-8
		sys_language_uid = 1
		htmlTag_langKey = en
	}
[globalVar = GP:L = 2]
	config {
		language = it
		locale_all = it_IT.UTF-8
		sys_language_uid = 2
		htmlTag_langKey = it
	}
[global]

Die Einstellung „linkVars“ legt hier fest, dass der Parameter „L“ im Wertebereich 0-2 bei der Erzeugung von Links immer berücksichtigt wird. Hat man mehr oder weniger Sprachen, muss der Wertebereich entsprechend angepasst werden. Damit Parameter in der URL nur ein Mal vorkommen, wird „uniqueLinkVars“ aktiviert, andernfalls könnten URLs im Format „?L=0&L=2“ erzeugt werden.

Die Zahlen in den Bedingungen/Conditions (z.B.: „[globalVar = GP:L = 1]“) und für den Parameter „sys_language_uid“ (z.B.: „sys_language_uid = 1“) entsprechen den IDs der im ersten Schritt angelegten Sprachen.

Der Parameter „locale_all“ muss an die installierten Systemsprachen angepasst werden und ist erforderlich um beispielsweise das Datum in der korrekten Sprache auszugeben.

3. RealURL: (Die Konfiguration ist hier nur auszugsweise dargestellt):

// [...]
'preVars' => array(
	// [...]
	'GETvar' => 'L',
	'valueMap' => array(
		'de' => 0,
		'en' => 1,
		'it' => 2,
	),
	'noMatch' => 'bypass',
	// [...]
),
// [...]

Damit die 404-Fehlerbehandlung auch auf der ersten Ebene korrekt funktioniert, muss für alle „preVars“ die Option „’noMatch‘ => ‚bypass'“ aktiviert und es darf „postVarSet_failureMode“ nicht gesetzt sein.

4. Sprachkürzel in der URL:

Die gezeigte Konfiguration würde für die Default-Sprache Links im Format „domain.tld/seite/“ generieren, Links für zusätzliche Sprachen im Format „domain.tld/sprache/seite/“ (z.B.: „domain.tld/en/page/“). Möchte man auch bei der Standardsprache das Kürzel in der URL haben, muss man mit dem TypoScript-Setup „config.defaultGetVars.L = 0“ den Standardwert setzen. Würde man in der RealURL-Konfiguration anstelle für „’noMatch‘ => ‚bypass'“ die Option „‚valueDefault‘ => ‚de'“ setzen, würde man zwar das selbe URL-Format erreichen, allerdings würde die 404-Fehlerbehandlung auf der ersten Ebene nicht mehr funktionieren.

1 2  nach oben