MIME Type Konflikt nach Umzug/Update

**tblumrich** · 17.04.2023, 15:14

Hallo!

Ich hab heute eine Contao Installation auf einen anderen Server gezogen und dabei von 4.4 auf 4.13 geupdatet. Das hat soweit geklappt mit den Manager.
Leider scheint das Frontend und auch das Backend diverse Dateien nicht zu laden bzw. die werden blockiert laut Developer Konsole "... wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff)"

Dadurch lädt das ganze extrem lange und im Fontend fehlen die meisten Grafiken und alle CSS und JS Dateien.

Konole Frontend:

Code:

Error: An unexpected error occurred spoofer.js:1:38935
GET
http://cbs.blusi.de/files/js_css/mobile.css?v=f0001238

GET
http://cbs.blusi.de/files/js_css/navigation.css?v=f0001238

GET
http://cbs.blusi.de/files/js_css/layout.css?v=f0001238

GET
http://cbs.blusi.de/files/js_css/forms.css?v=f0001238

GET
http://cbs.blusi.de/files/fonts/font-awesome-4.7.0/css/font-awesome.min.css?v=67c64414

GET
http://cbs.blusi.de/files/fonts/webfont.css?v=f0001238

GET
http://cbs.blusi.de/files/js_css/popup.css?v=f0001238

GET
http://cbs.blusi.de/files/js_css/columns.css?v=f0001238

GET
http://cbs.blusi.de/system/modules/mobile_menu/assets/css/mobile-menu.min.css?v=c2e22dce

GET
http://cbs.blusi.de/system/modules/mobile_menu/assets/js/mobile-menu.jquery.min.js?v=c2e22dce

GET
http://cbs.blusi.de/files/js_css/popup.js

GET
http://cbs.blusi.de/files/js_css/macy.js

GET
http://cbs.blusi.de/files/img/CP Bad Stuer 2023 icon Stellplatz min.png
[HTTP/1.1 404 Not Found 16089ms]

GET
http://cbs.blusi.de/files/img/SEASIDE_CARAVAN.png
[HTTP/1.1 404 Not Found 15232ms]

GET
http://cbs.blusi.de/files/bilder/Wohnmobilvermietung-Rostock.jpg
[HTTP/1.1 404 Not Found 17022ms]

GET
http://cbs.blusi.de/files/img/Lage - Kontakt - Campingplatz Bad Stuer.png
[HTTP/1.1 404 Not Found 14397ms]

Die Ressource von "http://cbs.blusi.de/files/js_css/popup.css?v=f0001238" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/fonts/font-awesome-4.7.0/css/font-awesome.min.css?v=67c64414" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/system/modules/mobile_menu/assets/css/mobile-menu.min.css?v=c2e22dce" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/js_css/columns.css?v=f0001238" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/fonts/webfont.css?v=f0001238" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/js_css/forms.css?v=f0001238" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/js_css/layout.css?v=f0001238" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/js_css/mobile.css?v=f0001238" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/js_css/navigation.css?v=f0001238" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/js_css/popup.js" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
GET
http://cbs.blusi.de/files/js_css/popup.js

Die Ressource von "http://cbs.blusi.de/system/modules/mobile_menu/assets/js/mobile-menu.jquery.min.js?v=c2e22dce" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/js_css/macy.js" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Die Ressource von "http://cbs.blusi.de/files/js_css/popup.js" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
GET
http://cbs.blusi.de/files/js_css/macy.js

GET
http://cbs.blusi.de/files/img/SEASIDE_CARAVAN.png
[HTTP/1.1 404 Not Found 3844ms]

GET
http://cbs.blusi.de/files/bilder/Wohnmobilvermietung-Rostock.jpg
[HTTP/1.1 404 Not Found 3860ms]

GET
http://cbs.blusi.de/files/img/CP Bad Stuer 2023 icon Stellplatz min.png
[HTTP/1.1 404 Not Found 3860ms]

