
Recherche avancée
Médias (1)
-
1 000 000 (wav version)
26 septembre 2011, par
Mis à jour : Avril 2013
Langue : English
Type : Audio
Autres articles (74)
-
Gestion des droits de création et d’édition des objets
8 février 2011, parPar défaut, beaucoup de fonctionnalités sont limitées aux administrateurs mais restent configurables indépendamment pour modifier leur statut minimal d’utilisation notamment : la rédaction de contenus sur le site modifiables dans la gestion des templates de formulaires ; l’ajout de notes aux articles ; l’ajout de légendes et d’annotations sur les images ;
-
Activation de l’inscription des visiteurs
12 avril 2011, parIl est également possible d’activer l’inscription des visiteurs ce qui permettra à tout un chacun d’ouvrir soit même un compte sur le canal en question dans le cadre de projets ouverts par exemple.
Pour ce faire, il suffit d’aller dans l’espace de configuration du site en choisissant le sous menus "Gestion des utilisateurs". Le premier formulaire visible correspond à cette fonctionnalité.
Par défaut, MediaSPIP a créé lors de son initialisation un élément de menu dans le menu du haut de la page menant (...) -
Supporting all media types
13 avril 2011, parUnlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)
Sur d’autres sites (7069)
-
Evolution #3603 : Ergonomie des onglets de sélection des plugins
21 avril 2020+1 pour ne pas avoir un onglet des mises à jour.
Ok s’il y a un moyen de filtrer les mises à jour une fois qu’on est dans l’onglet des plugins actifs.
Toutefois je pense qu’on devrait prévoir le cas où on puisse atterrir sur cette page avec ce filtre déjà activé. À ce compte là un vrai lien serait plus simple qu’un truc javascript. Un exemple : mettons que dans le futur il y ait un tableau de bord plus complet, avec éventuellement une partie comportant les notifications admins : "la version de 4.0 de spip est disponible", "3 plugins peuvent être mis à jour", etc. Hop, un clic sur le lien et on arriverait sur la page déjà filtrée.Ben, le truc aussi c’est que les verrouillés c’est pareil que les dépôts, l’utilisateur lambda s’en fout complètement, et en plus ça ne signifie rien, on a aucune raison de garder ça.
Attention certains plugins de la dist ne sont configurables qu’à partir de cette page (svp, etc.).
Et si un jour il y a des distributions différentes, il pourra y avoir des plugins communautaires également dans la liste (et donc qu’on doit pouvoir configurer aussi).
C’est peut-être le terme « verrouillés » qui n’incite pas trop à aller dessus.----
En pj un petit test en ajoutant une pastille dans l’onglet des actifs, avec le nombre de mises à jour.
Et aussi séparer les onglets en 2 groupes pour voir : d’un côté ceux qui listent les plugins, et de l’autre les actions. Bon, je sais pas quoi en penser, c’est juste pour voir :p -
Evolution #3589 (Fermé) : Modification au pointage des résultats de recherche...
9 mars 2021, par cedric -J’ai intégré en adaptant parce que :
- le patch proposé est buggué en se basant uniquement sur$regs[0][0]
qui est le premier résultat trouvé : il faudrait donc itérer sur chaque résultat
- pour le résultat multi-mots, l’algo ne marche pas si bien car si par exemple je cherche "tempete de sable" le "de" est supprimé des regexp car trop court, et donc je n’ai que des match sur tempete et sable
- la distinction mot entier/partie de mot est quand même lourde car il faut donc refaire une preg dans un foreach (sans oublier d’échapper le résultat pour reconstruire une preg) et discutable car si je trouve "baton" dans le mot "batons" au pluriel en quoi ce serait moins bien que dans "baton" au singulier ? Il faudrait donc pousser plus loin l’analyse ce qui va in fine être très couteuxTout bien pesé et regardé, j’ai donc tiré la substantifique moelle du patch qui est de dire "plus le résultat trouvé est long mieux c’est" et ça donne https://git.spip.net/spip/spip/commit/c1ab59cb72c77102ea9b75309c2062ab8d8aa51a : je pondère le poids par la longueur totale des matchs trouvés et non par le nombre de match.
Effet de bord, tous les #POINTS vont fortement augmenter, si quelqu’un utilisait un seuil pour filtrer ses résultats ça va tomber à l’eau (mais c’est pas très grave...)
-
Evolution #3966 (Nouveau) : Date de création des contenus
26 juin 2017, par tcharlss (*´_ゝ`)Il n’y a pas longtemps j’ai eu besoin de faire des statistiques éditoriales : on voulait connaître l’évolution du nombre d’articles publiés chaque année.
Mais les données ne sont pas fiables : les utilisateurs avaient pour habitude de faire des « remises en avant » en changeant la date de publication de vieux articles pour les refaire apparaître en page d’accueil. Donc un article écrit en 2014 mais remis en avant en 2017 se retrouve compté comme ayant été publié en 2017.Et c’est valable pour tout les objets éditoriaux en fait : on ne conserve pas leur date de création / 1ère publication.
Certains objets ont une date de publication, mais elle peut être changée. Et d’autres objets n’ont tout simplement pas de date (hormis maj).Donc je me demandais s’il ne serait pas pertinent d’avoir cette information de façon générique pour tous les objets éditoriaux, un champ date_creation par exemple qui serait rempli soit à la création, soit à la 1ère publication, et qui ne bougerait pas ensuite.
Ci-dessous, un tableau récapitulatif de ce qu’on a actuellement pour les principaux objets.
Objet Champ de date Date pérènne ? Articles date Non : peut être modifiée manuellement Brèves date_heure Non : peut être modifiée manuellement Rubriques date Oui Auteurs X X Mot-clé X X Groupe de mots-clés X X Document date Oui Forum date_heure oui Pétition X X