Discussion Projet:Scripts et gadgets/Liste des fonctions disponibles

Pages de documentation

Je ne suis pas sûr qu'il soit utile de laisser des liens rouges du type Projet:JavaScript/Notices/PersoLiens pour la documentation d'un script utilisateur comme Utilisateur:Chphe/PersoLiens.js. Selon moi, les liens Projet:JavaScript/Notices/XXX doivent être réservés à la doc. des gadgets. Un script développé en espace personnel a plus intérêt à garder sa doc à proximité qu'à la placer dans l'espace projet. --CH_ristoPHE _(d) 29 octobre 2009 à 23:11 (CET)

Certes, mais la plupart du temps (ça peut devenir la règle), la page est une redirection vers la page utilisateur en question (cf mes propres scripts pour lesquels il existe une doc).

Pour les cas où il n'y a pas du tout de doc, tel que l'exemple que tu donnes, il serait quand même bien de créer une doc (après avoir prévenu l'auteur, quand même). Si celui-ci n'a pas envie ou pas le temps de faire la doc dans son espace personnel, on la fait dans l'espace projet, quitte à renommer la page pour la placer dans l'espace utilisateur si tel est le souhait de l'auteur. Il sera toujours possible, si le script devient un gadget, d'inverser la redirection.

L'essentiel est d'arriver à avoir une documentation minimum pour chaque script, et le fait de les avoir toutes en sous-pages de Projet:Javascript/Notices/ (même si ce sont des redirects) est quand même préférable pour les retrouver facilement, plutôt que de les avoir à droite à gauche, dispersées dans plusieurs espaces de noms. ⇨ Dr Brains ^{∞ Doléances ∞} 30 octobre 2009 à 00:27 (CET)

Dans le cas où la doc existe déjà en page utilisateur, pas de problème pour placer un lien dans le tableau (bien au contraire). Par contre je ne vois pas trop l'intérêt de créer une page Projet:Javascript/Notices/XXX pour faire une redirection. Si le lien original est dans le tableau, c'est suffisant pour accéder à la doc. Je tiens beaucoup (comme tu as dû le remarquer) à une séparation nette entre la partie "pseudo-officielle" (espace Projet:) et la partie "utilisateur" (espace Utilisateur:), alors une redirection inter-espace projet->Utilisateur... mouaih.

Dans le cas où cette doc n'existe pas, voir ma réponse dans la section suivante. Un point à ce sujet est que la doc devrait se trouver dans la mesure du possible dans l'espace utilisateur. --CH_ristoPHE _(d) 30 octobre 2009 à 22:42 (CET)

Scripts utilisateurs

Ce qui me gêne dans l'ajout "automatique" de scripts utilisateurs, c'est la possibilité de voir figurer dans cette liste des scripts qui ne sont plus maintenus ou des scripts dont les auteurs n'ont pas spécialement envie d'assurer le service après-vente. Il y a aussi le cas où un utilisateur pourrait modifier à tout va un script qu'il pense être seul à utiliser alors que ce n'est pas le cas vu son "officialisation" dans le projet JavaScript. C'est pour ça que je préfère lui laisser l'initiative de l'ajout (indépendamment des questions de licences qui ici n'entrent pas en jeu). --CH_ristoPHE _(d) 29 octobre 2009 à 23:53 (CET)

Je comprends ta réticence et je ne peux que souscrire à tes arguments. Je trouve cependant dommage de se passer de scripts qui pourraient être utiles. Une solution serait de demander à chacun des auteurs si il souhaite que son script soit listé, mais l'ennui c'est que certains sont en wikibreak plus ou moins long.

La solution que j'entrevois pour de tels cas (voire pour tous) ce serait de ne pas donner le lien vers la page .js (qui peut effectivement être modifiée sans préavis) et fournir à la place (dans une page qui serait incluse dans la documentation ou dans une page .js de l'espace Projet:JavaScript) un code source dont on est sûr qu'il ne présente pas de problème (page qui serait ensuite protégée contre les vandalismes éventuels).

