2. Tooling

2.1. Composer

2.1.1. Konfiguration repositories

Sucht Composer ein Paket, durchsucht es sogenannte „repositories“ nach diesem Paket. Per Default gibt es ein Repository: https://packagist.org/.

Nutzt man innerhalb einer Community (TYPO3) oder Firma nun verstärkt Composer, entstehen ggf. eigene Pakete die nicht auf Packagist.org liegen.

Composer stellt dafür innerhalb der composer.json die Konfiguration repositories bereit. Dort können weitere Quellen angegeben werden. Dies ermöglicht es auch einen Fork eines bestehenden Paketes zu laden.

Ein Beispiel aus einem Projekt kann wie folgt aussehen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
{
    "repositories": [
        {
            "type": "path",
            "url": "localPackages/*"
        },
        {
            "type": "composer",
            "url": "https://composer.typo3.org/"
        }
    ],
    "name": "website/typo3-extension-workshop",
    "description": "Example TYPO3 installation for workshop",
    "license": "GPL-2.0-or-later",
    "require": {
    }
}

Das Feature ist auf Composer unter der URL https://getcomposer.org/doc/04-schema.md#repositories und https://getcomposer.org/doc/05-repositories.md dokumentiert.

Im TYPO3 Kontext wird oft das obige Beispiel genutzt. So können auch nicht Composer-Extensions installiert werden, da TYPO3 alle Versionen von Extensions im TER unter composer.typo3.org bereitstellt. Zudem können mit der Einstellung auch Pakete aus dem Dateisystem, dem aktuellen Projekt, installiert werden.

2.1.2. Konfiguration autoloading

Früher wurden alle notwendigen Dateien zum betreiben einer Webseite mittels require_once(), require(), include_once() oder include() eingebunden. Da dies Code unnötig aufbläht und die Performance beeinträchtigen kann, bietet TYPO3 ein Autoloading. Sobald eine neue Klasse genutzt wird, die noch nicht bekannt ist, kann das Autoloading genutzt werden.

Das Autoloading ist eine Funktion die zur Laufzeit registriert werden kann. Diese übernimmt dann die Aufgabe die Klasse bereitzustellen.

Im Context von Composer kann jedes Paket seine Informationen zum Autoloading, wo Klassen zu finden sind, als Konfiguration in der composer.json bereitstellen. Composer generiert aus diesen Informationen einen Autoloader, welcher durch require __DIR__ . '/vendor/autoload.php'; geladen wird.

In den meisten Fällen sieht die Konfiguration wie folgt aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
{
    "name": "workshop/example-extension",
    "description": "Example for TYPO3 Extension Workshop.",
    "type": "typo3-cms-extension",
    "license": "GPL-2.0-or-later",
    "authors": [
        {
            "name": "Daniel Siepmann",
            "email": "coding@daniel-siepmann.de"
        }
    ],
    "autoload": {
        "psr-4": {
            "Workshop\\ExampleExtension\\": "Classes"
        }
    }
}

Weitere Informationen zum Autoloading gibt es unter:

2.1.3. Version Constraints (optional)

2.1.4. Verwendung von composer run (optional)

2.1.5. Verwendung von composer why und composer why-not (optional)

2.1.6. Verwendung von composer validate (optional)

2.2. TYPO3 Console

2.2.1. Verwendung von database:updateschema

Der Befehl ermöglicht die Ausführung des „Database Compare“ im Install Tool über die Kommandozeile. Dies ermöglicht dann die Integration in automatisierte Prozesse, wie Deployments.

Grundsätzlich führt der Befehl die als default markierten Updates aus. Er kann per Optionen aber auch Tabellen und Felder löschen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
./vendor/bin/typo3cms help database:updateschema
Usage:
  database:updateschema [options] [--] <schemaUpdateTypes>
  typo3_console:database:updateschema

Arguments:
  schemaUpdateTypes     List of schema update types (default: "safe")
                         • [default: ["safe"]]

