Discussion Projet:Scripts et gadgets

Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Suppression
  • Neutralité
  • Droit d'auteur
  • Portail de qualité
  • Bon portail
  • Lumière sur
  • À faire
  • Archives
OOjs UI icon bell.svg Le projet « Scripts et gadgets » n'est pas notifié pour le moment.


Projet Fonctions disponibles Notices Discussion projet Signaler un bug Demander une nouvelle fonction
Javascript icon.svg
PROJET SCRIPTS ET GADGETS
Centraliser les fonctions JavaScript et CSS pour éviter la dispersion du code.


Cette page de discussion est destinée aux discussions sur le Projet:Scripts et gadgets.


Gadget pour affichage de l'aide dans le menu de la version mobile[modifier le code]

Ne pas archiver.

Hello les sorciers du code,

Je vous ai trouvé une nouvelle mission Sourire !

Comme vous pourrez le lire sur ce sujet il y a un petit souci sur la version mobile du site, il n'y a pas de lien vers l'aide dans le menu hamburger.

Du coup, on a ouvert un ticket sur Phabricator (Phab:T252796) pour ajouter un lien. Ce n'est pas une priorité pour les dévs mais il semble qu'il y ait, sur la version sv.m.wikipedia.org, un gadget qui permette l'affichage du lien vers l'aide.

Sauf que je n'arrive pas à l'identifier ni à savoir s'il serait adaptable ici.

Est-ce que vous pourriez nous apporter votre éclairage ?

Merci — Mattho69 me joindre 8 juin 2020 à 18:38 (CEST)

Il faudrait sinon demander sur le Bistro suèdois... -- Nemo Discuter 8 juin 2020 à 19:45 (CEST)

Gadget Skins[modifier le code]

Bonjour,

Est-ce que c'est possible de créer un gadget qui permettrait de basculer d'un skin à l'autre ? Cette fonctionnalité permettrait de vérifier et d'optimiser l'affichage des articles et des modèles pour tous les skins. Amicalement. Face-smile.svg Menthe Poivrée • 6 février 2021 à 19:50 (CET)

Bug C-Helper[modifier le code]

Bonjour,

On m'a conseillé sur le Bistro de venir voir ici : Wikipédia:Le Bistro/20 février 2021#Bug C-Helper?. Si la requête n'est pas assez claire, n'hésitez pas à me demander des détails ou clarifications!

Merci et bonne soirée, — RG067 (discuter) 20 février 2021 à 18:41 (CET)

Notification RG067 :
Bonjour,
Quel est le problème exact avec le formulaire ? L'espace entre les cases à cocher et le texte ?
Orlodrim (discuter) 20 février 2021 à 21:31 (CET)

Il s'agit surtout de l'espace entre chaque propositions, et aussi de la liste avec les points. En fait, j'ai l'impression que l'outil apparaît de manière "brut" sans la mise en forme. — RG067 (discuter) 20 février 2021 à 21:48 (CET)

WP:QT : Rupture d'action du gadget accessibilité dans la détection des alt= après la rencontre du Modèle:Relevé hydrologique ? Peut-on trouver une explication/solution ?[modifier le code]

Une réponse a été apportée.

Article(s) ou modèle(s) concerné(s) : Les 1463 pages/articles avec le modèle relevé hydrologique ne peuvent pas être controlées par l'outil accessibilité pour le libellé alternatif alt= : voir wstat.fr Relevé hydrologique d'Orlodrim Questions :

Bonjour, suite aux vérifications d'accessibilité sur le Portail:Lacs et cours d'eau, il s'avère que l'outil/gadget d'Accessiblité s'arrête d'agir après la rencontre du Modèle:Relevé hydrologique : exemple article Somme faux faux, alors que canal de la Somme est  O.K.. Pouvez vous voir pourquoi ? ou mieux solutionner le sujet, sachant que le modèle relevé hydrologique a deux points particuliers : l'appel Timeline et l'appel de la catégorie Catégorie: Accessibilité : Graphique timeline sans alternative ! Clin d'œil. PS: J'ai vérifié avec les quatre navigateurs Brave (habituel), Firefox, Google Chrome et Safari.

