Kickstarter-CLI #

Lesen Sie diese Seite, wenn Sie Exponential über die Kommandozeile installieren, Installationen per Skript ausführen oder Testwebsites neu installieren. bin/php/kickstarter.php (Konsole: php bin/php/console exp:kickstarter, neu in Exponential 6.0.15) führt den Setup-Assistenten ohne Browser aus: Er liest jede Antwort des Assistenten aus kickstart.ini.

Kurz gesagt #

Voraussetzungen #

Führen Sie alle Befehle im Projektwurzelverzeichnis aus (dem Verzeichnis, das index.php, autoload.php, bin/, kickstart.ini usw. enthält).

# Confirm you are in the project root
ls index.php autoload.php kickstart.ini-dist

Sie brauchen:

• PHP 8.0 oder neuer (PHP 7.4 ohne Support nutzbar) in Ihrem $PATH.
• Einen bereits laufenden und erreichbaren Datenbankserver (MySQL, PostgreSQL, SQLite 3 oder MongoDB).
• Das Verzeichnis var/cache/ini/ muss beschreibbar sein, weil kickstart.ini dort gecacht wird.

Schnellstart #

# Generate an interactive kickstart.ini
php bin/php/console exp:kickstarter ini

# Test the remote packages and configuration (a dry run, the default)
php bin/php/console exp:kickstarter run --dry-run

# Install the site (requires --apply; --force is accepted with it)
php bin/php/console exp:kickstarter run --apply --force

Für eine unbeaufsichtigte Installation mit sinnvollen Standardwerten:

php bin/php/console exp:kickstarter ini --yes
php bin/php/console exp:kickstarter run --dry-run
php bin/php/console exp:kickstarter run --apply --force

Befehlsreferenz #

exp:kickstarter ini — kickstart.ini erzeugen #

Baut die Datei kickstart.ini, die exp:kickstarter run verarbeitet. Er liest kickstart.ini-dist (lauter auskommentierte Beispiele) und schreibt eine ausgefüllte kickstart.ini in das Projektwurzelverzeichnis.

php bin/php/console exp:kickstarter ini
php bin/php/kickstarter.php ini

Optionen #

Die Standardwerte von --yes werden aus kernel/classes/expkickstarterini.php geladen. Sie übernehmen nichts aus den Einstellungen einer installierten Website: Diese nennen eine laufende Datenbank, und eine daraus geschriebene kickstart.ini würde darüber installieren. Mit --from-installed werden Server, Name und Benutzer der Datenbank des ersten installierten Siteaccess, der eine Datenbank nennt, zu den Standardwerten; sein Passwort wird nie kopiert. Das Standard-Site_package ist sevenx_multisite, das Paket, das exp:install installiert.

exp:kickstarter run — den Setup-Assistenten ausführen #

Führt die Schritte des Setup-Assistenten von welcome bis final mit den Werten aus kickstart.ini aus. Ein konfiguriertes Site-Paket, das bereits in var/storage/packages/ liegt, wird so verwendet, wie es ist; nur ein fehlendes Paket (oder eine fehlende Abhängigkeit) wird aus dem entfernten Repository heruntergeladen. Löschen Sie zuerst die lokale Kopie, wenn Sie einen frischen Download möchten.

php bin/php/console exp:kickstarter run --apply
php bin/php/kickstarter.php run --apply

Optionen #

Die üblichen Skriptoptionen (--allow-root-user, --no-colors, --quiet, --debug, --verbose, --siteaccess, --logfiles) werden angenommen und ignoriert; der Kickstarter läuft immer auf dem einfachen Siteaccess.

CreateSites und --apply #

CreateSites ist der Schritt, der das Datenbankschema löscht / einfügt, das Site-Paket und die benötigten Pakete installiert und die Dateien in settings/siteaccess/ schreibt. Weil er zerstörend ist, installiert exp:kickstarter run nur mit --apply; ohne die Option ist der Lauf der Probelauf (--force allein wird mit Exit-Code 2 abgelehnt), der nach SiteDetails anhält. Vor dem 28. Oktober 2026 endete ein Lauf ohne --force mit dieser Meldung; sie nennt jetzt --apply:

The CreateSites step will modify the database and site settings.
Re-run with --apply to confirm you want to install the site package.

