Les liens pointent souvent vers d’autres pages HTML mais aussi vers d’autres types de documents et services. Améliorez le confort de navigation de l’internaute en distinguant visuellement les différents types de liens : documents à télécharger, liens externes, mailto, etc.
Ce plugin a pour avantage de traiter tous les liens de façon homogène, en respect des bonnes pratiques, en particulier Opquast V2 Critère 120 : Les hyperliens de même nature ont des couleurs, des formes et des comportements identiques sur toutes les pages.
Note de version
Suite de « Liens sortants ouvrants », cette seconde version du plugin change de nom, car l’explicitation des liens devient sa vocation principale.
- Cette version ajoute des styles et pictos [*] permettant de mieux distinguer les liens les uns des autres, exactement comme dans l’encyclopédie Wikipédia, ni plus, ni moins : pdf et autres doc, liens externes, mailto, etc.
- Sans oublier les styles historiques de SPIP.
- Affichage des hreflang [*].
- Meilleure explicitation des liens à l’impression [*].
- Correction des URLs des articles redirigés de SPIP, qui génèrent désormais l’URL cible (et non plus l’URL interne de l’article), ce qui permet de distinguer les liens externes.
- L’ouverture en nouvelle fenêtre n’est plus systématique, mais optionnelle et paramétrable, étendable aux documents.
Apparence : styles et pictos
Pour prévisualiser, affichez la page de test « ?page=demo/links
» sur votre site ou insérez le modèle « <charte|links>
» dans un de vos articles. Pour toute personnalisation, complétez en CSS, dans votre feuille de style.
Ce plugin permet de distinguer les liens vers des documents générés par SPIP, notamment via le raccourci [->doc324]
ou la balise #URL_DOCUMENT
, grâce à un sélecteur CSS dédié : .spip_doc
.
Tous les liens sont stylés par défaut, ce qui peut sembler radical. Saupoudrez des « padding-right: 0; background-image: none;
» pour annuler le style appliqué là où vous ne le souhaitez pas.
Pour appliquer une autre feuille de style, avec d’autres pictos, copiez la feuille links.css
dans le sous-répertoire /css
, modifiez-là, et déposez vos pictos dans le sous-répertoire /css/img/links
de votre dossier « squelettes ».
Ouverture en nouvelle fenêtre
Bien que cela mette certains utilisateurs et utilisatrices en sérieuse difficulté [1], forcer l’ouverture des liens dans une nouvelle fenêtre reste une demande impérieuse. Ce comportement est désormais optionnel, activable et désactivable, et peut être étendu aux documents, ce qui est utile dans les vieux intranets (http://forum.spip.org/fr_230827.html) — à éviter absolument sur Internet !
Un panneau de configuration permet de :
- activer/désactiver les styles et pictos
- activer/désactiver l’ouverture des liens externes dans une nouvelle fenêtre
- activer/désactiver l’ouverture de certains document dans une nouvelle fenêtre, d’après liste éditable des extensions
Avec ce plugin, il ne faut pas utiliser d’attributs « target="_blank"
» dans vos squelettes, afin de ne pas interférer sur cette configuration.
Todolist
Évolutions attendues :
- Correction des attributs
title
des liens ouvrant une nouvelle fenêtre, qui, en l’absence detitle
, devraient répéter le libellé du lien (comme suggéré ici). - Ajout automatique dans le libellé (entre les tags
<a>
et non pas entitle
) des liens générés par SPIP, du format et du poids du fichier, comme spécifié dans le ticket #2209.
Votre aide est bienvenue !
Discussions par date d’activité
18 discussions
Bonjour,
J’ai activé le plugin en version 4.0.0 dans mon site en HTTPS sous Spip 4.1.10 en cochant : Styler les liens (avec links.css)
mais ce ne fonctionne que dans l’espace privé. Un problème de CSS sans doute ?
Bon finalement cela fonctionne mais j’aimerais pouvoir supprimer le cadenas sur un lien interne, soit le logo du site qui est cliquable pour un retour à la page d’accueil. Je ne comprends pas pourquoi ce cadenas s’affiche.
Répondre à ce message
Hello ici,
Pour une raison qui m’échappe, sur un SPIP 4.2 avec une version fraichement récupérée sur SVP, même si on coche explicitement que nous n’en voulons pas, et même après avoir purgé tous les caches (spip images) les styles de links.css s’appliquent quand même aux liens ?
Si quelqu’un a une idée...
Merci par avance
Répondre à ce message
Hello
Je suis en train de tester ce plugin qui intéresse quelques utilisateurs d’Escal.
Dans le menu j’ai un lien vers l’accueil codé ainsi
a href="[(#CONFIG{gerer_trad}=={oui}|?{[(#URL_SITE_SPIP|parametre_url{lang,#ENV{lang}})],#URL_SITE_SPIP})]"
Et il se trouve que ce lien ouvre une nouvelle fenêtre si le plugin « liens explicites » est activé et si, bien sur, on a demandé de forcer les liens externes vers une nouvelle fenêtre.
Une idée pour corriger ?
Je me penche à nouveau sur ce souci et je constate que même avec un simple
le lien ouvre une nouvelle fenêtre.
J’ai ouvert une PR à ce sujet.
https://git.spip.net/spip-contrib-extensions/links/pulls/1
tu peux tester la branche (zip ici https://git.spip.net/spip-contrib-extensions/links/archive/url_site_spip.zip) et commenter. Après j’ai l’impression que tetue n’est plus trop active, donc je sais pas qui aurait la légitimité pour fusionner.
Résultats du test :
ça règle le problème si on écrit
mais pas si on écrit
et que le multilinguisme est activé
Ah oui, je l’avais pas vu celui là. La nouvelle version de la branche devrait faire l’affaire.
Bon là tout m’a l’air parfait ! Merci beaucoup.
Et tu me semble parfaitement légitime pour fusionner, non ?
Sinon, comment faire profiter les utilisateurs de tes corrections ?
bah en fait non, si précisement j’ai fait un PR, c’est que je ne suis pas à l’origine du plugin. Et normalement ce sont aux responsables de plugins de vérifier si j’ai pas fait des erreurs (par ex. si pas moyen de faire plus simple).
Mais là je ne sais pas qui a la responsabilité.
Du coup bah on va laisser cette PR en suspens. Et si dans disons 2 semaines personne s’est manifesté, je fusionnerai.
Ok ça roule. Merci encore.
bon pas de retour des responsables, j’ai mergé et tagué. Bientot disponible.
Répondre à ce message
Bonsoir
Je viens d’installer ce plugin pour diverses raisons, dont celle de faire pointer les liens externes au site vers une nouvelle fenêtre. Y en a qui disent que c’est mal, mais là n’est pas le sujet.
Cela fonctionne tout à fait correctement, sauf que pour les liens (présents dans les menus, dans le fil d’Ariane) vers la page d’accueil de mon site :
#URL_SITE_SPIP
», il est considéré comme un lien externe.#URL_SITE_SPIP/
» pour être considéré comme un lien interne.Je ne sais rien de la normalité de ce comportement.
Répondre à ce message
Est-ce normal si les liens explicites ne fonctionnent pas sur le champ URL d’un article ?
J’espérai que ce plugin détecte et ajoute tout seul le picto indiquant un lien externe (le cas échéant) mais cela ne semble pas être le cas.
PS sinon difficile à trouver ce plugin via la page / ?exec=charger_plugin
merci
Ce plugin agit sur les liens des squelettes générés. Ça dépend donc, non du champ de saisie dans l’espace privé, mais de la façon dont c’est codé dans le squelette. Ceci dit, aucune idée de ce qui pourrait faire obstacle…
À moins que tu n’évoques la redirection d’articles virtuels ?
Ah OK donc si je comprends bien je dois ajouter un mécanisme dans le squelette pour tester si un lien est externe ou interne et les traiter différemment.
Répondre à ce message
Bonjour,
Une petite remarque : le plugin considère comme externe tout lien ne correspondant pas à l’url du site spip dans lequel il est installé (
$GLOBALS['meta']['adresse_site']
du fichier links_pipelines.php).Ceci provoque un comportement bizarre lorsque l’on a des sous-domaines : un lien vers le sous-domaine sur lequel on se situe ouvre un nouvel onglet, alors que ce ne devrait pas être le cas (puisque c’est le même site).
Ne vaudrait-il pas mieux considérer comme externe tout lien dont l’url de base est différente de l’url de base de la page où l’on se trouve (
$js .= 'var links_site = \''.url_de_base().'\';';
au lieu de$js .= 'var links_site = \''.$GLOBALS['meta']['adresse_site'].'\';';
) ?Merci !
Sans doute, oui.
Tout dépend de ce que l’on entend par « lien externe », la définition variant selon le point de vue :
En fait, le problème est que si un certain thème est affiché avec un sous-domaine (c’est mon cas), les liens présents sur la page, également dans ce sous-domaine, sont considérés comme externes, alors que ce n’est pas le cas (je suis sur sousdomaine.domaine.com/page1 et mon lien envoie vers sousdomaine.domaine.com/page2... mais dans un nouvel onglet).
Je ne sais pas si je suis très clair.
Bonjour,
En fait, pour éviter des comparaisons avec des urls identiques mais considérées comme différentes à cause de / ajoutées parfois en fin d’adresse, il faudrait en réalité mettre
$js .= 'var links_site = \''.rtrim(url_de_base(),'/').'\';';
.Bonjour,
Si cette remarque vous paraît justifiée, savez-vous s’il sera possible de procéder à une mise à jour du plugin, afin de résoudre ce problème avec les sous-domaines ?
Merci beaucoup,
Mieux vaut répondre tard que jamais, cela a été fixé, en réponse à vos commentaires : https://github.com/tetue/links/commit/3b3dbb678ad10f7fddb121b890a1017bc7699369
Répondre à ce message
Merci pour ce plugin, pratique et élégant.
marche bien mais je n’ai tout de même pas l’effet sur mes liens.
Des liens externes sont interprétés en lock, des liens de même nature se retrouvent avec des icones différentes et, ce que je cherchais avant tout, les articles virtuels ne sont pas détectés comme externes (ni ans la liste des rubriques, ni dans le plugin menu).
J’ai mais fait quelque chose ?
Merci.
Alors je rentre dans ma coquille et je m’excuse platement pour le parasitage... Je n’avais pas vidé mon cache, ouhhhhh....
Pour chipoter, je trouve que la temporisation de l’apparition de la bulle « title » est un peu longue, et donc qu’on risque de passer à côté de l’info « nouvelle fenêtre » (je sais, c’est mal, mais dans mon cas, je ne peux que très difficilement faire autrement).
Mais l’info-bulle « title » on n’y peut rien, n’est-ce pas ?
Répondre à ce message
Hello,
Me revoilà avec mes petites questions sur cette vilaine pratique ;p !
Donc résolu le petit souci de compatibilité avec la compression de JS, et youpi, j’ai pu le remettre et compresser sur les sites où c’était vraiment nécessaire / demandé… sauf un :
C’est un site sur lequel j’ai dû avoir recours à JQuery 1.10.2 en surcharge du 1.7.2 utilisé nativement par Spip 3. Et bien ce n’est pas compatible avec la fonction de ce plugin et les liens externes ne s’ouvrent plus dans une nouvelle fenêtre :-(
Trop nulle JS pour mettre le nez dans le code et le rendre compatible, j’ai tenté de modifier l’ordre d’appel des scripts dans le head, et je crois bien avoir tout tenté : rien à faire !
Un expert, une bonne âme pour m’aider à rendre compatible ce plugin avec JQuery 1.10 ?
Cordialement,
Karen
Répondre à ce message
Bonjour,
Je rencontre un souci avec la partie « Comportement »
J’active l’item « Forcer l’ouverture de certains liens dans une nouvelle fenêtre (déconseillé) »
Ensuite j’active « Documents à télécharger » en laissant « .pdf,.ppt,.xls,.doc » dans le champ des extensions
Puis quand je clique sur un lien .pdf dans la partie publique (après avoir recalculé la page) le fichier ne s’ouvre pas dans une nouvelle fenêtre mais dans celle en cours.
Par contre cela fonctionne si j’active en plus l’item « Liens externes », mais ce n’est pas ce que je souhaite pour les liens web.
Est-ce que ce fonctionnement est normal ?
Merci
J’ai exactement le même problème en SPIP 3.0.10 :(
Au fait ça ne fonctionne pas du tout chez moi en spip 3.0.10
Le plugin en effet ne sauvegarde pas la configuration désirée si l’on désire forcer l’ouverture des pdf tant que l’on n’active pas aussi les liens externes comme mentionné plus haut par ?
Mais même comme ça en effet mes pdf ne s’ouvrent pas dans une nouvelle fenêtre :(
Une solution ??
C’est normalement corrigé avec la version 2.3.7
Bonjour,
Je viens de comprendre un truc après quelques petites heures de recherche, à savoir pourquoi un site en test ouvrait bien les liens dans une autre fenêtre, et le même site en prod sur le même serveur avec les mêmes plugins, n’ouvrait rien dans une nouvelle fenêtre :
La compression du JS annule ce paramétrage du plugin... Bizarre, puisque mes autres plugins utilisant du JS ne subissent pas cette pénalité.
Je suis trop nulle en JS pour pouvoir donner de la compréhension à ça, mais c’est bien ce que j’ai constaté ! Dommage de rester avec des scripts lourds du coup... c’est une punition pour avoir utilisé les liens ouvrants ? lol
Et merci pour ce plugin bien pratique, malgré la mauvaise pratique ;-)
Quand c’est demandé avec insistance et que les arguments ne servent à rien, il faut bien pouvoir réagir et avancer sur le reste !
Cordialement,
Karen
Bonjour,
Je confirma qu’avec SPIP 3.0.17 [21515] si le JS est compressé les liens ne s’ouvrent pas dans une nouvelle fenêtre.
dd
Bonjour,
C’est effectivement sur un spip 3.0.17 que j’ai installé le plugin pour la première fois, je n’ai donc pas d’élément de comparaison… si ce n’est que je viens de le tester sur un 3.0.15 et c’est pareil.
Vous suggérez qu’il y a des versions se spip sur lesquelles la compression du JS n’empêchait pas l’ouverture dans une nouvelle fenêtre ?
Karen
Bonjour,
Je viens de tester avec un site en SPIP 3.0.16 [21266 et les liens externes fonctionnent. Je dois trouver le temps de faire des tests pour voir si cela est du à ce plugin ou à une mauvaise interaction avec un autre plugin.
dd
Hello,
Je dois aussi trouver le temps, que je n’ai pas du tout en ce moment, pour faire ces tests du coup ;-)
Pour simplifier nos recherches, peut-être avons-nous des plugins en commun sur le 3.0.17 au moins, à savoir que moi j’ai :
- champs extra
- mosaïque
- saisies pour formulaire
- yaml
- spip cycle 2
- menu babbibel
- contact libre
Les 3 derniers ne sont pas sur mon site qui tourne en spip 3.0.15 sur lequel les liens ouvrants ne fonctionnent pas non plus (spip cycle 2, menu babbibel et contact libre), donc si nous en avons 1 en commun parmi les 4 premiers, ça pourrait éventuellement réduire la piste ?
Karen
Bon, je ne trouve pas ce qui cloche avec la dernière version de ce plugin (les liens externes s’ouvrent dans la même fenêtre) donc j’ai récupéré la version précédente 2.3.6 et cela refonctionne.
dd
Question bête : comment fait-on pour récupérer une vieille version d’un plugin quand on ne l’a pas téléchargée en son temps, en l’occurrence liens_explicites 2.3.6 ? Car du coup, si elle est compatible avec la compression du JS pour pouvoir tout de même ouvrir les liens dans un nouvel onglet, elle m’intéresse !
Voili voilu :
http://contrib.spip.net/La-Zone-Facile?lang=fr
il n’est pas besoin d’un logiciel client SVN pour récupérer les plugins de la zone qui ne sont pas disponibles en zip sur spip-contrib, car on accède directement à leur zip à l’adresse :
http://zone.spip.org/trac/spip-zone/changeset/latest/_plugins_/NOM_DU_PLUG?old_path=/&format=zip
dd
Merci pour les liens DD… je suis confuse, j’ai pourtant essayé de comprendre mais sans succès. Si je demande http://zone.spip.org/trac/spip-zone/changeset/latest/_plugins_/links?old_path=/&format=zip j’obtiens alors la dernière version, et si je tente te placer un 3.2.6 quelque part, je ne dois pas avoir la bonne syntaxe, j’ai toujours une réponse de chemin inconnu… même en ayant parcouru toute la page de la zone facile avant de poser cette question :-(
Bonjour,
Je reviens sur le sujet car ça me pose problème de ne pas pouvoir utiliser la compression JS sur les sites ou j’utilise ce plugin, sans quoi l’ouverture dans une nouvelle fenêtre ne fonctionne plus, depuis le passage à la version 3.2.7…
Si personne ne trouve la solution, est-ce que quelqu’un aurait la version 3.2.6 à me fournir ? J’ai fait la bêtise de ne pas sauvegarder la version avant la mise à jour, et maintenant je n’ai pas de quoi revenir en arrière… et apparemment je suis trop une bille pour parvenir à la récupérer sur spip-zone, quelque chose m’ayant échappé ??
D’avance merci pour ce dépannage qui me serait fort utile.
Bien cordialement,
Karen
Un grand merci pour la mise à jour 2.3.9 qui règle les problèmes que l’on rencontrait avec la compression du JS !
Répondre à ce message
Je viens de rencontrer un souci avec ce plugin, et un lien de type :
<link href='http://fonts.googleapis.com/css?family=mafont' rel='stylesheet' type='text/css'>
qui est modifié en
<link type="text/css" rel="external" href="http://fonts.googleapis.com/css?family=mafont" target="_blank" class="external" title=" (nouvelle fenêtre)">
quant le plugin est activé.
En modifiant la ligne 5 du fichier « links.js » comme ceci
cela permet de contourner l’erreur, mais est-ce qu’il n’y aurait pas une meilleure écriture ?
J’ai rencontré le même problème. Globalement il faudrait pouvoir cibler plus finement quels contenus sont ciblés ou non voire disposer d’un filtre à appliquer à une balise (par exemple n’avoir le comportement que sur les liens dans le champs #TEXTE).
Le bug est corrigé en version 2.3.6
Répondre à ce message
Merci !
Oui, merci, parce que même si c’est pas bien, ça fait parti des choses souvent demandées.
Répondre à ce message
Hello !
J’ai un comportement étrange avec ce plugin. Dès que je l’active, il fonctionne très bien par contre, la plupart des JS appelés après lui plantent.
Ainsi j’ai plusieurs plugins, tels socialtags, GooglePlus1, ou des JS externes tels innerfade ou coda slider, qui refusent obstinément de fonctionner tant que links est actif.
Quelqu’un a déjà eu ça ?
Oui, je confirme qu’il y a un problème.
J’ai le même comportement avec l’inclusion de css depuis Google webfonts.
Le « restylage » des liens fonctionne comme il faut, mais l’inclusion de scripts extérieurs sont plantés dès que l’on active l’ouverture dans une nouvelle fenêtre.
C’est ennuyeux...
Résolu avec un bidouillage crado.
Dans link.js, remplacer (ligne 5) :
jQuery(« (a|area)[href*=’ ://’]:not([href^= »+links_site+« ]):not([href^=javascript :]):not([href^=mailto:]) »)
par :
jQuery(« a[href*=’ ://’]:not([href^= »+links_site+« ]):not([href^=javascript :]):not([href^=mailto:]) »)
La conséquence, c’est que les images mappées ne sont plus prises en charge (perso je m’en fiche un peu).
La surcharge n’est pas une mauvaise idée !
Ah yes ! Merci pour la bidouille ! Oui en surcharge, le temps de trouver une solution plus pérenne ca peut gérer. :)
Répondre à ce message
Bonjour,
Je viens d’installer le plugin et j’obtiens une erreur au chargement de mes pages :
links_site is not defined
il faut un autre plugin ou qqchose de particulier que j’ai raté ?
Chag
en regardant un peu le code, je vois :
where est bien defini mais links_site (dans la derniere ligne) non. la version dispo via ajouter un plugin de spip est elle à jour ?
ok, j’ai trouve un peu de temps ce soir. Donc, si on coche « forcer l’ouverture(...) », on doit forcement cocher les 2 cases en dessous : Liens externes ET Documents à télécharger. Sinon, ca ne marche pas, on a l’erreur citée dans mon premier message.
Chag
Répondre à ce message
je ne conteste pas au sein des articles, par contre quand j’ai une image « j’aime » facebook ou une icone « Tweeter » elle est remplacé par l’image gif dans tous le template ce qui casse un peut la déco ;-) « si vous voyez ce que je veux dire » lol
par exemple sur le plugin social_tags : les icones pointes vers des liens ouvrant et apparait a coté le gif lien_ouvrant
C’est vrai que c’est pas top, qqun pour faire qqch ?
Il suffit d’éditer votre feuille de style pour annuler le style appliqué là où vous ne le souhaitez pas (personne ne peut deviner ça mieux que vous), en saupoudrant des «
padding-right: 0; background-image: none;
».Merci pour la réponse tetue !
Répondre à ce message
Mon problème : qu’un article avec une redirection vers un lien externe s’ouvre dans une nouvelle fenêtre.
Après installation du plugin et paramétrage, il s’ouvre toujours dans la même fenêtre...
Quelqu’un a-t-il une idée ? Merci d’avance.
Répondre à ce message
Bonjour,
SPIP en version 2.10 les documents proposés dans un article ouvrent systématiquement dans une nouvelle fenêtre ce n’est pas ce que je peux.
j avais essayé avec ce plugin mais cela ne solutionne pas mon problème
merci de vos idees sur la question
Non, SPIP ne modifie pas le comportement des liens et ne force donc pas l’ouverture de nouvelle fenêtre. Il y a vraisemblablement un
target="_blank"
dans vos squelettes : si c’est le cas, ce plugin n’y pourra rien. Sinon, cherchez parmi vos plugins.Répondre à ce message
Tiens y’a personne pour nous dire que c’est pas bien de faire des liens sortants, bizarre !
^^
À quand le plugin footer ?
mais c’est pas bien de faire des liens sortants ! lol
Oui même qu’après les visiteurs de nos sites font des auto-combustions spontanées, internet risque de planter mondialement et le tout puissant dans son immense colère nous envoi des catastrophes naturelles. :)
Hé les trolleurs, le premier d’entre vous qui termine ce plugin en rendant activable/désactivable l’ouverture dans une nouvelle fenêtre gagne ma considération.
merci pour le plugin ;-)
si c’est dans un onglet plutôt qu’une fenêtre c’est grave ??? lol
juste après test du plugin, il serait pas mal de pouvoir choisir via les sélecteur CSS ou ID les blocs ou la fonction est active (genre #wrapper, #container, ), car la ça corrige tout et c’est problématique sur certains cas : par exemple j’ai un menu avec des images qui renvoient sur des liens externes et du coup ça me casse tout.
Il a déjà été répondu (à ce commentaire) que l’intérêt de ce plugin est justement sa radicalité, contrairement aux contributions antérieures, comme le filtre liens_ouvrants ou le plugin Liens spip_out ouvrants. L’inconstance du comportement serait encore pire que pire ! vous allez rendre fous vos internautes :D
Désolée, mais ce plugin respecte les bonnes pratiques :)
Et bien, tout ma considération va à Gael, qui a branché le panneau de configuration qui rend optionnelle l’ouverture en nouvelle fenêtre (Changeset 48961). Merci ! La documentation vient d’être mise à jour en conséquence.
Répondre à ce message
Bonjour, merci pour la contrib !
Juste une question : est-il possible de limiter l’application du plugin au contenu des rubriques / articles ?
Non, surtout pas, ce serait trop déroutant ! Quelle drôle d’idée ! Ce plugin a justement pour avantage de traiter tous les liens de façon homogène, ce qui est une bonne pratique, cf. Opquast N°120 : .
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires : |