ESPO-13 legt Secrets unter /srv/espo/secrets ab (vorerst
gitea_package_token). Je Secret ein Parameter; leer oder woertlicher
Platzhalter laesst den Bestand. Erst Format und Funktion aller Werte
pruefen (Probeabruf der Registry), dann atomar schreiben - ein falscher
Token ersetzt keinen funktionierenden. Getestet: gesetzt, unveraendert,
falsches Format, abgelehnter Token.
ESPO-30 holt <extension> <version> aus der Package Registry
EspoCRM_Packages: SHA-256 gegen die Registry, Name und Version gegen das
Manifest, kein Rueckschritt, Snapshot srv-vor-update vor dem Download,
Installation per command.php als www-data, Neustart und Warten auf
healthy, Nachweis ueber --list. Danach liegt keine ZIP mehr auf der VM -
auch EspoCRMs eigene Archive in data/upload/extensions werden entfernt;
Update und Deinstallation brauchen sie nicht (Quelle 10.0.8).
ESPO-20 misst espo_extensions ("Name Version; ...", "none" wenn leer) und
beschreibt den Leseweg der Version wieder richtig. Ring 0 sperrt den
Extension-Upload in der Oberflaeche. README: Nummernkreise nachgezogen,
verrutschte Zeilen der Verzeichnistabelle zurueckgeholt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ESPO-03, ESPO-10, ESPO-12 und ESPO-20 lasen version aus
defaults/config.php, config.php und config-internal.php. EspoCRM 10 fuehrt
version aber als State-Parameter in data/state.php, und Config::load() liest
die Image-Vorgaben gar nicht. Gemeldet wurde also der Vorgabewert des Images:
nach einem gescheiterten migrate die neue Version, obwohl die Instanz auf der
alten steht.
Jetzt fragen die Skripte EspoCRM ueber "command.php version" - derselbe Wert,
gegen den auch Extensions ihre acceptableVersions pruefen. Aufruf als
www-data mit absolutem Pfad (bootstrap.php wechselt selbst ins
Installationsverzeichnis); akzeptiert wird nur eine Zeile der Form 1.2.3,
damit eine PHP-Warnung nie als Version in ein Custom Field geraet. Die
grep-Rueckfallwege auf config.php entfallen, sie lasen dieselbe falsche Quelle.
Probe gegen die Integrationsinstanz 10.0.8: Ausgabe "10.0.8".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Ursache ist bekannt - die Version steht in den Vorgabewerten des Images.
Das Geruest zur Fehlersuche kann damit weg.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der vorige Commit hat nur den Kommentar geaendert, der Ersetzungsausdruck griff
nicht. Jetzt lesen alle drei Skripte defaults, config und config-internal in
dieser Reihenfolge; der spaetere Wert gewinnt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gemessen: Auf einer frisch installierten Instanz steht 'version' weder in
data/config.php noch in data/config-internal.php - EspoCRM schreibt nur, was
vom Vorgabewert abweicht. Beide Dateien luden einwandfrei, der Schluessel fehlt
schlicht.
Gelesen werden jetzt alle drei Dateien in der Reihenfolge, in der EspoCRM sie
selbst zusammenfuehrt: defaults, config, config-internal - der spaetere Wert
gewinnt. Nach einem Upgrade sticht damit data/config.php den Vorgabewert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ESPO-20 meldete 'EspoCRM-Version nicht ermittelbar'. Ursache ist vermutlich der
relative Pfad: docker exec startet im Arbeitsverzeichnis des Images, data/...
ohne fuehrenden Schraegstrich geht dann ins Leere.
Jetzt absolute Pfade, beide Konfigurationsdateien (config-internal zuerst), als
Rueckfall ein grep ueber den Bind-Mount. Bleibt es leer, zeigt ESPO-20 welche
Dateien es gibt und welche Schluessel sie tragen - dann ist die Ursache nach
einem Lauf bekannt statt nach dreien.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eine Messung fuer alle Werte - sie stammen aus demselben Augenblick, die teuren
Aufrufe passieren einmal, und die Wertzeilen im Task sind nur noch ein cat.
Laesst sich ein Wert nicht ermitteln, bricht der Schritt ab; die Folgezeilen
laufen dann nicht und kein Feld wird ueberschrieben. Eine stehende Instanz darf
die Werte nicht leeren, sonst sieht eine Stoerung aus wie eine leere Instanz.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
