Youtube links met tijdstip werken niet goed

[JeroenE]

Als je geen externe cookies toestaan dat krijg je bij YouTube links een melding dat je de cookie instellingen moet aanpassen of dat je de video op YouTube moet kijken.

Als je de tweede optie klikt dan wordt de video wel geopend, maar bijvoorbeeld het tijdstip wordt dan niet meegegeven zodat op YouTube de video vooraan begint en niet op bijvoorbeeld 3:34:44. Zie dit bericht Hachy in "[EV] Openbare laadpalen, laadpassen en providers - Deel 2"

Als je daar op die knop klikt dan wordt https://youtu.be/e-VC_Lis69M geopend ipv https://youtu.be/e-VC_Lis69M?t=12884

[crisp]

Het is niet geheel triviaal om vanuit de embed-url weer een werkende youtube-url te destilleren. In dit geval is de t= parameter in de embedcode start=.

Om de functionaliteit simpel te houden genereren we daarom alleen een simpele link zonder verdere parameters. Het is ook de vraag in hoeverre mensen hier 'last' van hebben. Er worden volgens mij niet veel embeds geplaatst met een specifieke tijdcode, en ook veel mensen zullen gewoon de embeds toestaan waardoor ze niet naar YT zelf hoeven te gaan.

[JeroenE]

@crisp Als ik op "bekijk" klik bij die post staat daar gewoon een url met t en niet met start, zie dit plaatje. Begrijp ik iets verkeerd?

Ik snap dat dit geen "stop de persen" fout is, maar ik begrijp niet zo goed wat ik met een opmerking moet dat er waarschijnlijk niet veel mensen last van gaan hebben. Is dat een criterium om fouten niet op te lossen?

[crisp]

JeroenE schreef op dinsdag 5 oktober 2021 @ 15:07:
@crisp Als ik op "bekijk" klik bij die post staat daar gewoon een url met t en niet met start, zie dit plaatje. Begrijp ik iets verkeerd?

Die informatie wordt niet doorgegeven naar de geparsede versie (zeg maar de HTML) van de post.

Ik snap dat dit geen "stop de persen" fout is, maar ik begrijp niet zo goed wat ik met een opmerking moet dat er waarschijnlijk niet veel mensen last van gaan hebben. Is dat een criterium om fouten niet op te lossen?

Ja; als impact=laag en kosten=hoog dan is de kans dat we dit gaan fixen natuurlijk niet zo groot; onze tijd is immers niet onbeperkt. Daarbij is dit zoals ik al aangaf eigenlijk meer by design dan een echte bug.

[JeroenE]

crisp schreef op dinsdag 5 oktober 2021 @ 15:11:
Die informatie wordt niet doorgegeven naar de geparsede versie (zeg maar de HTML) van de post.

Ja, dat dit t= niet wordt doorgegeven is juist het probleem wat opgelost moet worden

Jij geeft als argument dat je dit niet makkelijk kan terughalen vanuit de embedded url, maar dat begrijp ik dus niet. Want de juiste url staat toch gewoon in de post, dus je hoeft toch helemaal niets terug te halen vanuit een embedded url (die blijkbaar anders is). Bovendien zie ik helemaal geen embedded youtube filmpje, maar een knop waar ik op kan klikken.

Ik zal vast een heleboel van jullie systeem niet begrijpen, maar het lijkt toch niet heel ingewikkeld om een url waar je niets aan hoeft te doen aan een knopje te plakken.

Nu is er blijkbaar een systeem wat die url ombouwt naar iets anders voor embedded filmpjes en wordt die omgebouwde url gebruikt om de knop te genereren. Maar omdat de omgebouwde url anders is dan de oorspronkelijke kan dit niet meer of niet makkelijk omgezet worden in de juiste url.

Maar omdat je al begint met de url die je bij die knop wil hebben, hoef je toch ook helemaal niets terug te bouwen? Plak daar gewoon de url in zoals die was voor je hem ging ombouwen naar een embedded url.

Daarbij is dit zoals ik al aangaf eigenlijk meer by design dan een echte bug.

Tja, als jullie dit soort een-richting conversies expres bedenken doen om de gebruikers slechte ervaringen te geven, dan kan ik dat natuurlijk ook niet helpen

[ImNotnoa]

JeroenE schreef op dinsdag 5 oktober 2021 @ 15:28:
[...]


[...]
Tja, als jullie dit soort een-richting conversies expres bedenken doen om de gebruikers slechte ervaringen te geven, dan kan ik dat natuurlijk ook niet helpen

Als je de URL even via de WYSIWYG editor maakt werkt het wel goed.

Isniezomoeilijknie

[JeroenE]

@ImNotnoa Sorry, wat bedoel je nu? Ik snap ook wel dat ik de link kan knippen en plakken als ik eerst "bekijk" doe, maar het lijkt mij logischer dat Tweakers zelf de juiste url aan een button hangt ipv dat ik dat als gebruiker zelf uit een post moet gaan vissen.

[crisp]

Dit is wat de gebruiker post:

code:

[EMBED=,,"Hyundai Ioniq 5 1000 km challenge via Sweden part 2"]https://youtu.be/e-VC_Lis69M?t=12884[/EMBED]

waarschijnlijk ook niet exact wat de gebruiker heeft gepost; de title wordt er op het moment van posten nog dynamisch bij gezet

