Recherche avancée

Médias (17)

Mot : - Tags -/wired

Autres articles (37)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

Sur d’autres sites (7460)

  • Anomalie #3476 : Prévisualiser un article post daté

    25 juillet 2015, par cedric -

    Non, sur un article post-daté non publié, on a bien un lien "Prévisualiser".

    Il n’y a que si tu passes un article publié en post-daté en changeant la date dans le futur : le formulaire de date en central s’execute en ajax, le reste de la page n’est pas rechargé, et du coup le bloc info de gauche reste avec un lien "voir en ligne" au lieu de "prévisualiser". Ce n’est pas idéal mais beaucoup moins gênant que ce que tu décris.

  • Revision 90346 : on peut demander maintenant depuis le tableau que le fieldset soit encadré ...

    19 juin 2015, par toutati@… — Log

    on peut demander maintenant depuis le tableau que le fieldset soit encadré d’un div au lieu du ul quand SPIP &lt ;3.1

  • Anomalie #3055 (En cours) : Autorisation sur les listes d’objets

    5 mai 2015, par Eric Lupinacci

    En fait, c’est à mon avis un problème plus général, de rigueur dans l’appel des autorisations en entrée des pages mais aussi de stratégie de définition des autorisations qui sont malheureusement assez rarement arborescentes.

    Si on prend les pages objet comme article, rubrique et auteur par exemple, elle commencent toutes par une autorisation :

    (#AUTORISERvoir,article,#ID_ARTICLE ou
(#AUTORISERvoir,rubrique,#ID_RUBRIQUE ou
(#AUTORISERvoir,auteur,#ID_AUTEUR


    Cependant d’ailleurs seul l’autorisation article_voir est définie, les autres renvoyant sur l’autorisation par défaut. Mais au moins une autorisation est appelée systématiquement quelque soit le moyen avec lequel on arrive sur cette page.
    A partir de là si il existe un bouton qui envoie sur cette page il faut le conditionner par cette autorisation (code HTML) et si c’est un menu créé automatiquement alors là il faut créer une autorisation de menu qui appelle l’autorisation de voir et pas le contraire à mon avis.

    Donc si on étend ça aux pages articles, auteurs et rubriques je suis d’accord qu’il faudrait une autorisation voir_xxxx (ce qui n’est pas le cas actuellement) qui serait appelée en entrée de la page comme l’exemple ci-dessous pour la page articles :

    (#AUTORISERvoir,_articles


    et il faudrait alors coder l’autorisation du menu Articles de cette façon :

    function autoriser_articles_menu_dist($faire, $type, $id, $qui, $opt) 
    return autoriser(’voir’, ’_articles’) ;


    En effet, la décision d’afficher ou pas le menu est indépendante du fait de voir ou pas la page articles mais doit s’appuyer dessus si on décide de ne pas présenter un lien qui mène vers une page interdite.
    Et il faudrait systématiser cela pour tous les plugins objet du core à mon avis.

    En second lieu il faudrait faire une passe sur le code des autorisations actuelles pour imbriquer un peu plus les autorisations de façon arborescente ce qui leur donnerait plus de lisibilité car parfois elles sont identiques sans qu’on s’en rende compte car le code est dupliqué.

Navigation