Serendipity Forums

Ich habe irgendwie das Problem mit meinen Beiträgen, dass der YouTube-Iframe im Feed falsch formatiert wird.

Im Beitrag/Quellcode steht Im Feed wird daraus dann Da das Problem trotz deaktiviertem serendipity_syndication_plugin zu bestehen scheint, vermute ich einen Fehler im Core.

Ein Beispielartikel mit Video wäre z. B. hier zu sehen.

bernd_d wrote:Ich habe irgendwie das Problem mit meinen Beiträgen, dass der YouTube-Iframe im Feed falsch formatiert wird.

Offenbar funktioniert die protokollfreie Verlinkung nicht überall, zumindest in diesem iframe nimmt der Browser dann an, es handele sich um eine relative URL. Wenn Du mit http: verlinkst, sollte es doch klappen?

YL

Das dürfte nix mit dem Browser zu tun haben, denn der Code steht ja so schon im Feed von s9y.

Man könnte natürlich s9y aushebeln und das http setzen, Hauptgrund warum ich darüber aber überhaupt gestolpert bin ist, dass YouTube den embed-Code so vorgibt ohne Protokollangabe.

Oh, ach so: Das ist nur im Feed problematisch? Hm.

Okay, ich kann das in meinem Devblog reproduzieren. (Nebenbei bemerkt killt das fehlende ="true" bei allowfullscreen auch den Atom-Feed.) Eine Lösung habe ich spontan leider nicht. Scheint mir aber in der Tat eher ein Problem der Feed-Templates (in default) als sonstiger Faktoren zu sein.

YL

@bernd_d Du hast recht, in der functions_rss.inc.php gibt es einen regulären Ausdruck, der in diesem Fall die falsche Ersetzung vornimmt. Wie das mit RegExps so ist, kann es etwas dauern, bis ich da eine funktionierende Lösung präsentieren kann

Good catch auf jeden Fall!

Ich habe hier mal einen Lösungvorschlag geschrieben, da wären jetzt Unit Tests wirklich eine praktische Sache.

Ich bin mir allerdings nicht sicher, ob sich damit alle Fälle von serendipityHTTPPath und Entry-Bodies vertragen. Sieht aber imho gut aus. Vielleicht könnte da trotzdem bitte noch ein anderer Entwickler drüberschauen?

Das Problem mit dem Atom-Feed kann ich bestätigen, der mag das Attribut nicht. Da meckert auch der W3C-Validator, aber die meisten Feedreader schlucken das vermutlich? Wie auch immer, das ist ein anderes Thema.

@bernd_d

Dein Ansatz müsste funktionieren - testen, ob dem relativen Pfad ein / folgt. Aber: Wir sollten sicherstellen, dass ein '/~john/serendipity//'... nicht nicht ersetzt wird. Solche URLs passieren relativ häufig und sollten normalerweise problemlos aufgelöst werden.

Im Grunde können wir das alles vereinfachen, oder?

Wir wollen, dass relative Pfade mit absoluten ersetzt werden, nur dann nicht, wenn der relative Pfad / ist und ihm ein / folgt. Dafür brauchen wir zwei verschiedene Pattern.

Also: Bei der Gelegenheit hab ich die regexp soweit mir möglich vereinfach. Wobei man das wohl wieder erweitern muss, um das wirklich nur in Links zu machen und den Rest des Links einzusetzen.

Meine Testfälle:
1, 2, 3, 4

Zu dem Attributfehler: Wenn da der Atomparser sich beschwert machen wir wahrscheinlich das escapen falsch. Das HTML des Eintrags ist ja kein valides xhtml und sollte daher mit <![CDATA[ ... ]] maskiert werden.

Wie sieht es denn mit dem Problem aus, macht da noch jemand was dran? Ich würde das gerne mal irgendwie beheben (lassen).

Ich würde mich freuen, wenn noch ein Entwickler (mattsches?) über meinen Regex geht und das am besten direkt implementiert, mindestens in 2.0. Dann könntest du den Code kopieren und bei dir einfügen und das nochmal testen.

Dein zweiter Testcase matcht nicht, soll das so sein?

Ich habe meine Version noch etwas erweitert, um Pfade mit zwei Slashes am Ende zu bereinigen. Natürlich lässt sich das noch refactoren, aber es muss ja erstmal funktionieren.

PS: Falls ich das mit der PHPUnit-Integration in Metatron hinbekommen sollte, gibt's vielleicht irgendwann auch mal "richtige" Unit Tests dafür

mattsches wrote:Dein zweiter Testcase matcht nicht, soll das so sein?

Ja, weil das ja der Fall ist, bei dem der führende / nicht durch den Pfad zum Blog ersetzt werden soll.

Ok, verstehe.

Könntest du bitte noch den kompletten preg_replace() Aufruf posten, also mit angepasstem replacement? Das match-Pattern ist ja nur die halbe Miete, und ich bin gerade zu faul

Und klappt dein Regex auch mit dem oben genannten Oder müsste man das vorher auch bereinigen, ähnlich wie '/~john/serendipity//'?

Seid ihr zufällig im Hintergrund an dem Thema dran? Nicht, dass mir das hier wieder in Vergessenheit gerät

Danke bernd. Ne, ich bin zurzeit beschäftigt und vergaß tatsächlich, hier zu antworten.

mattsches, ich habe keinen kompletten Aufruf. Das müsste jemand noch coden. Wenn ich das richtig sehe, sollte der Regex auch mit dem von dir zuletzt geposteten Testfall funktionieren - dann würde ja aus meinem Beispielcode das erste pattern genommen werden, das diese url ignoriert.

Falls jemand meinen Fix testen will: https://github.com/s9y/Serendipity/comm ... d3a5590889

Ist bisher nur in 2.0, die Datei sollte aber keinen Unterschied haben. Also auch mit 1.x testbar.