
Recherche avancée
Autres articles (45)
-
Support audio et vidéo HTML5
10 avril 2011MediaSPIP 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 (...) -
De l’upload à la vidéo finale [version standalone]
31 janvier 2010, parLe 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 (...) -
Librairies et binaires spécifiques au traitement vidéo et sonore
31 janvier 2010, parLes logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
Binaires complémentaires et facultatifs flvtool2 : (...)
Sur d’autres sites (6957)
-
Anomalie #3035 (Nouveau) : Association de mots-clés et autorisation
6 août 2013, par Joseph LarmarangeCréation d’un ticket suite à http://permalink.gmane.org/gmane.comp.web.spip.devel/64550
Cas de figure :
- des groupes de mots-clés pour lesquels les rédacteurs ont les droits pour ajouter un mot clé de ces groupes.
- un rédacteur qui visualise un article dont il n’est pas l’auteur et par conséquent pour lequel il n’a pas les droits d’ajouter ou de supprimer un mot-clé.Néanmoins, ce rédacteur va voir la liste des mots-clés associés à cet article, avec un lien pour supprimer les mots-clés en question, un lien ’Ajouter des mots-clés’ lui permettant de charger le formulaire d’ajout de mot-clé.
Si ce rédacteur décide de faire l’une de ces actions (ajout ou suppression), le bloc va se recharger, l’action ne sera pas exécutée et il n’y aura aucun message d’erreur, par exemple pour avertir que l’on n’a pas les droits nécessaires. On a donc une incohérence de l’interface.
En investigant, j’aperçois plusieurs points qui font défaut.
En premier lieu, la fonction autoriser_associermots_dist() regarde simplement si un auteur à le droit en général d’associer des mots-clés d’un groupe en fonction de son statut (admin ou rédacteur) mais ne prends pas en compte si l’individu a le droit de modifier l’objet en question.
Le formulaire EDITER_LIENS du core regarde dans sa fonction charger l’autorisation associerobjets (donc associermots dans notre cas de figure) pour savoir si le formulaire est editable ou non. Dans sa fonction traiter, le formulaire regarde simplement si l’individu a le droit de modifier l’objet en question ou non (mais ne revérifie pas qu’il a les droits d’associer l’objet en question). Par ailleurs, si on n’a pas les droits requis, la fonction traiter ne renvoie pas de message d’erreur.
Le squelette prive/objets/liste/mots_lies.html ne tient compte ni de #ENVeditable ni d’une quelconque autorisation pour afficher ou non un lien de suppression d’un mot-clé.
La fonction autoriser_groupemots_afficherselecteurmots_dist renvoie toujours true.
Propositions d’évolution
- Faire évoluer l’autorisation associermots pour qu’elle vérifie également, si un $id_objet est passé, que l’invidu a les droits de modifier l’objet en question. Cela permettra que la propriété editable soit correctement renseignée dans le formulaire d’ajout de mot-clé. Par ailleurs, pour les plugins ayant besoin de savoir si quelqu’un a le droit d’associer un mot-clé, cela fera une seule auorisation à vérifier (le problème s’est posé avec coche_mots).
- La fonction traiter de éditer_liens devrait dépendre de associermot (il faut vérifier que cela n’a pas d’incidence pour les autres tables de liens) et non des droits de modification d’un objet. Ces droits peuvent être différents dans un contexte d’autorisations personnalisées.
- Cette même fonction traiter doit renvoyer un message d’erreur si on n’a pas les droits suffisants.
- Le squelette prive/objets/liste/mots_lies.html doit vérifier l’autorisation associermots pour afficher un lien de suppression d’un mot-clé.
- Par cohérence, la fonction autoriser_groupemots_afficherselecteurmots_dist est modifiée pour renvoyer, par défaut, le résultat de l’autorisation associermots.
-
Revision 77167 : Ajout d’une pipeline afin de corriger la hiérachie sur les pages : faire ...
11 octobre 2013, par tcharlss@… — LogAjout d’une pipeline afin de corriger la hiérachie sur les pages : faire pointer la racine vers la liste des pages au lieu des rubriques
-
Option dans diogene pour publier un média dès sa création
11 octobre 2013Les formulaires de diogene contiennent tous un dernier champ "Modifier le statut de votre média", à choisir entre :
- publié
- évaluation
- rédaction
- poubelle
C’est inutilement compliqué pour la majorité des utilisateurs qui veulent juste publier le média.
Je propose donc d’ajouter une option de configuration de diogene qui fera ce qui suit :
- pas de champ de changement de statut
- le bouton "Enregistrer" devient "Publier"
- envoyer sur la page du media publié, au lieu de rester sur la page d’édition