Um die Schritte für Konfiguration und Pakete auszuführen und anzuhalten, bevor etwas installiert wird, halten Sie beim Schritt vor CreateSites an:

php bin/php/console exp:kickstarter run --apply --stop-step=Registration

--stop-step=CreateSites tut das Gegenteil: Es schließt CreateSites ein, installiert also (und braucht --apply) und lässt nur Final aus.

Nach einem Fehlschlag fortsetzen #

Ein Lauf kann nicht dort weitermachen, wo ein früherer angehalten hat. Die Schritte halten, was sie herausgefunden haben (Typ und Verbindung der Datenbank, das gewählte Paket und seine Sprachen, die Werte der Siteaccesses, das Ergebnis der Systemprüfung für ImageMagick, den Administrator), nur im laufenden Prozess; kickstart.ini enthält die Antworten, nicht diese Ergebnisse. Daher wird ein späteres --start-step abgelehnt, bevor irgendetwas läuft, wenn ein Schritt im Bereich einen früheren braucht, und die Meldung nennt den frühesten Schritt, der funktioniert:

--start-step=SiteDetails cannot work: the steps SiteDetails..Final need what Welcome, SystemCheck, EmailSettings, DatabaseChoice, DatabaseInit, LanguageOptions, SiteTypes, PackageLanguageOptions, SiteAccess found out earlier in the same run (...). Start at Welcome or earlier: --start-step=Welcome.

Jeder Bereich, der CreateSites einschließt, muss bei Welcome beginnen. Beheben Sie nach einem Fehlschlag die Ursache in kickstart.ini und führen Sie die ganze Installation erneut aus:

php bin/php/console exp:kickstarter run --apply --force

Umgang mit entfernten Paketen #

