Nach Update weisse Seite Frontend und Backend!

[OneChance]

Hallo liebe Leute,
habe heute den Manager auf 1.2.1 upgedatet danach eine Paketaktualisierung gemacht und nun ist bis auf den Manager alles weiss.

Habe Contao 4.7.7 installiert und folgendes schon probiert:

- Alle caches gelöscht
- den composer.lock gelöscht (da beim Paket aktualisieren immer die Meldung kommt das die .lock nicht mit dem composer übereinstimmt)

Und jetzt weiss ich einfach nicht weiter.

Würde mich über eure Hilfe und über einen Tipp freuen.
Danke schon im voraus.

[Spooky]

Du musst auf Contao 4.8.5 aktualisieren. Contao 4.7 hat schon das Lebensende erreicht.

[OneChance]

Du musst auf Contao 4.8.5 aktualisieren. Contao 4.7 hat schon das Lebensende erreicht.

Oh Mann Danke dir dafür da wäre ich in Tausend Jahren nicht drauf gekommen.
Wollte eigentlich erst auf 4.9 wieder upgraden aber gut dann halt so.

Danke noch mal dafür!

[theMatrix]

Hallo zusammen

@spooky Was meinst du damit?

Du musst auf Contao 4.8.5 aktualisieren. Contao 4.7 hat schon das Lebensende erreicht.

Ich habe gerade die composer update über Terminal ausgeführt und habe festgestellt, dass die Seiten in Frontend 500 Error ausgeben.

Was ich gemerkt habe, dass die Symfony-Pakete downgraded wurden.

Loading composer repositories with package information
Updating dependencies (including require-dev)                 
Package operations: 2 installs, 16 updates, 0 removals
...
  - Downgrading symfony/event-dispatcher (v4.2.12 => v3.4.36): Downloading (100%)   
  - Installing symfony/polyfill-php70 (v1.13.1): Downloading (100%)         
  - Downgrading symfony/http-kernel (v4.2.12 => v3.4.36): Downloading (100%)         
  - Installing symfony/class-loader (v3.4.36): Downloading (100%)         
  - Downgrading symfony/framework-bundle (v4.2.12 => v3.4.30): Downloading (100%)         
  - Downgrading symfony/security (v4.2.12 => v3.4.36): Downloading (100%)         
  - Downgrading symfony/twig-bundle (v4.2.12 => v3.4.36): Downloading (100%)         
  - Downgrading symfony/security-bundle (v4.2.12 => v3.4.36): Downloading (100%)
  - Downgrading symfony/web-profiler-bundle (v4.2.12 => v3.4.36): Downloading (100%)
...

Danach ging das Frontend nicht und nur noch über app_dev.php erreichbar.

Hat jemand eine Idee warum das passiert?

[Spooky]

Wie sieht deine composer.json aus?

[theMatrix]

Bitteschön

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0-or-later",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "require": {
        "php": "^7.1",
        "contao/calendar-bundle": "^4.7",
        "contao/comments-bundle": "^4.7",
        "contao/faq-bundle": "^4.7",
        "contao/listing-bundle": "^4.7",
        "contao/manager-bundle": "4.7.*",
        "contao/news-bundle": "^4.7",
        "contao/newsletter-bundle": "^4.7",
        "cocur/slugify": "^3.2",
        "symfony/intl": "^4.3",
        "madeyourday/contao-rocksolid-icon-picker": "^2.0",
        "menatwork/contao-multicolumnwizard-bundle": "^3.4",
        "terminal42/contao-changelanguage": "^3.1",
        "netzmacht/contao-leaflet-maps": "^3.1"
    },
    "conflict": {
        "contao-components/installer": "<1.3"
    },
    "extra": {
        "contao-component-dir": "assets"
    },
    "autoload": {
        "classmap": [
            "src/ContaoManager/ContaoManagerPlugin.php"
        ],
        "psr-4": {
            "": "src/"
        },
        "exclude-from-classmap": [
        ]
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }

}

[Spooky]

Da steht noch "contao/manager-bundle": "4.7.*". Wenn du auf Contao 4.8.7 aktualisieren willst, musst du das dort, oder im Contao Manager, auf 4.8.* ändern und danach eine Paketaktualisierung durchführen. Außerdem solltest du die contao/conflicts hinzufügen (entweder selbst oder vom Contao Manager automatisch).

[theMatrix]

Da steht noch "contao/manager-bundle": "4.7.*". Wenn du auf Contao 4.8.7 aktualisieren willst, musst du das dort, oder im Contao Manager, auf 4.8.* ändern und danach eine Paketaktualisierung durchführen. Außerdem solltest du die contao/conflicts hinzufügen (entweder selbst oder vom Contao Manager automatisch).

