[Externalmedia] Support de oEmbed

[xave]

Réécrire le plug Externalmedia pour supporter oEmbed, et prévoir pour les services ne le supportant pas une externalisation (miniplugins comme pour l'antispam ?) afin de n'avoir pas à réécrire entièrement le plug dès qu'un fournisseur change une virgule (non seulement c'est chiant, mais mettre uniquement ce plug à jour, ça casse l'autoupdate de Dotclear.)

Références:  http://www.oembed.com/  http://code.google.com/p/jquery-oembed/

Exemples:  http://www.dailymotion.com/api/oembed?url=http%3A%2F%2Fwww.dailymotion.com%2Fvideo%2Fxd0omo_apple-perd-le-prototype-du-prochain_tech&format=xml  http://code.google.com/p/jquery-oembed/source/browse/trunk/jquery.oembed.js (implémentation)

[bruno]

Excellente idée, très bon concept, en effet.

Toutefois, on peut intégrer oembed à plusieur étages :

1. Niveau public : on résout le oembed en partie publique, donc dynamiquement en partie publique

Pros : l'adresse est pérenne : tout changement chez l'hébergeur tiers est automatiquement propagé

Cons : requêtes externes, voir si c'est jouable en js (peut-être passer par un proxy), accessibilité très bof, dépendant de JS

2. Comme actuellement avec externalmedia : on insère dans le billet le code retourné par oembed

Pros : pas de requêtes JS coté public

Cons : si le fournisseur change son format d'affichage, il faut réinsérer le média dans le billet

3. Un mix des 2 : on insère le code retourné par oembed, et on garde quelque part l'url oembed pour le rejeu, si le fournisseur change de format

[Tomtom33]

Effectivement, c'est une excellente idée.

Pour l'admin, je verrais bien une interface à la ping ou on insère le nom du service et le endpoint

Après l'idée 3 de Bruno est effectivement la meilleure mais j'ai une question: Que sauvegarder dans le billet? L'url du média et le nom du service pour la remplacer par la suite pas le code réel?

[xave]

Je sais bien que ça va plus ou moins dégager, mais la version 3 pourrait reprendre les mécanismes des pièces attachées un peu.

[bruno]

Replying to xave:

Je sais bien que ça va plus ou moins dégager, mais la version 3 pourrait reprendre les mécanismes des pièces attachées un peu.

C'était exactement le fond de ma pensée :)

[Tomtom33]

Ok mais tu enregistres comment la position de la vidéo dans le billet?

[bruno]

Replying to Tomtom33:

Ok mais tu enregistres comment la position de la vidéo dans le billet?

Il y a peut-être un entre-deux qui pourrait être satisfaisant : passer par une macro spécifique.

Exemple : actuellement on peut faire un lien vers le post 34 en mettant [post:34] en syntaxe wiki. Et pourquoi pas définir un [extmedia:url] ?

[Tomtom33]

Replying to bruno:

Il y a peut-être un entre-deux qui pourrait être satisfaisant : passer par une macro spécifique.

Exemple : actuellement on peut faire un lien vers le post 34 en mettant [post:34] en syntaxe wiki. Et pourquoi pas définir un [extmedia:url] ?

Arf les marcos wiki, la partie de dc que je déteste... Il y a juste un truc qui me chiffonne la dedans, c'est que si mes souvenirs sont bons, la macro est lue et interprétée à l'enregistrement du billet et non à l'affichage. Le champ dc_post_content_xhtml de la table table post contiendra donc le code complet du lecteur. Or c'est lui qui est affiché sur la partie publique.

Du coup on se retrouve avec le même problème.

[bruno]

On peut aussi envisager une implémentation en php de oembed, associée à une macro (pas forcément wiki, voir #956) dans le billet. A l'enregistrement du billet, on stocke dans la partie xhtml le code généré. Cela a l'avantage certain de présenter un code assez potable au rédacteur.

A noter aussi, le potentiel souci avec free, qui ne tolère pas les requêtes http depuis php...

[bruno]

(In [3033]) oembed quick & dirty replacement for external media, needs to be refined. See #954

[xave]

(In [3035]) Merging changes from Bazar. Closes #906, addresses #954.

[Tomtom33]

L'intégration d'oEmbed est presque achevée. A voir sur la branche wysiwyg

[franck]

Le plugin a été recodé depuis. Je ferme.