[GELÖST] Weiße Seite nach dem Hochladen auf Server

Sabine · 28. Juni 2018 12:48

Hallo zusammen,

ich weiß, dass das Symptom mit der weißen Seite hier schon öfters angesprochen wurde. Nur habe ich momentan in den entsprechenden Themen für uns keine Lösung gefunden.

Situation: Wir haben in einem Unterverzeichnis unserer eigenen Website eine Arbeitsversion einer Vereins-Website erstellt und alles soweit eingearbeitet. (NaN hatte mir dabei schon mehrfach geholfen) Die Domain wurde von T-online zu Strato umgezogen - ist auch alles freigeschaltet. Wir hatten die Arbeitsversion, die auch so wieder hochgeladen wurde, auch schon bei Strato liegen und dort funktioniert auch alles weiterhin. Nur auf der eigentlichen Domain erscheint nach dem Hochladen der Daten eine reine weiße Seite. Ins Backend komme ich ebenfalls nicht, da auch nur eine weiße Seite angezeigt wird.

Anfangs nachdem die Domain beim neuen Provider Strato freigeschaltet war, erschien die "Oops-Seite" von CMSms - mein Mann konnte aber im Strato-Login keine Zugriffsrechte vergeben, sodass er keine weiteren Eingriffsmöglichkeiten hatte. Nach 2 Tagen Telefonaten mit Strato haben wir bestimmte FTP-Einstellungen zusammen mit einem Service-Mitarbeiter geändert, die meinem Mann vorher unbekannt waren. Dann hat er den gesamten Ist-Zustand erst gelöscht (da war kurzzeitig die Strato-Baustellenseite zu sehen) und dann nochmals hochgeladen und seitdem erscheint jetzt nur die weiße Seite. Mein Mann, der seit vielen Jahren bei Strato Webseiten einrichtet und dieses Phänomen noch nicht hatte, ist mit seinem Latein am Ende.

Zuerst hatten wir bei der neu hochgeladenen Website PHP 7 aktiviert, dann aber auf PHP 5.6 gewechselt, so wie es auch in der Arbeitsversion (in dem oben genannten Unterverzeichnis) eingestellt ist - hat aber nicht das Problem gelöst. Momentan ist alles auf PHP 5.6, damit wir das mit der Arbeitsversion vergleichen können.

Daher hier wieder die Frage an euch: wo könnte das Problem liegen?

Ich hatte hier im Forum was von mysqli gelesen, von dieser Erweiterung "li" - das hat mein Mann nachgsehen und ist bei uns gegeben.

Danke!

Beitrag geändert von Sabine (05. September 2018 13:54)

Sabine · 28. Juni 2018 13:10

Was ich mir jetzt selbst nochmal angesehen habe, ist der Quelltext der Arbeitsversion, die bei uns funktioniert. Dort waren zwei gelbe Warnmeldungen angezeigt, die den damals eingesetzten T-Online-Besucherzähler betrafen. Der funktioniert jetzt natürlich nicht mehr. Ich habe das in der Arbeitsversion gelöscht.

Und auf der Startseite war als "rotes Schild" auch wieder das bereits aufgetretene Problem mit der Header-Galerie und den Verlinkungen zu anderen Seiten, die Galerien enthalten angezeigt.

Diesen Anker habe ich jetzt auch manuell entfernt, sodass auf der Startseite keine Warnungen mehr auftauchen.

Diesen Zustand müssen wir dann erst noch mal neu hochladen, um sagen zu können, ob es daran lag. Klappt aber vermutlich erst heute abend. Das nur als Info für euch, was ich jetzt noch selbst versuche.

NaN · 28. Juni 2018 15:49

Idee #1:
den Inhalt der Verzeichnisse /tmp/cache/ und /tmp/templates_c/ löschen. Ich betone das deshalb, weil die Verzeichnisse selbst bestehen bleiben müssen - aber eben leer.

Idee #2:
Die Datei /lib/config.php wurde entsprechend der Datenbank angepasst?
(Benutzername, Passwort, Datenbankname, Datenbankserver)

Leere Seite ist beim Debuggen immer blöd (aber ansonsten aus Sicherheitsgründen völlig okay). Daher mal versuchen, dem Server ein paar Meldungen zu entlocken (Punkt 2 mit der .htaccess Datei)
Oder mal in Erfahrung bringen, ob und wo die Error-Logs bei Strato gespeichert werden.
(Sind .log-Dateien oder zip-Archive mit reinen Textdateien in denen dann die Fehler drin stehen, die wir mit der .htaccess-Datei versuchen auszugeben)

Ohne irgendeine Fehlermeldung wird es jedenfalls schwierig bis unmöglich, herauszufinden, woran es liegt.

Sabine · 28. Juni 2018 18:52