Options:
      --dry-run         If set the updates are only collected and shown, but not executed
  -h, --help            Display this help message
  -q, --quiet           Do not output any message
      --ansi            Force ANSI output
      --no-ansi         Disable ANSI output
  -n, --no-interaction  Do not ask any interactive question
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Help:
  Compares the current database schema with schema definition
  from extensions's ext_tables.sql files and updates the schema based on the definition.

  Valid schema update types are:

  - field.add
  - field.change
  - field.prefix
  - field.drop
  - table.add
  - table.change
  - table.prefix
  - table.drop
  - safe (includes all necessary operations, to add or change fields or tables)
  - destructive (includes all operations which rename or drop fields or tables)

  The list of schema update types supports wildcards to specify multiple types, e.g.:

  - "*" (all updates)
  - "field.*" (all field updates)
  - "*.add,*.change" (all add/change updates)

  To avoid shell matching all types with wildcards should be quoted.

  Example: ./vendor/bin/typo3cms database:updateschema "*.add,*.change"

2.2.2. Verwendung von upgrade:all

TYPO3 stellt für Upgrades von einer Versionen zur nächsten Upgrade Wizards bereit. Diese werden meistens im Install Tool ausgeführt. Um diesen Prozess zu automatisieren, gibt es den Befehl migrate:all. Dieser führt alle notwendigen Upgrade Wizards im Konsolen Kontext aus. In diesem gibt es auch meistens keine Begrenzung der Laufzeit.

In Kombination mit selbstgeschriebenen Upgrade Wizards kann somit das Deployment von TYPO3 Projekten vollständig automatisiert werden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
./vendor/bin/typo3cms help upgrade:all
Usage:
  upgrade:all [options]
  typo3_console:upgrade:all

Options:
      --arguments=ARGUMENTS  Arguments for the wizard prefixed with the identifier, e.g. compatibility7Extension[install]=0; multiple arguments separated with comma
  -h, --help                 Display this help message
  -q, --quiet                Do not output any message
      --ansi                 Force ANSI output
      --no-ansi              Disable ANSI output
  -n, --no-interaction       Do not ask any interactive question
  -v|vv|vvv, --verbose       Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Help:
  Execute all upgrade wizards that are scheduled for execution

2.3. ddev

2.3.1. Wechsel der konkreten Versionen (PHP, MariaDB)

Die konkrete Version ist in der Datei .ddev/config.yaml hinterlegt.

Dort gibt es die Optionen php_version und mariadb_version. Diese beiden können angepasst werden.

Anschließend genügt ein ddev restart im Projekt.

Bemerkung

Das wechseln der MariaDB Version funktioniert meist nicht. Im Zweifelsfall kann aber das Docker Image getauscht werden.

2.3.2. Unterschiede zum Produktiven Hosting (optional)

2.3.3. Verwendung von Hooks (optional)

2.3.4. Importieren und Exportieren von Assets und Datenbanken

ddev stellt die Befehle ddev import-db und ddev import-files bereit. Diese beiden Befehle ermöglichen es Daten in die Datenbank, oder ins Dateisystem zu importieren.

Datenbank

Der Dump der Datenbank kann z.B. vom Produktiv- oder Stagingsystem kommen. Alternativ kann ein Kollege einen Dump seiner Datenbank mittels ddev export-db -f dump.sql.gz erzeugen, und diese Datei weitergeben.

Der Import findet dann durch den Befehl ddev import-db --src dump.sql.gz statt.

Assets

Im Fall von TYPO3 bedeutet Assets werden die Dateien in den fileadmin Ordner importiert. Dabei wird der Ordner selbst geleert.

Einen Export gibt es hier nicht. Da der Ordner selbst geleert wird, empfiehlt es sich im Anschluss ddev exec ./vendor/bin/typo3cms install:fixfolderstructure auszuführen.

Snapshots

Neben Dumps bietet ddev auch Snapshops an, z.B. wenn man während der Entwicklung Änderungen vornimmt und ein Backup benötigt.

Dazu kann der Befehl ddev snapshot genutzt werden. Dieser legt einen Snapshot der Datenbank an. Dabei wird der Name des Snapshots ausgegeben, z.B. typo3-workshop_20190327074215.

Anschließend kann dieser Snapshot mittels ddev restore-snapshot typo3-workshop_20190327074215 wiederhergestellt werden.