Vielen Dank für den Hinweis!
Wie lautet die Version für contao/conflicts und gehört es in die "conflict": { oder in die "require": { ?

Wenn Frontend und Backend nichts zeigt (500), kann ich trotzdem auf 4.8.x aktualisieren oder muss ich erst 4.7.x zum laufen bringen und dann update auf 4.8.x führen?

[Spooky]

Vielen Dank für den Hinweis!
Wie lautet die Version für contao/conflicts und gehört es in die "conflict": { oder in die "require": { ?

https://github.com/contao/managed-ed...poser.json#L16

Wenn Frontend und Backend nichts zeigt (500), kann ich trotzdem auf 4.8.x aktualisieren oder muss ich erst 4.7.x zum laufen bringen und dann update auf 4.8.x führen?

Ich denke in deinem Fall würde ich zuerst auf 4.8.7 aktualisieren.

[theMatrix]

Contao/conflicts ist drin.
Ich habe jetzt die Contao v4.7 auf v4.8 aktualisiert.
Die Seite funktioniert. Ich danke dir vielmals.

Da die app_dev nicht mehr existiert, muss ich die Debug-Modus aktivieren. Was allerdings nach 5 min wieder abschaltet.
Frage: Kann ich die Devug-Modus dauerhaft aktivieren?
Es sollte eigentlich mit .env in Root funktionieren, aber es existiert bereits eine .env mit APP_DEV_ACCESSKEY Eintrag.
Frage: Wofür ist APP_DEV_ACCESSKEY=d3b43fz30qfv3q0ofv4283fp3pvfi... ...?

[Spooky]

APP_DEV_ACCESSKEY war für die app_dev.php. Den Eintrag kannst du löschen oder auch einfach bestehen lassen.

An dieser Stelle möchte ich auch zur Sicherheit nochmals darauf hinweisen, dass du APP_ENV=dev nicht in einer .env der Live Umgebung verwenden solltest.

[theMatrix]

Vielen Dank! Genau, das war es APP_ENV=dev

An dieser Stelle möchte ich auch zur Sicherheit nochmals darauf hinweisen, dass du APP_ENV=dev nicht in einer .env der Live Umgebung verwenden solltest.

@Spooky, ich bin dessen bewusst. Bei der Live-Umgebung wird es entfernt. Dafür gibt es Checklisten Eintrag damit es ja nicht vergessen wird.

[Spooky]

@Spooky, ich bin dessen bewusst. Bei der Live-Umgebung wird es entfernt. Dafür gibt es Checklisten Eintrag damit es ja nicht vergessen wird.

Korrekterweise würde man es so machen: du hast zwei Dateien:

1. .env
2. .env.local

In die .env kommen Umgebungsvariablen, die für alle Umgebungen gelten sollen. In die .env.local kommen nur Dinge, die in der jeweiligen, lokalen Umgebung gelten sollen. Die .env wird im Repository versioniert, die .env.local nicht. Die .env wird auf dem Live Server deployed, die .env.local nicht.

[theMatrix]

Und diese .env.local erkennt Contao auch automatisch?

Aber wie ist es, wenn ich auf einem Server entwickle und die Datei .env verwenden muss? Hier kann ich doch auch mit .htaccess Schutz arbeiten oder nicht um die Seite von fremden Eingriffen zu schützen.

[Spooky]

Und diese .env.local erkennt Contao auch automatisch?

Yep.

Aber wie ist es, wenn ich auf einem Server entwickle und die Datei .env verwenden muss? Hier kann ich doch auch mit .htaccess Schutz arbeiten oder nicht um die Seite von fremden Eingriffen zu schützen.

Klar, aber du kannst ja trotzdem die .env.local verwenden.

[theMatrix]

Sorry, aber ich stehe auf der Leitung

Ich habe jetzt die .env bei der lokalem 4.8 installation von vorhin auf .env.local umbenannt und es hat keine Wirkung.
Muss ich es irgendwo einstellen oder wie erkennt es Contao?

Wie kann ich .env.local auf dem Live-Umgebung verwenden? Meinst du mit umbenennen von beiden Dateien?

Es ist sehr spät und ich blicke nicht mehr durch, nach all den Problemen von Heute.

[Spooky]

Nein, du brauchst folgende Dateien:

• .env
• .env.local

Nur .env.local reicht nicht. .env.local wird nur geladen, wenn eine .env vorhanden ist.

• .env » Enthält Umgebungsvariablen für alle Umgebungen; wird in deinem Repository versioniert; wird auf den Live Server (bzw. alle Umgebungen) deployed
• .env.local » Enthält lokale Umgebungsvariablen für die jeweilige Umgebung; wird nicht in deinem Repository versioniert; wird nicht auf den Live Server deployed

[theMatrix]

Nein, du brauchst folgende Dateien:

• .env
• .env.local

Nur .env.local reicht nicht. .env.local wird nur geladen, wenn eine .env vorhanden ist.

• .env » Enthält Umgebungsvariablen für alle Umgebungen; wird in deinem Repository versioniert; wird auf den Live Server (bzw. alle Umgebungen) deployed
• .env.local » Enthält lokale Umgebungsvariablen für die jeweilige Umgebugn; wird nicht in deinem Repository versioniert; wird nicht auf den Live Server deployed

Perfekt. Ich danke dir für dein Geduld und deine ausführliche Erklärung.