Discussion MediaWiki:Common.js

Personnaliser l'interface

Données clés

Aide • Exemples

Fonctions avancées

Apparence Vector

Apparence Timeless

Projet:Scripts et gadgets

(en) User styles

CSS

common.css personnel

Common.css commun

Monobook.css commun

Vector.css commun

(en) Catalogue of classes

Index des propriétés CSS2

JavaScript

common.js personnel

Common.js commun

Fonctions JavaScript

Cliquez ici pour purger le cache

Archives

archives 2004 - 2008

Utilisation de common.js v. pages spécifiques

Bonjour,

je suis un peu surpris par ces différents ajouts à Common.js, dans la mesure où il s'agit de gadgets ou d'outils spécifiques (sauf erreur de ma part). Pourrait-on détailler ici les raisons (liées à des questions d'optimisation, je suppose). --Lgd (d) 1 février 2009 à 10:19 (CET)

Salut Lgd,

Pour la partie du bouton modifier, je pense qu'elle a plus sa place sur MediaWiki:Monobook.js, vu que c'est spécifique à cette skin.

Pour la fonction setCookie, elle est pratique pour plein de scripts et sa place me semble bien ici.

Pour le reste, je ne me prononce pas. Plyd /!\ 1 février 2009 à 13:37 (CET)

Chalut (conflit dédit, ça m'apprendra a faire plusieurs choses àla fois)

pour ceux qui me concernent ( get_editcounts, CreateAdressNode ), ils sont utilisés dans plusieurs gadgets, donc c'est de la factorisation de code.

• CreateAdresseNode est prévu pour être réutilisable par n'importe quel script
• setCookie n'est pas encore utilisé et est une générisation de celui utilisé pour la page d'acceuil (stockage de l'info de l'état deplié/replié des cases). Je compte m'en servir pour autoriser un système similaire sur les portails et projets (quand j'aurai le temps)

- DarkoNeko ^{(にゃ? )} 2 février 2009 à 02:18 (CET)

j'utilise setCookie pour le projet poster, j'ai trouvé le script très utile :) Plyd /!\ 2 février 2009 à 07:56 (CET)

wow, cool ^^ - DarkoNeko ^{(にゃ? )} 3 février 2009 à 01:02 (CET)

Alert javascript

Mon Firebug me détecte parfois l'erreur

Tables[i].getElementsByTagName("tr")[0] is undefine
var Header = Tables[i].getElementsByTagName( "tr" )[0].getElementsByTagName( "th" )[0];

Cette ligne est utilisé dans la fonction createCollapseButtons

@++ -- Xfigpower (pssst) 23 juin 2009 à 16:44 (CEST)

Ce script serait à revoir entièrement, notamment pour l'usage erroné qu'il fait de l'élément TH des tableaux (les boîtes déroulantes ne devraient en fait pas utiliser de tableaux de mise en forme, ou être indifférentes au balisage utilisé, c'est à dire passer par des ID et non les éléments, ou au minimum ne pas imposer la présence d'un TH impropre). --Lgd (d) 24 juin 2009 à 07:41 (CEST)

Bug entre la mise en page de tableau et le javascript

(discussion déplacée depuis le bistro)

Bonsoir,

Je viens de modifier le paramétrage de l'infobox dans Gouvernement Jean-Pierre Raffarin (3), de façon à utiliser la présentation avec la chronologie tout en bas de la boîte. Or je vois apparaitre un problème : le titre (en blanc sur fond gris) tout en haut de l'infobox n'apparait pas complètement : "Gouvernement Jean-Pierre Raffarin" se répartit sur deux lignes avec un retour à la ligne entre Jean-Pierre et Raffarin. Jusque là tout est normal, mais le problème est que la fin de "Jean-Pierre", c'est à dire le dernier "e" est caché et c'est finalement "Jean-Pierr" qui s'affiche avec, immédiatement après le "r", la barre verticale constituant le bord droit du tableau.

C'est au moment où le javascript s'enclenche que la mise en page devient défectueuse. Sans javascript il n'y a aucun problème (j'ai testé en désactivant javascript dans Firefox).

Teofilo ◯ 24 juin 2009 à 22:33 (CEST)

