TYPO3 CMS

TYPO3 mit Komprimierung auf Plesk-Host mit Reverse Proxy nginx

caticonslite_bm_alt

Wird in TYPO3 die Frontend-Komprimierung mit „$GLOBALS[‚TYPO3_CONF_VARS‘][‚FE‘][‚compressionLevel‚] = 9″ und in den TypoScript-Setup-Einstellungen „config.compressJs“ bzw. „config.compressCss“ aktiviert, werden statische „pre-rendered“ JavaScript- und CSS-Dateien im gzip-Format im Ordner „typo3temp/compressor“ abgelegt. Für die korrekte Auslieferung ist für Apache (z.B. in der Datei .htaccess) die folgende Konfiguration erforderlich:

<FilesMatch "\.js\.gzip$">
	AddType "text/javascript" .gzip
</FilesMatch>
<FilesMatch "\.css\.gzip$">
	AddType "text/css" .gzip
</FilesMatch>
AddEncoding gzip .gzip

Seit Plesk 12 wird nginx als Reverse Proxy eingesetzt und statische Dateien werden nicht mehr von Apache, sondern direkt von nginx ausgeliefert. Das führt dazu, dass nginx die Dateien zwar mit dem korrekten „Content-Type“, aber ohne erforderliches „Content-Encoding: gzip“ im HTTP-Header ausliefert und infolgedessen die Dateien vom Browser falsch (so als wären sie nicht komprimiert) interpretiert werden. Analog zur o.g. Konfiguration für Apache ist auch eine Konfiguration für nginx erforderlich: In Plesk kann unter „Einstellungen für Apache & nginx“ der Domain entweder die Option „Intelligente Bearbeitung statischer Dateien“ deaktiviert werden (nicht empfohlen), oder folgende Konfiguration unter „Zusätzliche nginx-Anweisungen“ hinterlegt werden:

location ~ "\.js\.gzip$" {
	add_header Content-Encoding gzip;
	gzip off;
	types { text/javascript gzip; }
}
location ~ "\.css\.gzip$" {
	add_header Content-Encoding gzip;
	gzip off;
	types { text/css gzip; }
}

Diese Konfiguration bringt nginx dazu die komprimierten JS- und CSS-Dateien analog zu Apache zu behandeln und das erforderliche „Content-Encoding: gzip“ im HTTP-Header zu setzen.

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 = [email protected].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.

Überschriften in TYPO3 umbenennen

caticonslite_bm_alt

In TYPO3 lassen sich Überschriften direkt im Content Element/Inhaltslement und im Rich Text Editor (RTE) festlegen. Die vordefinierten Labels „Layout x“ bzw. „Headline x“ sind wenig aussagekräftig und für Redakteure nicht ausreichend beschreibend. Beide Arten von Labels lassen sich wie folgt anpassen.

Anlegen der Übersetzungsdatei (z.B. in „EXT:projektkonfiguration/Resources/Private/Language/locallang_db.xlf“):

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<xliff version="1.0">
	<file source-language="en" datatype="plaintext" original="messages" date="2014-09-249T09:33:00Z" product-name="projektkonfiguration">
		<header/>
		<body>
			<trans-unit id="label.h1">
				<source>Main headline</source>
			</trans-unit>
			<trans-unit id="label.h2">
				<source>Headline</source>
			</trans-unit>
			<trans-unit id="label.h3">
				<source>Sub headline</source>
			</trans-unit>
		</body>
	</file>
</xliff>

Zusätzlich kann können auch noch Übersetzungen z.B. für Deutsch angelegt werden.

Zuweisen der Überschriften-Labels für Content Element in User- oder PageTS:

TCEFORM.tt_content.header_layout {
	altLabels.1 = LLL:EXT:projektkonfiguration/Resources/Private/Language/locallang_db.xlf:label.h1
	altLabels.2 = LLL:EXT:projektkonfiguration/Resources/Private/Language/locallang_db.xlf:label.h2
	altLabels.3 = LLL:EXT:projektkonfiguration/Resources/Private/Language/locallang_db.xlf:label.h3
}

Zuweisen der Überschriften-Labels für den RTE in User- oder PageTS:

RTE.default.buttons.formatblock.items {
	h1.label = LLL:EXT:projektkonfiguration/Resources/Private/Language/locallang_db.xlf:label.h1
	h2.label = LLL:EXT:projektkonfiguration/Resources/Private/Language/locallang_db.xlf:label.h2
	h3.label = LLL:EXT:projektkonfiguration/Resources/Private/Language/locallang_db.xlf:label.h2
}

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;

Upgrade auf TYPO3 6.2

caticonslite_bm_alt

Für ein erfolgreiches Upgrade auf TYPO3 6.2 gibt es aufgrund der individuellen Seitenkonfigurationen kein Patentrezept, dieser Beitrag soll einen Leitfaden der in jedem Fall erforderlichen bzw. sinnvollen Schritte darstellen. Upgrades auf TYPO3 6.2 sind ausgehend von TYPO3 4.5 oder höher möglich.

0. Überprüfen der Systemvoraussetzungen:
Bevor mit dem Upgrade begonnen wird, sollten die Systemvoraussetzungen (insb. PHP- und MySQL-Versionen) überprüft und ggf. angepasst werden. Die Systemvoraussetzungen sind auf der TYPO3 Download-Seite ersichtlich. Auf größeren Installationen müssen ggf. die PHP-Umgebungsvariablen „memory_limit“ und „max_execution_time“ während des Vorgangs angepasst werden.