Die Ressource von "http://cbs.blusi.de/files/js_css/macy.js" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). stellplatz.html
Uncaught TypeError: $(...).mobileMenu is not a function
    <anonymous> http://cbs.blusi.de/stellplatz.html:230
    <anonymous> http://cbs.blusi.de/stellplatz.html:243
stellplatz.html:230:25
GET
http://cbs.blusi.de/files/img/Lage - Kontakt - Campingplatz Bad Stuer.png
[HTTP/1.1 404 Not Found 3828ms]

GET
http://cbs.blusi.de/apple-touch-icon.png
[HTTP/1.1 404 Not Found 0ms]

GET
http://cbs.blusi.de/favicon-16x16.png
[HTTP/1.1 404 Not Found 0ms]

Backend läuft... allerdings sehr langsam und die Konsolenausgabe sagt das:

Code:

Error: An unexpected error occurred spoofer.js:1:38935
GET
http://cbs.blusi.de/bundles/multicolumnwizard/css/multicolumnwizard.css?v=ff27f19b

GET
http://cbs.blusi.de/system/modules/m17StickyBEFooter/assets/m17StickyBeFooter.css?v=93a50119

GET
http://cbs.blusi.de/system/modules/notification_center/assets/backend.css?v=00892a2e

GET
http://cbs.blusi.de/system/modules/sharebuttons/assets/backend.css?v=d8d3755e

GET
http://cbs.blusi.de/bundles/multicolumnwizard/js/multicolumnwizard_be.js?v=ff27f19b

GET
http://cbs.blusi.de/system/modules/m17StickyBEFooter/assets/m17StickyBeFooter.js?v=93a50119

Die Ressource von "http://cbs.blusi.de/system/modules/m17StickyBEFooter/assets/m17StickyBeFooter.css?v=93a50119" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). contao
Die Ressource von "http://cbs.blusi.de/system/modules/notification_center/assets/backend.css?v=00892a2e" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). contao
Die Ressource von "http://cbs.blusi.de/bundles/multicolumnwizard/js/multicolumnwizard_be.js?v=ff27f19b" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). contao
Die Ressource von "http://cbs.blusi.de/system/modules/sharebuttons/assets/backend.css?v=d8d3755e" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). contao
Die Ressource von "http://cbs.blusi.de/bundles/multicolumnwizard/css/multicolumnwizard.css?v=ff27f19b" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). contao
GET
http://cbs.blusi.de/bundles/multicolumnwizard/js/multicolumnwizard_be.js?v=ff27f19b

Die Ressource von "http://cbs.blusi.de/system/modules/m17StickyBEFooter/assets/m17StickyBeFooter.js?v=93a50119" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). contao
Die Ressource von "http://cbs.blusi.de/bundles/multicolumnwizard/js/multicolumnwizard_be.js?v=ff27f19b" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). contao
GET
http://cbs.blusi.de/system/modules/m17StickyBEFooter/assets/m17StickyBeFooter.js?v=93a50119

Die Ressource von "http://cbs.blusi.de/system/modules/m17StickyBEFooter/assets/m17StickyBeFooter.js?v=93a50119" wurde wegen eines MIME-Typ-Konfliktes ("text/html") blockiert (X-Content-Type-Options: nosniff). contao
GET
http://cbs.blusi.de/favicon.ico
[HTTP/1.1 404 Not Found 0ms]

Die htaccess ist die Originale von Contao 4.13.

In der Dateiverwaltung ist alles öffentlich und die Symlinks habe ich neu erstellen lassen und die Caches mehrfach neu aufgebaut.

Freue mich über jede Idee! Dankeschön.

**Spooky** · 17.04.2023, 15:18

Wenn du die URLs aufrufst, siehst du, dass da jeweils 404 kommt. Prüfe nochmal die Symlinks, die Berechtigungen - und auch ob FollowSymlinks beim Webserver überhaupt aktiv ist (falls Apache zum Einsatz kommt).

**tblumrich** · 17.04.2023, 15:32

Ich prüfe nochmal alles...
Was mir noch auf/eingefallen ist.

