Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Hallo!
Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.
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:
idn_to_ascii('däne-dömän.de');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.
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.
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/func…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... :D
Dann brauch ich die Funktion erst gar nicht nutzen und schreibe eine eigene E-Mail-Validierung. [...] Davon abgesehen liefert der "Fehlercode" keinen Hinweis auf einen Umlaut. ;)
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ß@).
[COLOR=#333333]Wenn wir alle WordPress bewegen wollen, müssen Codex und RFC Richtlinien beachtet werden.[/COLOR]
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!
PS: Deine Mutmaßungen und Annahmen zu meiner Person treffen nicht zu.
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... ;)
Vielen Dank für all die Hinweise und die Diskussion. Ich habe erst mal versucht, dem Tipp von Dir, SirEctor nachzugehen:
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.
Das brachte auch schon einen Effekt, nämlich dass der Formulareinträger die Fehlermeldung bekam, dass das Feld nicht leer sein dürfe - Ich vermute, dass das ein Ergebnis des leeren Wertes ist, der zurückgegeben wird, wie von Dir erwähnt. Leider bin ich mit PHP nur sehr oberflächlich vertraut und kann Deinen Tipp aus mangelndem tieferem Verständnis nicht weiterverfolgen.
So wie auch nicht diesem Hinweis von Dir, mensmaximus:
Der Filter sanitize_email liefert einen "Fehlercode" mit, den kann man abfangen, selbst prüfen und die Adresse entsprechend wieder zurück geben.
Ich habe es daher eher damit versucht, einen Weg zu finden, die Umlaute zuzulassen (und nicht als „Fehler“ zu validieren. Wenn ich das richtig verstanden habe, sind das die beiden Optionen…)
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.
Leider kenne ich mich mit Hooks nicht aus. Ich habe die regulären Ausdrücke in einer Testumgebung direkt in der formatting.php angepasst. Das hat soweit geklappt. Auch wenn das keine besonders gute Lösung wäre. Für mich wäre es problematisch, die Funktion rauszuziehen und im Plugin anzupassen (abgesehen davon, dass ich ziemlich rumprobieren müsste, bis das funktioniert, würde ich ja bei jedem Plugin-Update ggf. wieder von vorne anfangen). Es ist aber auch genauso problematisch, die Funktion im Wordpress-Core zu ändern, da muss ich auch bei jedem Update ggf. nacharbeiten… Könnte ich denn mit einem Hook ein Plugin so ergänzen bzw. variieren, dass bei einem Update des Plugins meine Anpassung bestehen bleibt?
@formateins
Ob Umlaute tatsächlich in Domainnamen und Mailadressen benutzt werden, ist eine berechtigte Frage, leider (oder auch nicht) hatten wir solche Fälle in unseren Mailinglisten, das ist bisher nur vereinzelt, aber die Entwicklung geht ja weiter und offensichtlich nimmt die Akzeptanz solcher Adressen insgesamt zu.
Deshalb habe ich als erstes die Entwickler des Plugins angeschrieben - die haben aber auf Wordpress verwiesen. Dann dachte ich, ich poste das mal im deutschen Wordpress-Forum, vielleicht ist bei anderen auch schon die Frage aufgetaucht. Ich verstehe Open Source ja so, dass man Fragen und Probleme an die Entwicklergemeinde zurückgibt (wenn es einem selbst schon nicht möglich ist, konstruktiv zur Lösung dieser Probleme beizutragen), um das Projekt insgesamt voranzutreiben.
Sorry, das ist jetzt ein langer Beitrag. Zu lang, wie ich befürchte.
Auf jeden Fall danke für alle Tipps.:)
Könnte ich denn mit einem Hook ein Plugin so ergänzen bzw. variieren, dass bei einem Update des Plugins meine Anpassung bestehen bleibt?
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.
Ob Umlaute tatsächlich in Domainnamen und Mailadressen benutzt werden, ist eine berechtigte Frage, leider (oder auch nicht) hatten wir solche Fälle in unseren Mailinglisten, das ist bisher nur vereinzelt, aber die Entwicklung geht ja weiter und offensichtlich nimmt die Akzeptanz solcher Adressen insgesamt zu.
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. ;)
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