Qu'en penses-tu ? ⇨ Dr Brains ^{∞ Doléances ∞} 30 octobre 2009 à 00:27 (CET)

Je pense qu'on est d'accord ; je vois plusieurs cas que je vais tenter de lister. L'idée est avant tout d'une part de ne forcer la main de personne (les auteurs), d'autre part de proposer une liste de scripts en bon état et accessibles pour une maintenance (les utilisateurs):

1. L'auteur est actif, on lui demande, s'il accepte de donner une visibilité à son script par un lien dans la liste du projet.
   1. il accepte sans problème. Si la doc n'existe pas, ça ne devrait pas poser de problème de l'écrire (si possible dans sa page utilisateur). Il est prévenu qu'il risque d'être sollicité pour diverses questions concernant son script et qu'il ne doit plus le modifier à tout va, bref, qu'il va rentrer dans le monde merveilleux du service après-vente.
   2. il refuse ou il accepte sans vouloir les inconvénients cités ci-dessus. Son script, si on persiste à vouloir lui donner une visibilité, demande donc à être hébergé ailleurs : cf. le cas "sans ami" plus bas.
2. l'auteur est inactif, il ne répond pas :
   1. son script est fonctionnel, a priori il semble assez stable aux changements du logiciel mediawiki (bref, il ne demandera pas d'entretien), et voire même une doc est présente : on peut prendre le risque de lier son script dans le tableau (en prévenant les utilisateurs de l'inactivité du créateur). S'il revient, il aura de toute façon un message sur sa PdD et on retombe sur les cas 1.
   2. son script demande ou risque de demander du travail (-> problème de la maintenance), on le considère comme un script "sans ami".

Un script sans ami (désolé, je n'ai pas trouvé de meilleure appelation) est un script à la recherche d'un meilleur hébergement. C'est à dire qu'on va le recopier à un endroit où son entretien sera plus assuré. Je vois trois possibilités, qui recouvrent plus ou moins ta solution) :

1. il va dans l'espace MediaWiki, sans spécialement devenir un gadget listé dans les préférences : il s'agit surtout dans le mettre dans un espace protégé ;
2. un utilisateur l'héberge dans son espace utilisateur (espace protégé) : équivalent du cas 1.1 ;
3. son code, s'il est petit, est recopié dans une sous-page du projet JavaScript, mais une page normale, pas en .js. L'idée est qu'un utilisateur intéressé devra recopier le code dans son monobook à la place d'utiliser un obtenir("..."), LoadJs("..."), etc. Ce serait une seule sous-page pour tout ces scripts (en gros, une section de la page = script + doc). Même si cette page n'est pas protégée, le risque est amoindri : une seule page à surveiller, et l'impact d'une modification pour l'utilisateur sera beaucoup moins direct... Cette solution me semble idéale pour les scripts de quelques lignes (par ex. désactivation de l'affichage d'un élément) qu'il vaut mieux recopier in extenso dans son monobook. Elle peut même avoir un côté éducatif en réunissant en un seul endroit des exemples simples de code JavaScript.

Mais bon, tout ça n'est encore que du concept. A voir à l'épreuve du feu. --CH_ristoPHE _(d) 30 octobre 2009 à 22:42 (CET)

OK avec ton analyse. Reste à faire la liste des gens à contacter, mais en fait, il y en a pas tant que ça :

• Delhovlyn (d · c · b), Zelda (d · c · b), toi, et moi (pour les scripts listés actuellement)
• quelques codes de Dake (d · c · b), Seb35 (d · c · b) et GôTô (d · c · b) dans Aide:Monobook/Fonctions avancées qui ne sont pas encore listés
• + le fameux système de messagerie de Céréales Killer (d · c · b) créé par GôTô (d · c · b)
• je ne compte pas LiveRC qui est un cas à part.

Ne pourrait-on pas considérer, même si l'auteur accepte de jouer le jeu, que le script est sans ami (orphelin ?) et devrait être hébergé ailleurs que dans son espace perso ?

