Website läuft auf Subdomain, aber nicht auf Hauptdomain

[Maspi76]

Theme Eclipse, Contao 4.4.45, Host 1&1 Ionos

Hallo zusammen,
ich würde gerne die auf einer Subdomain (sozusagen als Testumgebung) entwickelte Website nun umrouten, so
dass sie auf der Hauptdomain abrufbar wird.
Wenn ich den gleiche Pfad im Webspace, den ich für die Subdomain verwendet habe, nun auf die Hauptdomain
route, wird mit die Home nicht mehr gezeigt.

Woran kann das liegen? Lt. 1&1 ist auf deren Seite alles fein.

Muss ich auf der Contao-Seite noch etwas switchen?

Vielen Dank für ein kurzes Feedback.

[tschero]

Hi,

führe noch mal das Installtool aus, leere danach var/cache/prod und führe auch noch mal die Systemwartung aus.
Wenn Dein Contao auf der Subdomain läuft, sollte das auch mit der Hauptdomain funktionieren.

Gruß
tscheo

[Maspi76]

Hi,
ich hab versucht das so zu machen.

Folgender Weg:
Aufruf Installtool => PW vergessen => über Änderung localconfig neu auf werkszustand gesetzt => parallel im Backend Cache geleert => dann PW für Installtool geändert => danach installtool nicht mehr aufrufbar => letzte Datei in var/cache gelöscht => immer noch nicht aufrufbar => Browsercache geleert => jetzt Contao Backend und Frontend nicht mehr aufrufbar

Anbei die Logdatei.

Was ist passiert?

[Maspi76]

Hier der Anhang

[Tim]

Parse error: syntax error, unexpected '$GLOBALS'

Die fehlerhafte Domain scheint nicht PHP 7.x zu fahren. Bitte die eingestellten PHP Version prüfen.

[Maspi76]

Das wäre dann beim Host oder? Bis gestern war das aber nie ein Problem bzw. tauchte nie als Problem auf?

[Maspi76]

Hat nicht geholfen. Hab auf PHP 7.4 upgegradet.

[Tim]

Fällt mir nur noch ein, dass du event. in der "Startpunkt einer Webseite"-Seite die Domain fixiert hast.

[Maspi76]

Ja, das hatte ich auch gemacht, aber deutlich bevor die Ausfälle des Backends/Frontends erfolgten, also gestern. Wie kann ich das denn ohne Backend rückgängig machen?

[Tim]

Wenn das Backend tot ist, muss man direkt mit phpmyadmin in die Datenbank.

[Maspi76]

Das Backend ließ sich nun über das Löschen von var/cahe/prod wiederherstellen.

Jedoch haben alle o.a. Tipps für das korrekte Routen statt auf die Subdomain eben auf die Hauptdomain noch nicht funktioniert.

Woran könnte es Contaoseitig noch liegen? Kann irgendwo im System die Seitenreferenz auf die Subdomain noch in den Dateien stehen?

[Tim]

Mir fällt nichts mehr ein. Eventuelle Modifikationen oder Weiterleitungen auf server-ebene, htaccess können wir extern nicht prüfen. tscheros Aussage in der ersten Antwort gilt für ein normal konfiguriertes System:

Wenn Dein Contao auf der Subdomain läuft, sollte das auch mit der Hauptdomain funktionieren.

[Maspi76]

Wenn ich jetzt Beispiele für Weiterleitungen oder Modifikationen auf Server-Ebene erhalten würde, dann könnte ich da nochmal auf Nachforschung gehen.

Wobei ich mittlerweile tatsächlich vermute, dass es daran liegt, dass die Startseite gerade

in
contao.msp-service.com/msp-service/htdocs/msp-service.com/web
liegt und
msp-service.com/msp-service/htdocs/msp-service.com/web

da irgendwie nicht reingucken kann

oder?

[Tim]

Sorry, aber mir fällt auch nichts mehr ein. Normalerweise reicht es die jeweiligen Zielpfade in den Webspace-Einstellungen auf das gewünschte /web Verzeichnis pointen zu lassen.

[Maspi76]

Das ist ja das kuriose. Der Zielpfade der Hauptdomain zeigt auf den gleichen Ordner, wie der der Subdomain, aber nur der von der Subdomain wird richtig angezeigt.

[Maspi76]

Hier nochmal die Htaccess im Zielordner:


<IfModule mod_headers.c>
# Allow access from all domains for webfonts (see contao/core-bundle#528)
<FilesMatch "\.(ttf|ttc|otf|eot|woff2?|font\.css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On

# Determine the RewriteBase automatically and set it as environment variable.
# If you are using Apache aliases to do mass virtual hosting or installed the
# project in a subdirectory, the base path will be prepended to allow proper
# resolution of the app.php file and to redirect to the correct URI. It will
# work in environments without path prefix as well, providing a safe, one-size
# fits all solution. But as you do not need it in this case, you can comment
# the following 2 lines to eliminate the overhead.
RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
RewriteRule ^(.*) - [E=BASE:%1]

# Sets the HTTP_AUTHORIZATION header removed by Apache
RewriteCond %{HTTP:Authorization} .
RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# Redirect to URI without front controller to prevent duplicate content
# (with and without `/app.php`). Only do this redirect on the initial
# rewrite by Apache and not on subsequent cycles. Otherwise we would get an
# endless redirect loop (request -> rewrite to front controller ->
# redirect -> request -> ...).
# So in case you get a "too many redirects" error or you always get redirected
# to the start page because your Apache does not expose the REDIRECT_STATUS
# environment variable, you have 2 choices:
# - disable this feature by commenting the following 2 lines or
# - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
# following RewriteCond (best solution)
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

# If the requested filename exists, simply serve it.
# We only want to let Apache serve files and not directories.
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^ - [L]

# Rewrite all other queries to the front controller.
RewriteRule ^ %{ENV:BASE}/app.php [L]
</IfModule>

<IfModule !mod_rewrite.c>
<IfModule mod_alias.c>
# When mod_rewrite is not available, we instruct a temporary redirect of
# the start page to the front controller explicitly so that the website
# and the generated links can still be used.
RedirectMatch 302 ^/$ /app.php/
# RedirectTemp cannot be used instead
</IfModule>
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

[tschero]

Lösche noch mal var/cache/prod, führe die Systemwartung aus, leere den Browsercache und rufe dann!!! noch mal das Installtool auf.
Wenn alle Pfade richtig eingestellt sind, sollte das doch passen.

Gruß
tschero

[Maspi76]

Sollte ich dies so tun BEVOR oder NACHDEM ich die Hauptdomain auf den richtigen Zielordner gesetzt habe?

[tschero]

Danach, um das Installtool mit der Hauptdomain aufzurufen.

[Maspi76]

Hab das jetzt genauso gemacht.

1) Routing der Hauptdomain auf den Zielordner (den, der beim Subdomain funktioniert)
2) Leeren von var/cache/prod
3) Systemwartung und Daten bereinigen
4) Browsercache leeren
5) Installtool aufrufen

Ergebnis:
a) Das Routing funktioniert immer noch nicht.
b) Alle Seiten (also auch Backend und Frontend) wieder down
c) var/cache/prod kann nicht mehr geleert werden (ist schon leer), um Backend/Frontend wieder ans laufen zu bringen

Hilfe!!!

[tschero]

Das müsste man sich dann direkt mal bei IONOS anschauen...

[Maspi76]

Hab mit IONOS gesprochen, die meinten, dass Problem läge daran, dass der Pfade der Subdomain liegt auf der gleichen Ebene, als der Pfad der Hauptdomain:

Subdomain:
/msp-service/htdocs/msp-service.com/web/

Hauptdomain:
msp-service/htdocs/Neu/easy_business_template

müsste aber tiefer liegen?

Passiert etwas mit dem Contao-Backend, wenn ich den Sudomain eins tiefer lege?

[ankbin]

Hi,

führe noch mal das Installtool aus, leere danach var/cache/prod und führe auch noch mal die Systemwartung aus.
Wenn Dein Contao auf der Subdomain läuft, sollte das auch mit der Hauptdomain funktionieren.

Gruß
tscheo

Ich habe das gleiche Problem. Subdomain mit Eclipse Theme läuft, Hauptdomain liefert Fehler 500. Und zwar im manager, Installtool, Back- und Frontend: deshalb kann ich Installtool und Systemwartung nur in der Subdomain ausführen.
Manager 1.8, Contao 4.13.29, PHP 8.2
Der Zielordner web ist korrekt eingestellt, denn lege ich da per FTP testweise eine index.html rein, kann ich die im Browser öffnen mit https://domain.de/index.html
Habt ihr vielleicht eine Idee?