Kopie der Website erkennt Erweiterungen nicht

[gm-team]

Hallo,

ich habe eine 4.4er Installation auf eine neue Hosting Umgebung kopiert.

Die genauen Schritte:
- Sicherung aller CMS files
- dump der DB
- Subdomain in neuer Umgebung angelegt, PHP Einstellungen entsprechend gesetzt
- CMS files hochgeladen (alle außer contao-manager.phar.php!)
- DB dump importiert und parameters.yml angepasst
- Frische contao-manager.phar downgeloaded und in /web hochgeladen, umbenannt auf contao-manager.phar.php
- In Contao Manager angemeldet, hier war eine "Bereinigung" nötig --> gemacht
- CM Konfiguration passt, erkennt alle Erweiterungen
- Im Install Tool stehen plötzlich alle (?) Tabellen der Erweiterungen zum Löschen da
- Wenn man das FE aufruft werden die Erweiterungen scheinbar auch nicht geladen
- Habe dann auch noch folgende Wartungen via CM durchgeführt:
- Symfony Cache
- Composer Class loader
- Composer Cache
Und via BE die Symlinks neu erstellen lassen

Hat alles nichts gebracht - habe ich etwas bez. Manager falsch gemacht? Oder hat es mit dieser "Bereinigung" zu tun?
In der composer.json stehen die Erweiterungen drin, sonst würde wohl CM sie auch nicht anzeigen können.

Danke für Hinweise.

[xchs]

Im Prinzip kannst Du es so machen wie u. a. hier beschrieben: https://erdmann-freunde.de/logbuch/contao-4-4-umziehen/

[fiedsch]

- Sicherung aller CMS files
- CMS files hochgeladen (alle außer contao-manager.phar.php!)

1. Aus Neugierde: wieso die contao-manager.phar.php nicht?

2. "Alle CMS Files" sollte zwar gehen, ist aber zu viel. So brauchst Du z.B. den Ordner vendor/ nicht. Was dort liegen soll, kannst Du jederzeit mit den Angaben in der composer.lock wieder herstellen (composer install). In diesem Schritt werden dann auch noch Sachen gemacht (wie z.B. Cache neu aufbauen), die bei Dir gefehlt haben dürften.

So, wie es @xchs in #2 geschrieben sollte es wohl am einfachsten gehen.

Etwas Eigenwerbung: Unter https://github.com/fiedsch/contao-4-backup-script habe ich ein Backupskript für Contao-4. Und ein Umzug ist nichts anderes als ein Backup und darauffolgendes Restore (auf einer anderen Maschine). Vielleicht hilft Dir das weiter.

[gm-team]

Im Prinzip kannst Du es so machen wie u. a. hier beschrieben: https://erdmann-freunde.de/logbuch/contao-4-4-umziehen/

Danke, den Link kenne ich bereits und habe die Vorgehensweise darin aus einem bestimmten Grund nicht gemacht: Die Installation von Contao über den Manager hat bei mir bei DF kein einziges mal funktioniert, ich musste immer CLI benutzen.

Es geht eben darum, eine Installation zum Download anzubieten, welche sich versch. Vertriebspartner runterladen und installieren sollen können.
Da hat nicht jeder CLI (und auch begrenztes memory_limit) und es müsste doch genügen eine Kopie der files hochzuladen und die Konfiguration anzupassen?

1. Aus Neugierde: wieso die contao-manager.phar.php nicht?

Den soll man ja nicht als "contao-manager.phar.php" übertragen sondern als "contao-manager.phar" und deswegen dachte ich, ich nehme eine frische Version. War das ev. ein Fehler?

2. "Alle CMS Files" sollte zwar gehen, ist aber zu viel. So brauchst Du z.B. den Ordner vendor/ nicht. Was dort liegen soll, kannst Du jederzeit mit den Angaben in der composer.lock wieder herstellen (composer install). In diesem Schritt werden dann auch noch Sachen gemacht (wie z.B. Cache neu aufbauen), die bei Dir gefehlt haben dürften.