Wat wij daarmee technisch doen is dit omzetten naar HTML. Die HTML wordt ook opgeslagen en dat is feitelijk wat we ook naar je browser toesturen. In dit geval wordt de embedcode gegenereerd via de oEmbed API van YouTube. Uiteindelijk komt daar zoiets uit:

HTML:

<iframe
  title="Hyundai Ioniq 5 1000 km challenge via Sweden part 2"
  data-thumbnail="https://tweakers.net/camo/aa33d58dd99759a4f279a400e88c6a7ccfad79c8/?url=https%3A%2F%2Fi.ytimg.com%2Fvi%2Fe-VC_Lis69M%2Fhqdefault.jpg"
  width="640" height="360"
  src="https://www.youtube.com/embed/e-VC_Lis69M?start=12884&amp;feature=oembed"
  frameborder="0" allowfullscreen=""
></iframe>

Je ziet dat deze code geen referentie meer heeft naar de door de gebruiker opgegeven URL. Wat wij voor de cookie-accept-placeholder doen is dan vanuit de embed-url weer een link genereren naar YT zelf. Letterlijk zo:

JavaScript:

case 'youtube':
    if ((m = targetSrc.match(/\/embed\/([\w-]+)/))) {
        targetSrc = 'https://www.youtube.com/watch?v=' + m[1];
    }
    break;

En ja, we zouden moeite kunnen doen om de originele url ook ergens mee te geven, of om die start= parameter weer om te zetten naar t=, maar als we dat doen dan blijft het waarschijnlijk niet bij die ene parameter, en moeten we dat mogelijk ook gaan doen voor andere embeds.

De link naar YT in de cookie-accept-placeholder is echt bedoelt als een simpele fallback voor wanneer iemand nog geen consent heeft gegegeven, en zal in 99% van de gevallen gewoon ook een prima alternatief zijn naar mijn mening. Dan rest alleen de vraag hoeveel moeite we moeten steken in die laatste 1%.

[ Voor 5% gewijzigd door crisp op 05-10-2021 15:51 ]

[JeroenE]

crisp schreef op dinsdag 5 oktober 2021 @ 15:48:
En ja, we zouden moeite kunnen doen om de originele url ook ergens mee te geven

Wat ik dus niet snap is dat jullie dat sowieso niet doen. Nu is er dus moeite in gestoken om de embedded url weer terug te bouwen naar iets wat je onder een knopje kan hangen en dan ook daadwerkelijk werkt. Tenminste, ik neem aan dat wanneer je de embedded url gebruikt je dan een foutmelding krijgt als je die in een nieuw venster laat openen.

Als je ergens een "orig_user_url" (of verzin zelf een leuke naam) had gevuld met de door de gebruiker opgegeven url dan had je die gewoon gelijk kunnen gebruiken, toch?

maar als we dat doen dan blijft het waarschijnlijk niet bij die ene parameter, en moeten we dat mogelijk ook gaan doen voor andere embeds.

Bovendien had je dan het probleem gelijk opgelost voor alle andere embeds. Want daar kan je natuurlijk de code voor de youtube embedded url ook niet gebruiken en hebben jullie misschien wel weer andere code voor geschreven om dit om te bouwen.

Je kan me best alles wijsmaken, maar dat een ongewijzigde url doorgeven om die aan een knopje te hangen ingewikkelder is dan die url diverse keren om te laten bouwen waarbij de laatste stap dan voor het gemak maar even onvolledig is vind ik toch bijzonder moeilijk om te geloven.

[crisp]

JeroenE schreef op dinsdag 5 oktober 2021 @ 16:10:
[...]
Wat ik dus niet snap is dat jullie dat sowieso niet doen. Nu is er dus moeite in gestoken om de embedded url weer terug te bouwen naar iets wat je onder een knopje kan hangen en dan ook daadwerkelijk werkt. Tenminste, ik neem aan dat wanneer je de embedded url gebruikt je dan een foutmelding krijgt als je die in een nieuw venster laat openen.

Als je ergens een "orig_user_url" (of verzin zelf een leuke naam) had gevuld met de door de gebruiker opgegeven url dan had je die gewoon gelijk kunnen gebruiken, toch?

We hadden voordat we click-to-load implementeerden daar simpelweg geen usecase voor. Voor de click-to-load was het uiteindelijk sneller om vanuit de embed-url een 'gewone' url te genereren dan de parser aan te passen (wat ook niet met terugwerkende kracht werkt voor bestaande content).

[...]
Bovendien had je dan het probleem gelijk opgelost voor alle andere embeds. Want daar kan je natuurlijk de code voor de youtube embedded url ook niet gebruiken en hebben jullie misschien wel weer andere code voor geschreven om dit om te bouwen.

Je kan me best alles wijsmaken, maar dat een ongewijzigde url doorgeven om die aan een knopje te hangen ingewikkelder is dan die url diverse keren om te laten bouwen waarbij de laatste stap dan voor het gemak maar even onvolledig is vind ik toch bijzonder moeilijk om te geloven.

En toch is het zo dat het aanpassen van de parsing van RML naar HTML complexer is dan de huidige oplossing voor dit probleem (waar in eerste instantie bij de introductie van de click-to-load ook niet in was voorzien).