En vous remerciant d'avance de votre retour.--Philippe rogez (discuter) 24 mars 2021 à 15:16 (CET)

Bonjour. La demande n'est pas claire : je n'y ai rien compris : quel article est concerné, que veut dire "après la rencontre du Modèle:Relevé hydrologique", par quelle détection (le gadget en comporte 6, dire "faux" à propos du gadget ne veut rien dire). Merci de préciser votre demande. 'toff [discut.] 24 mars 2021 à 17:35 (CET)
Bonjour Supertoff. Je tente une traduction. Il s'agit de la détection « Alternatives ». En gros, dans la page Somme (fleuve), aucune image ne possède d'alternative textuelle. Le gadget indique à juste titre « ALT MANQUANT » pour les images du début de l'article mais pas pour celles de la fin, à partir de la section Somme (fleuve)#Canal de la Somme. D'où l'étonnement de Philippe rogez. Notons toutefois que si on clique sur modifier ladite section en wikicode et que l'on prévisualise, le gadget signale bien le défaut de texte alternatif. Il reste à trouver si une quelconque erreur de syntaxe, dans la page ou dans un modèle est à l'origine de ce léger problème. Le contributeur suggère que le problème puisse être lié à la présence de l'histogramme dans la section précédente de l'article, ce que la remarque ci-avant n'exclut pas. Voilà pour la clarification. Bien à vous. — Ideawipik (discuter) 24 mars 2021 à 19:23 (CET)
Merci de la clarification. C'est effectivement dû à {{Relevé hydrologique}} : si on le supprime en prévisualisation, les alt manquants apparaissent. Voilà pour ce qui est de la raison. Pour ce qui est de la solution, je n'en ai pas : le contributeur à l'origine de ce gadget a été banni (comme quoi on peut faire des choses bien et d'autres moins) et je n'ai pas les connaissances suffisantes pour corriger ou aider à corriger mais peut-être qu'un lecteur de cette section sera plus doué que moi. 'toff [discut.] 24 mars 2021 à 19:36 (CET)
Idem. Plus généralement un conflit avec la balise/extension <timeline> et peut-être d'autres. — Ideawipik (discuter) 24 mars 2021 à 19:48 (CET)

Message déposé par Philippe rogez (discuter) le 26 mars 2021 à 17:05 (CET)

L’arrêt du script en milieu de page est corrigé (modulo les mises à jour de cache, je ne sais pas pourquoi ça ne veut pas passer chez moi). Par contre il faudra peut-être voir à avoir un comportement spécifique à <timeline>, je ne suis pas convaincu que le message affiché soit pertinent. — bonnes contributions, Ltrlg (discuter), le 7 avril 2021 à 15:06 (CEST)
bonjour Ltrlg (d · c · b)Notification Ltrlg : Super résultat Bravo !. merci encore de ta participation. Il me semble que l'on cherchait un spécialiste dans ce genre de spécialité technique, depuis un certain temps... Clin d'œil très cordialement et A+--Philippe rogez (discuter) 7 avril 2021 à 15:14 (CEST)
Pour information, un ticket Phabricator en rapport avec ce problème : T216318 - EasyTimeline outputs an image with no width and height dimensions which is incompatible with MobileFrontend lazy loading. J'y ai publié une proposition de patch pour ajouter ces attributs width/height manquants. od†n ↗blah 4 juin 2021 à 06:37 (CEST)

Class "error"[modifier le code]

Bonjour,

Cette classe va être supprimée selon meta:Tech/News/2021/18. Elle est très utilisée dans les modèles, les modules et les gadgets.

Je propose donc de l'ajouter à MediaWiki:Common.css comme suggéré. Quelque chose comme ça :

.error {
  font-size: larger;
  color: #d33;
}

Orlodrim (discuter) 9 mai 2021 à 21:09 (CEST)

