Übertragen der Website auf einen anderen Webspace - Verknüpfungen fehlen

//Update: Ich habe diesen Ausgangsbeitrag mal etwas aufgeräumt und die wichtigen Schritte benannt, damit andere die nach Hilfe suchen, hier auch Infos finden und nicht nur über die Punkte stolpern, die ich falsch gemacht habe (wie aus Übermüdung die composter.phar löschen und sich dann wundern ;)).

Ich wollte eine Contao 4.3-Installation nach der Fertigstellung auf den Webspace des Kunden übertragen. Scheinbar übernimmt er dabei aber nicht die notwendigen Verknüpfungen (Symlinks?). So findet Contao natürlich weder die Module noch kommt es sonst zurecht.

Meine Frage war also, ob ich diese irgendwie nach der Übertragung automatisch neu erstellen lassen kann (SSH?).

// Hier der erste Schritt zur Lösung (laut diesem Thread)

Prüfen, ob auf dem Webspace Composer installiert ist und dann ggf eben drauf installieren. Ich habe also in dem Projektordner diesen Aufruf per SSH gestartet:

Code:

---

wget https://getcomposer.org/download/1.4.1/composer.phar

---

Danach habe ich Composer angewiesen, ein Update zu machen. Vorteil: Dadurch werden Symlinks neu generiert.

Code:

---

php composer.phar update

---

Beim Aufruf der Website bzw. der Install kam jetzt immer noch der Fehlerhinweis, dass die Extension X nicht gefunden werden kann. Also habe ich Composer angewiesen, die Extension nochmal neu zu installieren:

Code:

---

php71 composer.phar require terminal42/contao-pageimage

---

Danach war der Fehlerhinweis weg und ich konnte endlich die Install erreichen (/install.php nicht /contao/install.php wie früher). Die Install wird mir aber ungestyled angezeigt (You don't have permission to access /system/themes/flexible/install.css). Davon habe ich mich erstmal nicht aufhalten lassen und sie dennoch genutzt (Eingabe der Datenbank-Zugangsdaten vom neuen Webspace und Prüfung ob sonst etwas angemeckert wird; war nicht der Fall).

Danach konnte ich Frontend und Backend wieder aufrufen - allerdings leider komplett ungestyled. Der Zugriff auf alle Files wie CSS/Bilder sowohl für Frontend als auch Backend ist nicht möglich. Mal schauen, woran das nun liegt.

- soweit der Stand bis Post #8 dieses Threads -

Hier nun der wirklich wichtige finale Schritt
Ab #10 hier im Thread sieht man, dass ein großes Problem dadurch entstanden ist, dass wohl die neueste Version von Symfony Ärger macht. Dadurch werden u.a. Symlinks kaputt gemacht, was wiederum dazu führt, dass die Website keine Styles im Frontend/Backend hat. Es wurde eine temporäre Lösung dafür gepostet (sie weiter unten). Danach musste ich die Datenbanksicherung nochmal neu einspielen, weil Contao sich an den kaputten Symlinks verhustet hatte und weder verknüpfte Files noch die entsprechenden Einstellungen in den Modulen noch kannte.

Nach 9 Stunden Arbeit, ist die Website nun endlich übertragen. Ich hoffe sehr, dass andere dieses Märtyrium nicht machen müssen und hier im Thread gleich wichtige Hilfe finden :)

Ich wollte versuchen, mit den SSH-Befehlen das vielleicht neu erstellen zu lassen:

Code:

---

php app/console contao:install
php app/console contao:symlinks

---

Problem: Die Konsole meldet could not open input file: app/console

Dann dachte ich mir, dass vielleicht der Composer dort noch nicht läuft. Habe also im Root der Contao-Installation den Befehl durchlaufen lassen:

Code:

---

wget https://getcomposer.org/download/1.4.1/composer.phar

---

Danach nochmal oben den ersten Befehl eingegeben, aber erneut die Meldung mit could not open bekommen. Hat jemand eine Idee, warum das hakt?

Wenn du die contao/standard-edition mit Contao 4.3.7 neu installierst hast, dann liegt die console Datei unter bin, der Aufruf wäre also:

Code:

---

php bin/console …

---

Wenn du die contao/managed-edition verwendest, dann gibt diese Datei nicht, dafür gibt es aber vendor/bin/contao-console. Der Aufruf lautet

Code:

---

vendor/bin/contao-console …

---

(ohne php).

Siehe https://docs.contao.org/books/extend...ition/#console

Danke, ich habe es versucht, aber leider kommt dann das:

