
Recherche avancée
Autres articles (33)
-
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs -
Emballe médias : à quoi cela sert ?
4 février 2011, parCe plugin vise à gérer des sites de mise en ligne de documents de tous types.
Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ; -
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 (2294)
-
Documentation #3027 : Squelette Spip.net
18 novembre 2013, par Arnaud Dupin de BeyssatBonjour
Merci de la réponse.
Il s’agit notammen t du menu latéral de la page
http://www.spip.net/fr_rubrique135.html et des suivantes (filrtres,
critères ; etc.)
sans doute associéà<a class="external" href="http://www.spip.net/">www.spip.net</a><br /> /squelettes<br /> /branches<br /> /2008<br /> /inc-rubriques.html
Merci
ADBLe 16/07/2013 10:35, redmine@spip.org a écrit :
La demande #3027 a été mise à jour par b b.
Salut, de quelle page du site s’agit-il ?
Evolution #3027 : Squelette Spip.net
- Auteur : Arnaud Dupin de Beyssat
- Statut : Nouveau
- Priorité : Normal
- Assigné à :
- Catégorie :
- Version cible :
- Resolution :
Bonjour
Serait-il possible de passer la liste des rubriques du menu latéral
ordonné en alphabétique ? Cela faciliterait les recherches de balises, etc.
Actuellement, les lignes sont :
12
13 id_rubriqueid_rubrique=#ENVid_rubrique par num titre !par date
doublons>
14 #TITRE
15A la ligne 13, passer en par nom ai lieu de par num titre !par date
Merci
Vous recevez ce mail car vous êtes impliqués sur ce projet.
Pour changer les préférences d’envoi de mail, allez sur
http://core.spip.org/my/account -
Anomalie #4623 : Styles des fieldset dans l’espace privé
17 avril 2021, par RastaPopoulos ♥Alors c’est justement ce que je ne voulais pas générer au moins pour les groupes racines : là on se retrouve pour les fieldsets racines avec 2 bordures collées, ce qui fait super lourd visuellement il me semble : bordure du form et direct collé bordure du groupe.
Je détaille l’argument du foncé qui était volontaire : quand il y a des décorations claires, certaines personnes (et suivant la qualité des écrans) ne les voient pas ou peu, mais ce n’est pas grave si ce n’est que de la déco. Alors qu’un élément foncé va être vu par un pourcentage bien plus grand de personnes. Comme là il s’agit d’une indication visuelle utile, et non pas juste de décoration, je trouvais donc important que ce soit foncé pour que le max de gens les voit.
Pour les barres horizontales, là aussi c’était voulu de les enlever, afin d’alléger visuellement : là on se retrouve de nouveau avec des "cadres enfermants" de partout et donc visuellement (quand on a des yeux qui voient toutes les lignes) on a dès le premier coup d’œil cette impression de "cadres dans des cadres dans des cadres". Alors que le but des simplifications de Tcharlss était justement de minimiser le plus possible cette impression, et du coup mon but était de trouver une solution pour les fieldsets qui n’en rajoute pas dans ce domaine.
Pour la bordure sur la droite b_b, je vais faire un essai, mais le premier truc qui me vient c’est que justement on lit à gauche, et que seulement une indentation sans bordure à gauche c’est beauuuucoup plus faible pour voir du premier coup quels champs sont regroupés avec quels autres. Ça va faire qu’on va voir le regroupement que dans un deuxième temps au lieu de le voir au début de chaque ligne.
-
Anomalie #3978 : Reload ajax et contexte au retour d’un URL_ACTION_AUTEUR
29 septembre 2018, par cedric -Pas de bug ici, juste une erreur de conception dans les 2 squelettes :)
Dans le cas 1 les arguments reloada=1 et reloadb=1 sont passés en argument du href et viennent dans l’URL après un reload ajax d’un bloc
Du coup quand on passe un{args:{reloadb:''}}
et{args:{reloada:''}}
dans le refresh ajax ça annule bien l’argument de l’URL et évite la boucle infinieDans le cas 2 les reloada et reloadb ne sont pas en arguments de l’URL mais en argument de l’URL de retour passée à l’action
Du coup les arguments{args:{reloadb:''}}
et{args:{reloada:''}}
ne viennent rien faire car ils s’appliquent sur l’URL de l’action, pas sur l’URL de retour.Consequence sans doute pas vue : au second coup le refresh de A se fait via l’URL action, c’est a dire en faisant une action indésirable au lieu de simplement rafraichir
Solution : indiquer dans le refresh ajax qu’il faut utiliser l’URL de départ et pas l’URL action :
Bloc A (#REM
Reload A => Declenchera ensuite le Reload de B
[(#ENVreloada|oui)
<script type="text/javascript"><br />
ajaxReload('blocb', {args:{reloadb:''},href:'#SELF'});<br />
</script>]
Bloc B (#REM
Reload B => Declenchera ensuite le Reload de A
[(#ENVreloadb|oui)
<script type="text/javascript"><br />
ajaxReload('bloca', {args:{reloadb:''},href:'#SELF'});<br />
</script>]
A noter qu’ici j’ai aussi ajouté une class nohistory sur les liens pour ne pas modifier l’URL de la page web et éviter qu’elle ne devienne celle de l’action