Beiträge von diethardw

Hallo Erleuchteter, danke für die Hinweise. Tatsächlich: Auf der Website, wo dieselbe Konfiguration funktioniert, ist noch "aus alten Tagen" eine start.html auf dem Server vorhanden. Zwar leer, aber da! Und die war in der Kopie (neue Website) nicht mehr drin. Das heißt also, der Webserver schaut beim Scannen der htaccess schon nach, ob die als DirectoryIndex angegebene Datei "physikalisch" vorhanden ist und gibt Fehler 403 aus, falls das nicht der Fall ist. Erst danach wird aus der start.html über die html-Umleitung an verteiler.php ein tatsächlicher (funktionierender) Aufruf.

Also: mit DirectoryIndex start.php funktioniert es und jetzt auch mit DirectoryIndex start.html, nachdem ich eine (leere) start.html hochgelanden habe. Insofern: dank deinem Hinweis Problem gelöst und Ursache verstanden.

Zu "verteiler.php": Alle Links sind als statische Links (*.html) eingebaut (also "meine-beispielseite.html"). Diese existiert aber nicht. "verteiler.php" schaut als erstes nach, ob die "meine-beispielseite.php" tatsächlich vorhanden ist und ruft diese dann auf (wie bei der Startseite). Falls nicht, wird in der Datenbank nachgeschaut, was für ein Seitentyp bzw. welcher Datensatz dahintersteckt und setzt das entsprechend z.B. in "post.php?id=25" um, ohne dass das in der Adresszeile des Browsers erscheint. Deshalb leitet htaccess alle Aufrufe .html nach verteiler.php um.

Nochmals danke & schönen Tag!

Hallo zusammen,

ich hoffe, dass meine Frage in dieser Rubrik hier richtig platziert ist. Beim Einrichten einer neuen Website (die im Wesentlichen die Kopie einer laufenden Website ist) stoße ich auf folgendes Phänomen, für das ich aktuell überhaupt keine Erklärung habe. Es geht um den Zugriff auf die Startseite. Die Startseite ist start.html, wobei alle html-Aufrufe auf gleichnamige php-Seiten umgeleitet sind.
Ein Aufruf https://meine_url/start.html funktioniert und bringt das erwartete Ergebnis, ein Aufruf nur als https://meine_url bringt Fehler 403.
Wird irgendeine andere Seite in .htaccess als Startseite verwendet, kommt ebenfalls Fehler 403. Es liegt also anscheinend an irgendeiner Konfigurationseinstellung. Nur an welcher?

Die .htaccess sieht (identisch zu der funktionierenden anderen Website so aus:

DirectoryIndex start.html

RewriteEngine on

RewriteCond %{HTTPS} !=on

RewriteRule ^ https://%%7bhttp_host%7d%%7brequest_uri} [L,R=301]

RewriteBase /

RewriteRule ^(.*)\.html$ /verteiler.php [L]

ErrorDocument 404 /fehlermeldung-404.php

Danke für den Tipp - das ist offensichtlich die Lösung. Unter Produkte - Übersicht - Globale Verwaltung und Konfigurationen des Webhostings findet man die externe Adresse des MySQL-Servers, und damit funktioniert der Zugriff auch von einem anderen Webspace aus.

Mir war nicht bewusst, dass IP-Adressen mit 10... genau wie 192... immer interne und keine globalen Adressen sind.
Nochmals danke!

Ich wundere mich auch. Ich habe es noch 3x kontrolliert: die 4 Daten beim Connect sind exakt dieselben wie bei dem funktionierenden Zugriff aus dem anderen Webspace.

Hallo zusammen,

ich habe in einem Webpaket von netcup eine MySQL-Datenbank. Diese ist konfiguriert mit "Remoteverbindungen von beliebigem Host zulassen", und es ist ein spezieller Datenbankuser für den Remotezugriff eingerichtet. Ich versuche nun, von einer anderen Domain (die liegt auch bei netcup, aber in einem anderen Webpaket) auf die DB zuzugreifen, dies wird aber mit "Connection refused" abgewiesen.
Muss das so sein oder mache ich etwas falsch? Die Idee dahinter ist, Daten in einer Tabelle zu pflegen, die aber von mehreren meiner Domains verwendet werden kann (um diese nicht überall nachführen zu müssen). Oder gibt es eine andere Lösung dafür?
Danke für jeden Hinweis.

Hallo Peter,

danke für deinen superschnellen Tipp. Ich habe es sofort ausprobiert, der absolute Pfad ist dann /var/www/vhosts/xn--bcherboxx-sdpark-jzbk.de/httpdocs/logs/log.txt und sieheda - damit funktioniert es wunderbar. Vielen Dank. Was ich offenbar nicht verstanden hatte: Der Cronjob wird auf Serverebene ausgeführt, nicht auf Domainebene, daher braucht es den kompletten Pfad. Kapiert!

Noch eine Frage, die du vielleicht auch aus dem Stegreif beantworten kannst: Führe ich das Skript unter PHP 5 aus, so bekomme ich als Zeitstempel date ("Y-m-d H:i:s") die Lokalzeit (MESZ). Dasselbe unter PHP 7: dann bekomme ich UTC, also z.B. 11:28 statt 13:28. Bug oder Feature??

Danke und freundliche Grüße aus der Südpfalz

Diethard

Hallo zusammen,

für meine eigene Webstatistik experimentiere ich zum ersten Mal mit "Geplante Aufgaben" in PLESK. Ich habe zum Test ein Miniskript geschrieben:

<?

$now = date ("Y-m-d H:i:s");

$log = fopen ("logs/log.txt", "a");

fwrite ($log, "CRONSTATS: $now\r\n");

fclose ($log);

?>

Wenn ich dieses ganz normal im Browser aufrufe, tut es einfach, was es soll (in die Logdatei schreiben).

Dann habe ich dieses Skript in PLESK unter "Geplante Aufgaben" als Aufgabentyp "PHP-Skript ausführen" eingehängt (siehe Bild). Probiere ich es mit "Jetzt ausführen" aus, so bekomme ich eine Rückmeldung "Die Aufgabe "httpdocs/crontest.php" wurde erfolgreich in 0 Sekunden abgeschlossen." Aber: in meiner Logdatei erfolgt kein Eintrag. Ebensowenig, wenn die Geplante Aufgabe zeitgesteuert ausgeführt wird.

Dasselbe gilt für ein weiteres Testskript, indem ich etwas in meine Datenbank schreibe: Beim Browseraufruf tut das Skript, was es soll, beim Aufruf über Plesk nicht.

Verstehe ich da jetzt irgendwas falsch?

Danke für eure Unterstützung.

Diethard