HTML/PHP: E-Mail per „mailto:“-Aufruf als Redirect

neues-Mitglied

Lt. Junior Grade
Registriert
Feb. 2011
Beiträge
443
Hallo zusammen, zum Schutz der E-Mail-Adresse möchte ich diese per „mailto:“-Aufruf als Redirect implementieren.

In der html-Datei sieht das wie folgt aus:
HTML:
            <p><a href="redirect-mailto.php">E-Mail</a>
Dazu habe ich eine Datei namens redirect-mailto.php erstellt und diese in das Stammverzeichnis hochgeladen:
PHP:
<?php
header("Location: mailto:mail@server.com");
exit();
?>
Leider passiert nichts, wenn ich auf den e-Mail-Link klicke. Es bleibt eine weiße Seite. Was fehlt noch? Mit html habe ich bereits Erfahrung aber php ist für mich noch völlig neu.
Danke!
 
Halt Dich an die gängige URI Konvention, dann sollte das auch funktionieren (zumindest krieg ich einen Dialog vom Mailprogramm):

PHP:
<?php
header('Location: mailto://a.b@c.de');

Ansonsten versteht PHP das nicht als absoluten URI und versucht bestenfalls noch auf den Pfad webserver.de/path/mailto:adresse@domain.de zuzugreifen.
 
  • Gefällt mir
Reaktionen: neues-Mitglied
@RalphS
Quatsch. PHP ist an der Auswertung des Links gar nicht beteiligt, das schreibt lediglich den Header. Und das Format ist für mailto-Links so völlig korrekt.

@neues-Mitglied
Also bei mir funktioniert das Beispiel problemlos. Es ist auch noch unnötig lang. Dies reicht:
PHP:
<?php header('Location: mailto:mail@server.com');
Wenn es nicht funktioniert, drängelt sich eventuell irgendwas bei der Ausgabe vor dieses Skript. Vielleicht mal in den Server-PHP-Logs gucken, ob da irgendwas von "Headers already sent" steht.
 
  • Gefällt mir
Reaktionen: neues-Mitglied
Ich hab beide Varianten probiert und brachte leider keine Änderung. Also muss es an etwas anderem liegen.

Die Server-Logs sind leer. Gibt es spezielle Server-Logs für php oder muss ich dafür erst eine MySQL-Datenbank anlegen?

Ich nutze Webgo, falls da vielleicht jemand irgendwelche serverspezifischen Voreinstellungen kennt.
 
Probier mal die Datei als UTF-8 without BOM abzuspeichern.
 
  • Gefällt mir
Reaktionen: seluce, Nixdorf und neues-Mitglied
Super, das war das Problem! Man sollte eben keine Websites im Texteditor schreiben und dann nicht auf die Codierung achten :)
Stundenlange Fehlersuche wegen so einer Kleinigkeit. Wieder was gelernt.
 
Wem sagst du das; Kleinigkeiten! Aber schön, dass es nun geht. Dir noch einen entspannten Sonntag!
 
neues-Mitglied schrieb:
Gibt es spezielle Server-Logs für php
Ja, gibt es. Eingestellt wird das in der php.ini mit der Direktive "error_log". Das ist dann eine separate Datei, nicht die Web-Server-Logdatei von Apache oder welchem Server auch immer.

neues-Mitglied schrieb:
Super, das war das Problem!
Mit Speichern als UTF mit BOM hatte ich nicht gerechnet. Nur dort gibt es dann noch vor dem öffnenden "<php" etwas, das ausgegeben wird. Normalerweise hat man unter Windows immer noch ANSI-Dateien (Windows 1252), und da passiert es auch nicht. Auch ISO-8859-Dateien auf z.B. Linux haben es nicht. Und meine Tools habe ich alle auf UTF8 ohne BOM gestellt. Den Typ "UTF mit BOM" sollte man im Zusammenhang mit PHP grundsätzlich bei allen Quelltextdateien meiden wie der Teufel das Weihwasser.

Das Log würde hier genau den oben genannten "Headers already sent" melden. Die Header müssen vor dem Inhalt kommen, und mit dem BOM beginnt die Ausgabe des Inhalts schon am Anfang der Datei. Bei der Zeile mit dem Location-Header kann PHP ergo keine Header mehr senden, und loggt stattdessen die Meldung.
 
  • Gefällt mir
Reaktionen: gravitas
Nixdorf schrieb:
Ja, gibt es. Eingestellt wird das in der php.ini mit der Direktive "error_log". Das ist dann eine separate Datei, nicht die Web-Server-Logdatei von Apache oder welchem Server auch immer.


Mit Speichern als UTF mit BOM hatte ich nicht gerechnet. Nur dort gibt es dann noch vor dem öffnenden "<php" etwas, das ausgegeben wird. Normalerweise hat man unter Windows immer noch ANSI-Dateien (Windows 1252), und da passiert es auch nicht. Auch ISO-8859-Dateien auf z.B. Linux haben es nicht. Und meine Tools habe ich alle auf UTF8 ohne BOM gestellt. Den Typ "UTF mit BOM" sollte man im Zusammenhang mit PHP grundsätzlich bei allen Quelltextdateien meiden wie der Teufel das Weihwasser.
Damit es da nicht zu Missverständnissen kommt. Ich kann nicht 100%ig sagen, ob es an mit oder ohne BOM lag aber dennoch hat mich dieser Lösungsvorschlag zum Ziel geführt. Denn beim Erstellen der php-Datei ich einfach einen Texteditor genommen, nicht auf die Kodierung geachtet und diese Datei dann als .php gespeichert. Nun habe ich nochmal eine saubere Datei neu erstellt, UTF-8 ohne BOM ausgewählt und mit dieser klappt es nun. Es kann theoretisch also auch im ANSI gespeichert worden sein, ich will dem jetzt aber auch nicht noch weiter nachgehen, bin froh, dass es nun läuft. :)

In meiner php.ini sind die folgenden Einträge vorhanden.:
Code:
mysqli.default_socket = /var/run/mysqld/mysqld.sock
mysql.default_socket = /var/run/mysqld/mysqld.sock
pdo_mysql.default_socket =  /var/run/mysqld/mysqld.sock
pdo_mysqli.default_socket =  /var/run/mysqld/mysqld.sock
mysql.allow_persistent = Off
mysqli.allow_persistent = Off
curl.cainfo = /etc/ssl/certs/ca-certificates.crt
upload_max_filesize = 50M
post_max_size = 50M
display_errors = Off
memory_limit = 256M
session.save_path = /tmp
error_reporting = E_ALL & ~E_NOTICE
date.timezone = 'Europe/Berlin'
expose_php = Off
opcache.jit_buffer_size=0
Wenn ich dort error_log hinzufüge, braucht dieser noch irgendeinen Wert?
gravitas schrieb:
Wem sagst du das; Kleinigkeiten! Aber schön, dass es nun geht. Dir noch einen entspannten Sonntag!
Danke ebenso!
 

Ähnliche Themen

Zurück
Oben