Der Links zum CM fehlt im Backend, ich hatte da sschon öfter wenn ich in einem Update vom web zum public Ordner gewechselt bin... Kann das auch damit zusamenhängen?
Meine composer.json hat wohl auch noch alte Bestandteile?

Code:

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0+",
    "authors": [{
        "name": "Leo Feyer",
        "homepage": "https://github.com/leofeyer"
    }],
    "require": {
        "php": "^5.6|^7.0",
        "backboneit/contao-navigation": "^1.8",
        "codefog/contao-mobile_menu": "^2.7",
        "contao/calendar-bundle": "4.13.*",
        "contao/comments-bundle": "4.13.*",
        "contao/conflicts": "*@dev",
        "contao/faq-bundle": "4.13.*",
        "contao/listing-bundle": "4.13.*",
        "contao/manager-bundle": "4.13.*",
        "contao/news-bundle": "4.13.*",
        "contao/newsletter-bundle": "4.13.*",
        "fritzmg/contao-sharebuttons": "^2.0",
        "fritzmg/contao-swiper": "^1.0",
        "hofff/contao-calendarfield": "^3.0",
        "hypergalaktisch/contao-animate": "^2.0",
        "jrgregory/m17-sticky-backend-footer": "^2.0",
        "madeyourday/contao-rocksolid-columns": "^2.0",
        "madeyourday/contao-rocksolid-slider": "^2.0",
        "menatwork/semantic_html5": "^2.0",
        "terminal42/contao-ajaxform": "^1.0",
        "terminal42/notification_center": "^1.4",
        "webexmachina/contao-webp-converter-bundle": "^0.1.1"
    },
    "conflict": {
        "symfony/finder": "3.4.8 || 4.0.8"
    },
    "config": {
        "component-dir": "assets"
    },
    "extra": {
        "branch-alias": {
            "dev-4.4": "4.4.x-dev"
        }
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }
}

**Spooky** · 17.04.2023, 15:36

Konzentrier' dich zuerst mal auf eine Sache.

**tblumrich** · 17.04.2023, 15:46

Okay.

Also Symlinks scheinen mir alle richtig zu sein, ich kann sie auch problemlos in der Systemwartung neu setzen. Wenn ich den Symlinks folge z.B. aus dem public Ordner, lande ich jedenfalls immer im Ziel.
Berechtigungen sind alle 755 für Ordner und 644 bei Dateien (habs jetzt fast überall geprüft - vor allem die Dateiverwaltung, vendor, system, assets) Alle Ordner sind öffentlich.

Ich weiß jetzt nicht wie ich "FollowSymlinks" prüfen kann, aber ich hab auf dem Webserver sehr viele Contao Installationen, die sauber laufen - insofern nehme ich an das das bei der Installation auch der Fall ist.

**Spooky** · 17.04.2023, 16:00

Zitat von tblumrich

Ich weiß jetzt nicht wie ich "FollowSymlinks" prüfen kann

Notfalls der Hoster.

**tblumrich** · 17.04.2023, 16:15

Das ist ein eigener (Managed vServer), bei dem ich alle Installationen gleich eingestellt habe bzw. alle Installationen immer gleich vornehme, so auch heute. Alle anderen Installationen laufen... ich frage mal so naiv, ist es überhaupt möglich/wahrscheinlich, das die Funktion bei diesem einen Verzeichnis nicht geht?
Oder anders... ist es in dem Fall sinnvoll den Support zu fragen?

Ich hab was gefunden:

Fähigkeit, symbolischen Verknüpfungen zu folgen, einschränken
Wählen Sie diese Option aus, um Benutzer daran zu hindern, die Anweisung FollowSymLink in .htaccess zu verwenden und um so die Serversicherheit zu verbessern.

Das ist nicht angehakt.

**tblumrich** · 17.04.2023, 17:28

Okay, ich glaube ich habs jetzt...
Die Erkenntnis kam dann doch mit der Anpassung der composer.json. Die hab ich geändert auf:

Code:

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0+",
    "authors": [{
        "name": "Leo Feyer",
        "homepage": "https://github.com/leofeyer"
    }],
    "require": {
        "backboneit/contao-navigation": "^1.8",
        "codefog/contao-mobile_menu": "^2.7",
        "contao/calendar-bundle": "4.13.*",
        "contao/comments-bundle": "4.13.*",
        "contao/conflicts": "*@dev",
        "contao/faq-bundle": "4.13.*",
        "contao/listing-bundle": "4.13.*",
        "contao/manager-bundle": "4.13.*",
        "contao/news-bundle": "4.13.*",
        "contao/newsletter-bundle": "4.13.*",
        "fritzmg/contao-sharebuttons": "^2.0",
        "fritzmg/contao-swiper": "^1.0",
        "hofff/contao-calendarfield": "^3.0",
        "hypergalaktisch/contao-animate": "^2.0",
        "jrgregory/m17-sticky-backend-footer": "^2.0",
        "madeyourday/contao-rocksolid-columns": "^2.0",
        "madeyourday/contao-rocksolid-slider": "^2.0",
        "menatwork/semantic_html5": "^2.0",
        "terminal42/contao-ajaxform": "^1.0",
        "terminal42/notification_center": "^1.4",
        "webexmachina/contao-webp-converter-bundle": "^0.1.1"
    },
    "extra": {
        "public-dir": "public",
        "contao-component-dir": "assets"
    },
    "scripts": {
        "post-install-cmd": [
            "@php vendor/bin/contao-setup"
        ],
        "post-update-cmd": [
            "@php vendor/bin/contao-setup"
        ]
    }
}

Danach wurde parallel zu public /web erstellt (vermutlich durch den Manager).
Jetzt konnte ich sehen, das doch ein paar Symlinks fehlten (bzw. war der web-Ordner nicht gleich mit /public). Vor allem /files, /system/modules und der Symlink /bundles/multicolumnwizard fehlten... Warum auch immer? Ich vermute der Fehler war irgendwo in meinem Vorgehen:

1. 4.13 neu installiert (mit contao-manager.phar in /public)
2. Alte composer.json in die neue Installation kopiert (dazu auch /files und /templates)
3. Alle Pakete aktualisiert (danach stand auch Contao auf 4.4) Fehler?
4. Contao auf 4.13 gestellt - Alle Pakete aktualsieren
5. Datenbank Update mit gesicherter DB aus der 4.4 (mit Installtool)

Irgendwo müssen dabei einige der Symlinks in /public "verloren" gegangen sein. Hätte ich an irgendeiner Stelle anders vorgehen sollen?

**Spooky** · 17.04.2023, 17:38

Zitat von tblumrich

Hätte ich an irgendeiner Stelle anders vorgehen sollen?

Nächstes mal:

Ordner web/ auf public/ umbenennen.
Im Hosting den DocumentRoot auf public/ ändern.
Nochmal sicherstellen, dass kein web/ Ordner vorhanden ist. Wenn doch, löschen.
Contao Manager aufrufen und composer install ausführen.

**tblumrich** · 17.04.2023, 17:45

Ich hab ja zuerst Contao 4.13 installiert mit dem DocRoot auf /public. Hätte ich das wegen des folgenden Updates zunächst doch als DocRoot /web machen sollen?

**Spooky** · 17.04.2023, 17:59

Nein. Aber irgendwann scheinst du web/ gehabt zu haben als DocumentRoot.

**tblumrich** · 17.04.2023, 22:19

Nein. /web war nie der docroot. Jedenfalls hab ich nur /public eingerichtet am Anfang und das dann auch nicht mehr geändert. So hab ich ja problemlos 4.13 installiert. Der Web Ordner entstand erst später und nicht durch mich. So wie ich es oben beschrieben habe… vermutlich nachdem der CM die importierte composer.json der 4.4. verarbeitet hat und aus meiner frischen 4.13 eine 4.4 gemacht hat.
Anders kann ich es nicht sagen, definitiv.