Code:

---

vendor/bin/contao-console contao:symlinks
bash: vendor/bin/contao-console: Permission denied

---

Ich glaube, dass da irgendein Composer-Problem ist (also Composer falsch installiert ist oder so). Ich wollte mal testweise die Extension die er als fehlend anmeckert, über den Composer nochmal neu drüber installieren. Da kommt dann:

Code:

---

php71 composer.phar require terminal42/contao-pageimage
Could not open input file: composer.phar

---

Vielleicht hakt es also schon an der rudimentären Sache. Mal schauen ... *such*

Existiert die composer.phar?

Ich bin einen kleinen Schritt weiter. Vorhin hatte ich testweise die Contao4.3 frisch runtergeladen und nochmal drüber gebügelt. Dabei muss ich wohl die composer.phar erlegt haben (deshalb der vorhergehende Fehler). Nun habe ich nochmal im Ordner des Projekts den Aufruf zur Installation des Composers gemacht:

Code:

---

wget https://getcomposer.org/download/1.4.1/composer.phar

---

Und gleich danach:

Code:

---

php composer.phar update

---

Jetzt kann ich zumindest schon mal das Install-Tool wieder ohne die Fehlermeldung (von wegen fehlender Extension) aufrufen, da hierbei scheinbar die Symlinks (zum Teil?) wieder repariert wurden.
Es hakt aber nun noch an der Anzeige, da keine Styles beim Install-Tools geladen werden (You don't have permission to access /system/themes/flexible/install.css). Mal weiter schauen ... *such*

So, das ist der aktuelle Stand:

• Ich kann jetzt endlich die /install.php aufrufen (das ging anfangs nicht, weil er immer meckerte, dass er die Extensions nicht findet - wegen der fehlenden Symlinks).
• Aber die Install ist ungestyled, weil die CSS-Files aus einem mir noch unbekannten Grund nicht geladen werden können.
• Ich habe die Install trotzdem durchlaufen lassen, weil ich in dem Zug mal eben die neuen Datenbank-Angaben eingeben konnte.
• Das Frontend der Website kommt nun, aber sämtliche CSS-Files und Bilder werden weder im Frontend noch beim Backend-Login angezeigt. Es scheint also irgendein Rechteproblem zu sein.

// hab das mal oben imn Eingangspost so ergänzt

Wie hast du die Contao Installation übertragen bzw. installiert? Bist du mit dem richtigen User eingelogged? Überprüfe über SSH die Dateirechte selbst. Notfalls wende ein chown und chmod auf die gesamte Installation an.

Zitat:

---

Zitat von Spooky

Wie hast du die Contao Installation übertragen bzw. installiert? Bist du mit dem richtigen User eingelogged? Überprüfe über SSH die Dateirechte selbst. Notfalls wende ein chown und chmod auf die gesamte Installation an.

---

Ich habe die Contao-Installation mit SFTP mit dem Hauptnutzer übertragen. Die Rechte der Files liegen alle bei diesem Nutzer. Ich habe mir mal testweise die Rechte einer angemeckerten Styledatei vom Backend-Login angeschaut. Der Browser meint, dass die Rechte für /system/themes/flexible/fonts.css nicht passen (Permission denied). Wenn ich mir die vendor/contao/core-bundle/src/Resources/contao/themes/flexible/font.css aber ansehe, gehört sie dem primären Nutzer und hat CHMOD 0644. Sollte also eigentlich ok sein, oder?

Komisch...

// Ich logge mich jetzt einfach mal so ins Backend ein (auch wenn es ungestyled ist). Wollte schauen, ob aus irgendeinem Grund die Ordner in der Dateiverwaltung nicht mehr öffentlich geschaltet sind (wobei das nur die Sache vom Frontend erklären würde, nicht vom Backend). Hier sieht man mal gleich wieder ein aktuelles akutes Barrierefreiheitsproblem: Ohne Styles kann man die Icons der Dateiverwaltung für die einzelnen Ordner gar nicht sehen, weil sie keine richtigen Alternativtexte haben. Naja, das ist ein anderes Thema um das ich mich separat kümmern werde ;)

Daran liegt es nicht. Die Ordnereinstellungen der Dateiverwaltung sind korrekt auf öffentlich gesetzt.

Jetzt habe ich etwas gefunden:
Ich habe mir mal gerade testweise via Web-FTP die Struktur auf dem Technikserver und dem Kundenserver nebeneinander angesehen und bin sie Ordner für Ordner durchgegangen (so kann ich schön auf einen Blick sehen, welche Ordner/Dateien da sind und welche Benutzer/Rechte sie haben). Dabei ist mir aufgefallen, dass am Technikserver im /web-Ordner ein Symlink für die assets liegt, der am Kundenserver nicht da ist. Das würde vermutlich einiges erklären.

Hat jemand eine Idee, warum Contao den nicht selbst anlegt, obwohl ich im Backend die Systemwartung gemacht und dabei gesagt habe, es soll die Symlinks neu generieren?

Weiterer Fehler gefunden:
Ich habe vorhin mal testweise in der Dateiverwaltung die Synchronisation durchlaufen lassen. Hat nichts verbessert. Danach habe ich mir den Ordner /web/files/ mal angesehen.
Unter /web/files/ liegen zwar Symlinks, aber sie sind falsch eingestellt. Zum Beispiel:
Am Technikserver zeigt aktuelles korrekt auf ../../files/aktuelles
Am Kundenserver zeigt aktuelles falsch auf ../aktuelles

Hi,

das könnte mit einer aktuellen Symfony-Inkompatibilität zusammenhängen https://github.com/contao/core-bundle/issues/751

Da hat es bei mir einige Contao-Installationen zerrissen mit dem gleichen Effekt.

Man könnte vorübergehend in die composer.json explizit die funktionierende Symfony-Version reinschreiben:

"symfony/symfony": "3.2.6"

Dann einen Composer-Update und die Symlinks werden wieder ordentlich angelegt.

Hat bei mir geholfen. Sollte halt nicht vergessen werden der Eintrag, wenn es wieder eine kompatibele Symfony-Version gibt.

Gruß
Franky

Oh VIELEN, vielen Dank für diesen Hinweis! :)