Fait Orlodrim (discuter) 12 mai 2021 à 08:46 (CEST)
N'aurait-on pas besoin d'ajouter le .error aussi dans le Mobile.css, ainsi que les classes .warning et .success ? od†n ↗blah 12 mai 2021 à 15:01 (CEST)
Les classes .warning et .success semblent beaucoup moins utilisées. Une requête similaire pour ces classes ne renvoie aucune occurrence ([1] [2]).
Je te laisse juger si ça vaut le coup de mettre .error dans Mobile.css. D'après le bug, ça n'a jamais marché sur mobile, mais ce serait plus cohérent.
Orlodrim (discuter) 12 mai 2021 à 19:23 (CEST)
  • J'ai effectué des recherches plus larges, et je n'ai pas non plus trouvé d'occurrences de .warning ou .success. Donc effectivement, pas besoin d'ajouter ces classes.
  • J'ai aussi cherché s'il y a des codes (Lua notamment) cherchant des error pour détecter si une erreur a été produite (aussi justement évoqué sur le phabricator). Cela m'a un peu surpris, mais je n'ai rien trouvé (sans être sûr à 100 %). Bon… tant mieux.
  • Je suis d'avis à ajouter le .error dans Mobile.css.
  • T281228 a réintroduit une règle .mw-parser-output .error… Du coup, l'idéal serait d'éliminer les .error qui seraient présents en dehors du .mw-parser-output (typiquement, les messages systèmes), selon le phabricator à remplacer par .messagebox, .errorboxetc. On pourrait ensuite retirer notre règle du Common.css, et modifier cele du Mobile.css en .mw-parser-output .error.
od†n ↗blah 13 mai 2021 à 08:32 (CEST)
Pour l'instant, en cherchant sur le namespace MediaWiki tout ce que j'ai trouvé c'est quelques javascripts/css, par exemple (non exhaustif) le gadget accessibilité (mais ces .acc_attr_show .error se trouvent dans le .mw-parser-output), du code LiveRC (pas étudié davantage) ou encore le gadget RefJournalArticle (là celui-ci est effectivement à traiter). od†n ↗blah 13 mai 2021 à 08:49 (CEST)
Si ça reste défini dans .mw-parser-output, les conséquences devraient être assez minimes. J'ai retiré le code de MediaWiki:Common.css et on pourra toujours corriger plus tard.
Après vérification, la classe n'existe toujours pas sur mobile, donc la question de le mettre dans MediaWiki:Mobile.css se pose quand même (là, il s'agirait de corriger MediaWiki).
La classe était utilisée dans MediaWiki:Articleexists, mais ce n'était pas indispensable.
Le fonctionnement de RefJournalArticle est assez obscur. Ça affiche un bouton dans la barre d'outil d'édition. Le bouton affiche une zone de saisie et un bouton "OK" qui ouvre une fenêtre sur api.labs.crossref.org, qui ne semble plus marcher (la racine du serveur affiche une page "It works"). Je pense qu'il n'y a rien à récupérer.
Orlodrim (discuter) 13 mai 2021 à 22:10 (CEST)
Je devine bien pourquoi ce n'est pas dans le CSS Mobile de MediaWiki… pour le CSS Desktop c'est dans du code intitulé "legacy", donc au moment de la création de l'interface Mobile ils se sont dit qu'ils n'allaient pas remettre les codes "legacy". Et si ensuite il s'avère que les codes sont encore nécessaires, il y a une sorte de jurisprudence et il est difficile de faire admettre qu'il faut remettre en place ces codes, tant que les autres solutions en projet n'ont pas été mises en œuvre. Je ne me souviens plus à quelle occasion, mais j'ai déjà eu le coup.
Aussi j'ai quand même traité le gadget RefJournalArticle, à toutes fins utiles (c'est-à-dire pas grand chose).
od†n ↗blah 15 mai 2021 à 13:49 (CEST)
J'ai peut-être juste testé trop tôt. Il y a deux changements liés à phab:T281228. Le premier ajoute la règle .mw-parser-output .error et il est déjà actif sur la version bureau. L'autre semble faire quelque chose pour la version mobile. Orlodrim (discuter) 15 mai 2021 à 14:16 (CEST)
Bien vu ! Donc du coup, il semblerait que ça soit tout bon, il ne nous reste rien à faire. od†n ↗blah 15 mai 2021 à 22:48 (CEST)

