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.
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:
composer run (optional)¶composer why und composer why-not (optional)¶composer validate (optional)¶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"
|
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
|
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.
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.