Wer rechnet denn damit, dass genau jetzt eine neue Symfony-Version Ärger macht? :eek:

Ich versuch das gleich...

Also die Sache mit Symfony hat geklappt. Allerdings gibt es jetzt ein richtiges Problem - keine Ahnung, ob das daraus entstanden ist - sämtliche Verknüpfungen sind weg. Contao hat also auf der gesamten Website vergessen, wo Bilder lagen, welche Archive z.b. bei den News gewählt waren usw.

Ich hoffe, dass ich das durch erneutes Einspielen der Datenbank korrigieren kann.

// Nachtrag, ja, das hat geholfen. Jetzt sind die Verknüpfungen wieder alle da.

Die Website scheint nun korrekt zu laufen. Somit hat mein erster Versuch eine fertige Website mit C4.3 auf den Live-Server zu übertragen nur knapp 9 Stunden (über Nacht) gedauert :eek:
... ich hoffe sehr, dass dieser Thread zumindest anderen Nutzern den Ärger ersparen kann oder ihnen wenigstens auch bei der Lösung hilft.

Herzliche Dank an euch beide für eure Hilfe!

Du könntest einstweilen auch diesen Hotfix benutzen: https://github.com/contao/core-bundle/pull/752/files

Anmerkung: der wird zwar vielleicht nicht in das core-bundle übernommen, weil der Bug eigentlich bei Symfony liegt, schaden kann es bis zum nächsten Symfony oder Contao Update aber trotzdem nicht.

Ich halte das Problem für erheblich und habe daher temporär oben im Forum einen Hinweis angepinnt.

Zitat:

---

Bis das behoben ist, gibt es einen Hotfix der installiert werden kann bzw. eine nicht updatesichere Methode, wie verhindert werden kann, dass bei einem Update Composer die fehlerhafte Symfony-Version lädt und dadurch diverse erhebliche Folgeprobleme auftreten.

---

Das stimmt so nicht, die Methode wie man verhindern kann, dass die fehlerhafte Symfony Version installiert wird, ist definitiv "Update Sicher". Das Anwenden von https://github.com/contao/core-bundle/pull/752 ist nicht Update Sicher - mehr oder weniger, denn bei einem Composer Update würde Composer aber fragen, was damit passieren soll.

Ich formuliere es um.

sicherer ist es wenn man einen conflict auf Symfony 3.2.7 macht.

Code:

---

{
    [...]
    "require": {
        "php": ">=5.5.0",
        "symfony/symfony": "~2.8|~3.0",
        [...]
    },
    "conflict": {
        "symfony/symfony": "3.2.7"
    },
    [...]
}

---

Das ist 100% update sicher und composer aktualisiert dann automatisch auf 3.2.8 (in welcher das Problem dann hoffentlich behoben ist).