Danke schon mal. Mein Mann hat die genannten Verzeichnisse geleert, hat aber nichts bewirkt. Die config-Datei hat er kontrolliert und sie stimmt.

Ich soll fragen, ob du hiermit etwas anfangen könntest:
Warning: file_put_contents(/mnt/web309/c1/78/59283078/htdocs/tmp/cache/9272aaa9a13b31687c8636faf5add8db.dat): failed to open stream: Permission denied in /mnt/web309/c1/78/59283078/htdocs/lib/classes/class.cms_route_manager.php on line 406 Fatal error: Uncaught --> Smarty: unable to write file /mnt/web309/c1/78/59283078/htdocs/tmp/templates_c/wrt5b3509c77d6d91_72193644 <-- thrown in /mnt/web309/c1/78/59283078/htdocs/lib/smarty/sysplugins/smarty_internal_runtime_writefile.php on line 49

Und dann gibt es noch eine ellenlange Liste, die Strato SiteGuard ausgespuckt hat. Davon kopiere ich nur mal ein paar... das würde glaube ich das Thema sonst sprengen:

Liebe STRATO Kundin, lieber STRATO Kunde,

mit dieser E-Mail informieren wir Sie ueber erfolgte Schreibzugriffe auf Ihren Webspace. Sie erhalten diese E-Mail, weil Sie in Ihrem STRATO Kunden-Login die Option "SiteGuard" aktiviert haben.
Hier aufgefuehrte Schreibzugriffe werden meist durch regulaere Operationen einer installierten Web-Anwendung, wie z.B. Wordpress oder Joomla!, hervorgerufen. In seltenen Faellen können die Eintraege auch auf einen Angriff auf Ihre Website hinweisen.

Operationen auf Ihrem Webspace:

Juni 28 12:03:00
ausfuehrendes Script: /usr/bin/php56
betroffene Datei: tmp/cache/cache_5359e725d32ab940b7787eb7db27ecfd_1d45e295e1476bf755ba2912042071b4.cms
Vorgang: deny[create]

Juni 28 12:03:00
ausfuehrendes Script: /usr/bin/php56
betroffene Datei: tmp/cache/cache_5359e725d32ab940b7787eb7db27ecfd_4f4b1bfe1231ff07fc576eebe183428a.cms
Vorgang: deny[create]

Juni 28 12:03:04
ausfuehrendes Script: /usr/bin/php56
betroffene Datei: tmp/cache/cache_5359e725d32ab940b7787eb7db27ecfd_6c7fdb5c8d415f3438e3c782403f8ca2.cms
Vorgang: deny[create]

Juni 28 12:03:05
ausfuehrendes Script: /usr/bin/php56
betroffene Datei: tmp/cache/cache_5359e725d32ab940b7787eb7db27ecfd_5fa9f28509bf7c15c9fba23277560c85.cms
Vorgang: deny[create]

Juni 28 12:05:42
ausfuehrendes Script: /usr/bin/php56
betroffene Datei: tmp/cache/cache_5359e725d32ab940b7787eb7db27ecfd_6c7fdb5c8d415f3438e3c782403f8ca2.cms
Vorgang: deny[create]

Juni 28 12:05:42
ausfuehrendes Script: /usr/bin/php56
betroffene Datei: tmp/cache/cache_5359e725d32ab940b7787eb7db27ecfd_5608c6ed616ae72829d341316ec860a6.cms
Vorgang: deny[create]

usw. usw. ....

Kannst du irgendwas damit anfangen?

NaN · 28. Juni 2018 21:13

Kannst du irgendwas damit anfangen?

Naja, "Permission denied", "unable to write file" ... etc. ... und das alles in eben jenem Verzeichnis welches Du nur leeren solltest, weil es für die Funktion des CMS wichtig ist ... musst nur 1 und 1 zusammenzählen.

Das Verzeichnis "tmp" ist ein Verzeichnis für "temporäre" Dateien. Also Dinge die nur mal vorrübergehend zwischengespeichert werden sollen. Und wenn man in diesem Verzeichnis nichts schreiben darf, dann geht halt nix. D.h. die Zugriffsrechte in diesem Verzeichnis müssen volle Lese-/Schreibberechtigungen sein.

Wenn das Verzeichnis via FTP erstellt wurde (also beim Übertragen von a nach b), dann bist Du der Eigentümer dieses Verzeichnisses. Je nachdem wie die Berechtigungen für dieses Verzeichnis lauten, kann es sein, dass außer Dir (via FTP) niemand in diesem Verzeichnis schreiben darf. D.h. das PHP-Script (also das CMS) bist ja nicht Du. Und daher darf via PHP-Script auch nix in diesem Verzeichnis geschrieben werden.

