
Recherche avancée
Médias (3)
-
MediaSPIP Simple : futur thème graphique par défaut ?
26 septembre 2013, par
Mis à jour : Octobre 2013
Langue : français
Type : Video
-
GetID3 - Bloc informations de fichiers
9 avril 2013, par
Mis à jour : Mai 2013
Langue : français
Type : Image
-
GetID3 - Boutons supplémentaires
9 avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
Autres articles (66)
-
Personnaliser les catégories
21 juin 2013, parFormulaire de création d’une catégorie
Pour ceux qui connaissent bien SPIP, une catégorie peut être assimilée à une rubrique.
Dans le cas d’un document de type catégorie, les champs proposés par défaut sont : Texte
On peut modifier ce formulaire dans la partie :
Administration > Configuration des masques de formulaire.
Dans le cas d’un document de type média, les champs non affichés par défaut sont : Descriptif rapide
Par ailleurs, c’est dans cette partie configuration qu’on peut indiquer le (...) -
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 ;
-
Diogene : création de masques spécifiques de formulaires d’édition de contenus
26 octobre 2010, parDiogene est un des plugins ? SPIP activé par défaut (extension) lors de l’initialisation de MediaSPIP.
A quoi sert ce plugin
Création de masques de formulaires
Le plugin Diogène permet de créer des masques de formulaires spécifiques par secteur sur les trois objets spécifiques SPIP que sont : les articles ; les rubriques ; les sites
Il permet ainsi de définir en fonction d’un secteur particulier, un masque de formulaire par objet, ajoutant ou enlevant ainsi des champs afin de rendre le formulaire (...)
Sur d’autres sites (5367)
-
Anomalie #4119 (En cours) : Page gestion des plugins : Selecteur d’action mal positionné quand on ...
28 mars 2018, par jean marieQuand on sélectionne un ou plusieurs plugins à mettre à jour via SVP et qu’on descend en bas de page pour valider, la liste déroulante est sur Désactiver par défaut alors qu’on est en train de faire une action de mise à jour.
C’est casse gueule (j’ai désactivé plusieurs plugins au lieu de les mettre à jour).C’est bien adapté si on n’active pas la mise à jour via SVP :
- soit on est sur la page des plugins actifs et on ne peut que les désactiver
- soit est sur la page des plugins inactifs et on ne peut que les activer.
Mais si on active la mise à jour, il y a un 3e choix : les mettre à jour. Dans ce cas, est-ce que la liste ne devrait pas être par défaut sur un champ "choisir quoi faire" ?Souci présent uniquement quand on coche manuellement les plugins (pour n’en mettre que certains à jour) pas quand on clique sur "Cocher les mises à jour" (ping b_b :) ).
Sur spip-dev : https://www.mail-archive.com/spip-dev@rezo.net/msg66339.html
-
Anomalie #3941 (Fermé) : CSS carnet contrib
5 mai 2017, par jluc -Dans le carnet wiki de contrib, les balises code et cadre génèrent un listing dont les lignes sont numérotées.
Il y a une colonne grisée plus claire spécialement pour les n° de ligne, à gauche du code.
Malheureusement les n° sont déportés à droite à cause d’un `margin-left : 43px ;` spécifié par le plugin coloration_code, et du coup cette colonne est vide.
Voir la copie d’écran de la page https://contrib.spip.net/test-du-carnet pour se rendre compte.
Les n° de ligne sont tous décalés au lieu d’utiliser la colonne dégagée pour eux !
Ça va nettement mieux quand on active la css suivante :
Je ne sais pas la motivation de ce margin de 43px dans coloration_code, et si c’est à corriger dans gribouille (mais je ne sais pas quel gribouille le carnet de contrib utilise car yen a plusieurs) ou dans coloration_code ou spécifiquement dans contrib.
-
Anomalie #4623 : Styles des fieldset dans l’espace privé
19 avril 2021Je pense qu’il faut garder la règle un fieldset == un div.editer en plus gros.
Oui, ça se tient aussi. Je crois avoir vu cette structure utilisée sur un form de la dist d’ailleurs.
Pour les fieldsets on pourrait employer un nom qui rappelle que ça fait partie d’un.editer-groupe
non ? Genre.editer-fieldset
par exemple, au lieu de.fieldset tout court
?Je signale pour pas oublier et ne pas exclure cette possibilité que certains formulaires ont besoin de plusieurs
.editer-groupe
à la racine, avec des choses entre. Par exemple pour le multi il y a des.boutons
au milieu du formulaire :form .editer-groupe .boutons .editer-groupe .boutons
On peut imaginer aussi un formulaire qui aurait besoin en cours de route d’un groupe de saisies en 2 colonnes, donc de plusieurs
.editer-groupe
consécutifs :form .editer-groupe .editer-groupe.deux_colonnes .editer-groupe
Et aussi entre le
legend
et le.editer-groupe
d’un fieldset, la charte permet d’insérer des explications (et autres ?).