Pas seulement à cause du service après-vente à fournir, mais aussi parce que c'est amha plutôt embêtant d'avoir une page personnelle "bloquée".

En définitive, l'auteur garderait "chez lui" sa version perso, considérée "en développement", et on fournirait sur le projet une version "stable" avec documentation.

L'auteur est bien sûr libre (encouragé même) de participer à tout ça, et dans tout les cas, il devrait au minimum être prévenu que le projet "s'approprie" son script.

⇨ Dr Brains ^{∞ Doléances ∞} 31 octobre 2009 à 00:23 (CET)

Je préfère laisser le script dans la page utilisateur, sauf avis contraire de l'auteur. C'est plus simple ainsi pour maintenir le script : l'auteur corrige son script et la correction est immédiatement disponible (pas besoin de maintenir en parallèle 2 versions). Même s'il n'arrive pas à le corriger, on peut lui indiquer l'erreur et la correction à apporter. S'il s'agit d'un script dans une page protégée, il faut trouver un admin dispo pour le corriger, un admin qui doit avoir quelques notions de JavaScript puisqu'il prend en quelque sorte la responsabilité de la modification : pas toujours facile d'avoir une rapide correction par ce biais. Et oui, si l'auteur est actif, sa page personnelle est moins "bloquée" qu'une page de MediaWiki. C'est pour ça que j'aurai des réticences à placer certains de mes scripts (principalement les plus récents et les usines à gaz du type SuiviCat) dans un espace où je ne peux plus intervenir. --CH_ristoPHE _(d) 31 octobre 2009 à 10:00 (CET)

OK, mais dans le cas où l'auteur est inactif, ça revient au même que si le script était dans l'espace MediaWiki, puisqu'il faut également trouver un admin pour faire la correction (ou attendre que l'auteur revienne).

Je suppose que le mieux est finalement de contacter les auteurs concernés en suivant ce que tu écrivais plus haut.

Quand je parlais de "bloqué", je ne parlais pas du niveau de protection mais du fait que le script étant utilisé par d'autres que moi, je ne peux plus le modifier comme je le souhaite, faire des tests, ajouter/supprimer des fonctionnalités, etc... Faut voir ça au cas par cas, mais pour ma part je préfère fournir un code source et déconseiller au gens de lier leur monobook à un de mes scripts perso (ou alors à une version archivée).

⇨ Dr Brains ^{∞ Doléances ∞} 31 octobre 2009 à 14:15 (CET)

Importation

J'ai changé loadJS par importScript d'après la recommandation de MediaWiki:Common.js. Par contre, ça lie à la dernière version. Lier une version archivée est préférable pour éviter les surprises. Je vais voir si c'est possible avec cette fonction (a priori oui).

Tu as raison pour le importScript.

J'ai bien indiqué que ça lie à la dernière version. Si on fait confiance à l'auteur, c'est le meilleur choix, vu qu'il permet de garder un script à jour. Avec l'avertissement au-dessus et les alternatives plus sécurisées (mais pas complètement) en dessous, je préfère laisser à l'utilisateur le choix.

Maintenant, on peut imaginer une colonne supplémentaire dans la liste pour indiquer la version du script recommandée par l'auteur.--CH_ristoPHE _(d) 31 octobre 2009 à 14:54 (CET)

Extrait de /skins-1.5/common/wikibits.js?urid=243z2_1254880607 :

function importScript(page) {
 // TODO: might want to introduce a utility function to match wfUrlencode() in PHP var uri = wgScript + '?title=' +
 encodeURIComponent(page.replace(/ /g,'_')).replace(/%2F/ig,'/').replace(/%3A/ig,':') +
 '&action=raw&ctype=text/javascript';
 return importScriptURI(uri);
} 

var loadedScripts = {}; // included-scripts tracker
function importScriptURI(url) {
 if (loadedScripts[url]) {
 return null;
 }
 loadedScripts[url] = true;
 var s = document.createElement('script');
 s.setAttribute('src',url);
 s.setAttribute('type','text/javascript');
 document.getElementsByTagName('head')[0].appendChild(s);
 return s;
}

