
Recherche avancée
Médias (1)
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
Autres articles (44)
-
Personnaliser en ajoutant son logo, sa bannière ou son image de fond
5 septembre 2013, parCertains 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 ;
-
Ecrire une actualité
21 juin 2013, parPrésentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
Vous pouvez personnaliser le formulaire de création d’une actualité.
Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...) -
(Dés)Activation de fonctionnalités (plugins)
18 février 2011, parPour gérer l’ajout et la suppression de fonctionnalités supplémentaires (ou plugins), MediaSPIP utilise à partir de la version 0.2 SVP.
SVP permet l’activation facile de plugins depuis l’espace de configuration de MediaSPIP.
Pour y accéder, il suffit de se rendre dans l’espace de configuration puis de se rendre sur la page "Gestion des plugins".
MediaSPIP est fourni par défaut avec l’ensemble des plugins dits "compatibles", ils ont été testés et intégrés afin de fonctionner parfaitement avec chaque (...)
Sur d’autres sites (7177)
-
Evolution #4548 : Améliorer _request et set_request pour prendre en compte les champs qui sont des...
10 septembre 2020, par RastaPopoulos ♥@marcimat ? "n’a pas beaucoup de sens" ? => c’est la syntaxe officielle normalisée de HTML ! Ça a d’après moi encore plus de sens de gérer cette écriture, que de gérer une écriture personnalisée (à base de / chez nous, de . chez laravel), qui est très bien aussi et qui devrait être fait aussi d’après moi, mais qui mais nous est propre, en interne. Alors que la première écriture ne nous est pas propre : c’est la norme HTML !
Les deux fonctions request (_request et set_request) sont directement liées aux formulaires HTML, dont la norme de nom de champ est "tableau[index]" et non pas "tableau/index", donc la priorité c’est de prendre en compte l’écriture officielle directement liée.Et comme je le dis plus haut, et contrairement à ce qui se discutait dans #4110 : ça n’a aucune spécificité à Saisies. On peut stocker la liste des noms des champs pour d’autres raisons, et on a aussi des squelettes à inclure et des filtres PHP dans le noyau qui génèrent des champs devant leur passer "nom" ou "name" en param (pour id_parent, pour sélectionner rubrique, article…) et qu’on peut parfaitement vouloir poster dans un sous-tableau (ya plein de raisons valables et utiles, comme éditer un objet dans un autre, une géoloc, des infos de commerce, etc, des milliers - si :p - d’autres CMS font ça depuis toujours : patate[gis][lat]… patate[prix][taxe]…).
Quand ensuite on veut récupérer ou modifier ces valeurs postées en masse automatiquement, car on connait les noms de chacun, sans faire un traitement à la main particulier, bah ce qu’on connait c’est "patate[gis][lat]", donc autant pouvoir l’utiliser directement.
Après si ça ne prend en compte que "tableau/index" mais que le core fournit aussi la transformation et qu’il faille écrire
_request(name2chemin('patate[gis][lat]'))
plutôt que directement_request('patate[gis][lat]')
, ça serait déjà ça puisque ça permet l’automatisation aussi… (mais dans ce cas pourquoi ne pas l’appeler directement en interne, ça ne coûte rien du tout de plus !)Au niveau du code, ya rien de compliqué à gérer dans ce cas, rien de "ça va être chiant", puisque SPIP a déjà tout ce qu’il faut pour chercher une valeur suivant un "chemin". Il y a uniquement 2 choses à faire :
- avoir une fonction mutualisée qui transforme la norme HTML en chemin de chez nous (avec / donc) et appeler cette fonction au tout début des deux fonctions request
- dans les deux fonctions chercher table_valeur($tableau, $var) plutôt que directement $_GET[$var], $_POST[$var] etcAinsi dans _request() avant c’était :
if (is_array($c)) return isset($c[$var]) ? $c[$var] : null ;
if (isset($_GET[$var]))
$a = $_GET[$var] ;
elseif (isset($_POST[$var]))
$a = $_POST[$var] ;
else
return null ;
Et alors ça serait environ :
$chemin = name2chemin($var) ;
if (is_array($c))
return table_valeur($c, $chemin) ;
if ($valeur=table_valeur($_GET, $chemin) !== null)
$a = $valeur ;
elseif (…Quasiment rien qui change !
-
lavf/protocols : avoid discarding const in avio_enum_protocols()
25 novembre 2021, par Anton Khirnov -
Difference between stream level and file level in ffmpeg
25 avril 2013, par UsamaConcatenation of files with same codecs with ffmpeg
Two methods
Concat demuxer
Concat protocol
While the demuxer works at the stream level, the concat protocol works at the file level. Certain files (mpg and mpeg transport streams, possibly others) can be concatenated. This is analogous to using cat on UNIX-like systems or copy on Windows. In general, the demuxer is the better option
What is the difference between stream level and file level ?
Thanks in Advance