ICH könnte das so machen, aber es geht mir mehr darum einen Weg ohne CLI zu finden welcher dann auch für unsere Partner funktioniert.

Unter https://github.com/fiedsch/contao-4-backup-script habe ich ein Backupskript für Contao-4.

Kannte ich noch nicht - wenn man über CLI verfügt sicher praktisch - danke

[fiedsch]

Den soll man ja nicht als "contao-manager.phar.php" übertragen sondern als "contao-manager.phar" und deswegen dachte ich, ich nehme eine frische Version. War das ev. ein Fehler?

Ein Fehler war das bestimmt nicht. Beim "als contao-manager.phar übertragen" geht es nur darum, daß die Datei im Binärmodus übertragen wird. Wenn der Name mit .php endet (damit der Server den Manager ohne weiter Konfiguration ausführt) meint Dein FTP-Programm evtl. so schlau sein zu müssen, die Zeilenenden anzupassen. Damit wäre die Binärdatei dann kaputt.

[gm-team]

Ein Fehler war das bestimmt nicht.

Danke, d.h. irgendeine Art Konfiguration hab ich also dadurch nicht verloren, denn die Konfiguration wird ja in einem anderen file gespeichert (?).
Ich konnte mich ja auch mit den bestehenden Benutzerdaten im Manager anmelden.

Nur frage ich mich was da passiert ist dass der CM die Erweiterungen erkennt, aber Contao selbst nicht?
Ich muss es wohl nochmal durchspielen.

Gibt es an der Vorgehensweise - ohne CLI - berechtigte Gründe dass man das so nicht machen sollte?
Ich könnte das ja als Alternative anbieten wenn die Installation via Manager nicht klappt und man kein CLI zur Verfügung hat.

[fiedsch]

Gibt es an der Vorgehensweise - ohne CLI - berechtigte Gründe dass man das so nicht machen sollte?
Ich könnte das ja als Alternative anbieten wenn die Installation via Manager nicht klappt und man kein CLI zur Verfügung hat.

Wenn Du das so machst, mag die Installation zwar funktionieren, aber spätestens bei einem (Contao) Update hast Du ohne Manager oder CLI verloren.

M.E. daher der falsche Ansatz. Du solltest versuchen, die Probleme zu lösen, die verhindern, daß der Manager läuft - im Extremfall den Provider wechseln.

[tab]

Du musst auch in jedem Fall sicherstellen, dass die verwendete PHP-Version auf dem Zielrechner die selbe ist wie bei dem Rechner, auf dem die Installation per Composer erzeugt wurde. Unter anderem aus diesem Grund gibt es ja auch die offiziellen Download-Archive nicht mehr.

[gm-team]

Du musst auch in jedem Fall sicherstellen, dass die verwendete PHP-Version auf dem Zielrechner die selbe ist wie bei dem Rechner, auf dem die Installation per Composer erzeugt wurde. Unter anderem aus diesem Grund gibt es ja auch die offiziellen Download-Archive nicht mehr.

Muss das die exakt gleiche sein? Und wenn das der neue Host nicht hat - muss man es dann zuvor in der composer.json ändern?

Edit: zB in der composer.json aus der Original-Installation steht:

"php": "^5.6 || ^7.0",

Somit sollte es egal sein welche PHP7 Version am neuen host benutzt wird?

[mlweb]

Somit sollte es egal sein welche PHP7 Version am neuen host benutzt wird?

Nein ist es definitiv nicht. Die Auflösung der Abhängigkeiten hängt auch von der PHP-Version ab.
Also entweder die gewünschte PHP-Version für die Abhängigkeitsauflösung festlegen oder auf gleiche Version achten.

Wenn Du allerdings so arbeitest wie oben vorgeschlagen (erdmann), dann kannst Du Dir das sparen.

[gm-team]