1. Backup von Datenbank und Dateien anlegen:
Vor dem Upgrade sollten unbedingt Datenbank und Dateien der bestehenden Installation gesichert werden. Wenn SSH-Zugriff besteht bietet es sich an „mysqldump“ und „tar“ zum Erstellen der Backups zu verwenden:

mysqldump -uUsername -p -hHostname Database > public_html/typo3conf/ext/dump.sql
tar cJf backup.tar.xz public_html

Alternativ kann das Backup auch mit FTP-Zugriff und z.B. phpMyAdmin erstellt werden.

2. Kopie der Installation für das Upgrade anlegen:
Das Upgrade der Installation wird idealerweise auf einer Arbeitskopie der bestehenden Installation durchgeführt und wird mit dem in Schritt 1 erstellten Backup erzeugt. Damit wird zugleich sichergestellt, dass das Backup funktioniert und im Fehlerfall eine Wiederherstellung damit möglich ist:

tar xJf backup.tar.xz public_html
mysql -uDevUsername -p -hDevHostname DevDatabase < public_html/typo3conf/ext/dump.sql

Abschließend müssen noch die Verbindungsdaten der Datenbank in „public_html/typo3conf/localconf.php“ angepasst werden.

3. Update des TYPO3 Core:
Als erster Schritt im Upgrade-Prozess erfolgt die Aktualisierung des TYPO3 Core auf die aktuellste Patch-Version. Ist beispielsweise TYPO3 4.7.17 installiert, erfolgt die Aktualisierung auf TYPO3 4.7.19. Dies ist mit dem Ersetzen des „typo3_src“-Verzeichnisses erledigt.

4. Aufräumen der Installation:
Zuerst werden alle nicht mehr benötigten Extensions im „Extension Manager“ deinstalliert und endgültig vom System gelöscht. Anschließend führt man im „Database Analyser“ des „Install Tool“ mit „COMPARE“ ein Update der Tabellen durch. Als nächstes erfolgt die Aktualisierung des „Reference Index“ (Extension „lowlevel“ muss hierfür installiert sein) im Modul „Admin tools > DB check“ bzw. über die Konsole (Hinweise siehe „Admin tools > DB check“). Abschließend können optional noch alle Tabellen mit temporären Daten (Cache-Tabellen, Logs, etc.) geleert werden.

5. Update bzw. Upgrade der Extensions:
Als nächstes werden die verbleibenden Extensions auf die letzte mit dem aktuell installierten TYPO3 Core kompatible Version aktualisiert (zuvor „Retrieve / Update“ des Extension Repository durchführen und Aktualisierungshinweise in der Dokumentation der Extensions berücksichtigen!). Sind Extensions in einer Version mit TYPO3 < 6.2 und in der nächsten mit TYPO3 > 6.2 kompatibel (d.h. es gibt keine Version die mit beiden TYPO3 Core-Versionen kompatibel ist), werden diese deinstalliert (allerdings nicht gelöscht) und erst nach dem Upgrade des TYPO3 Core wieder installiert.

6. Smoothmigration:
Als nächstes im „Extension Manager“ die Extension „smoothmigration“ installieren, die Anforderungen bzgl. Extbase und Fluid können ignoriert werden und nach der Installation „Clear all caches“ ausführen. Anschließend im Modul „Admin tools > Smooth Migration“ „Run all checks“ ausführen und abschließend alle in „Show report“ dargestellten Mängel beheben.

7. Upgrade des TYPO3 Core:
Nun wird der TYPO3 Core auf 6.2 aktualisiert und das nicht mehr in Verwendung befindliche Verzeichnis „t3lib“ gelöscht. Im folgenden Beispiel ist „typo3_src“ als Git-Submodule eingebunden:

cd public_html/typo3_src/
git fetch
git checkout tags/TYPO3_6-2-4
cd ..
git rm t3lib
git add typo3_src
git commit -m "[TASK] upgrade of TYPO3 core to v6.2.4"

8. Datenbank aktualisieren, Caches leeren und „Upgrade Wizard“ ausführen:
Achtung: In diesem Schritt dürfen keine Tabellen oder Spalten gelöscht werden, da sonst Daten der in Schritt 5 vorübergehend deaktivierten Extensions verloren gehen würden!
Um die Datenbank zu aktualisieren wird das „Install Tool“ direkt und nicht über das Backend aufgerufen (z.B. „http://webentwickler.at/typo3/install/“). Zuerst werden unter „Folder structure“ u.a. fehlende Order mit „Try to fix file and folder permissions“ angelegt. Anschließend wird unter „Important actions“ „Compare current database with specification“ aufgerufen und ausschließlich die vorselektierten Aktionen ausgeführt. Danach unter „Important actions“ „Clear all cache“ ausführen, daraufhin im „Upgrade Wizard“ alle Schritte einzeln durchführen. Abschließend erneut „Clear all cache“ unter „Important actions“ ausführen.

9. Reaktivierung der Extensions:
Zurück im Backend wird im „Extension Manager“ „Get extensions“ aufgerufen, um die neuesten Informationen des TER zu laden. Danach werden mit TYPO3 6.2 kompatible Updates der in Schritt 5 deaktivierten Extensions über „Get extensions“ installiert (Aktualisierungshinweise in der Dokumentation der Extensions berücksichtigen!).

Damit sollte das Upgrade abgeschlossen sein.

1 2 3 5  nach oben