
Recherche avancée
Médias (1)
-
La conservation du net art au musée. Les stratégies à l’œuvre
26 mai 2011
Mis à jour : Juillet 2013
Langue : français
Type : Texte
Autres articles (70)
-
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
Possibilité de déploiement en ferme
12 avril 2011, parMediaSPIP peut être installé comme une ferme, avec un seul "noyau" hébergé sur un serveur dédié et utilisé par une multitude de sites différents.
Cela permet, par exemple : de pouvoir partager les frais de mise en œuvre entre plusieurs projets / individus ; de pouvoir déployer rapidement une multitude de sites uniques ; d’éviter d’avoir à mettre l’ensemble des créations dans un fourre-tout numérique comme c’est le cas pour les grandes plate-formes tout public disséminées sur le (...) -
Ajouter des informations spécifiques aux utilisateurs et autres modifications de comportement liées aux auteurs
12 avril 2011, parLa manière la plus simple d’ajouter des informations aux auteurs est d’installer le plugin Inscription3. Il permet également de modifier certains comportements liés aux utilisateurs (référez-vous à sa documentation pour plus d’informations).
Il est également possible d’ajouter des champs aux auteurs en installant les plugins champs extras 2 et Interface pour champs extras.
Sur d’autres sites (8662)
-
Anomalie #4543 (Nouveau) : Accessibilité des chargements ajax (live regions)
2 septembre 2020, par nicod _Suite à un audit de site par Temesis, il remonte que les attributs aria qu’on utilise sont mal placés.
Je cite :
Il semble qu’il y a un problème plus global avec l’utilisation des live region :
Je rencontre à nouveau le div englobant div.ariaformprop qui possèdent les attributsaria-live
aria-atomic
aria-relevantCette utilisation de ces attributs est erronée :
elle ne donne pas le résultat probablement attendu
le support d’aria-relevant dans les assistances technologiques n’est pas assuréIl est donc nécessaire de ne pas utiliser de live region sur une div englobante comme là.
Il faut supprimer ces attributs et utiliser aria-live et aria-atomic avec parcimonie.J’ai regardé l’exemple que tu donnes sur spip.net également.
L’exemple était : https://www.spip.net/spip.php?page=recherche&recherche=plugin&debut_articles=0#pagination_articles
Cette prolifération d’aria-live + aria-atomic part probablement d’un bon sentiment, mais comme parfois avec l’accessibilité, le mieux est l’ennemi du bien.
En positionnant ces attributs, avec ces valeurs, sur des div englobantes, cela génère dans les lecteurs d’écran la lecture automatique des contenus qui ont été mis à jour.
Certes la lecture peut être interrompue par l’utilisateur, mais cela revient, à mon avis à imposer quelque chose qui n’a pas été forcément souhaité. De cette manière le propriétaire du site impose une expérience différente aux utilisateurs de lecteur d’écran.
Ensuite, il faut bien entendu prendre en compte le contexte. Il pourrait arriver que ce comportement soit pertinent. Ce n’est pas le cas ici.Dans le cas de rechargement ajax, il faut étudier chaque cas et son contexte, mais le plus souvent le principe est :
Ne pas utiliser ces attributs lorsqu’il n’y a pas d’interactions / rechargement ajax . Exemple sur un formulaire, cela n’a pas de sens : on rempli un form et puis on valide le form. A priori (si j’ai bien compris le fonctionnement) il n ’y a aucune raison d’utiliser de live region. En théorie, la présence de ces attributs s’il n’y a pas de rechargement ne devrait pas gêner. Mais certains lecteurs d’écran peuvent prendre des libertés par rapport aux spécifications et vocaliser des contenus tout de même. C’est pourquoi il faut être parcimonieux.
Lorsqu’ils sont utiles et nécessaires, utiliser ces attributs pour informer d’un changement. Exemple : donner le nouveau nombre de résultats après utilisation de filtre. Mais il faut bien penser que dans plusieurs cas ils ne sont pas nécessaires, en effet, un bouton d’action doit être explicite avant qu’on appuie dessus. Donc par exemple : lorsque je demande à afficher la page 2 dans une pagination de résultat, il n’y a pas d’info à vocaliser automatiquement, le fait que le bouton dise "afficher la page 2" est suffisant, il serait superflu, voire gênant d’aller plus loin dans ce qui est vocalisé.
Enfin, il faut gérer le focus clavier. Cet aspect est essentiel dès qu’il y a des interactions ajax, mais il dépend totalement du contexte. Et cet aspect est indépendant de la nécessité d’utiliser les live regions. Exemple : dans une série de filtre on va laisser le focus sur le filtre pour que l’utilisateur puisse parcourir la série de filtre. A contrario, dans une pagination (ou quand on a un bouton de type "afficher plus d’articles", dans des news ou dans une page de produits pour un site de e-commerce) on va déplacer le focus sur le 1er nouveau élément qui vient de s’afficher (la zone qui a été mise à jour).
-
Anomalie #4128 (En cours) : Bug de génération de boucle avec les modèles Spip
11 avril 2018, par Julien PORIAUDans les modèles personnalisés Spip, les images (boucle documents ou logos) sont mal générées et provoque un bug d’encodage visible dans le front-end lors du passage dans une autre langue (balises multi).
Nous n’avons pas trouvé où était le souci dans Spip, mais les caractères qui remontent dans le code source, ressemblent aux octets qui composent le fichier binaire d’une image.
Voir en live ici : http://spip-dev.nidecker.com/probleme-de-langue.html?lang=ca.Pour essayer d’isoler cette anomalie, nous avons procédé de la sorte avec l’aide de mon développeur :
1. Nous sommes reparti d’un SPIP 3.1.7 entièrement neuf (minimal), avec deux modèles Spip, rien d’autre.
Le bug se reproduit, ce qui exclus un problème lié aux squelettes ou autres plugins.Nous n’avons pas réussi a déterminer précisément ce qui génère ce bug, à part que c’est dans un contexte où on appelle une langue pas définie dans le multi.
En fonction du contenu de l’article, du nombre de modèles dans l’article, en fonction des boucles dans les inclure, le bug n’arrive pas au même endroit...Le problème vient de la génération des logos ou documents : si on supprime les balises
#LOGO_*
ou si on renommeIMG
enIMG_
, plus d’erreur.
Même sans traitements, avec juste[(#LOGO_*)]
, rien à faire.2. Nous avons pensé que c’était peut être une image au mauvais format : On a alors tenté de passer
ImageOptim
sur tout le répertoire/IMG
, redimensionné tous les logos en vignettes png de 320x240, rien à faire...3. On a fini par passer ce site de test en 3.2, pas mieux.
4. Nous avons épluché les caches générés dans
/tmp/cache
et/tmp/cache/skel
, tout paraît normal de ce côté là..5. On a ensuite un peu avancé en enlevant dans
mes_options.php
la variable$GLOBALS['forcer_lang'] = true
".
Sur la version minimal, plus de bug. Mais sur le site de production, le problème réside toujours.
Mais en faisant des tests avec et sans (et en supprimant bien/tmp/cache/
à chaque fois), ça se confirme pour la version minimal.6. A partir d’une copie de la version production, nous avons désactivé tout les plugins, passer
ImageOptim
sur/IMG
et rien a faire.. Impossible de déterminé d’où vient le problème :(7. Nous avons essayé d’écrire comme ceci :
[<img src="http://core.spip.org/projects/spip/(#LOGO_MOT|image_reduire{50,*}|extraire_attribut{src})" alt="" style='max-width: 300px; max-height: 300px' />]
Cela fonctionne sur la version minimal mais pas sur la version production.8. Dans la version minimal, j’ai encore récemment testé une dernière chose. J’ai supprimé les documents non sollicités sur ma page de teste (spip.php ?article1441&lang=ca).
Avec la requête SQL suivante :DELETE FROM jones_documents WHERE id_document NOT IN (1948,1949,2534,2535,630,631,1783,1784,1785,1786,1787,1788,1781,1782)
Le bug n’apparait plus..Je sèche..
Vous trouverez ici en téléchargement une archive de la version minimal (Spip 3.1.7) : https://www.dropbox.com/s/dek0zg7jafl8uxe/jones.zip?dl=0] ( 20mo)
Pour reproduire le bug, il suffit de passer la variable "&lang=ca" dans l’article 1441 (localhost/spip.php ?article1441&lang=ca).Je donne volontiers un accès à la version production si besoin.
-
ffmpeg have unmet dependencies (Ubuntu20) [closed]
10 août 2024, par mojiangwhen installing ffmpeg with ubuntu20(fosal), it have conflict dependencies :


# sudo apt-get install ffmpeg
Reading package lists... Done
Building dependency tree 
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ffmpeg : Depends: libavdevice58 (= 7:4.2.7-0ubuntu0.1) but it is not going to be installed
 Depends: libavfilter7 (= 7:4.2.7-0ubuntu0.1)
 Depends: libavformat58 (= 7:4.2.7-0ubuntu0.1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.



I solved it by install the reason of conflit library with a specific version, may be someone will need the solution.


step 1. fix-broken


sudo apt --fix-broken install
Reading package lists... Done
Building dependency tree 
Reading state information... Done



step2. find the reason of unmet dependencies :


# sudo apt install libavdevice58=7:4.2.7-0ubuntu0.1 libavfilter7=7:4.2.7-0ubuntu0.1 libavformat58=7:4.2.7-0ubuntu0.1
Reading package lists... Done
Building dependency tree 
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libavformat58 : Depends: libchromaprint1 (>= 1.3.2) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.



Here the problem is from libchromaprint1


step3. find candidate versions of libchromaprint1(conflict reason)


# apt-cache policy libchromaprint1
libchromaprint1:
 Installed: (none)
 Candidate: 1.5.1-1~20.04.sav0
 Version table:
 1.5.1-1~20.04.sav0 500
 500 http://ppa.launchpad.net/savoury1/multimedia/ubuntu focal/main amd64 Packages
 1.4.3-3build1 500
 500 http://mirrors.cloud.aliyuncs.com/ubuntu focal/universe amd64 Packages
 500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages



step4. install the old version of libchromaprint1 to solve the conflicts


# sudo apt install libchromaprint1=1.4.3-3build1
Reading package lists... Done
Building dependency tree 
Reading state information... Done
The following NEW packages will be installed:
 libchromaprint1
0 upgraded, 1 newly installed, 0 to remove and 223 not upgraded.
Need to get 37.6 kB of archives.



step5. reinstall ffmpeg


# sudo apt install ffmpeg
Reading package lists... Done
Building dependency tree 
Reading state information... Done



Done. the reason of conflict is that the latest version of libraries have conflict, by install old version of the conflicted ones to solve it.