Si nous suivons un lien disparu, c’est comme si nous n’étions plus membres :
C’est comme si une crise s’était produite.
D’après ce que je sais, c’est toujours le cas :
Ainsi, une erreur générée par un mauvais lien entrant servira la page plate, tandis qu’une erreur provenant d’un mauvais lien navigué en interne contiendrait toujours ces éléments.
Je vois. J’espère que Deleted topics lead to error page ne déclenchera bientôt plus cela en premier lieu.
Juste un autre rappel : je travaille principalement avec le contenu et la manière dont les humains l’utilisent, et je suis webmaster, administrateur système et administrateur de tout simplement parce que je suis un pauvre petit poisson…
Mais — le problème est-il si simple que, parce que Discourse est une solution web un peu atypique 
, il est plus difficile, voire impossible, d’envoyer du contenu basé sur JS lors de la diffusion d’une erreur de statut HTML 404 qui nécessite un contenu statique dans le sens où le client le voit ? Je ne sais pas du tout ce que disent le W3C, les RFC, etc.
Non ? Pas du tout ?
Je pensais que les pages web pouvaient avoir à la fois des parties script et noscript.
Mais Discourse n’est pas une page Web, c’est une application JavaScript monopage.
Si vous visitez l’application via une route inexistante, comme un lien brisé, vous recevez une page 404 statique qui est stylisée pour ressembler au reste du site. Elle ne fait pas partie de l’application, donc elle ne peut pas fonctionner comme elle.
Si vous cliquez sur un lien interne (depuis l’application) vers une page qui n’existe pas, elle vous sert une erreur 404 au sein même de l’application.
Ce ne sont pas la même chose.