La mise à jour de ton navigateur (de Firefox 2 vers Firefox 3) règlera le problème (Sauf erreur de ma part, il s'agit d'un bug du navigateur et non d'un défaut du modèle, même si ce dernier a pris quelques risques en utilisant un élément - jargon: caption - dont le rendu est souvent délicat à gérer).--Lgd (d) 25 juin 2009 à 06:55 (CEST)

Firefox 3 n'est pas disponible sur toutes les versions de Windows. Je ne vois pas où figure ce "caption" dans le modèle qui parait être un tableau tout à fait ordinaire. Le problème semble être à chercher au moins autant dans le javascript que dans le modèle. Teofilo ◯ 26 juin 2009 à 10:10 (CEST)

Le caption est présent dans le modèle via son code wiki, c'est à dire |+. C'est la ligne {{!}}+ {{{nom|{{PAGENAME}}}}} de {{Gouvernement français}}.

Le bug est curieux (C'est le genre de choses qu'on rencontre plus souvent avec les anciens IE), mais franchement, à première vue, il a tout du bug de navigateur (jargon: un problème de reflow de la part de gecko, puisqu'il suffit de forcer le recalcul de la taille de caractère dans le caption via firebug, en passant par exemple de font-size-bolder à font-size:bold, pour obtenir le rendu correct).

Si quelqu'un veut chercher quelle partie de la couche javascript de wp:fr y est éventuellement associée, pourquoi pas, bien-sûr.

Mais la solution de fond est de revoir ces modèles utilisant inconsidérément un caption mis en forme de cette manière (avec bordures et largeur équivalente à celle du tableau). Accessoirement, pour avoir l'esprit tranquille, il faudrait aussi revoir certains javascripts locaux comme celui des boîtes déroulantes qui utilisent des tableaux là où ils ne sont pas nécessaires. --Lgd (d) 26 juin 2009 à 10:24 (CEST)

Eh bien merci pour toutes ces explications. J'ai donc modifié le Modèle:Gouvernement français de façon à faire disparaître ce "|+". Teofilo ◯ 26 juin 2009 à 11:47 (CEST)

redirection vers le css et le js personnalisés

Sur le bistro du 23 nov j'ai proposé d'ajouter une redirection présente sur en.wp (en:MediaWiki:Common.js). --almaghi (d) 23 novembre 2009 à 19:13 (CET)

/*
 * Description: Redirects from /User:UserName/skin.js or .css to the user's actual skin page
 * Maintainers: en:user:Cacycle, fr:user:Al Maghi, fr:user:Dr Brains
 */
if (wgArticleId == 0 && wgUserName) {
  var slash = wgPageName.indexOf('/');
  var norm = wgPageName.substr(0, slash) + wgPageName.substr(slash).toLowerCase();
  var LocalUserNamespace =  wgFormattedNamespaces[2] + ":";
  var test = LocalUserNamespace + wgUserName.replace(/ /g, '_') + '/skin.';
  var ext = null;
  if (norm == test + 'js') ext = 'js';
  else if (norm == test + 'css') ext = 'css';
  if (ext != null) window.location.href = window.location.href.replace(/\/skin.(css|js)/i, '/' + skin + '.' + ext);
}

Je ne suis pas convaincu que ça soit une bonne idée. On peut vouloir customiser différement monobook et vector, et donc ne pas vouloir du CSS/js de l'un dans l'autre. - DarkoNeko ^{(にゃ? )} 23 novembre 2009 à 21:13 (CET)

ça ne me paraît pas valoir le coup non plus...

je préfèrerais un vrai common.js common.css perso. Plyd /!\ 23 novembre 2009 à 21:49 (CET)

Je crois qu'il y a mécompréhension, il s'agit d'une fonction redirigeant l'utilisateur de la page spécial:ma Page/skin.js vers ses CSS/JavaScript personnalisés. Je vous renvoie également aux explications de Dr Brains sur le bistro du 23 nov ou à en:mediawiki talk:common.js.

Ou je n'ai pas compris les critiques ? --almaghi (d) 23 novembre 2009 à 23:56 (CET)

Je trouve de mon côté que cela ne vaut pas le coup de rajouter cette fonction dans common.js pour ce à quoi elle sert.

Il y a des pages d'aide à améliorer, sinon (sur le monobook), ce qui pallierait à l'ajout de ceci ici.

Puis, quand quelqu'un touche au monobook perso, c'est qu'il sait déjà de quoi il parle. — Steƒ ^๏̯͡๏ 24 novembre 2009 à 06:28 (CET)

Common.js sur .fr : 52.7Ko. Common.js sur .en : 18.2Ko.

Ce ne sont que deux chiffres très rapides et synthétiques, mais .fr peut manifestement faire mieux avec moins de scripts de micro-détail à (très) faible valeur ajoutée. --Temesis (d) 25 novembre 2009 à 07:52 (CET)

Ton argument ne vaut pas grand chose : le système de cache fait que les CSS/js n'ont pas à être rechargés à chaque affichage d'une page. Et au passage, de nombreux morceaux du javascript d'enwiki sont appelés depuis common.js mais stockés dans des sous pages : en:MediaWiki:Common.js/edit.js, en:MediaWiki:Common.js/watchlist.js, en:MediaWiki:Common.js/file.js, ... dont la taille n'a pas été prise en compte dans ton chiffre. DarkoNeko 25 novembre 2009 à 21:53 (CET)

Ce n'était pas un argument, mais une remarque d'ailleurs trop allusive, puisque vous ne semblez pas l'avoir comprise. La question visée n'est pas celle des performances (requêtes, bande passante, temps de téléchargement, d'exécution et d'affichage etc.) qui ne se pose évidemment pas de manière aussi simpliste (et surtout pas sans tenir compte de la compression des scripts, notamment).

Ces deux chiffres ne font qu'illustrer un constat aisé à faire ici: wp:fr a un goût particulièrement prononcé pour l'accumulation désordonnée de fonctions javascript à la valeur ajoutée incertaine, le plus souvent en remplacement de développements de fond (certainement plus longs à obtenir). --Temesis (d) 26 novembre 2009 à 06:34 (CET)

@Temesis: pourrais-tu indiquer les fonctions à la valeur ajoutée quasi-nulle, afin que soit rediscuté leur pertinence et qu'un admin les supprime si elles ne sont plus pertinentes anymore ?

@temesis: bugzilla:6908. Cette solution JS est en attendant une meilleure solution. Tu sais que MW est libre et que tu peux participer à son dev "de fond" ? en espérant te croiser sur bugzilla, almaghi (d) 26 novembre 2009 à 22:57 (CET)

@almaghi : En gros, ce qui intéresse Temesis, c'est l'interaction avec les rédacteurs, et pas le développement de MediaWiki. Bien à toi, Dodoïste ^{[ dring-dring ]} 26 novembre 2009 à 23:52 (CET)

SVG images: adds links to rendered PNG images in different resolutions

Sorry for writing in English, but is it easier for me in this case: Many users are not familiar with using SVG images available on Wikipedia/Commons in office applications, etc. This is particularly true, if the base size is small (example). Therefore, I suggest adding links to rendered PNG images in different resolutions to the file description page (see same example in en.wikipedia). The script was first implemented on Commons and in de-wikipedia, then in en.wikipedia. I originally had the idea, Commons:User:Slomox did the coding and en:User:TheDJ made some refinements. It is available at en:MediaWiki:Common.js/file.js. --Leyo 13 novembre 2010 à 01:43 (CET)

(traduction du message ci-dessus) Beaucoup d'utilisateurs ne sont pas accoutumés aux images SVG que l'on rencontre sur Wikipedia/Commons, pour l'utilisation de celles-ci avec leurs logiciels de bureautique, etc. Ceci est d'autant plus vrai si la taille de départ est petite (exemple). Aussi, je propose d'ajouter sur la page de description de l'image des liens vers des rendus en PNG dans plusieurs résolutions (voir le même exemple sur le wiki en). Le script effectuant cela a été implémenté d'abord sur Commons et le wiki de, puis ensuite sur le wiki en. L'idée vient de moi, Commons:User:Slomox a écrit le code et en:User:TheDJ a fait quelques corrections. Le script est disponible sur en:MediaWiki:Common.js/file.js.  – od†n ^{[dead words]} 16 novembre 2010 à 21:39 (CET)

Si c'est implémenté sur Commons, cela devrait suffire. Pas fasciné par la multiplication des javascripts (donc client) là où c'est le back-office qui devrait être amélioré. Cordialement, --Lgd (d) 18 novembre 2010 à 11:24 (CET)

Il y a aussi des images SVG sur fr.wikipedia. --Leyo 18 novembre 2010 à 14:43 (CET)

Bug avec Firefox

Bonjour, quand on installe le module de Firefox "Corrector para Português Europeu", le site devient inaccessible en lecture : 400 bad request. Alors que cela fonctionne sur fr.wikt et en.w (voilà pourquoi je le poste ici et non sur Bugzilla). JackPotte ($♠) 2 décembre 2010 à 00:03 (CET)

Je n'ai pas réussi à reproduire le problème, pourrais-tu nous donner plus d'informations ? od†n ^{[dead words]} 2 décembre 2010 à 03:01 (CET)

Je n'ai que Firefox 3.5.3 avec "Check for updates" grisé, ça doit venir de ça. JackPotte ($♠) 2 décembre 2010 à 05:28 (CET)

Pas réussi non plus à reproduire avec Fx 3.5.3. À propos cette version est archi obsolète, elle a plus d'un an, tu devrais songer à mettre à jour. Il faudrait plus de détails, par exemple l'URL qui retourne l'erreur 400. od†n ^{[dead words]} 2 décembre 2010 à 06:54 (CET)

N'ayant pas les droits sur les fichiers de la 3.5.3, j'ai installé la 3.6.12 à côté, et j'ai le même problème :

Bad Request Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit. Cookie: frwikiUserID=390290; frwikiUserName=JackPotte; centralauth_LoggedOut=20101201223355; centralauth_User=JackPotte; centralauth_Token=****; hidesnmessage=1; botsDeluxeHistory=(...); sysopsDeluxeHistory=(...)

Sauf que quand j'ai désinstallé le dictionnaire de portugais cette fois, cela a persisté (j'écris maintenant avec IE). JackPotte ($♠) 2 décembre 2010 à 07:34 (CET)

À tout hasard, en désactivant le gadget DeluxeHistory ça donne quoi ? od†n ^{[dead words]} 2 décembre 2010 à 07:59 (CET)

Je referai le test sur ce PC plus tard, pour l'instant je suis avec le mien et tout fonctionne avec "DeluxeHistory" + "Corrector para Português Europeu". JackPotte ($♠) 2 décembre 2010 à 09:39 (CET)

En mode déconnecté nous n'avons pas le gadget DeluxeHistory, après reboot du PC j'ai toujours le bug, après effacement de tout l'historique Firefox c'est résolu . JackPotte ($♠) 4 décembre 2010 à 15:53 (CET)

Catégories cachées en small

Sur Commons, les catégories cachées sont en small. J'aime bien cette idée, d'autant que Wikipédia en français fait un usage important de ces catégories, notamment du fait des catégories d'articles liés. Quelqu'un peut-il donc passer nos propres catégories cachées en small, ce qui aura le mérite de rendre moins rébarbatif les pieds de page quand on les affiche ? Thierry Caro (d) 7 décembre 2010 à 10:21 (CET)

Il suffit d'éditer Mediawiki:Common.css et d'y ajouter :

.mw-hidden-cat-user-shown {
    font-size:XX%;
}

Reste à déterminer la valeur de XX

⇨ D^r Brains ^{∞ Doléances ∞} 7 décembre 2010 à 10:26 (CET)

PS : Voir peut-être sur WP:DIMS pour récolter plus d'avis.

OK. Thierry Caro (d) 7 décembre 2010 à 12:30 (CET)

Liste des moteurs de recherche

Sur Spécial:Recherche on voit une liste de moteur de recherche. Il semble qu'à l'origine ces recommandation ont été faites en raison de la piètre qualité du moteur de recherche interne. Il est devenu beaucoup plus performant, au point que en:Special:Search n'en présente plus aucun.Dachary 18 février 2011.

Il faut aussi noter que la recommendation de moteurs de recherches propriétaires sur une page centrale de wikipedia (elle apparait à chaque recherche) crée une dépendance de l'utilisateur à une technologie qui ne peut pas être reproduite dans les mêmes conditions que wikipedia. S'il se trouve que ces moteurs sont peu utilisés, alors les supprimer ne devrait pas poser de problème.S'il se trouve au contraire qu'ils sont très utilisés, cela signifie que les utilisateurs de wikipedia sont fortement dépendants d'une technologie propriétaire.Certes, le contenu de wikipedia importe plus que les outils qui servent à le manipuler. Mais que serait wikipedia si mediawiki était propriétaire ? Nous sommes encore loin du temps ou il existera un format universel pour stocker les informations de wikipedia. Lorsque ce temps arrivera l'utilisateur aura la choix entre plusieurs logiciels. Actuellement il n'a pas d'alternative : il s'habitue au chemin utilisateur que lui présente wikipedia et dépend donc de façon exclusive des logiciels qui lui permettent d'emprunter ce chemin. Dachary 18 février 2011.

Euh déjà, moi sur Spécial:Recherche, je ne vois aucune liste de moteur de recherche…

Juste sous le champ de saisie du critère de recherche, il y a des radio bouttons qui permettent de lancer la rechreche sur plusieurs moteurs de recherche — Le message qui précède, non signé, a été déposé par Dachary (discuter)

De toute façon, le moteur interne suffisant largement la plupart du temps, je ne vois pas de raison de proposer un autre moteur (libre ou pas d’ailleurs).

Ensuite, le but d'un moteur de recherche est de fournir les résultats d’une recherche. Évidemment, il serait mieux de promouvoir un moteur libre (et open source, et qui fait le café, et qui sauve les petits enfants en Afrique, etc.) mais cela ne doit pas surtout pas se faire au détriment de la performance desdits résultats.

En suivant cette logique (performances avant l'indépendance) wikipedia.org utiliserait de nombreux logiciels propriétaires (sauf a penser que mediawiki est un logiciel parfait qui surclasse tous les autres). Mais ce n'est pas le cas et cela deḿontre mieux que tout argumentaire que la priorité est donnée au logiciels libres, même si leurs fonctionalités sont inférieures.— Le message qui précède, non signé, a été déposé par Dachary (discuter)

Enfin, je ne vois pas bien ce que cette question fait ici sur cette page.

La liste des moteurs propriétaires de la page Spécial:Recherche est dans le script Common.js— Le message qui précède, non signé, a été déposé par Dachary (discuter)

Cdlt, Vigneron * ^discut. 18 février 2011 à 23:16 (CET)

Faire de l'ajout de cette liste de moteurs externes un gadget activable selon le souhait de chacun plutôt qu'un comportement par défaut serait simple. Mais il serait tout aussi beaucoup plus simple de laisser ceux que cela gêne désactiver ce comportement : cela nécessitera en effet que beaucoup moins de gens aient à modifier leur configuration .

Pour désactiver ce comportement dans l'immédiat : ajoutez la ligne suivante dans votre common.js personnel :

SpecialSearchEnhanced2Disabled = true;

Cordialement, --Lgd (d) 27 février 2011 à 10:27 (CET)

Pour info, je viens de supprimer cette option car personne ne l'utilisait, et surtout, le script a depuis lors été transformé en gadget (activé par défaut), donc désactivable via les préférences. od†n ↗^blah 27 décembre 2017 à 16:51 (CET)

redirectedFromArticle

Explication de [1] : cette fonction permettait d'exécuter du code javascript arbitraire en créant un simple lien externe. J'ai ajouté un htmlize() qui ne devrait rien changer pour une utilisation normale de la fonction. Orlodrim ^[discuter] 22 mai 2011 à 01:01 (CEST)

Dans le doute tu as eu raison d'ajouter cela, mais mediawiki traite déjà les ancres spécialement pour éviter ce genre de problème, le lien final est bien externe mais ce fait via un lien interne où les données sont passé dans une ancre et récupérés par window.location.hash. L'utilisation de window.location.hash procure aussi un deuxième niveau de protection, < n'est pas un caractère valide dans les ancres. (Je vais aussi supprimer ce code après avoir nettoyé à droite et à gauche) - phe 22 mai 2011 à 14:12 (CEST)

Il est plus prudent de considérer qu'on ne peut faire aucune hypothèse sur une chaîne extraite du document ou de son URL. Dans ce cas précis, avant la correction, cliquer sur un lien comme celui-ci provoquait l'exécution du script. Orlodrim ^[discuter] 22 mai 2011 à 14:20 (CEST)

Ouch. - phe 22 mai 2011 à 14:39 (CEST)

Secure.js

Message du comte Ɲemoi – Nous avons une section :

/**
 * Lien vers secure.wikimedia.org quand on y est déjà.
 * Repris depuis enwiki.
 */
if ( mw.config.get( 'wgServer' ) == 'https://secure.wikimedia.org' ) {
    importScript( 'MediaWiki:Common.js/secure.js' );
}

qui me semble assez peu utile, depuis que le serveur sécurisé est https://fr.wikipedia.org/.

Les anglophones ont quand à eux une section :

/**
 * Description: Stay on the secure server as much as possible
 * Maintainers: [[User:TheDJ]]
 */
if ( mw.config.get('wgServer') == 'https://secure.wikimedia.org' ) {
    /* Old secure server */
    importScript( 'MediaWiki:Common.js/secure.js');
} else if( document.location && document.location.protocol  && document.location.protocol == "https:" ) {
  /* New secure servers */
  importScript('MediaWiki:Common.js/secure new.js');
}

mais en:MediaWiki:Common.js/secure new.js est vide… Y a-t-il encore des personnes qui utilisent l’ancien serveur ? (est-ce possible, d’ailleurs ?) Ne pourrait-on pas retirer notre section, puisqu’elle est destinée à ne plus vraiment servir, et que l’on n’a pas de code de remplacement ? Ce 24 novembre 2011 à 01:24 (CET).

Euh… ce n'est pas vide pour moi .

Concernant https, je vais probablement encore bosser dessus ce week-end ; j'ai notamment deux projets de tickets pour demander :

1. que secure.wm redirige vers le nouveau schéma d'urls (on pourra du coup jeter définitivement tout le code dédié qui encombre inutilement les scripts) ;
2. l'activation d'HSTS pour que les scripts (nécessairement lents) de réécriture d'url puissent n'être activés qu'en cas de réel besoin (vieux navigateurs).

Pour répondre à tes questions :

• On peut encore utiliser l'ancien serveur, donc non, on ne vire pas tout de suite (mais le plus tôt sera le mieux).
• Je mettrai un jour ou l'autre un équivalent du script d'en, que HSTS soit déployé ou non, pour les vieux navigateurs donc àmha la section n'a pas de raison de disparaître complètement, juste d'être adaptée — du moins jusqu'à ce qu'on passe enfin en « tout https » .

Amicalement — Arkanosis ^✉ 24 novembre 2011 à 20:23 (CET)

Réponse du comte Ɲemoi – Je sais pas ce que j’avais hier, mais entre une infoboîte que j’ai cru protégée à l’édition alors qu’elle ne l’était pas, et (vraisemblablement) la recherche « MediaWiki:Common.js/secure new.js » sur :fr: au lieu de sur :en:, je devais pas être bien. Toujours est-il rattrapage aux branches que ce serait vraiment chouette d’avoir un truc fonctionnel pour gérer le https, que j’ai déjà eu une demande en ce sens, et que ça dépasse mon niveau (de pures routines) en ce langage. Amicalement, ce 24 novembre 2011 à 21:56 (CET).

Migrate WikiMiniAtlas to a default gadget

Hi!

Could someone move the code of WikiMiniAtlas to a gadget enabled by default? Specifically, this would require creating a page such as MediaWiki:Gadget-Wikiminiatlas.js with:

/**
 * WikiMiniAtlas
 *
 * voir WP:WMA 
 */
window.wma_settings = { 
  buttonImage: '//upload.wikimedia.org/wikipedia/commons/thumb/e/e9/Geographylogo.svg/18px-Geographylogo.svg.png'
}
mw.loader.load( '//meta.wikimedia.org/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400' );

This would make the MediaWiki:Gadget-AtlasOff.js obsolete and then its definition

* AtlasOff|AtlasOff.js

could be removed and replaced by the definition of the above gadget (which would make use of Resource Loader):

* Atlas[ResourceLoader]|Atlas.js

PS: Notice that the function importScriptURI which is currently used here on Common.js is deprecated and should be replaced by mw.loader.load (check out the migration guide), which is available since MW 1.17. Besides, the script from Meta-Wiki assumes that wma_settings is a global variable, and as such that should be indicated explicitly by changing var wma_settings by window.wma_settings, as in the code above. Helder 31 janvier 2012 à 12:47 (CET)

Thank you! — Arkanosis ^✉ 19 février 2012 à 18:56 (CET)

Sysop

La dernière "fonction" à la fin (Mediawiki:Sysop) n'aurait-elle pas plutôt sa place en tant que gadget réservé aux admins (activée par défaut et désactivable dans les préférences) ? — Dakdada (discuter) 20 février 2012 à 23:31 (CET)

C'est pour ça que ça rame sur mon téléphone . JackPotte ($♠) 21 février 2012 à 21:16 (CET)

L'idée n'est pas de transférer tout en gadgets parce que la possibilité existe. Les gadgets ont eu aussi leur coût (assez élevé) en terme de performance. Dans ce cas, cela ne me semble pas avisé, à première vue.

Ici, si l'on veut améliorer les performances, on pourrait commencer par supprimer l'import d'une CSS vide, par exemple. Cordialement, --Lgd (d) 21 février 2012 à 21:26 (CET)

J'ai mis en commentaire la ligne de code en question. iAlex (Ici ou là), le 21 février 2012 à 22:19 (CET)

L'idée était moins d'améliorer les performances que d'avoir un code propre en utilisant les préférences pour la personnalisation. Ça évite par exemple d'avoir à toucher à cette page cruciale s'il y a des modifications à faire. Ça m'intéresserait de savoir le coût des gadgets, d'ailleurs. — Dakdada (discuter) 22 février 2012 à 15:22 (CET)

ça ne rendrait pas le code plus « propre » en général (en quel sens plus précis, d'ailleurs ?). Les gadgets étant destinés à faciliter l'activation/désactivation par chacun à sa convenance, ce ne serait en fait pas leur bon usage dans ce cas (l'avertissement en cas de blocage de bot n'a pas de raison d'être désactivable, il me semble ?).

Côté performances, un gadget = une requête supplémentaire, à la différence d'une fonction dans Common.js (enfin, selon la façon dont elle est écrite, disons). Cordialement, --Lgd (d) 22 février 2012 à 15:32 (CET)

En fait il y a justement une option pour importer le script (if ( !window.disableSysopJS ). En outre côté performances, je me demande quand même : puisque d'une part seuls les administrateurs utiliseront le gadget (quelques dizaines de personne sur le projet, sur des millions de visiteurs), les requêtes seront très limitées (et seulement eux la feront). D'autre part, en parlant de requête, il y a de toute façon un "importscript" dans le code. Autant alors implémenter l'import du script (et son activation/restriction) via un gadget qui est sensé faire ça de manière plus efficace (=c'est ce que j'entends par plus propre). — Dakdada (discuter) 22 février 2012 à 19:02 (CET)

On ne s'est pas compris, je le refais : le propre d'un gadget est d'être désactivable (via les préférences). Ici, ce script d'alerte en cas de blocage de bot n'a pas de raison d'être désactivé (si tant est qu'il soit encore fonctionnel, cela dit, j'ai un doute tout à coup ). Le gadget n'est donc pas indiqué.

Pour les requêtes, oui, c'est pour cela que je précisais qu'une fonction du common.js n'entraînait pas de requête supplémentaire selon la façon dont elle était écrite. --Lgd (d) 22 février 2012 à 19:19 (CET)

Ha, apparemment le importscript importe une page qui importe elle-même le gadget MediaWiki:Gadget-NoBlockIpBots.js... À en lire cette discussion, l'idée était bien d'en faire un gadget activé par défaut pour les admins, mais désactivable. Le seul hic c'est qu'à l'époque il n'était pas possible, je crois, d'activer des gadgets par défaut pour un groupe d'utilisateurs donnés, d'où l'installation du script et de la condition dans le common.js. Mais c'est maintenant possible, et donc un "vrai" gadget semble plus approprié, si tant est que cette fonction fonctionne bel et bien et sert encore à quelque chose. — Dakdada (discuter) 23 février 2012 à 01:18 (CET)

J'ai supprimé tout le bloc de code, car maintenant il y a des pages pour des scripts et des styles pour chaque groupe directement dans MediaWiki ; celle pour les administrateurs est MediaWiki:Group-sysop.js. iAlex (Ici ou là), le 26 février 2012 à 22:05 (CET)

Encore mieux ! Merci de l'info. — Dakdada (discuter) 26 février 2012 à 22:56 (CET)

Liens directs vers Commons

Bonjour,

La dernière modification de MediaWiki:Common.js visant à rediriger vers Commons me semble précipitée : nous n'avons toujours pas régler la question de WikiPosters. --Dereckson (d) 17 janvier 2013 à 18:17 (CET)

urgentsynchronejs

Ça n'a l'air utilisé nulle part… je peux enlever ?

Amicalement — Arkanosis ^✉ 26 janvier 2013 à 21:33 (CET)

C'est utilisé dans les pages de description de fichier qui se trouvent sur Commons (par exemple Fichier:Exemple.jpg), via MediaWiki:Sharedupload-desc-here, pour charger MediaWiki:Common.js/lienposter. Vu l'absence de réaction à la section juste au-dessus, je pense que tu peux effectivement le supprimer. Orlodrim ^[discuter] 26 janvier 2013 à 21:38 (CET)

Aargh… ça veut dire que MediaWiki:Sharedupload-desc-here n'est pas indexé par le moteur de recherche local .

Merci pour ta réponse, ça m'éclaire un peu sur l'usage qui est fait de ce bout de script… Je pense comme Dereckson que le dernier ajout a été précipité — mais pas pour les mêmes raisons — mais je croix qu'il n'y a pas de retour en arrière a espérer .

Je retire donc le morceau de code — si on avait de nouveau besoin de la fonctionnalité, je pense qu'il y aurait moyen de s'y prendre de façon plus lisible pour le mainteneur de passage.

Amicalement — Arkanosis ^✉ 26 janvier 2013 à 22:01 (CET)

Bonjour,

Cf Wikipédia:Le_Bistro/12_mars_2013#Poster_.3F: le projet WikiPosters fonctionne toujours via les liens forcés vers la page fantôme de fr.wp, donc ce bout de JS est toujours utile :)

Jean-Fred (d) 12 mars 2013 à 21:27 (CET)

MoveResizeAbsolute

Le jeu des fonctions custom cache le fait qu'on force l'activation de ce « gadget » pour tout le monde, sans passer par ResourceLoader. Impact à froid : une requête HTTP supplémentaire, cache miss sur squid, hit direct sur nginx, entre 200ms et 2s d'attente pour une requête HTTP dispo (avec Firefox 18), ~400ms d'attente de réponse, pour seulement ~28ms de transfert. Total de retard sur onload() à cause du seul chargement de ce gadget : entre 600ms et 2,6s.

Les fonctions utilisées sont GetScreenWidth, GetScreenHeight, AddMoveArea, et AddResizeArea. Il faudrait voir si on peut s'en passer (en les remplaçant par du jQuery, peut-être) ou à défaut, au minimum les servir inlinées dans le Common.js avec vanish.

Amicalement — Arkanosis ^✉ 26 janvier 2013 à 22:52 (CET)

Lien wikidata

Le logiciel donnant déjà/maintenant un lien pour ajouter des interwikis, le lien en rouge est désormais inutile. Quelqu'un pour enlever CreateEmptyWikidataLink() ? — Dakdada (discuter) 24 avril 2013 à 21:39 (CEST)

  Fait par Hoo man (d · c) (global sysop). — Ltrl G^☎, le 27 avril 2013 à 11:45 (CEST)

AFTv5 temp fix for forms appearing for no reason

A change recently deployed for AFTv5 has the unfortunate side-effect of AFTv5 sometimes showing up on pages where it shouldn't. This is caused when the page output still being cached, while the new Javascript is already loaded.

On an per-article basis, an ?action=purge will fix the problem. Or as soon as an article is updated, this problem will no longer occur. Or over time, caches will expire. Until then though, the below code is a temporary fix that will ensure the form is not added to pages where it does not belong.

 /**
  * A recent update for AFTv5 is not behaving properly when
  * cache page output is served & a non-cached JS is loaded.
  * The default value of 'permissionLevel' will now be false,
  * instead of an actual value. Cached pages will still have
  * the default value set though (instead of false), so the
  * new JavaScript will interpret that as that the permission
  * level has been set specifically, instead of falling back
  * to the real (disabled) default value.
  * This code will basically detect if the page output is old,
  * and if so, re-calculate and correct what the values for
  * permissionLevel & defaultPermissionLevel.
  */
  var article = mw.config.get( 'aftv5Article' );
  if (
  	article &&
  	// when this key was introduced, so was the good data we're using now
  	!( 'aft-noone' in mw.config.get( 'wgArticleFeedbackv5Permissions' ) ) &&
  	// make sure no specific protection was set (aft-reader was default)
  	article['permissionLevel'] === 'aft-reader'
  ) {
  	// pretend no permission level is set
  	article['permissionLevel'] = false;
   
  	// now that data is corrected, check if AFT should be enabled;
  	// if not, we should make sure that any form being added is
  	// removed again
  	// if verify function does not exist, we need not worry,
  	// AFT data is corrected now already so nothing wrong
  	// will be added
  	if ( typeof $.aftUtils.verify === 'function' && !$.aftUtils.verify( 'article' ) ) {
  		var remove, interval;
   
  		remove = function() {
  			var $aft = $( '#mw-articlefeedbackv5' );
   
  			if ( $aft.length > 0 ) {
  				$aft.remove();
  				clearInterval( interval );
  			}
  		};
  		interval = setInterval( remove, 100 );
  	}
  }

the above post is by WMF engineer mw:User:Mlitn, the same fix has already applied on dewiki by him: [2].--se4598 (d) 7 juin 2013 à 17:45 (CEST)

I have added the function to MediaWiki:common.js, thanks. I trust you, I did not take time to understand what's happening in details. Orlodrim ^[discuter] 8 juin 2013 à 01:42 (CEST)

I just updated the script: a more robust check has been deployed as part of AFT; if someone could replace the previous code by this new code (old, stale caches still need to be accounted for until they expire), that'd be great. The date the script can then be removed is still July 7. Mlitn (d) 19 juin 2013 à 03:14 (CEST)

Orlodrim ^[discuter] 19 juin 2013 à 09:04 (CEST)

Nouvelle version de "Direct imagelinks to Commons" disponible

Bonjour,

Il y a une nouvelle version du lien directe à Commons sur mw:Snippets/Direct imagelinks to Commons avec support pour utiliser l’aperçu rapide. -- Rillke (discuter) 29 novembre 2013 à 01:06 (CET)

Give search results even when page doesn't exist

Screenshot of the Earth test search, with this script adding links to Wikidata, Reasonator, Commons, and Wikipedia.

Hello, I propose to enable the tool created by Magnus Manske (creator of MediaWiki) to provide results from other languages and Commons (via Wikidata) when a page doesn't exist here: links are added to Special:Search and noarticletext. This helps to encourage translation and to make readers use your wiki more, because they can be sure to find something even if it's not local (rather than searching directly on the biggest wiki). The Italian and Polish Wikipedias, among others already enabled it by default.
Examples: [3] [4] [5]. More information: Magnus blog.
How to: just add the following line at the end of Common.js.

// Results from Wikidata
// [[File:Wdsearch_script_screenshot.png]]
if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Search' ||  ( mw.config.get( 'wgArticleId' ) === 0 && mw.config.get( 'wgCanonicalSpecialPageName' ) === false ) ) {
	importScriptURI("//en.wikipedia.org/w/index.php?title=MediaWiki:Wdsearch.js&action=raw&ctype=text/javascript");
}
--[[m:User:Nemo_bis|Nemo]] ~~~~~ ([[w:en:MediaWiki talk:Wdsearch.js|comments, translations and last instructions]])
<!-- EdwardsBot 0661 -->

Announced JavaScript change for badges implementation

Hi! I want to let you know that in near future badges will be deployed on Wikidata and the Wikipedias. They help us with displaying the good and featured article icons next to the sitelinks and will replace the javascript hack which is used at the moment together with the Link GA and Link FA templates. To avoid an overlap where the current system and the new feature conflict, I will add a minor fix to your Common.js which adds the class names to the interwiki links. This is part of my task as a global edit interface editor for the Wikidata team. Thanks, Bene* (discuter) 18 août 2014 à 22:25 (CEST)

 Bene* : Hi! Thanks for taking care of updating the conflicting script! Do you plan to do something similar to your change on en:MediaWiki:Gadget-featured-articles-links.js? If so, what is going to happen if (for instance) Wikidata says that it's a featured article but the local page says it's a good article? If I understand correctly, the gadget on enwiki does not see a conflict in this case, even after your update. Wouldn't it be better to give the priority to new badges even if they don't have the same "level" than what is stored on the local wiki? Orlodrim (discuter) 18 août 2014 à 23:16 (CEST)

Hi Orlodrim, I think the cases where Wikidata says it's a featured article and the local page, it's a good one are very rare as the templates get imported by bot and I can't imagine any case where a conflict like for interwiki links might happen. After the badges are imported completely, the entire script can be removed anyway because it is no longer needed then. If you also want the templates to be removed you can contact Amir who has a bot for that task. Best regards, -- Bene* (discuter) 23 août 2014 à 22:01 (CEST)

 Bene* : Bot updates do not happen very often. For instance, en:Red Skelton was promoted to FA about one month ago, but it still has a {{Lien BA|en}} ("GA link") on frwiki instead of {{Lien AdQ|en}} ("FA link"). Orlodrim (discuter) 23 août 2014 à 23:16 (CEST)

@Orlodrim: That is the data which is being migrated to Wikidata by bots, and we won't need these updates anymore, as far as I know. Once en:Red Skelton is marked as featured on Wikidata (well, it already is!), that info is available for every wiki. Helder 24 août 2014 à 00:51 (CEST)

I understand that Bene*'s modification is only to avoid issues during the transition, and that the whole script can be removed shortly after that. My point is that the change done on en.wikipedia.org will avoid some conflicts but not all of them, because it relies on the assumption that the old system of templates is perfectly up-to-date. That's why I suggest to give priority to wikidata badges in all cases. It's just a matter of changing the order of "if" instructions:

if (!$this.hasClass( 'badge-featuredarticle' ) && !$this.hasClass( 'badge-goodarticle' ) && !$this.hasClass( 'badge-featuredlist' )) {
  /* Run the old code to add stars. */
}

Orlodrim (discuter) 24 août 2014 à 10:45 (CEST)

Got it! This change should fix the issue. Helder 25 août 2014 à 01:31 (CEST)

Changement de l'id des coordonnées GPS : pourquoi ?

Bonjour

On fait ceci :

function moveCoord( $ ) {
	$( '#coordinates' ).attr( 'id', 'coordinates-title' ).insertBefore( '#firstHeading' );
}
$( moveCoord );

C'est mal. C'est mal parce qu'avec un id qui change, les scripts qui s'exécutent de manière asynchrone (et donc dans un ordre non déterministe) ne peuvent pas savoir sur quel id s'appliquer.

Quelqu'un aurait-il la moindre idée de pourquoi on effectue ce renommage ? Ne pourrait-on pas se contenter de déplacer les coordonnées sans en changer l'id ?

Contexte pour les curieux, je suis en train de travailler à régler le problème que j'avais signalé en janvier 2013.

Merci, amicalement — Arkanosis ^✉ 2 octobre 2014 à 01:25 (CEST)

En tout cas c'est vieux : « déplacement de des coordonnées dans le titre pour éviter les superpostions moches ». Je crois que l'élément est créé par Module:Coordinates via Modèle:Coord. S'il faut changer une id, c'est là-bas, pas ici. Je ne comprend toujours pas pourquoi l'id devrait changer par contre. — Dakdada (discuter) 2 octobre 2014 à 11:05 (CEST)

Il y a toujours une règle CSS pour "#coordinates" dans MediaWiki:Monobook.css pour mettre les coordonnées dans le coin, qui est plus ancienne que l'ajout du code javascript. Elle aurait sans doute un effet indésirable si elle s'appliquait à l'élément après son déplacement par la fonction javascript (du coup, l'explication est sans doute : c'était plus simple de changer l'id pour tester le nouveau code et ça n'a jamais changé ensuite). Orlodrim (discuter) 2 octobre 2014 à 13:01 (CEST)

Bien vu, merci à tous les deux !

Je propose donc :

• une suppression de la règle #coordinates dans Monobook.css ;
• un ajout de #coordinates dans les sélecteurs des règles #coordinates-title * dans Common.css ;
• l'arrêt du renommage dans Common.js ;
• la suppression du sélecteur #coordinates-title.

Amicalement — Arkanosis ^✉ 2 octobre 2014 à 14:19 (CEST)

Ne pas oublier d'enlever #coordinates-title de Common.css plus tard, quand la transition sera finie. — Dakdada (discuter) 2 octobre 2014 à 18:07 (CEST)

C'est ce que je voulais dire par « la suppression du sélecteur #coordinates-title » . Merci ! — Arkanosis ^✉ 2 octobre 2014 à 18:11 (CEST)

Il y a aussi une règle pour #coordinates-title dans MediaWiki:Vector.css et des règles pour les deux id dans MediaWiki:Modern.css. Orlodrim (discuter) 2 octobre 2014 à 20:08 (CEST)

Un grand merci pour votre aide !

À la réflexion, je me dis qu'il vaudrait mieux n'appliquer le nouveau style qu'après le déplacement, pour le cas où ce dernier n'aurait pas lieu (JavaScript désactivé ou cassé, gadget désactivé — lorsque le code sera complètement migré en gadget). C'est ce qui est fait actuellement avec le changement d'id — mais encore une fois, ce changement d'id est indésirable.

Ce que je prévois de faire :

• ☑ Suppression du sélecteur #coordinates dans MediaWiki:Monobook.css et MediaWiki:Modern.css (selon le parti pris suivant : pas de déplacement si JavaScript est désactivé).
• ☑ Ajout du sélecteur .coordinates-title en doublon de #coordinates-title dans MediaWiki:Common.css, MediaWiki:Vector.css, MediaWiki:Modern.css et MediaWiki:Gadget-WikiMiniAtlas.js (edit: pas besoin, s'applique directement sur l'id #coordinates qui a vocation à rester).
• ☑ Remplacement du changement d'id par un ajout de la classe coordinates-title dans MediaWiki:Common.js et MediaWiki:Gadget-osm.js.
• ☑ Suppression du sélecteur #coordinates-title dans MediaWiki:Common.css, MediaWiki:Vector.css, MediaWiki:Modern.css et MediaWiki:Gadget-WikiMiniAtlas.js.
• ☑ Suppression de tout le code lié à OSM dans MediaWiki:Common.js (enfin !).

Idéalement, les sélecteurs .coordinates-title devraient se retrouver dans un CSS propre au gadget et non dans MediaWiki:Common.css, MediaWiki:Vector.css et MediaWiki:Modern.css. Pour cela, il faudrait utiliser les sélecteurs .skin-vector .coordinates-title et .skin-modern .coordinates-title (ou un truc du genre) pour les règles provenant des deux dernières feuilles de style. Mais je crois que je garderai cette étape pour plus tard : il y a déjà bien assez à faire

Amicalement — Arkanosis ^✉ 12 novembre 2014 à 02:35 (CET)

En creusant un peu plus, je remarque que MediaWiki:Gadget-WikiMiniAtlas.js a été significativement patché pour être compatible avec OSM. Dans un premier temps, il va falloir le re-patcher pour qu'il fonctionne avec la classe .coordinates-title à la place de l'id #coordinates-title. Dans un second temps, il faudra s'assurer qu'il fonctionne toujours correctement lorsque le gadget OSM est désactivé, les sélecteurs #coordinates ayant été supprimés.

Je pense qu'à terme, il conviendra toutefois de désactiver WMA par défaut (OSM a, semble-t-il, la préférence de la plupart des contributeurs s'étant rendu compte de son existence — même s'il faudra peut-être lui apporter quelques petites améliorations).

Amicalement — Arkanosis ^✉ 12 novembre 2014 à 02:56 (CET) (edit: liste mise à jour au dessus)

Voila, j'ai enfin terminé : OSM est désormais dans un gadget activé par défaut et chargé avec ResourceLoader. Cela signifie que pour tous les utilisateurs de Wikipédia, il y aura une requête HTTP en moins pour chaque ouverture de page. Accessoirement, il est aussi possible de désactiver OSM.

Ce qu'il reste à faire (non critique) : déplacer les règles CSS dans une feuille de style propre au gadget (cf. plus haut).

Amicalement — Arkanosis ^✉ 22 novembre 2014 à 14:28 (CET)

Pourquoi : <nowiki> /!\ Ne pas retirer cette balise

Pourquoi cette mention ? Gentil ♥ (discuter) 9 mai 2015 à 16:47 (CEST)

Je pense que c'est pour éviter que les "subst:" soient interprétés (entre autres). JackPotte ($♠) 12 mai 2015 à 21:50 (CEST)

Remplacer certaines url externes HTTP par du HTTPS quand on est déjà en HTTPS

On introduit un risque à utiliser les uri externes en HTTP. Il faudrait détecter lorsqu'on est déjà en HTTPS sur Wikipédia, et alors privilégier l'HTTPS externe dans ce cas. Exemples d'uri à corriger en HTTPS selon les cas :

• ligne 244 : http://upload.wikimedia.org/
• ligne 1105 : http://www.google.fr/
• ligne 1113 : http://www.bing.com/
• ligne 1117 : http://fr.search.yahoo.com/

Les autres URI trouvées (wikiwix.com, exalead.com, aka-online.de) ne semblent pas encore compatibles HTTPS. Gentil ♥ (discuter) 9 mai 2015 à 17:48 (CEST)

Mieux vaudrait utiliser des protocoles relatifs, par exemple écrire [//www.google.fr] donne [6] (cf en:Wikipedia:Protocol-relative URL). — Dakdada (discuter) 12 mai 2015 à 11:46 (CEST)

Remplacement de liens en fonction d'un paramètre de l'URL

Bonjour,

Pour mettre en œuvre ce qui est décrit dans Révision du modèle Brouillon sur Discussion Projet:Aide et accueil, je prévois d'ajouter le code de Utilisateur:Orlodrim/subst-sourcepage.js à MediaWiki:Common.js.

Orlodrim (discuter) 15 mars 2016 à 19:18 (CET)

JavaScript associé au Modèle:Animation

Bonjour, simplement pour attirer votre attention sur le message que j'ai posté concernant le JavaScript de ce modèle : Discussion modèle:Animation#Besoin de réécriture du JavaScript. od†n ↗^blah 27 août 2017 à 20:13 (CEST)

Syntax error due to unescaped jQuery selector

Bonjour et je suis tres desole pour l'anglais... There is a Javascript error that is impacting only French Wikipedia which makes me believe that something in this page is responsible.

I've documented the error in phab:T264786. If somebody is familiar with this code could you help me track down this issue? There is likely a piece of code in the form $('#' + variable) which needs to use $.escapeSelector. i thought this was the culprit but it doesn't seem to be the case.

The error Uncaught Error: Syntax error, unrecognized expression: [id='Baldur's_Gate'] occurred on https://fr.wikipedia.org/wiki/Baldur%27s_Gate - could you help me track it down with this information?

Thanks in advance for your help. Jdlrobson (discuter) 6 octobre 2020 à 23:33 (CEST)

I wish to eradicate this bug too. I have done a handful of searches on the wiki, but without success. We definitely need more information in order to find it out. Just a guess, as you wrote on the phabricator task it occurs every 12 hours, maybe it could be a javascript bot? od†n ↗^blah 7 octobre 2020 à 05:48 (CEST)

I'm pretty sure it's not a bot. Sorry for the confusion but the errors are occurring across the course of the day. 5000 errors occur across 12hrs from at least 10 IP addresses which is quite a significant error rate compared to our other known errors.

I suspect this code is limited to a certain group of people with certain user rights and relates to a script that operates on either the table of contents or the section headings.

It would be helpful if a few people view https://fr.wikipedia.org/wiki/Baldur%27s_Gate and see if they can trigger any errors in their developer consoles while clicking or hovering over these elements of text which contain the single quote character! Jdlrobson (discuter) 7 octobre 2020 à 17:55 (CEST)

Guessing from the examples you gave, wouldn't it be more likely related to wgPageName? (notably because of the underscores) od†n ↗^blah 8 octobre 2020 à 00:45 (CEST)

I believe I've tracked this down now to an error in an active fundraising banner, so the error is not in this code. Thanks for helping me narrow down the possibilities! I'll continue on the phabricator ticket. Jon (WMF) (discuter) 8 octobre 2020 à 20:15 (CEST)

Proposition de suppression de MediaWiki:Common.js/EditTags.js

Bonjour,

Ce script est chargé via MediaWiki:Common.js sur la page d'édition des balises (ça). Il a pour but d'empêcher la modification de certaines balises, censées être ajoutées seulement par des scripts/gadgets et pas modifiées ensuite. Il a été ajouté en 2015 puis déplacé vers une sous-page par  Od1n.

Il ne semble plus être fonctionnel. Je propose de le supprimer plutôt que d'essayer de le réparer car :

• Peu après l'apparition des balises, il a été décidé de restreindre leur modification aux utilisateurs autopatrolled. Il n'y a donc pas de risque d'abus.
• On pourrait considérer qu'il rend la page plus pratique, en ne laissant que les balises utiles. Mais bon, en pratique, la fonctionnalité d'édition manuelle des balises est extrêmement peu utilisée. À part paidedits, je ne vois pas de balise destinée à être ajoutée ou retirée de cette façon. Même si on le répare, on risque de passer plus de temps à tenir à jour la liste des balises dans le script qu'à utiliser la page sur laquelle le script agit.

Des objections à la suppression ?

Orlodrim (discuter) 29 novembre 2020 à 15:10 (CET)

Partant du principe que davantage que la simplification pour l'utilisateur, l'intérêt du script est d'empêcher la modification des balises ajoutées par des outils tels que AWB, j'ai regardé pour quand même réparer le script.

Le code serait effectivement à mettre à jour pour être compatible avec le nouveau dropdown en OOUI.

Ensuite, la liste des balises serait effectivement à mettre à jour. Par exemple, il y a PaFtec en trop, il manque huggle…

Sauf que, je me suis rendu compte qu'une fois retirées les balises des outils AWB, huggle, etc, ben il ne reste plus grand chose. Et donc, on rejoint ce que tu disais, à savoir que la modification manuelle des balises est une fonctionnalité qu'il faut rarement utiliser.

Par conséquent, d'accord pour la simple suppression du script, ça sera toujours ça de moins à maintenir.

od†n ↗^blah 1 décembre 2020 à 01:45 (CET)

Orlodrim (discuter) 3 décembre 2020 à 18:25 (CET)

Prepare for T314318

Please copy this upstream change, https://www.mediawiki.org/w/index.php?title=Snippets%2FDirect_imagelinks_to_Commons&type=revision&diff=5451422&oldid=3976429

For more information, see mw:Parsoid/Parser_Unification/Media_structure/FAQ

Thanks, Arlolra (discuter) 25 novembre 2022 à 00:06 (CET)

Added to the Common.js (edit 2023-11-11: applied a small correction). I fine-tuned the implementation, here it internally makes use of two getElementsByClassName(), which are extremely fast.

Of course, there are many other JavaScript and CSS codes that need this "mw-file-description" update. And there are yet other markup changes that have to be taken care of…

od†n ↗^blah 26 novembre 2022 à 00:59 (CET)

By the way, for the CSS files, it's an use case where the :is() pseudo-class would have been appreciated. It isn't supported on IE 11 sadly… od†n ↗^blah 26 novembre 2022 à 02:02 (CET)

insource:thumbinner… « Résultats 1 à 20 sur 292 » od†n ↗^blah 28 novembre 2022 à 00:27 (CET)

As the old markup is no longer used, I removed support for it: 209559044. od†n ↗^blah 12 novembre 2023 à 10:29 (CET)