Recherche avancée

Médias (1)

Mot : - Tags -/net art

Autres articles (63)

  • Participer à sa traduction

    10 avril 2011

    Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
    Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
    Actuellement MediaSPIP n’est disponible qu’en français et (...)

  • Use, discuss, criticize

    13 avril 2011, par

    Talk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
    The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
    A discussion list is available for all exchanges between users.

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

  • Evolution #3459 (Nouveau) : Essayer d’éviter les spams de referrer

    2 juin 2015, par kent1 -

    Ce serait pas mal d’essayer de les restreindre un peu

    Regarder comment fait Piwik ici : http://piwik.org/blog/2015/05/stopping-referrer-spam/?pk_campaign=org_newsletter_2015_06&pk_medium=email&pk_source=piwik_org_newsletter

    Avec un début de liste ici : https://github.com/piwik/referrer-spam-blacklist

    On pourrait peut être fonctionner un peu comme no-spam ?

    à développer en sous-plugin peut être ?

    Des avis ?

  • Révision 22206 : Deux bugs dans le phraseur illustré par l’exemple ci-dessous fourni par Georges K...

    6 juin 2015, par esj -

    * (ligne 295) ce qu’il y a avant un nom de balise dans un argument n’est pas forcément du texte brut, il peut y avoir des chaînes de langues ;
    * (ligne 256) les apostrophes et guillemets en début d’argument ne sont pas forcément des délimiteurs SPIP, il faut qu’il y en ait un 2e plus loin, ce que preg_match contrôlait sans que SPIP tienne compte de son résultat. On y veille à présent mais il est à noter que cette condition est nécessaire mais non suffisante, du fait de la terrible ambiguité de la syntaxe des squelettes. Il y a donc d’autres bugs potentiels quand on met des balises comme arguments d’une balise.

    Autre chose qui ne relève pas du phraseur : dans le code ci-dessous le "**" après #SESSION n’est pas seulement destiné à produire un code plus efficace (il ne sécurise pas car ce n’est pas nécessaire quand on ne s’intéresse qu’au résultat booléen), mais aussi parce que le "interdire_script" introduit sinon transcode le chevron dans le "< ?php" de la balise dynamique #URL_LOGOUT, ce qui la neutralise. C’est un autre bug à creuser.

    <span class="CodeRay">[(#SESSION**{nom}|?{
    
<span class="tag">&lt;:bienvenue:></span> <span class="tag"><strong></strong></span>#SESSION{nom}<span class="tag"></span>    
    
<span class="tag">span> <span class="tag">/></span><span class="tag">span> <span class="attribute-name">href</span>=<span class="string"><span class="delimiter">'</span><span class="content">#URL_LOGOUT</span><span class="delimiter">'</span></span><span class="tag">></span><span class="tag">&lt;:logout:></span><span class="tag"></span>
    
,
    
<span class="tag"><p></p></span><span class="tag"><small></small></span><span class="tag">span> <span class="attribute-name">alt</span>=<span class="string"><span class="delimiter">"</span><span class="content">&lt;:zonep:</span></span><span class="error">></span>" src="#CHEMIN{encrypted.png}" /<span class="error">></span> <span class="tag">&lt;:acces:></span> <span class="tag">span> <span class="attribute-name">href</span>=<span class="string"><span class="delimiter">"</span><span class="content">#URL_PAGE{login,url=#SELF}</span><span class="delimiter">"</span></span><span class="tag">></span><span class="tag">&lt;:ident:></span><span class="tag"></span>
    
<span class="tag"></span><span class="tag"></span>
    
})]
    
</span></span></span></span></span>

  • Révision 22269 : Retour sur r22264. En fait l’emplacement orginel de "interdire_scripts" provoque ...

    25 juin 2015, par esj -
    • la neutralisation inopportune des scripts introduits par le compilateur (bug corrigé par r22264) ;
      • l’altération des appels à des scripts introduits par un rédacteur, scripts q’il ne faut effectivement pas interpréter (cas du squelette nécessitant une double passe de PHP, cf. scénario possible sur http://article.gmane.org/gmane.comp.web.spip.devel/66397) mais cette stratégie brutale ne répond pas à l’intention d’un rédacteur qui s’attend à voir s’afficher le source de l’appel du script, pas le résultat de son exécution (je ne parle évidemment pas d’un rédacteur malveillant qui essaye d’exploiter une faille).

    A première vue la résolution correcte du 2e point nécessite de gros changements
    dans la stratégie de compilation adoptée depuis le début de SPIP.
    Il vaut mieux se donner le temps de la réflexion avant d’aller dans cette voie.
    Je remets le code antérieur par "svn merge -r -r22264:22263 ."
    pour ne pas laisser cette faille potentielle,
    en actant provisoirement que le premier bug doit être considéré comme une limitation de SPIP,
    savoir le fait qu’il n’est pas possible d’utiliser une balise produisant du PHP dans un argument de filtre.

Navigation