Danke, das ist natürlich schön. So muss ich nicht daran denken, später eine Sperre zu entfernen :)

Danke für die Information. Ich ar hier gerade am durchdrehen weil meine Sym-Links einfach nicht gepasst haben und das bisher immer gepasst hat.

Hallo Nina,
Vielleicht kannst Du die graue Hinweis-Box oben im Forum mal leicht modifizieren. Gestrig stimmt ja schon eine Weile nicht mehr.

Mit der neusten Contao Version sollte das Problem ja nun nicht mehr auftreten, oder? Auch ohne Symfony fix.

Hallo Zusammen,

ich bin über Eure Korrespondenz gestolpert weil mein aktuelles Problem ähnlich ist wie bei Nina.
Nach dem hochladen aller Dateien des Templates auf den Server habe ich das Problem dass sich die install.php im "web Ordner" nicht aufrufen läßt. (www.h-u-d-pictures.de/install.php) Er zeigt mir einen 500 Fehler an.
In der php_errors.log wird mir auch Fehler mit den Symlinks angezeigt. Ich habe mir hier zwar alles durchgelesen, aber verstehe zu wenig davon um weiterzukommen.
Könnt ihr mir weiterhelfen?

Danke im Voraus.

Zitat:

---

Zitat von Nina

//Update: Ich habe diesen Ausgangsbeitrag mal etwas aufgeräumt und die wichtigen Schritte benannt, damit andere die nach Hilfe suchen, hier auch Infos finden und nicht nur über die Punkte stolpern, die ich falsch gemacht habe (wie aus Übermüdung die composter.phar löschen und sich dann wundern ;)).

Ich wollte eine Contao 4.3-Installation nach der Fertigstellung auf den Webspace des Kunden übertragen. Scheinbar übernimmt er dabei aber nicht die notwendigen Verknüpfungen (Symlinks?). So findet Contao natürlich weder die Module noch kommt es sonst zurecht.

Meine Frage war also, ob ich diese irgendwie nach der Übertragung automatisch neu erstellen lassen kann (SSH?).

// Hier der erste Schritt zur Lösung (laut diesem Thread)

Prüfen, ob auf dem Webspace Composer installiert ist und dann ggf eben drauf installieren. Ich habe also in dem Projektordner diesen Aufruf per SSH gestartet:

Code:

---

wget https://getcomposer.org/download/1.4.1/composer.phar

---

Danach habe ich Composer angewiesen, ein Update zu machen. Vorteil: Dadurch werden Symlinks neu generiert.

Code:

---

php composer.phar update

---

Beim Aufruf der Website bzw. der Install kam jetzt immer noch der Fehlerhinweis, dass die Extension X nicht gefunden werden kann. Also habe ich Composer angewiesen, die Extension nochmal neu zu installieren:

Code:

---

php71 composer.phar require terminal42/contao-pageimage

---

Danach war der Fehlerhinweis weg und ich konnte endlich die Install erreichen (/install.php nicht /contao/install.php wie früher). Die Install wird mir aber ungestyled angezeigt (You don't have permission to access /system/themes/flexible/install.css). Davon habe ich mich erstmal nicht aufhalten lassen und sie dennoch genutzt (Eingabe der Datenbank-Zugangsdaten vom neuen Webspace und Prüfung ob sonst etwas angemeckert wird; war nicht der Fall).

Danach konnte ich Frontend und Backend wieder aufrufen - allerdings leider komplett ungestyled. Der Zugriff auf alle Files wie CSS/Bilder sowohl für Frontend als auch Backend ist nicht möglich. Mal schauen, woran das nun liegt.

- soweit der Stand bis Post #8 dieses Threads -

Hier nun der wirklich wichtige finale Schritt
Ab #10 hier im Thread sieht man, dass ein großes Problem dadurch entstanden ist, dass wohl die neueste Version von Symfony Ärger macht. Dadurch werden u.a. Symlinks kaputt gemacht, was wiederum dazu führt, dass die Website keine Styles im Frontend/Backend hat. Es wurde eine temporäre Lösung dafür gepostet (sie weiter unten). Danach musste ich die Datenbanksicherung nochmal neu einspielen, weil Contao sich an den kaputten Symlinks verhustet hatte und weder verknüpfte Files noch die entsprechenden Einstellungen in den Modulen noch kannte.

Nach 9 Stunden Arbeit, ist die Website nun endlich übertragen. Ich hoffe sehr, dass andere dieses Märtyrium nicht machen müssen und hier im Thread gleich wichtige Hilfe finden :)

---