Fonctions pour obtenir un token[modifier le code]

Enregistré sur Phabricator
Tâche 280806

Bonjour,

D'après ce message, les anciennes méthodes pour obtenir un token vont être supprimées « bientôt » ou « maintenant » (c'est pas très précis).

Il y a de nombreuses pages concernées, dont quelques gadgets, surtout avec intoken.

Orlodrim (discuter) 5 juin 2021 à 12:22 (CEST)

J'ai mis à jour les gadgets de l'espace MediaWiki (j'espère n'avoir pas trop cassé LiveRC, je ne sais même pas comment déclencher les extensions que j'ai mises à jour).
Pour l'espace utilisateur, Utilisateur:Hexabot/botclasses.php est un code de bot qui utilise à la fois intoken et rvtoken (Notification Hexasoft).
Le reste n'utilise que intoken. Utilisateur:0x010C/script/editlib.js semble être le script plus critique.
Orlodrim (discuter) 11 juin 2021 à 22:42 (CEST)
Utilisateur:0x010C/script/editlib.js est maintenant à jour.
Je notifie les utilisateurs encore actifs dont l'un des scripts semble concerné :
En résumé : ces scripts utilisent intoken=edit dans les requêtes à l'API MediaWiki. Ce paramètre est obsolète et va cesser de fonctionner prochainement.
À la place, vous pouvez :
  • remplacer le paramètre par action=query&meta=tokens&type=csrf (+ &curtimestamp=true si vous avez besoin d'une valeur pour remplir starttimestamp dans une requête d'édition), comme dans cet exemple) ;
  • utiliser mw.user.tokens.get('csrfToken') pour obtenir directement un token, à condition de charger le module mediawiki.user ;
  • utiliser les fonctions de plus haut niveau disponibles dans mw.Api, comme edit ou postWithEditToken.
Orlodrim (discuter) 12 juin 2021 à 18:32 (CEST)
Fait pour ma page VarminUn problème? 12 juin 2021 à 20:25 (CEST)
J'y comprends rien. Une bonne âme pour corriger ce qui doit l'être dans mon cas? - Simon Villeneuve 14 juin 2021 à 12:26 (CEST)
Bonjour ! Je ne comprends pas non plus. Quelqu'un dispo pour m'expliquer que faire ou me le faire ? Merci Clin d'œil. — Tarkuhal 14 juin 2021 à 14:44 (CEST)
Notification Simon Villeneuve : Utilisateur:Simon Villeneuve/AWB.js semble être une copie modifiée de en:User:Joeytje50/JWB.js. Ton propre common.js charge directement la version originale, donc il n'a peut-être jamais été utilisé. Dans ce cas, tu peux ignorer mon message (et éventuellement en demander la suppression). S'il est encore utilisé d'une façon que je n'ai pas vue, le plus simple serait de le mettre à jour à partir de la dernière version de en:User:Joeytje50/JWB.js, qui n'utilise plus la fonction API obsolète.
Notification Tarkuhal : Apparemment, tu as copié toute une extension de LiveRC (MediaWiki:Gadget-LiveRC.js/Extensions/MarkQuestionableExtension.js) vers Utilisateur:Tarkuhal/common.js. Cette extension sert à gérer les modifications marquées comme douteuses directement depuis LiveRC. Je vois qu'en fait, personne n'a modifié la page des modifications à relire avec cette extension depuis 2015 ! J'imagine donc qu'elle ne t'est pas très utile. Tu devrais enlever tout le code à partir du bloc "LiveRC" en ASCII art (ligne 259).
Orlodrim (discuter) 14 juin 2021 à 23:47 (CEST)