Il semblerait que

importScript('Utilisateur:MACHIN/SCRIPT.js&oldid=REVISION');

puisse marcher. (peut-être un problème avec les caractères & et =, à voir). ⇨ Dr Brains ^{∞ Doléances ∞} 31 octobre 2009 à 14:55 (CET)

Bon, ben effectivement, ça marche pas... ⇨ Dr Brains ^{∞ Doléances ∞} 31 octobre 2009 à 15:03 (CET)

Colonne "auteurs" des gadgets

De ma grande (hum) expérience de débug de gagdet, l'identité des auteurs d'un script n'a pas une très grande utilité. Quand on veut corriger le script, on le lit, on trouve le problème, on le corrige. Et comme ça fait gagner une colonne, donc donne une meilleure lisibilité à la page... --CH_ristoPHE _(d) 29 octobre 2009 à 23:53 (CET)

C'est pas faux... D'autant que l'auteur est généralement présent dans l'entête du script. Pour les autres, qui n'ont pas eu la présence d'esprit de mettre leur nom, tant pis pour eux : vu le temps que prend l'intervention sur un message système (voir ma demande pour OptimizedSuivi, toujours pas effectuée), je ne m'amuserai pas à en demander l'ajout... ⇨ Dr Brains ^{∞ Doléances ∞} 30 octobre 2009 à 00:27 (CET)

A l'aide ! Script pour modification des catégories

Je souhaite travailler sur la catégorisation du projet Aéronautique.

J'ai trouvé le gadget Projet:JavaScript/Notices/RenommageCategorie qui me semble convenir.

J'ai fait un copier-collé du texte du scrip et essayé avec le code obtenir sur ma page Utilisateur:AnTeaX/monobook.js pour avoir la fonction. Je ne vois pas apparaître l'onglet promis sur les pages catégories.

Quelqu'un peut-il me dire où je me suis planté ?

Merci.--AnTeaX (d) 19 novembre 2010 à 21:34 (CET)

Salut,

Déjà, retire le code copié-collé et ne conserve que la ligne avec « obtenir » : ça ne sert à rien d'avoir tout le code et potentiellement ça crée des conflits de nom entre ce que tu as copié et ce que tu obtiens avec « obtenir ».

Ensuite, n'es-tu pas passé sous Vector (la nouvelle interface) par hasard ? Dans ce cas c'est Utilisateur:AnTeaX/vector.js qu'il faudrait modifier à la place du monobook.js.

Sinon, as-tu bien fait ctrl+maj+f5 pour forcer le rechargement de tous les fichiers (f5 ne suffit pas) ?

Amicalement — Arkanosis ^✉ 19 novembre 2010 à 22:17 (CET)

OK, j'ai trouvé le bug, je l'ai aussi.

Alors manifestement tu dois être sous vector (pour mettre une page dans ta liste de suivi tu cliques sur une étoile, n'est-ce pas ?).

Le bug est que le lien « renommer » s'ajoute dans le menu déroulant, sauf que lorsque celui-ci est vide (et c'est le cas chez toi comme chez moi), il a une classe CSS qui le rend invisible. Donc le lien est bien présent mais dans un menu invisible.

Dr Brains n'a pas pu s'en rendre compte car il est administrateur et pour lui, il y a toujours quelque chose dans ce menu, qui est donc toujours visible.

Parade temporaire :

Lorsque tu es sur la page de la catégorie que tu veux renommer, tapes « javascript:document.getElementById('p-cactions').setAttribute('class', 'vectorMenu'); » (sans les guillemets) dans la barre d'adresse de ton navigateur. Cela fera apparaître le menu déroulant dans lequel se trouve le lien renommer.

Correctif (Dr Brains ? ) :

Simplement ajouter « 

OngletsCactions.setAttribute('class', OngletsCactions.getAttribute('class').replace('emptyPortlet', ''));

 » dans la fonction « RenommageCategorie_AddLink() », après le « if ».

Merci .

Amicalement — Arkanosis ^✉ 20 novembre 2010 à 23:11 (CET)