exp:kickstarter run ist dafür gedacht, das Site-Paket aus dem entfernten Paket-Repository zu installieren, das in package.ini konfiguriert ist (z. B. https://exponential.packages.exponential.earth/exponential/6.0/6.0.15/index.xml). Die entfernte index.xml führt Pakete mit einem Attribut version auf. Bis 2026-10-19 passte dieses Attribut nicht zu der Version, die die eigene package.xml des Pakets meldet; seitdem führt der Index für 6.0.15 die Site-Pakete von 7x und cjw_multisite mit genau dem Text auf, den eZPackage::getVersion() zurückgibt (6.0-15-stable).

Zum Beispiel hatte sevenx_site im entfernten Index version="1.0.0-0", während das heruntergeladene .ezpkg enthielt:

<version>6.0.10-stable</version>
<version>
  <number>6.0</number>
  <release>10-stable</release>
</version>

Daher gab eZPackage::getVersion() 6.0-10-stable zurück. Ein naives version_compare('1.0.0-0', '6.0-10-stable') würde entscheiden, dass die lokale Kopie neuer ist, und den Download überspringen. Der Kickstart-Ablauf verlässt sich in keiner Richtung auf die Version im Index.

Hat kickstart.ini einen Abschnitt [site_types], sieht eZStepSiteTypes::createSitePackagesList(), dass hasKickstartData() wahr ist, und behält den entfernten Eintrag (mit seiner URL), auch wenn es eine lokale Kopie gibt, sodass der obige Versionsvergleich das Paket nicht verstecken kann. eZStepSiteTypes::init() ruft dann downloadAndImportPackage() mit forceDownload=false auf: Ein Site-Paket, das bereits in var/storage/packages/ liegt, wird so verwendet, wie es ist, und nur ein fehlendes wird heruntergeladen. downloadDependantPackages() prüft jede benötigte Abhängigkeit gegen ihre min-version und lädt nur fehlende oder ältere Pakete herunter, wobei es die URLs aus der entfernten index.xml bezieht. Um eine neuere Kopie eines bereits vorhandenen Pakets zu installieren, entfernen Sie zuerst die lokale Kopie.

Probelauf #

--dry-run ist nicht mehr nur ein statischer Validator. Er:

1. Validiert kickstart.ini und listet die Schritte des Assistenten auf.
2. Führt die Schritte des Assistenten von DatabaseChoice bis SiteDetails aus.
3. Importiert während SiteTypes das Site-Paket und seine Abhängigkeiten in ein temporäres Repository var/storage/packages/dryrun/.
4. Räumt das Repository dryrun/ auf, sobald der Schritt SiteTypes fertig ist.
5. Hält nach SiteDetails an (Index 10): vor SiteAdmin, das ein erzeugtes Passwort nach var/log/initial-admin-password schreiben kann, vor Registration, das eine E-Mail senden kann, und vor CreateSites (Index 14).

Der Pfad des Probelaufs verwendet dieselben Helfer downloadAndImportPackage() und downloadDependantPackages() wie eine echte Installation, aber mit repositoryID='dryrun' und skipExisting=true. eZPackage::import() unterstützt das Flag skipExisting, sodass es in das temporäre Verzeichnis importieren kann, ohne STATUS_ALREADY_EXISTS zurückzugeben, auch wenn 7x/sevenx_site lokal bereits existiert. So wird der Probelauf zu einem echten Test des entfernten Downloads und der Auflösung der Abhängigkeiten, ohne den lokalen Paket-Cache oder die Dateien in settings/siteaccess/ zu überschreiben.

php bin/php/console exp:kickstarter run --dry-run

Weil der Schritt zum Anhalten SiteDetails ist, wird CreateSites nie erreicht, daher bleiben Datenbank und Dateien der Website unberührt, keine Passwortdatei wird geschrieben und keine E-Mail gesendet.

Setup-Schritte #

Die Schritte des Assistenten sind in kernel/setup/steps/ezstep_data.php definiert.

Referenz für kickstart.ini #

kickstart.ini ist eine gewöhnliche INI-Datei im Projektwurzelverzeichnis. Jeder Abschnitt entspricht einem Schritt des Assistenten. Das Flag Continue=true in einem Abschnitt bedeutet, dass der Assistent die Oberfläche für diesen Schritt überspringen und die Werte aus der Datei verwenden soll.

email_settings #

[email_settings]
Continue=true
Type=mta
Server=
User=
Password=

database_choice #

[database_choice]
Continue=true
Type=sqlite3

Wichtig: Type wählt den Treiber, mit dem sich das Installationsprogramm verbindet. Er entscheidet nicht über die DatabaseImplementation, die für die fertige Website in settings/override/site.ini.append.php geschrieben wird. Dieser Wert wird aus der laufenden site.ini genommen, und er bleibt bewusst dem Betreiber überlassen.

Der Grund ist, dass ein Treiber mehr als einen Namen hat. mysql, mysqli, ezmysql und ezmysqli lösen sich alle über den Block ImplementationAlias in settings/site.ini zu eZMySQLiDB auf, und eine Website kann dort einen eigenen Alias für einen eigenen Treiber registrieren. Den Namen von dem Treiber abzuleiten, der sich gerade verbunden hat, würde diese Wahl bei jeder Installation überschreiben, daher behält das Installationsprogramm sie.

Die Folge sollte man vor einer Installation kennen, die die Engine wechselt. Die laufende site.ini enthält noch den Namen der Engine, die Sie verlassen, daher wird die neue Installation mit der Implementierung der bisherigen Engine neben dem neuen Host, der neuen Datenbank und den neuen Zugangsdaten geschrieben. settings/override/ hat Vorrang vor jedem Siteaccess, daher versucht dann die ganze Website, mit dem neuen Server das Protokoll der alten Engine zu sprechen, und keine Seite lädt.

Setzen Sie den Wert vor dem Lauf passend zum Ziel, zum Beispiel beim Wechsel zu MySQL:

sed -i '/^\[DatabaseSettings\]/,/^\[/ s/^DatabaseImplementation=.*/DatabaseImplementation=mysqli/' \
  settings/override/site.ini.append.php

Führen Sie dann das Installationsprogramm wie üblich aus. Danach sollten der Wert in settings/override/site.ini.append.php und der in jedem Siteaccess beide die Engine nennen, auf die Sie gerade installiert haben; stimmen sie nicht überein, ist das zu korrigieren.

database_init #

[database_init]
Continue=true
Server=localhost
Port=
Database=ezp
User=root
Password=
Socket=

language_options #

[language_options]
Continue=true
Primary=eng-GB
Languages[]=eng-US

Wichtig: Jede Locale, die das gewählte Site-Paket verwendet (zum Beispiel eng-US in sevenx_site), muss in Languages[] stehen oder der Hauptsprache zugeordnet sein. Sonst werden Inhaltsobjekte mit einer Sprache importiert, die nicht als priorisierte Sprache der Website gesetzt ist, und das Nachschlagen von Baumknoten für diese Objekte schlägt fehl.

Bleibt Languages[] leer, behandelt der Schritt eZStepPackageLanguageOptions es als leeres Array und ordnet Locales, die nur das Paket hat, der Hauptsprache zu, sodass die Installation ohne einen fatalen Fehler von array_diff() weiterlaufen kann.

site_types #

[site_types]
Continue=true
Site_package=sevenx_site

site_access #

[site_access]
Continue=true
Access=url

site_details #

[site_details]
Continue=true
Title=My Exponential Site
URL=
Access=sevenx_site_user
AdminAccess=sevenx_site_admin
AccessPort=8080
AdminAccessPort=8081
AccessHostname=sevenx-site.test.com
AdminAccessHostname=sevenx-site-admin.test.com
EditorAccess=editor
EditorAccessPort=8082
EditorAccessHostname=edit.sevenx-site.test.com
Database=ezp
DatabaseAction=skip

Werte von DatabaseAction #

site_admin #

[site_admin]
Continue=true
FirstName=Admin
LastName=User
Email=<e-mail address of the first administrator>
Password=<choose a password>

security #

[security]
Continue=true

registration #

[registration]
Continue=true
Send=false

Ein Schlüssel Comments=, den ältere Versionen von exp:kickstarter ini schrieben, wird nicht gelesen.

Ablauf der Installation #

1. Erzeugen Sie die Konfigurationsdatei:

   php bin/php/console exp:kickstarter ini --yes

2. Prüfen und bearbeiten Sie kickstart.ini. Bestätigen Sie mindestens:

   • die Zugangsdaten in database_init.
   • Site_package in site_types.
   • dass Primary und Languages[] in language_options jede Locale enthalten, die das Site-Paket verwendet.
   • dass DatabaseAction in site_details für eine saubere Installation auf remove gesetzt ist oder auf skip, um Siteaccesses neu zu erzeugen.

3. Prüfen Sie, dass sich die entfernten Pakete herunterladen lassen, ohne die Website zu ändern:

   php bin/php/console exp:kickstarter run --dry-run

   Das führt DatabaseChoice bis SiteDetails aus, importiert das Site-Paket und seine Abhängigkeiten nach var/storage/packages/dryrun/ (das nach dem Schritt SiteTypes entfernt wird) und hält vor SiteAdmin an: Nichts wird installiert, keine Passwortdatei geschrieben und keine E-Mail gesendet.

4. Führen Sie das Installationsprogramm aus:

   php bin/php/console exp:kickstarter run --apply --force

5. Prüfen Sie, dass die Website unter der in der Zusammenfassung geschriebenen URL erreichbar ist.

Beispiele #

Saubere Installation #

php bin/php/console exp:kickstarter ini --yes
sed -i 's/^DatabaseAction=skip$/DatabaseAction=remove/' kickstart.ini
php bin/php/console exp:kickstarter run --apply --force

Nur die Dateien der Siteaccesses und die INI-Dateien neu erzeugen #

# Adjust the relevant fields and keep DatabaseAction=skip
php bin/php/console exp:kickstarter run --apply --force --stop-step=CreateSites

Nach einem fehlgeschlagenen Lauf #

Ein Lauf kann nicht ab einem späteren Schritt fortgesetzt werden (siehe Nach einem Fehlschlag fortsetzen); --start-step=SiteDetails wird mit dem Schritt abgelehnt, bei dem zu beginnen ist. Beheben Sie kickstart.ini und führen Sie die Installation erneut aus:

php bin/php/console exp:kickstarter run --apply --force

Probelauf, um kickstart.ini und die entfernten Pakete zu validieren #

php bin/php/console exp:kickstarter run --dry-run

Das validiert die INI-Abschnitte, listet die Schritte des Assistenten auf und führt dann die Schritte von DatabaseChoice bis SiteDetails aus, um die Datenbankverbindung zu prüfen und dass sich das konfigurierte Site-Paket und alle seine entfernten Abhängigkeiten herunterladen lassen. Es hält vor SiteAdmin an, daher werden weder Datenbank noch Dateien der Siteaccesses geändert, keine Passwortdatei geschrieben und keine E-Mail gesendet. Die heruntergeladenen Pakete werden in ein temporäres Repository var/storage/packages/dryrun/ importiert, das entfernt wird, wenn der Schritt SiteTypes fertig ist.

Die Schritte des Assistenten auflisten #

php bin/php/console exp:kickstarter run --list-steps

Fragen und Antworten: kurze Antworten für häufige Anliegen #

Wie fange ich am einfachsten an? #

php bin/php/console exp:kickstarter ini --yes
php bin/php/console exp:kickstarter run --dry-run
php bin/php/console exp:kickstarter run --apply --force

Die erste Zeile erzeugt die Konfiguration. Die zweite Zeile testet die entfernten Pakete, ohne etwas zu ändern. Die dritte Zeile installiert.

Brauche ich für die normale Verwendung --start-step oder --stop-step? #

Nein. Sie sind für Teilläufe, und ein späteres --start-step kann einen früheren Lauf nicht fortsetzen: Es wird abgelehnt, wenn die Schritte davor gebraucht werden, und das ist bei einem Bereich, der installiert, immer der Fall. Die normalen Befehle sind run --dry-run und run --apply.

Warum braucht run --apply? #

CreateSites installiert Datenbankschema, Daten und Dateien der Siteaccesses. --apply bestätigt, dass Sie das möchten. Ohne die Option ist der Lauf der Probelauf und ändert nichts. Bis zum 28. Oktober 2026 war --force diese Bestätigung; zusammen mit --apply wird es weiter angenommen.

Was tut --dry-run tatsächlich? #

Es validiert kickstart.ini, listet die Schritte auf und führt dann DatabaseChoice bis SiteDetails aus, um die Datenbankverbindung und den Download der Pakete zu testen. Es hält vor SiteAdmin an und räumt das temporäre Repository dryrun/ auf.

Was ändert --dry-run auf der Festplatte? #

Nichts Dauerhaftes. Es lädt Pakete nach var/storage/packages/dryrun/ herunter und entfernt dieses Verzeichnis, wenn SiteTypes fertig ist. Es berührt weder die Datenbank noch settings/siteaccess/, schreibt kein var/log/initial-admin-password und sendet keine E-Mail.

Was ändert run --apply? #

Es installiert das Site-Paket und die Abhängigkeiten nach var/storage/packages/, schreibt settings/siteaccess/, legt das Datenbankschema an und fügt die Daten der Website ein. Verwenden Sie zuerst --dry-run zum Testen.

Kann ich run --dry-run ohne funktionierende Datenbank ausführen? #

Nein. DatabaseChoice und DatabaseInit testen weiterhin die Verbindung. Es werden aber keine Daten geschrieben. Die Datenbank muss nur erreichbar sein.

Warum verwendet der entfernte Paketindex eine andere Version? #

Für die Site-Pakete von 7x und cjw_multisite tut er das nicht mehr: Seit dem 2026-10-19 führt der Index für 6.0.15 sie als 6.0-15-stable auf, den Text, den eZPackage::getVersion() für ihre package.xml zurückgibt (vorher 1.0.0-0 und 6.0.15-0). Andere Einträge tragen weiterhin eigene Versionen, daher behält der Kickstart-Modus den entfernten Eintrag, was immer der Vergleich sagt.

Macht das den normalen Setup-Assistenten im Web kaputt? #

Nein. Der Setup-Assistent im Web verwendet eZStepSiteTypes::display() mit der alten Logik des Versionsvergleichs. Das Bevorzugen des entfernten Eintrags geschieht nur innerhalb von eZStepSiteTypes::init(), ausgelöst durch kickstart.ini [site_types] mit Continue=true. Lassen Sie kickstart.ini nicht im Web-Wurzelverzeichnis, bleibt der Web-Assistent unverändert.

Macht die Änderung an eZPackage::import() andere Werkzeuge kaputt? #

Nein. Die Signatur ist eZPackage::import( $archiveName, &$packageName, $dbAvailable = true, $repositoryID = false, $skipExisting = false ). Das neue fünfte Argument ist optional und standardmäßig false. Alle vorhandenen Aufrufer (ezpm.php, upload.php, bin/php/ezwebincommon.php, Tests) funktionieren weiter.

Ist es sicher, kickstart.ini im Projektwurzelverzeichnis zu lassen? #

kickstart.ini wird vom CLI-Werkzeug gelesen und kann, wenn vorhanden, auch vom Setup-Assistenten im Web gelesen werden. Soll der Web-Assistent sie nicht verwenden, entfernen oder verschieben Sie sie nach der Installation über die CLI.

Was, wenn Languages[] in language_options leer ist? #

Das Installationsprogramm wandelt die Liste der Sprachen jetzt in ein Array um, sodass ein leeres Languages[] keinen fatalen Fehler von array_diff() mehr verursacht. Die Paketsprachen werden der Hauptsprache zugeordnet.

Was ist das Verzeichnis dryrun/? #

Ein temporäres Paket-Repository, das nur während --dry-run angelegt wird. eZPackage::import() unterstützt ein Flag skipExisting, sodass der Probelauf das entfernte Paket dort importieren kann, ohne mit der lokalen Kopie 7x/sevenx_site zu kollidieren. expKickstarter entfernt dryrun/ nach SiteTypes und entfernt außerdem beim Start der CLI ein übrig gebliebenes dryrun/.

Was, wenn der entfernte Paketserver nicht erreichbar ist? #

eZStepSiteTypes fällt auf eine lokale index.xml zurück, wenn sich die entfernte index.xml nicht herunterladen lässt. Ist keine von beiden verfügbar, bleibt der Schritt stehen und zeigt die Paketliste, damit Sie ein Paket von Hand hochladen können. Der normale Web-Assistent ist nicht betroffen, weil er den Kickstart-Modus nur verwendet, wenn kickstart.ini existiert.

Was, wenn der Probelauf unterbrochen wird und dryrun/ zurückbleibt? #

expKickstarter entfernt dryrun/ nach SiteTypes und außerdem zu Beginn jedes CLI-Laufs ein übrig gebliebenes dryrun/. Das Verzeichnis ist ein temporärer Cache und enthält weder Datenbank noch Einstellungen der Website.

Ist es für den langfristigen Einsatz sicher? #

Ja. Die Änderungen sind additiv. Der Pfad von --dry-run ist vom Installationspfad getrennt. Der Installationspfad braucht --apply (vor dem 28. Oktober 2026 --force). Die APIs von eZPackage und eZStepSiteTypes behalten ihr altes Verhalten, sofern die neuen optionalen Flags nicht verwendet werden.

Fehlerbehebung #

kickstart.ini not found #

Erzeugen Sie sie zuerst:

php bin/php/console exp:kickstarter ini

The CreateSites step will modify the database and site settings #

Fügen Sie --apply hinzu, um zu bestätigen, dass die Datenbank geändert wird:

php bin/php/console exp:kickstarter run --apply --force

eZINI cacht veraltete Werte #

Sowohl exp:kickstarter ini als auch exp:kickstarter run löschen var/cache/ini/kickstart-*.php automatisch. Bearbeiten Sie kickstart.ini von Hand, leeren Sie dieses Verzeichnis:

rm -f var/cache/ini/kickstart-*.php

Inhaltsseiten werden gerendert, aber Unterelemente (Bilder, Galerien) fehlen #

Das bedeutet meist, dass die Paketsprachen nicht mit den Sprachen der Website abgeglichen wurden. Stellen Sie sicher, dass Languages[] in language_options von kickstart.ini jede Locale aufführt, die das Site-Paket verwendet. Verwendet das Paket eng-US, fügen Sie hinzu:

[language_options]
Primary=eng-GB
Languages[]=eng-US

Setzen Sie dann DatabaseAction=remove und führen Sie das Installationsprogramm erneut aus:

php bin/php/console exp:kickstarter run --apply --force

Felder von kickstart.ini werden nicht gelesen #

• Stellen Sie sicher, dass vor Abschnittsköpfen oder Schlüsseln kein führender Leerraum steht.
• Stellen Sie sicher, dass Continue=true für den Abschnitt gesetzt ist, den Sie überspringen möchten.
• Stellen Sie sicher, dass die Datei als kickstart.ini im Projektwurzelverzeichnis gespeichert ist.

Das Site-Paket wird nicht vom entfernten Server heruntergeladen #

• Bestätigen Sie, dass package.ini auf eine erreichbare URL einer index.xml zeigt.
• Bestätigen Sie, dass Site_package in site_types zum Attribut name in der entfernten index.xml passt.
• Ein Paket, das bereits in var/storage/packages/ liegt, wird nicht erneut heruntergeladen; entfernen Sie die lokale Kopie, um einen Download zu erzwingen.
• Denken Sie daran, dass hasKickstartData() wahr sein muss, damit der entfernte Eintrag bevorzugt wird. Der Abschnitt [site_types] muss Continue=true haben und Site_package gesetzt sein.
• Führen Sie --dry-run aus, um genau zu sehen, wo der Download fehlschlägt.

Dateien #

Hinweise zur Implementierung #

Änderungen an eZPackage::import() #

eZPackage::import( $archiveName, &$packageName, $dbAvailable = true, $repositoryID = false, $skipExisting = false ) nimmt jetzt ein fünftes Argument an. Ist $skipExisting true, überspringt die Funktion die Prüfung mit eZPackage::fetch(), die normalerweise STATUS_ALREADY_EXISTS zurückgeben würde. Das erlaubt dem Pfad des Probelaufs, ein Paket in ein anderes als das Standard-Repository zu importieren (z. B. var/storage/packages/dryrun/), während eine Kopie mit demselben Namen noch in var/storage/packages/7x/ existiert.

Änderungen an eZStepSiteTypes #

• downloadAndImportPackage( $packageName, $packageUrl, $forceDownload = false, $repositoryID = false, $skipExisting = false ) leitet jetzt die optionalen Flags für Repository und Überspringen vorhandener Pakete an eZPackage::import() weiter.
• downloadDependantPackages( $sitePackage, $repositoryID = false, $skipExisting = false ) leitet jetzt dieselben Flags an downloadAndImportPackage() weiter.
• Ist in init() die POST-Variable eZSetupKickstartDryRun gesetzt, wird das Site-Paket mit skipExisting=true in das Repository dryrun importiert. Im normalen Modus wird es in das eigene Herstellerverzeichnis des Pakets (7x) mit forceDownload=false importiert: Ein bereits vorhandenes Paket wird so verwendet, wie es ist.
• createSitePackagesList() ruft jetzt vor dem Versionsvergleich $this->hasKickstartData() auf. Ist eine Kickstart-Konfiguration aktiv, wird der lokale Paketeintrag übersprungen und der entfernte behalten, sodass die entfernte URL erhalten bleibt; das Paket wird nur heruntergeladen, wenn es nicht im lokalen Repository liegt.

Änderungen an eZStepPackageLanguageOptions #

siteLanguageLocaleList wird jetzt sowohl in processPostData() als auch in init() mit (array) umgewandelt, sodass ein leerer Wert für Languages[] in kickstart.ini keinen fatalen Fehler von array_diff() in eZStepPackageLanguageOptions::init() mehr auslöst.

Die Zusammenfassung endet mit einer Endzeit und einer Dauer #

Nach der Zusammenfassung gibt der Kickstarter eine Linie aus, dann Finished: mit Datum, Uhrzeit und Zeitzone und Elapsed: als hh:mm:ss (n seconds). Zwei Läufe derselben kickstart.ini geben sonst identischen Text aus, daher unterscheidet die Endzeit einen frischen Lauf vom Scrollback, und die Dauer lässt Sie sie vergleichen (showFinishTime() in kernel/classes/expkickstarter.php).

Jeder Lauf wird außerdem mit maskierten Passwörtern nach var/log/kickstart.log protokolliert; frühere Läufe werden als kickstart.log.1 (der letzte) bis kickstart.log.9 behalten, und EXP_KICKSTART_LOG=0 schaltet das Log aus (siehe php bin/php/kickstarter.php --help). Die Schritte auflisten, ohne etwas zu ändern: php bin/php/kickstarter.php run --list-steps.

Verwandte Seiten #

• Kickstarter-CLI (Funktionsseite) und Installation mit einem Befehl
• Anleitung für den Einstieg
• Logs des Installationsprogramms und Startdaten
• Exponential-Konsole
• September 2026, erste Hälfte: 13. September
• Changelog 6.0.15
• kickstart.ini-dist im Projektwurzelverzeichnis: jeder Abschnitt und jedes Feld, kommentiert.