ZEP-38 : mise en place d'un raccoucisseur d'URL

Problème

Cette ZEP concerne les URLs des articles, des tutoriels et des sujets sur le forum. Par exemple :

• https://zestedesavoir.com/tutoriels/446/les-promesses-en-javascript/
• https://zestedesavoir.com/forums/sujet/4922/importer-un-module-dans-python-besoin-dexplication/.

Vous remarquez que ce n'est pas très élégant à publier sur les réseau sociaux.

Solution au problème

Je propose de mettre en place un raccourcisseur d'URL qui génère des adresses raccourcies pour chaque article, tutoriel et sujet. Cette URL serait utilisée pour les boutons "Partager" dans le menu de gauche et, pour le forum qui ne possède pas de tels boutons, on pourrait l'insérer directement dans le menu.

Au final une adresse telle que zds.com/1fmO6Z1 (par exemple) pointerait vers un tutoriel tel que celui de Viki53 que j'ai cité plus haut. Ce serait quand même plus sympa à mettre dans un tweet .

Mise en œuvre technique

Pour le nom de domaine on a deux possibilités, soit on utilise le zestedesavoir.com, soit on en acquiert un plus court (je fais confiance à votre imagination) comme zds.com (je ne sais pas si il est disponible).

Pour le service de réduction d'URLs, on peut coder un script maison ou utiliser quelque chose de déjà fait comme YOURLS.

Voilà, dites-moi ce que vous en pensez.

Je suis totalement et définitivement contre. On ne devrait jamais utiliser de raccourcisseur d'URL tant qu'on y est pas contraint et forcé. Ce qui couvre 2 cas :

1. Les URLs sur papier, parce que c'est plus simple à taper (cf ce que fait Canard PC avec cpc.cx)
2. Les services qui imposent une limite forte de caractères (ex : Twitter).

Or, il se trouve que :

1. C'est un cas à la marge, dont la résolution ne rentre pas dans les attributions de Zeste de Savoir.
2. Aujourd'hui, tous les services du genre qui sont très utilisés raccourcissent eux-mêmes les URLs.

Pourquoi les URLs raccourcies ne doivent pas être utilisées tant que ce n'est pas indispensable ? La raison dépend du choix technologique utilisé pour raccourcir l'URL.

• Utilisation d'un service externe : l'URL devient dépendante d'un tiers, qui peut fermer (c'est arrivé, même chez de très gros), tomber en panne, être lent à mourir, etc. Ça fait une redirection supplémentaire par raccourcisseur d'URL utilisé¹, ce qui ralentit l'utilisateur, spécialement sur mobile. De plus, tous ces intermédiaires peuvent collecter des données sur l'utilisateur (et ne s'en privent généralement pas).
• URL raccourcie interne : il faut gérer les URLs en double, ce qui peut vite devenir lourd et poser des problèmes de cohérence, de persistance dans le temps, et de duplication de contenu si un nom de domaine court est utilisé. Plus les coûts additionnel (NDD court = souvent cher, etc.)

Pourquoi ne pas utiliser un raccourcisseur d'URL existant pour ça ? A ma connaissance, il y en a plein qui sont utilisés sur Twitter.

Code en plus, bugs en plus, travail en plus.

Merci pour cette proposition de cette ZEP.

Toutefois, je n'y suis pas très favorable. Le seul objectif de ce raccourcisseur d'URs serait de pouvoir partager sur les réseaux sociaux : ceux-ci ont proposent déjà tout un tas d'outils.

Alors je suis en partie d'accord avec SpaceFox mais j'aimerai rajouter quelques informations.

Utiliser un système externe c'est en être dépendant. Demain ce service ferme ou est hors ligne et les liens ne fonctionnent plus. Là SpaceFox a entièrement raison.

Ce qui est possible en revanche c'est faire quelque chose d'interne assez simple pour les contenus publiés avec le pk.

On pourrait avoir https://zestedesavoir/c/558 pour https://zestedesavoir.com/tutoriels/558/les-arbres-binaires-de-recherche-1/ ou encore https://zestedesavoir/f/4935 pour https://zestedesavoir.com/forums/sujet/4935/zep-38-mise-en-place-dun-raccoucisseur-durl. À réfléchir.

À voir aussi : comment gérer convenablement les redirections pour ne pas se faire sanctionner par les moteurs de recherches (d'autant si on choisi de le faire sur le même NDD)

Ce qui est possible en revanche c'est faire quelque chose d'interne assez simple pour les contenus publiés avec le pk.

PK, Pretty Link ?

Le pk est un identifiant unique pour chaque objet en Django. C'est une Primary Key.

Ah, d'accord. Je n'ai jamais programmé avec Django.

• Utiliser un service externe est effectivement une mauvaise idée.
• Intégrer un raccourciceur à ZdS me semble inutile.
• Acheter un .com à 3 lettres n'est pas réaliste (on m'a fait une offre à 97'000$ pour un .com de 3 lettres il y a moins de 2 mois).
• Avoir des URLs alternatives pour les contenus, plus courtes que les actuelles, me semble en revanche indispensable, et je suis pour une solution à base de routes telle que décrite par gustavi.

Problème

Cette ZEP concerne toutes les URLs potentiellement longues. C'est à dire celles de tous les modèles présents et futurs. En effet, on se dirait volontiers "Ouais mais les pages de profiles feront pas des URLs de 12 pieds de long", mais la limite de longueur d'un username est de 150 caractères sur ZdS.

• https://zestedesavoir.com/tutoriels/686/arduino-premiers-pas-en-informatique-embarquee/745_les-grandeurs-analogiques/3430_les-entrees-analogiques-de-larduino/#2-10725_les-convertisseurs-analogiques-numerique-ou-can
• https://zestedesavoir.com/membres/voir/lorem-ipsum-dolor-sit-ameta-consectetur-adipiscing-elita-curabitur-aliquam-dui-orcia-at-ullamcorper-sapien-porttitor-nona-curabitur-varius-dui-nullama/

Vous remarquez que ce n'est pas très élégant à publier sur les réseau sociaux. Et c'est pas cool pour des raisons purement techniques, typiquement l'utilisation d'URLField (max 255) au lieu de TextFields pour stocker ces URLs en base de donnée.

Solution au problème

Je propose de mettre en place des routes "courtes" pour chaque route utilisant actuellement un slug.

Ces routes se passeront de slugs pour ne reposer que sur des PK.

Mise en œuvre technique

1. Facile techniquement
2. Peu de travail donc vite fait
3. Sans grand risque
4. C'est "gratuit" en terme de ressources serveur
5. Ca permet d'économiser plein de ressources serveur (si on admet que la ZEP-24 utilise un TextField)

PS : Oui j'ai renommé cette ZEP. Si ça se fait pas, je veux bien ouvrir une nouvelle ZEP avec un plus joli numéro que 38. C'est banal, 38.

Facile techniquement

C'est intégré à Django ? Ou faut écrire des routes mappées sur /{typeDeContenu}/{slugId} et lui faire renvoyer une 302;Location=...

(par pure curiosité technique)

@Javier il suffit de faire une vue qui redirige (301 ou 302) si le contenu existe et une 410 sinon. Ça se fait en 1à lignes.

Plus d'informations : https://docs.djangoproject.com/es/1.9/ref/class-based-views/base/#redirectview

Merci pour la doc c'est exactement ce que je cherchais !

Une offre pour un NDD que tu possèdes ?