Also entweder die gewünschte PHP-Version für die Abhängigkeitsauflösung festlegen oder auf gleiche Version achten.

Aber die wird ja in der composer.json mit dem von mir gezeigten snippet festgelegt - oder irre ich?

[fiedsch]

Aber die wird ja in der composer.json mit dem von mir gezeigten snippet festgelegt - oder irre ich?

Das nützt bloß gar nichts, wenn Du die composer.json nirgends verwendest. Du hattest ja geschrieben

Ich könnte das ja als Alternative anbieten wenn die Installation via Manager nicht klappt und man kein CLI zur Verfügung hat.

d.h. Du müsstest für jede PHP-Version ein eigenes Paket bereitstellen.

[tab]

Genau, ein Paket je PHP-Version, erzeugen kannst du das beim lokalen installieren (oder auf einem anderen Server installieren) mit dem "platform" Parameter in der composer.json.

Edit: Zielsysteme, auf denen der Contao-Manager nicht läuft und kein SSH-Zugang möglich ist, die willst und musst du nicht haben. Also ich jedenfalls nicht. Wer sich ein Paket mit SSH-Zugang nicht leisten kann (< 60€/Jahr), der braucht auch keine Contao 4 Website, da reicht eine Web-Visitenkarte.

[mlweb]

Aber die wird ja in der composer.json mit dem von mir gezeigten snippet festgelegt - oder irre ich?

Richtig Du irrst. Die für die Auflösung verwendete PHP-Version kann mit "platform" (composer.json) "manipuliert" werden. Ausführlich erklärt mehrfach hier im Forum z.B. hier https://community.contao.org/de/showthread.php?69326-4-4-x-Umzug-Kopie-mit-composer-lock

Nachtrag: Um welchen Provider geht es eigentlich bei dem der Contao Manger nicht läuft bzw. was genau steht dem entgegen genauso vorzugehen wie von "erdmann und freunde" erklärt?

[gm-team]

Vielen dank für die ganzen Antworten.

Es stimmt natürlich - meine Standardvariante sollte auch die "normale" Variante sein wie man Contao installiert.
Also genau wie im Erdmann Beitrag beschrieben.

Habe nochmal alles zurückgesetzt und mich genau an den Beitrag gehalten. Diesmal hat es funktioniert - auch die Installation von Contao über den Manager.
Warum das damals - immer bei DF in gleichwertigen Tarifen, aber bei versch. Kunden - nicht geklappt hat weiß ich auch nicht, jedenfalls wurde der Prozess immer - relativ schnell - abgebrochen.
Ich hatte die Installation über den Manager schon abgeschrieben.

D.h. ich biete nun folgende Varianten an:
Standard) Installation via Contao Manager = PHP-Version kann frei gewählt werden (7.x)
Alternative 1) Installation via Composer/SSH = PHP-Version kann frei gewählt werden (7.x)
Alternative 2) Alle CMS files bereit stellen = muss in versch. PHP-Versionen vorliegen, erzeugen kann ich mir das indem ich in einer lokalen Installation die composer.json entsprechend anpasse und ein Composer Update durchführe(?)

[fiedsch]

Alternative 2) Alle CMS files bereit stellen = muss in versch. PHP-Versionen vorliegen, erzeugen kann ich mir das indem ich in einer lokalen Installation die composer.json entsprechend anpasse und ein Composer Update durchführe(?)

Sollte funktionieren, würde ich mir aber nicht antun! Ein vernünftiges Hosting, bei dem ich keine Krücken brauche, ist früher oder später billiger (eher früher). Updates oder Installation neuer Erweiterungen benötigen so immer ein neues Paket und das muss irgendjemand (Du) bauen. Das dauert = kostet Geld.

[gm-team]

Es wird wohl darauf hinauslaufen dass ich das dann nur gegen Aufpreis anbiete wenn "alle Stricke reissen" wie man so schön sagt.

Denn dann kenne ich auch die exakte PHP Version und ggfs. weitere techn. Parameter.