**Spooky** · 18.04.2023, 00:47

Wenn du von 4.4 auf 4.13 aktualisiert hast, hast du auf jeden Fall web/ verwendet.

**tblumrich** · 18.04.2023, 10:26

Wenn ich direkt von einer 4.4 mit dem Manager auf die 4.13 update, ist das natürlich so.

Ich will das auch garnicht weiter (be)streiten (das würde ich mir nie anmaßen). Ich kann aber definitiv sagen, das ich den Docroot nie aktiv geändert habe auf web/!
Und... es läuft ja wieder. Dafür bin ich sehr dankbar.

Ich will ja eigentlich nur wissen wie ich es in Zukunft besser mache, wenn z.B. ein Serverumzug einer 4.4 ansteht mit folgendem Update. Das ist mir nachwievor nicht ganz klar.

Gemacht hab ich (eigentlich schon öfter):

1. 4.13 auf neuen Server installiert ohne Datenbanupdate
2. composer.json der 4.4 Quellinstallation importiert zur neuen Installation
3. CM auf Zielinstallation aufgerufen und dort alle Pakete aktualisiert
(danach stand Contao Core auf v4.4 - ich hab aber nirgends den Docroot auf web/ geändert - ich schwöre!)
4. Contao im CM auf 4.13 gestellt - wieder alle Pakte aktualisiert
5. Datenbankupdate auf Zielinstallation mit importierter DB aus Quellinstallation v4.4

Sollte ich das an irgendeiner Stelle anders machen?

**Spooky** · 18.04.2023, 10:35

Zitat von tblumrich

(danach stand Contao Core auf v4.4 - ich hab aber nirgends den Docroot auf web/ geändert - ich schwöre!)

Das ist egal, Contao 4.4 unterstützt nur web/ und legt daher web/ an.

Zitat von tblumrich

Sollte ich das an irgendeiner Stelle anders machen?

Ja, warum der Umweg mit "zuerst 4.13 installieren"? Deswegen ist das Problem entstanden.

**tblumrich** · 18.04.2023, 13:07

Zitat von Spooky

Ja, warum der Umweg mit "zuerst 4.13 installieren"? Deswegen ist das Problem entstanden.

Weil ich ja umziehen musste mit einer 4.4 auf einen anderen Server. Und ich hab irgendwo aufgeschnappt hier im Forum *, das der Updateweg auf eine 4.13 so geht bzw. so gemacht werden kann. Ich kann mit dem Manager ja keine 4.4 neu mehr installieren.

Oder hätte ich wie hier beschrieben https://docs.contao.org/manual/de/in...ntao-umziehen/
...die composer.lock mitnehmen müssen? Und der Manager hätte mir den exakten 4.4 Stand erstmal auf den neuen Server gebracht... und dann dort das Update auf 4.13 machen?

* Sprich... ich mach ja kein Update auf einer Live-Installation. Heißt ich kopiere mir die 4.4 (in meinem Fall) für das Update, nur wie? Und da hatte ich irgendwo aufgeschnappt direkt die 4.13 neu zu installieren und mit der alten composer.json (Update/Migration CM) sowie der alten Datenbank (Update/Migration über Installtool) das ganze zu machen.

**Spooky** · 18.04.2023, 13:15

Unter Nutzung der Konsole kopierst du composer.json + composer.lock, dann composer install ausführen. Ob das so auch mit dem Contao Manager funktioniert kann ich nicht sagen, da ich den nicht nutze.

**tblumrich** · 18.04.2023, 13:31

Ok, dankeschön.
Ich denke das ist quasi analog das Vorgehen, wie es im Handbuch mit dem Manager beschrieben ist.

Ich bin vermutlich fälschlicherweise davon ausgegangen, das ich die Updatevariante von der 3.5 auf die v4.* auch von 4.4 auf 4.13 verwenden kann... also in Zukunft beim Umzug immer die composer.lock vor Installation mitnehmen.

Vielen Dank für deine Geduld.