Ah, mais on a à notre disposition une fonction removeClass() pour faire ça plus proprement.

Ça va mieux comme ça ?

⇨ D^r Brains ^{∞ Doléances ∞} 21 novembre 2010 à 01:30 (CET)

PS : il doit y avoir pas mal d'autres scripts où ce problème se pose...

PPS : Pour signaler un bug, il est préférable d'utiliser Discussion Projet:JavaScript/Rapport de bug, pour laquelle je suis prévenu de la moindre modification par un gros bandeau orange, contrairement à celle-ci que j'ai "simplement" en liste de suivi.

⇨ D^r Brains ^{∞ Doléances ∞} 21 novembre 2010 à 01:35 (CET)

Je n'ai pas encore eu le temps de retester, mais AnTeaX me dit que c'est bon.

Merci doc — Arkanosis ^✉ 21 novembre 2010 à 22:12 (CET)

MonobookToolbarNotif

Bonjour à tous.

Sur mon bac à sable figure un script ajoutant à la barre d'outils Monobook quatre boutons pour ajouter un modèle de notification. Celui-ci est opérationnel après test et j'aimerai vous demander si vous pouvez le rajouter dans les gadgets activables dans les préférences (avec déplacement dans l'espace MediaWiki), ne sachant pas toutes les étapes.

Merci d'avance, --— Superjuju10 ^{[Aubline à votre disposition]}, le 28 février 2014 à 15:05 (CET)

Il te suffit de :

• Renommer Utilisateur:Neiluj10/BàS.js en MediaWiki:Gadget-MonobookToolbarNotif.js
• Créer MediaWiki:Gadget-MonobookToolbarNotif avec une courte phrase de présentation du gadget
• Modifier MediaWiki:Gadgets-definition et y ajouter une ligne dans la section "Boutons" (s'inspirer des lignes existantes).

⇨ D^r Brains ^{∞ Consultation ∞} 28 février 2014 à 17:14 (CET)

 Dr Brains : Bon, j'ai fais comme tu m'as dis. Le bouton apparait bien, la coche marche avec succès... mais le gadget en lui même ne démarre pas. Help me ! --— Superjuju10 ^{[Aubline à votre disposition]}, le 28 février 2014 à 19:37 (CET)

 Superjuju10 :

Réécris-le avec les mêmes fonctions que MediaWiki:Gadget-MonobookToolbarPatrouille.js, car je crois que addCustomButton() est amené à disparaître (si ce n'est déjà fait).

⇨ D^r Brains ^{∞ Consultation ∞} 28 février 2014 à 20:46 (CET)

 Dr Brains : Je l'avais déjà testé. Sans succès... --— Superjuju10 ^{[Aubline à votre disposition]}, le 28 février 2014 à 20:59 (CET)

 Superjuju10 :

Chez moi ça marche (mais les boutons sont moches).

Peut-être est-ce à cause de la toolbar "améliorée".

As-tu essayé en sélectionnant aussi ForceMonobookToolbar ?

⇨ D^r Brains ^{∞ Consultation ∞} 28 février 2014 à 22:28 (CET)

 Dr Brains : J'ai forcé le nettoyage complet du cache de mes navigateurs, à coup notamment de CCleaner. Enfin je suis sur que le script marche ! Mais je ne te dis pas l'agacement que j'ai réussit à avoir.... En même temps, pour quelqu'un qui prend les choses trop à cœur ^^

Bien à toi, --— Superjuju10 ^{[Aubline à votre disposition]}, le 28 février 2014 à 23:50 (CET)

Comment qu'on installe ?

Bonjour,

J'arrive de Projet:Scripts et gadgets/Notices/QPreview, je suis passé par Projet:Scripts et gadgets, et maintenant sur cette page je ne trouve pas QPreview. Comment activer le gadget ? Un lieu direct eût été plus pratique, mais comme je ne trouve pas, je ne peux pas le créer. Merci pour votre aide ! — Vega (discuter) 9 juin 2020 à 11:50 (CEST)