twig eine url mit Parameter erzeugen

[R1100]

Hallo Zusammen,

ich würde gerne meinen alten thead wieder auffrischen wenn es erlaubt ist:

ich habe das Problem dass die Anwender in der DB als Homepage verschiedene Schreibweisen nutzen:
-http://www.example.com
-www.example.com
-www.ümlaute.example.com

bisher habe ich einen Link so über twig gerendert:

Homepage: <a href="{{ data.HOMEPAGE|e('html_attr') }}">{{ data.HOMEPAGE|raw }}</a><br>

Es funktioniert wenn die url vollständig ist: http://www.example.com
Es funktioniert auch mit Umlaute: http://www.ümlaute.example.com
Es funktioniert nicht wenn aus der DB www.example.com ohne "http://" kommt. Der ausgeführte Link ist: http://localhost.local/www.example.com. (localhost.local ist in Apache eingerichteter virtueller Host)

Gibt es in Twig eine Methode die die URLs richtig ausführt oder muss ich mich selbst darum kümmern?

So habe ich es ausprobiert, funktioniert leider nicht. Ich bekomme eine exception: Warning: preg_match(): Inknown modifier

{% if data.HOMEPAGE matches '(?i)(http:\/\/)' %}   //suche nach http:// case insensitive
    Homepage: <a href="{{ data.HOMEPAGE|e('html_attr') }}">{{ data.HOMEPAGE|raw }}</a><br>
{% else %}
    Homepage: <a href="http://{{ data.HOMEPAGE|e('html_attr') }}">{{ data.HOMEPAGE|raw }}</a><br>
{% endif %}

[Zeichen32]

Das hat nichts mit TWIG zu tun, das gibt die Variable ja nur aus. Du musst deine URL schon normalisieren, am besten vor dem Speichern in der DB.

[R1100]

Danke für den Hinweis.

Ist nicht wirklich ein Problem. So habe ich es jetzt lösen können. Vorher richtig in die DB schreiben geht leider nicht da die Daten aus einem alten System importiert wurden.

Email: <a href="mailto:{{ data.EMAIL|e('html_attr') }}"> {{ data.EMAIL|raw }}</a><br>

{% if data.HOMEPAGE matches '/(?i)http:/' %}
    Homepage: <a href="{{ data.HOMEPAGE|e('html_attr') }}"  target="_blank">{{ data.HOMEPAGE|raw }}</a><br>
{% else %}
    Homepage: <a href="http://{{ data.HOMEPAGE|e('html_attr') }}" target="_blank">{{ data.HOMEPAGE|raw }}</a><br>
{% endif %}

Dir noch einen schönen Tag.

[hellbringer]

Ist nicht wirklich ein Problem. So habe ich es jetzt lösen können. Vorher richtig in die DB schreiben geht leider nicht da die Daten aus einem alten System importiert wurden.

Und warum kann man die Daten in der Datenbank nicht korrigieren?

[R1100]

Einige Anwender haben die Felder missbraucht da das alte System Ihnen keine andere Möglichkeit zur Verfügung gestellt hat. Das neue System prüft bei Neueingaben oder Änderung eines Datensatzes dass nur noch gültige Daten erfasst werden können. Wenn ich das Emailfeld prüfen würde, würde ich einige "Nutzdaten" der Anwender löschen. Die Anwender wissen schon seit drei Jahren dass sie die Daten überarbeiten müssen, machen die aber nicht.

[hellbringer]

Ich würde aus der einen Spalte zwei Spalten machen. Alle validierten E-Mail-Adressen kommen in eine Spalte, alle Schrottdaten kommen in die andere Spalte. Somit ist klar, dass in der einen Spalte nur E-Mail-Adressen vorkommen können und man muss dann nicht solche Krücken in Templates bauen. Gleichzeitig werden aber nicht die "wertvollen" Schrottdaten gelöscht.

Probleme sollten dort behoben werden, wo die Ursachen liegen und nicht wo sich die Symptome zeigen.

[R1100]

Sicherlich auch eine gute Idee, würde allerdings einen großen Umbau bedeuten. Ich spekuliere etwas auf den Zwang den die Anwender jetzt haben da die Daten auch von anderen Anwendergruppen einsehbar sind.
Das alte System hatte zu einer Person nur eine TelefonNr, Email und Web-Adresse. Das jetzige System, hat 1:n Kontakte. Jeder Kontakt hat einen Kontakttyp(Telefon, Mobil, Fax, Email) jeweils für Privat und Geschäftlich. Und es hat für alles andere an Nutzdaten 1:n Benutzerdefinierte Felder die Pro Organisationseinheit definiert werden können. Somit können die Daten sauber getrennt werden. Jemand muss das allerdings machen. Sie hatten ja über drei Jahre Zeit die Daten zu korrigieren. Vermutlich war genau das das Problem, sie hatten einfach zu viel Zeit.

[tomBuilder]

Wieso nutzt Du weder PATH noch URL?

Sie hatten ja über drei Jahre Zeit die Daten zu korrigieren. Vermutlich war genau das das Problem, sie hatten einfach zu viel Zeit.

Setze einfach eine dealine, nach der man die AccDaten nur noch nutzen kann, wenn man im neuen system ist, oder sich ins neue System migrieren kann.
am tag der deadline gibts viel ärger, auch wenn eine frist von zig jahren gesetzt ist, aber machmal ist das der einzige weg.

[protestix]

Bezogen auf die Spalte mit den URLs kannst du doch einfach ein Update auf die Spalte machen und korrigierst alle die Datensätze, die kein http am Anfang haben. Das ist doch relativ einfach.

Spalte url sollte, wenn Leer, mit NULL als DEFAULT gefüllt sein.

UPDATE `mytable` SET `url` = CONCAT('http://', `url`) WHERE SUBSTR(`url`,0,4) <> 'http' AND `url` IS NOT NULL

[Zeichen32]

Wieso nutzt Du weder PATH noch URL?

Er hatte am Anfang gesagt das er Twig Standalone verwendet. Path und Url sind Twig Erweiterungen von Symfony. Weswegen ich ihm geraten hatte die URL dann direkt auszugeben und zu escapen.

[tomBuilder]

Er hatte am Anfang gesagt das er Twig Standalone verwendet. Path und Url sind Twig Erweiterungen von Symfony. Weswegen ich ihm geraten hatte die URL dann direkt auszugeben und zu escapen.

Achso, danke.
dann macht es aber wohl durchaus sinn eine Erweiterung deiser art selbst zu bauen.