Hallo!
Shop läuft unter http://dev.xxx.srv.inexio.net/ wie er soll.
Unter https:// nicht. Weisse Seite – nicht eine Zeile Quelltext kommt an – nicht mal: <!DOCTYPE html>
Gemacht / getestet:
Config:
$this->sShopURL = ‘http://dev.xxx.srv.inexio.net’;
$this->sSSLShopURL = ‘https://dev.xxx.srv.inexio.net’;
Temp + views
.htacces war unverändert und so wie sie für http lief.
Hab mal alles zwischen <IfModule mod_rewrite.c> </IfModule> rausgeworfen – keine Änderung
Auf dem dev Server ist das Zertifikat noch self-signed. Das scheint mir aber zu laufen wie es soll.
https://dev.xxx.srv.inexio.net/robots.txt oder
https://dev.xxx.srv.inexio.net/phpinfo.php werden ausgeliefert.
Habe überhaupt keine Idee wo bohren.
Grüsse!
Zoidberg
weiße Seite ohne Quelltext bedeutet php Fehler.
steht irgendwas im Error Log vom Webserver?
Hast du auch versuch admin über https zu erreichen?
das gleiche für den admin. Komme bei dem dev server nicht ans error log und vor dienstag ist da keiner zu erreichen. Das es wohl php ist habe ich für den Falle weisse seit schon in einem anderen post von Dir gelesen. Die hoffnung stirbt zuletzt bekanntlich - dachte mir, kann nicht sein dass die sich an der server config verschraubt haben. Ich hatte da keine finger drinne.
So ein mist. Wollts mal endlich über Pfingsten durchziehen.
Danke für ür den Stoss auf php.
grüsse - zoidberg
…moment mmh - ist die Anweisung
<?php
phpinfo();
?>
so - ich sag mal rudimentär - dass da trotz fehlerhafter php config geliefert werden kann ?
https://dev.xxx.srv.inexio.net/phpinfo.php geht ja…
wenn eine andere Datei über https ausgeliefert wird, dürfte es nicht an php config des Servers liegen. Wenn der Shop aufgerufen wird, werden aber einige php Config parameter umgestellt, damit der Shop bestimmte Voraussetzungen erhält.
Einige browser haben Probleme mit self signed Zertifikaten, aber das könnte man ebenso ausschließen, wenn robots.txt und phpinfo ausgeliefert werden.
Ich würde sonst noch irgendwelche Module verdächtigen, die vielleicht nicht mit https umgehen können.
die module hatte ich deaktiviert. Was bleibt mir bevor ich beim provider die pferde scheu mache ? Nackten, frischen oxid installieren ?
webserver error log prüfen (wenn du es ohne provider kannst)
alternativ kann man sich irgendwie die php fehler direkt ausgeben lassen.
versuch das mal: http://stackoverflow.com/questions/5438060/showing-all-errors-and-warnings
du kannst das Zeug oben in config.inc.php einfügen
Immer gut, wenn man sich selbst die console abdrehen lässt. Ohne restart zieht das nicht.
Aber interessant. Danke. Nicht geahnt, dass sowas überhaupt möglich.
Hallo!
Kurze Rückmeldung falls jemand über die Suche hier landet und weil Vanilla Thunder Zeit investiert hatte: Ist wohl eher ein sehr individuelles Problem. Das Warum konnte ich nicht wirklich klären und verschiebe es auf andermal.
Egel mit welchem FTP client – nach Template Änderungen und löschen /tmp wirfts die Rechtevergabe durcheinander. Selbst wenn /tmp dann per client auf 777 gesetzt wird. Wird so auch angezeigt – stimmt aber irgendwie nicht. Betrifft komischerweise auch nur SSL. Ich habe da den Durchblick nicht.
Der Behelf ist jetzt ein Cronjob für den root-Benutzer, der zu jeder vollen Minute die Rechte des tmp/ Ordners rekursiv anpasst. Wohl alles nicht der Weisheit letzter Schluss. Muss aber weiter zur nächsten Baustelle…
Grüsse!
Zoidberg
Der Ordner /tmp darf nicht gelöscht werden, nur der Inhalt (ohne .htaccess)
Hallo Bastelfex,
ja klar - habe ich nicht sauber getippt. Natürlich nur der Inhalt.
Grüsse!