Deutsche Umlaute in sanitize_email nicht vorhanden

Du könntest als erstes versuchen mit is_email() die Adresse auf Gültigkeit zu prüfen und dann mit sanitize_email zu filtern. In etwa so:
sanitize_email( (is_email( $email ) )

Damit kann WordPress zwar immer noch keine Umlaute, aber durch is_email() würde bei Umlauten in der Adresse ein leerer Wert zurück geliefert.

Nur mit sanitize_email würden einfach die Umlaute entfernt und dann der Rest der Adresse weiter verwendet.

 

Quick & Dirty:

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

Erst ab PHP 5.4.x - erschlägt dem Domainnamen vorab.

Ansonsten musst Du die 3 regulären Ausdrücke in der formattings.php anpassen. Mit einem Hook wird's ggf. schwer, deswegen kannst Du die Funktion auch direkt rausziehn und für Deine Anwendung anpassen.

 

Der Filter sanitize_email liefert einen "Fehlercode" mit, den kann man abfangen, selbst prüfen und die Adresse entsprechend wieder zurück geben.

 

Dann brauch ich die Funktion erst gar nicht nutzen und schreibe eine eigene E-Mail-Validierung. Meine Rede: Die hier (https://developer.wordpress.org/reference/functions/sanitize_email/) nehmen, umbenennen, Umlaute im RegEx ergänzen, fertig. Davon abgesehen liefert der "Fehlercode" keinen Hinweis auf einen Umlaut.

Besser wäre es, vorher den domain part wie oben skizziert umzuwandeln. Was den local part betrifft... da sollte der Mailserver die UTF8SMTP-Extension drin haben, sonst wird das nix (RFC5336, http://tools.ietf.org/html/rfc5336#section-3.2, mit Hinweis auf die dot-atom-Einschränkung plus RFC5321). Ich such jetzt keine Statistik raus, wie viele MTA's weltweit überhaupt eine Unterstützung für den local part drin haben - der Anteil dürfte verschwindend gering sein. Ansonsten freuen wir uns doch in Zukunft darauf, den hebräischen Vornamen unseres Israelischen Geschäftspartners per Zeichentabelle oder Google Translate zusammenzustellen (elias@business.il >> אליאס@business.il).

Weiterhin unterstützt PHP selbst sanitze und validate als filter. Auch wenn das eher halbgar ist...

*rumkram*

Hier noch ein allumfänglicher RegEx (ohne Umlaute): https://regex101.com/r/bE5gY3/1 - und dann beten, das kein Bot reinspringt. Da ruft der Hoster schnell an...

 

Warum einfach wenn es doch auch kompliziert geht. Warum soll man eine ganze Funktion neu schreiben, wenn nur eine Zeile nicht RFC konform ist, weil eben Sonderzeichen in IDN Domains "verschluckt" werden? Sanitize_email prüft verschiedene Dinge, unter anderem die Zeichen und liefert ein "local_invalid_chars" wenn Umlaute in der Email sind. Also einfach den Filter anwenden, abfragen ob der Fehler "local_invalid_chars" lautet und nur dann eine einzelne Regexzeile anwenden, die den Zeichensatz nach RFC zulässt und die Email zurückgeben.

 

Genau. Einfach wäre es, die vorhandene Funktion zu forken und den RegEx zu ergänzen. So bleibt's dann bei einer (1) Validierung und man kann entweder den domain part ergänzen oder die IDN-Konvertierung machen.

Mit dem geposteten RegEx kannst Du sanitize_email komplett links liegen lassen - der erschlägt die vollständige E-Mail-Adresse auf einmal. Geht evtl. noch etwas moderner, aber testen kannst Du das selber. Da meine Mailserver keine Umlaute unterstützen, fehlen die im RegEx. Können aber ergänzt werden. Es sind zahlreiche weitere Beispiele auf regex101 zu finden.

Weiterhin hat mich das mit den Umlauten im local part interessiert und ich habe 2 umfangreiche Mailinglisten von Kunden geprüft. Ohne Ergebnis - kein Vorkommen von ä, ö, ü oder ß. Die Frage darf erlaubt sein: wird das tatsächlich genutzt?

 

@formateins

Sorry aber das ist am Ziel vorbei geschossen. Es ist super, dass Du lange Regex Ketten schreiben kannst und Dich damit wohl fühlst. Es ist auch ganz toll dass Du ganze Funktionen ersetzt um Sie in Deinen Projekten zu nutzen. Und das ist genau was 100.000 andere Entwickler auch tun und deswegen haben wir Wildwuchs in WordPress. Jeder kocht sein Süppchen, allen voran die großen Agenturen wie z.B. der Forenbetreiber Ich nehme an Du hast noch nie Software für Apple entwickelt.

Die WP-Entwickler habe sich etwas dabei gedacht, als sie an allen Ecken und Enden Filter und Action Hooks eingebaut haben. Damit kann man Funktionen erweitern, korrigieren und überschreiben. Der Codex existiert nicht weil jemand Langeweile hat. Indem man den Filter richtig verwendet wird die IDN Funktionalität automatisch in allen Plugins aktiviert, die sanitize_email verwenden und eben nicht auf eigene Funktionen setzen.

Also wenn immer möglich sind Core Funktionen durch Filter und Hooks anzupassen und bei offensichtlichen Fehlern das Core Team zu informieren. Du bist doch in Slack und sprichst mit den Leuten, außerdem hast Du ja anscheinend auch das Wissen. Nutze die Macht!

Ach ja und ob IDN Domains tatsächlich genutzt werden ist nicht relevant. Es gibt sie und der Weg da hin war lang und steinig, wo kommen wir denn hin, wenn wir RFC Richtlinien ignorieren nur weil es uns in den Kram passt. Alle wollen Internet, aber die Regeln der Leute, die es aufbauen und ermöglichen, werden mit Füßen getreten. Du hast wahrscheinlich auch noch nie bei einem ISP gearbeitet, sonst wüstest Du, welchen Stress man bekommt weil am sich nicht an die RFC hält (z.B. Zeitintervalle zum erneuten Versuch der Zustellung von Emails oder eben die Unterstützung von IDN Domainnamen)

Wenn wir alle WordPress bewegen wollen, müssen Codex und RFC Richtlinien beachtet werden. Das gilt im Übrigen auch für Automattic selbst.

 

Der Wildwuchs in WordPress entsteht durch die nicht mehr zeitgemäße API und dadurch bedingt veraltete Verfahren und Funktionen. Ich mach mich jetzt hier nicht breit und prangere WP an - falscher Ort. WP ist gut so wie es ist und eine markante Änderung des Systems wird es aufgrund der Verbreitung nie geben. Die historischen Einflüsse mal außen vor gelassen.

Was die Entwickler nicht bedacht haben (oder seinerzeit als zeitgemäß erachtet haben), ist der Wildwuchs in der eigenen API. Allein die Tatsache, dass ein wahres Feuerwerk an regulären Ausdrücken abgefeuert wird, zeigt das. Die immer wieder gleichen Probleme, die hier im Forum und andernorts auftreten, bestätigen das.

Und richtig: WP kaut bei der E-Mail 3 reguläre Ausdrücke durch, was in einem Aufruf erledigt werden könnte. Die IDN-Domain interessiert beim Handling gar nicht, die Problemstelle ist und bleibt der local part. Wenn dort Umlaute zusammen mit einem . genutzt werden, greift dot-atom (björn.haselnuß@).

a) Ich will WordPress nicht bewegen.
b) Ich halte mich nicht immer an Richtlinien, Vorgaben und Regeln. Ich schaue lieber über den Tellerrand und fahre mit offenem Visier (auch wenn die proteinhaltigen Mücken ziemlich lästig sind). Und nicht selten liegt dort die einfachere Lösung für ein Problem.

PS: Deine Mutmaßungen und Annahmen zu meiner Person treffen nicht zu. Ich versuche aber gar nicht eine Diskussion mit einem "WP Guru" an der Stelle zu führen. Nix für ungut - aber ich habe auch ein "Brett-vorm-Kopf". Damit genug des OT - ich denke, der TS hat Möglichkeiten aufgezeigt bekommen, sein individuelles Problem zu lösen. Der Balkon lacht, Grill ist startbereit, Bier eiskalt. Prost!

 

Dann hast Du also keine Erfahrung und bist kein WordPress Entwickler, sondern einer der vielen Perl/PHP/Python/Rubby/Node.JS Coder die aufgrund Ihrer bisherigen, meist kurzen Erfahrung, nur schlau daher reden wie es besser gehen könnte aber keine Minute investieren um es tatsächlich besser zu machen? Ich hatte bis dato einen anderen Eindruck.

 

Nein, ich bin erst 16 und Code am liebsten auf meinem Ei-Phone... :roll:

Zeit ist bei mir ein monetäres Gut. Die investiere ich hier im Forum und auch andernorts trotzdem gerne, um Ratsuchende zu unterstützen.

Als Generalist interessiert mich nicht die Technologie, sondern die Lösung. Nachhaltig natürlich. Die Sprache verstehen meine Gegenüber besser, als die der Fundamentalisten und Spezialisten. Davon kannst Du 10 Fragen und Du bekommst 12 verschiedene Antworten.

Muss reichen, der Balkon ruft nach einem Teil meiner Zeit...

 

Ja, habe ich ja geschrieben. sanitize_email() ist ein Hook und wird per apply_filters zu $wp_filters (Großes Hook-Array) hinzugefügt. Es gibt eine Live-Klasse, mit der man die Verarbeitung in Echtzeit ausgeben kann, aber ich finde sie grade nicht (R_DUMP, Github, glaube ich). Vom Ansatz her bin ich einen Schritt weiter gegangen und Validiere mit dem geposteten RegEx die komplette E-Mail-Adresse auf einmal (ist ein kann, kein muss). Bei dem fehlen auch die Umlaute, aber die kann man nachtragen.

Ich hoffe inständig, dass die Akzeptanz - aus genannten Gründen - schnell wieder abnimmt. Sonst mutiert das E-Mail-Adressen-Eingeben in Zukunft zu einem Fall für die Zeichentabelle, wenn jedes Land seine diakritischen Zeichen verwenden will.