1. TYPO3 im Allgemeinen

1.1. Extensions

1.1.1. Dateistruktur einer Extension

Extensions sind immer wie folgt aufgebaut. Grundsätzlich gilt bei der Struktur „Convention over Configuration“. Viele Strukturen sind nicht zwingend notwendig, erleichtern das Leben aber.

extension_key
├── Classes
│   ├── Command
│   │   └── ExampleCommandController.php
│   ├── Controller
│   │   └── ExampleController.php
│   └── Domain
│       └── Model
│           └── Example.php
├── composer.json
├── Configuration
│   ├── TCA
│   │   └── Overrides
│   │       └── tt_content.php
│   └── TypoScript
│       ├── constants.typoscript
│       └── setup.typoscript
├── Documentation
├── ext_conf_template.txt
├── ext_emconf.php
├── ext_localconf.php
├── ext_tables.php
├── readme.rst
└── Resources
    └── Private
        └── Templates
            └── Search
                └── Search.html

Weitere Informationen kann man unter Files and locations in der TYPO3 Core API Reference finden.

Die Struktur von TypoScript wurde unter https://decisions.typo3.org/t/file-endings-for-typoscript-and-tsconfig-files-results/71/3 diskutiert und dokumentiert.

1.2. Bedeutung von PHP Caching (opcache, etc.)

PHP selbst ist eine interpretierte Programmiersprache. Im Gegensatz zu Sprachen wie C wird der Quellcode nicht vorab kompiliert und dann ausgeführt. PHP wird zu jedem Zeitpunkt neu ausgewertet und ausgeführt.

Da dies entsprechend zu Lasten der Performance ginge, kann der zur Laufzeit kompilierte Code gecached werden. PHP bietet hierzu bereits fertige Erweiterungen.

Die am meisten verwendete Erweiterung ist OPcache. Ein Auszug aus der Dokumentation:

OPcache improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request.

https://www.php.net/manual/en/intro.opcache.php

Bemerkung

Wie bei jedem Cache muss auch der OPcache korrekt invalidiert werden. Dies kann ggf. nach einem Deployment zu Problemen führen. Dazu gibt es bereits etablierte Lösungen die hier nicht dokumentiert werden.

1.2.1. Im Zusammenspiel mit Extbase / Reflection / PHPDoc

Was bedeutet dies nun im Zusammenspiel mit TYPO3? Zunächst nicht viel. Im Context von Extbase ergibt sich aber ein entscheidender Unterschied, wenn man sich die Konfigurationsoptionen ansieht:

opcache.save_comments „1“
opcache.load_comments „1“

https://www.php.net/manual/en/opcache.configuration.php

Extbase wird an diversen Stellen über PHP Kommentare, die PHPDoc Blocks, konfiguriert. Werden diese Kommentare nicht gespeichert, oder nicht geladen, fehlen diese Informationen und Extbase verhält sich nicht wie erwartet.

Mittlerweile nutzt TYPO3 das Paket doctrine/annotations zum parsen der Annotations. Können Kommentare nicht ausgewertet werden, wird eine Exception geworfen:

Doctrine\Common\Annotations\AnnotationException

You have to enable opcache.save_comments=1 or zend_optimizerplus.save_comments=1.

TYPO3 kann mit aktiviertem Caching also nur laufen, wenn Kommentare Bestandteil des Caches sind.

Tipp

Es wird empfohlen PHP Caching immer aktiv zu haben.

TYPO3 bietet mittlerweile auch eine Überprüfung im Install Tool unter „Environment Status“ an. Dort sollte folgendes reported werden:

A PHP opcode cache is loaded Name: OPcache Version: 7.2.14-1+0~20190205200805.15+stretch~1.gbpd83c69 This opcode cache should work correctly and has good performance. For more information take a look in our wiki https://wiki.typo3.org/Opcode_Cache.

1.3. MySQL Mode

Grundsätzlich gibt es unterschiedliche Datenbanksystem, wie MySQL oder MariaDB. Diese Systeme sind untereinander teilweise Kompatibel, teilweise jedoch auch inkompatibel.

Zudem verfügt z.B. MySQL über die Einstellung sql_mode:

1.3.1. Und die möglichen Auswirkungen

Ab einer bestimmten Version von MySQL wurde der Defaultwert dieser Einstellung verändert. Das löste bei vielen TYPO3 Entwicklern und Hostern zunächst diverse Bugs aus. TYPO3 ist seitdem bemüht die Kompatibilität zu verstärken.

Grundsätzlich kann jeder Server eine andere Einstellung hinterlegt haben. Unter Ubuntu ist der Default für Version 5.7.25:

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Treten Probleme in Kombination mit der Datenbank auf, z.B. beim holen oder speichern von Daten, sollte dieser Wert geprüft werden.

Tipp

TYPO3 bietet mittlerweile auch eine Überprüfung im Install Tool unter „Environment Status“ an. Dort sollte folgendes reported werden:

No incompatible SQL modes found.

1.4. System Locale (optional)

Die meiste Software, von Betriebssystem bis zu TYPO3, unterstützen mehrere Sprachen. Das involviert viele Bestandteile, von ganzen lokalisierten Sätzen, über Formaten wie Datumsformate, bis hin zu der Bezeichnung von Ländern oder Sprachen. All diese Informationen werden zentral vom Unicode Consortium verwaltet. Software wie Betriebssysteme und PHP greifen dann auf fertige Libraries zurück, die diese Informationen via APIs bereitstellen. Das Unicode Consortium stellt diese Informationen als CLDR - Unicode Common Locale Data Repository bereit.

Damit Software die korrekten Formate verwenden kann, muss diese die aktuelle Locale kennen.

1.4.1. Auswirkungen / Bedeutung (optional)

Wird die locale nicht korrekt gesetzt, kann z.B. der Monatsname mittels f:format.date nicht korrekt ausgegeben werden. Es findet dann ein Fallback auf die PHP locale statt.

1.4.2. Möglichkeit der Definition einer Locale (optional)

Bei TYPO3 kann diese Locale via TypoScript via locale_all konfiguriert werden. Seit TYPO3 9 wird die locale in der „Site Configuration“ angepasst.