Du musst die Zugriffsrechte für dieses Verzeichns also so setzen, dass alle darin schreiben können, die Zugriff haben. Also auf "777" setzen. Klingt jetzt etwas kryptisch, aber mit einem FTP-Programm (z.B. FileZilla) Rechtsklick auf das Verzeichnis -> den Menüpunkt für die Berechtigungen suchen und dann wirst Du schon verstehen, was Du da machen musst ;-)

Sabine · 29. Juni 2018 07:46

Theoretisch hätte ich 1 und 1 zusammenzählen können, wenn ich irgendwas davon kennen würde. big_smile Mein Mann kannte diese temp-Verzeichnisse auch noch nicht.

Wir haben das jetzt auf 777 gesetzt –> dann kam diese Warnmeldung - ich glaube das ist dasselbe wie vorher? Leer sind beide Verzeichnisse.

Warning: file_put_contents(/mnt/web309/c1/78/59283078/htdocs/tmp/cache/9272aaa9a13b31687c8636faf5add8db.dat): failed to open stream: Permission denied in /mnt/web309/c1/78/59283078/htdocs/lib/classes/class.cms_route_manager.php on line 406 Fatal error: Uncaught --> Smarty: unable to write file /mnt/web309/c1/78/59283078/htdocs/tmp/templates_c/wrt5b35d436762cc1_25936612 <-- thrown in /mnt/web309/c1/78/59283078/htdocs/lib/smarty/sysplugins/smarty_internal_runtime_writefile.php on line 49

Funktioniert noch nicht.

Beitrag geändert von Sabine (29. Juni 2018 07:53)

nockenfell · 29. Juni 2018 14:32

Wo genau habt ihr die Berechtigungen gesetzt.

Folgende Verzeichnisse müssen chmod 777 Rechte:

- ./tmp
- ./tmp/templates_c
- ./tmp/cache
- ./tmp/configs
- ./uploads (sowie alle Unterordner)

Sabine · 29. Juni 2018 17:17

Danke - alles überprüft, bei upoads noch auf 777 gesetzt, aber gleiches Ergebnis wie vorher. Es wird auch dieselbe Fehlermeldung wie oben schon reinkopiert, ausgegeben.

Was auch überhaupt nicht zu verstehen ist, ist dass die Seite im Unterverzeichnis unserer eigenen Seite ebenfalls bei Strato läuft/zu sehen ist, auf der richtigen Domain aber nicht. Wir wissen einfach nicht, was anders sein sollte.

Sabine · 29. Juni 2018 18:11

Endlich geschafft!!

Bei Strato haben wir zur Absicherung ein Extra-Programm gebucht, namens SiteGuard. Diese Funktion kollidiert offenbar mit den Debug-Einstellungen von CMSms. Das hat mein Mann jetzt auf der englischen CMSms-Seite gefunden, wo die Neuinstallation beschrieben ist. (Auf der deutschen Seite sind glaube ich fehlerhafte Links - aber das nur nebenbei).

Im Strato-Loginbereich haben wir jetzt folgende Einstellungen vorgenommen (damit andere diesen Hinweis finden können, falls nötig):

SiteGuard
Logging von Zugriffen –> Deaktiviert
Schreibschutz –> Deaktiviert
FTP-Zugriff –> Aktiviert
SSH-Zugriff –> Aktiviert

Die ersten beiden waren vorher auch aktiviert und das hat den Fehler verursacht.

Jetzt wissen wir auch, was auf unserem Server, wo die Seite in einem Unterverzeichnis sichtbar war, anders ist. Wir haben dieses SiteGuard nicht gebucht, der Verein jedoch.

Danke nochmals für eure Fehlersuche. Liebe Grüße und einen schönen Abend...

Forum für CMS/made simple

#1 28. Juni 2018 12:48

[GELÖST] Weiße Seite nach dem Hochladen auf Server

#2 28. Juni 2018 13:10

Re: [GELÖST] Weiße Seite nach dem Hochladen auf Server

#3 28. Juni 2018 15:49

Re: [GELÖST] Weiße Seite nach dem Hochladen auf Server

#4 28. Juni 2018 18:52

Re: [GELÖST] Weiße Seite nach dem Hochladen auf Server

#5 28. Juni 2018 21:13

Re: [GELÖST] Weiße Seite nach dem Hochladen auf Server

#6 29. Juni 2018 07:46

Re: [GELÖST] Weiße Seite nach dem Hochladen auf Server

#7 29. Juni 2018 14:32

Re: [GELÖST] Weiße Seite nach dem Hochladen auf Server

#8 29. Juni 2018 17:17

Re: [GELÖST] Weiße Seite nach dem Hochladen auf Server

#9 29. Juni 2018 18:11

Re: [GELÖST] Weiße Seite nach dem Hochladen auf Server

Fußzeile des Forums