Oxid umzug (mit composer)

Deutsches Forum
1

Hallo,

ich frage mich gerade wie ein optimaler umzug von oxid auf einen anderen server ablaufen sollte.

Sage wir mal aktuell läuft oxid 6 mit eigenen tpl und php anpassungen (im source ordner) auf einem server oder lokal mit z.b. php 7.2.8. Nun möchte oxid auf einen neuen server mit z.b. php 7.2.19 (neuere php version) umziehen.

Ich würde Oxid auf dem neuen server nicht installieren. Ganz simpel den source und vendor ordner sowie die composer.json auf den neuen server kopieren. In der composer.json den eintrag "platform": { "php": "7.2.19" } setzen. Ein composer update ausführen. Die neue db-verbindung eintragen usw.

Die composer.lock datei würde ich nicht mit umziehen/kopieren, da durch ein composer update eine neue saubere lock datei mit allen passenden abhängigkeiten passend auf die neue php version erstellt wird.

Kann man das so machen und ist es auch vorallem gängige praxis oder bin ich hier auf’m holzweg. Hab leider noch nicht viel erfahrung mit composer.

Beste grüße

2

Ho!

also die gängige Herangehensweise ist, lokal entwickeln und dann alles per GIT oder Rsync auf den Live-Server zu kopieren. Einige Leute (z.B. ich) nutzen auch Gitlab, welches Änderungen mit dem kuhlen “CI / CD” entgegen nimmt und alles Live pusht. (Lohnt sich sehr, dass mal zu testen).

composer, npm (bower, yarn) usw. werden auf einem Server eigentlich nicht gebraucht, da ja alles schon fertig gebaut ist.

composer update solltest du auf dem Live-Server nie ausführen, das frisst schnell mal 1GiB - 3GiB. Es kann passieren dass das Script abbricht und du eine kaputte Installation live hast.

Wenn du auf deinem Live-Server composer ausführen möchtest, empfehle ich dir composer update lokal laufen zu lassen, dann die erzeugte composer.lock hochzuladen und “composer install” stattdessen zu benutzen. Das braucht nicht annähernd so viel Arbeitsspeicher.

LG
Sioweb

3

Auf git verzichte ich aktuell (noch) bewusst, da ich mich da noch noch nicht sicher genug fühle.

Du machst also praktisch alles lokal und lädst dann den “fertigen” shop (httpdocs inhalt) 1 zu 1 auf den live-server, der vermutlich aus diesem grund mit der identischen php version wie lokal läuft, damit es hier zu keinen problemen/überraschungen kommt?!

Darf man fragen wie deine lokale dev umgebung aufgebau ist, damit sie genau dem live-server entspricht? VM mit einer linux linux distribution oder wie handhabst du das?

Jetzt habe ich aber den fall das die php versionen von server/lokal zu live-server eben nicht die gleichen sind und ich möchte auf dem live-server keine ältere php version mehr nutzen. Arbeitsspeicher sollte kein problem sein, da wir 64 gb ecc ram haben auch auch die restlichen komponenten sind mit nvme ssd und 8 cpu kernen ausreichend demesioniert sind.

Daher bezog sich meine frage speziel auf einem “umzug” wo die php versionen eben nicht gleich sind. Trotzdem danke für deine interessanten infos, die ich mir auf jeden fall noch mal genauer anschaue :slight_smile:

Hättest du evtl. noch paar tips bezüglich meiner ausgangssituation.

PS: ich bin mir auch ehrlich gesagt auch noch nicht sicher ob ich die composer.json und composer.lock wirklich 100 % verstanden habe …

Beste grüße

4

Jo, also meine PHP Versionen sind nicht gleich, lokal nutze ich 7.3 und Live 7.2; Lokal habe ich Wampserver und Live eben einen echten Server. Ich geb nicht viel drauf ob alles gleich ist, ich weiß ja was ich mache. Daten die Live/Lokal tatsächlich unterschiedlich sind - wie Datenbankzugang - speicher ich in Environment-Variablen.

Wichtig ist bei Windows z.B. dringend die Groß/Kleinschreibung der Dateinamen korrekt einhalten.
Bei PHP dürfen nur Funktionen verwendet werden, die in beiden PHP-Versionen vorkommen. Wenn Bei 7.0 & 7.1 sollte das kein Ding sein, bei 5.6 und 7.x solltest du sehr dringend die 5.6 anheben auf 7.x. Auch aus Sicherheitsgründen, 5.6 bekommt keine kostenlosen PHP-Updates mehr.

Umzug würde ich genauso mit einem Rsync machen - benötigt SSH Zugang und evt. etwas Mut den Befehl auszuführen ;D

Jedenfalls kannst du mit Rsync alles auf den neuen Server pushen, wenn du so viel Arbeitsspeicher hast, musst du es auch nicht erst herunterladen um Composer auszuführen. Wichtig ist, Composer ist ein “PHP-Programm”, also im Grunde ein Projekt welches mit Phar in eine Art ausführbare Zip verwandelt wurde. Es könnte sein, dass du PHP mehr Arbeitsspeicher zuweisen musst, falls composer doch abschmiert.

Wenn du öfter Live pusht, dann würde ich dort eine Shell-Datei hochladen die einfach so gängige Arbeit erledigt wie tmp leeren, grunt/gulp/webpack oder was auch immer und composer ausführt. Könnte heißen “deploy.sh” und liegt im Root neben /vendor und /source

rm -Rf /source/tmp # see http://www.thinkplexx.com/learn/snippet/shell/one-liner/remove-all-but-exclude-particular-file-or-directory
# npm run build 
composer update
php vendor/bin/ox.... # diverse oxid scripts

Git

Ich empfehle dir Sourcetree Das ist einfach und es ist nicht leicht etwas kaputt zu machen. Das nimmt dir viel Spannung, Gitlab z.B. bietet auch kostenlose private Repositories - auch gut geeignet um reinzukommen.

Composer.lock

Wenn du composer update ausführst, werden alle Webseiten die Composer in deinem Projekt bekannt sind nach den Paketen welche in der composer.json (und in der composer.json der Pakete ( und in der composer.json der Paket-Pakete…)). Das eine ist packagist.org und das andere ist die Paketseite von Oxid für PE und PP Versionen.

Alles gefundene wird in die composer.lock geschrieben, damit “composer install” einfach nur noch die Daten aus composer.lock nutzen kann, ohne rekursiv 10 ~ 10000 Pakete/Paketversionen durchsuchen zu müssen.

composer.json

Du kannst ja mal eine erstellen und schauen was passiert: composer init. Das hilft immer am Anfang. Du kannst ja mal Pakete auf packagist.org suchen und dir die JSON - Dateien dort anschauen, die ersten 10 composer.json Dateien werden vermutlich (Weil Copy&Paste) eh viel Unsinn enthalten ;D

5

Vielen vielen dank für deinen beitrag. Ich werde mir heute abend oder morgen früh alles durchlesen und versuchen zu verstehen :wink: