Recherche avancée

Médias (1)

Mot : - Tags -/vidéo

Autres articles (112)

  • Personnaliser en ajoutant son logo, sa bannière ou son image de fond

    5 septembre 2013, par

    Certains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

  • 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 (...)

Sur d’autres sites (6953)

  • Evolution #4080 : Raccourci puce : se débarasser de l’image

    24 janvier 2018, par tcharlss (*´_ゝ`)

    Dans le ticket #1817, un des arguments pour générer une vraie liste à la place de puces, c’est que les utilisateurs se trompent de raccourci (ils voudraient une vraie liste mais mettraient de simple tirets au lieu de -*).
    Je nuancerais, d’après ce que j’ai vu, je suis presque sûr que des fois c’est volontaire, pour des raisons esthétiques à priori.

    À mon avis ça pourrait générer effectivement une vraie liste, mais avec une classe supplémentaire :

      . Et ces listes pourraient être stylées avec le chevron à la place du truc par défaut au moyen de list-style-type
      Ça ferait donc 3 types de listes en tout : normales, numérotées, et "décorées" (avec un chevron ou autre selon le thème).

      Bon, après ça crée une petite incohérence dans la syntaxe. Si toutes les vraies listes commencent par un tiret suivi d’un caractère (étoile ou dièse), idéalement dans ce cas ça devrait être un tiret suivi d’un chevron ou autre : ->

  • Anomalie #4097 (En cours) : bug HTTPS dans la fonction url_de_base() sur certains serveurs mal con...

    14 février 2018, par Pierre-Aurélien Georges

    Bonjour,

    voici le contexte : le serveur web de mon hébergeur est mal configuré (et je n’ai malheureusement pas réussi à leur faire corriger le problème). Le site web [1] est accessible aussi bien en HTTP qu’en HTTPS, mais en allant sur /ecrire/ ?exec=info je vois que le serveur ne renseigne ni la variable $_SERVER[’HTTPS’] ni la variable $_SERVER["SCRIPT_URI"], et à vrai dire lorsque je compare sur ce serveur un phpinfo() en HTTP et un phpinfo() en HTTPS je vois qu’il y n’a strictement AUCUNE différence entre les deux, et qu’il est donc totalement impossible de savoir (côté serveur) si la requête a été faite en HTTP ou en HTTPS.

    Dans ce contexte bien précis, le code de la fonction url_de_base() situé dans /ecrire/inc/utils.php pose problème, car il se base sur le contenu de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"] pour choisir entre HTTP et HTTPS et il ne tient absolument pas compte du contenu du champ META, ce qui dans mon cas est bien dommage car j’y ai mis l’url en https:...

    La conséquence de tout ceci est qu’en HTTPS cela entraîne des problèmes d’affichage d’images et de CSS qui ne sont pas bien appliqués, cf. [2]. Sur ce forum, vous verrez que je ne suis pas le seul à avoir affaire à un serveur mal configuré de la sorte, et que nous sommes plusieurs à avoir ce même problème. La solution de bricolage donnée par un des participants du forum est de rajouter dans /config/mes_options.php les deux lignes suivantes :

    $_SERVER[’HTTPS’] = "on" ;
    $_SERVER[’SERVER_PORT’]=’443’ ;
    


    Ca fonctionne, certes, et c’est donc ce que j’ai fait pour mon site, mais c’est vraiment du bricolage et c’était pas évident de trouver cette astuce !

    Pour faire plus propre et plus simple, serait-il possible à l’avenir de modifier le code de url_de_base() pour qu’en l’absence de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"], la fonction aille regarder dans META si c’est du http ou du https qui y est renseigné (au lieu de mettre forcément du http) ? En effet, lorsque META commence par "https://" ça veut dire que le serveur gère le HTTPS, et donc s’il ne renseigne pas les variables HTTPS et SCRIPT_URI et bien dans le doute mieux vaut générer des url de base en "https://" plutôt qu’en "http://" car si cette url de base se retrouve mentionnée au sein d’un fichier html ou css, et que le fichier en question est demandé en HTTP, ce n’est pas grave s’il contient des ressources en HTTPS, alors que le contraire pose problème (ne pas mettre de ressources en HTTP au sein d’une page en HTTPS !)

  • Anomalie #4097 (En cours) : bug HTTPS dans la fonction url_de_base() sur certains serveurs mal con...

    15 février 2018, par b b

    le serveur web de mon hébergeur est mal configuré

    Ca fonctionne, certes, et c’est donc ce que j’ai fait pour mon site, mais c’est vraiment du bricolage

    Tout est dit, serveur mal configuré, bricole pour contourner le bug de l’hébergeur en question :p Mais au moins, ça fonctionne.

    Pour faire plus propre et plus simple, serait-il possible à l’avenir de modifier le code de url_de_base() pour qu’en l’absence de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"], la fonction aille regarder dans META si c’est du http ou du https qui y est renseigné (au lieu de mettre forcément du http) ?

    L’idée semble bonne à premier vue tellement ça parait simple, mais j’ai peur que cela ait des effets de bord sur certaines configurations, notamment derrière un proxy. Attendons les avis des autres membres de l’équipe avant de l’intégrer ou non.