web-dev-qa-db-fra.com

Pourquoi les slugs post WordPress ne permettent-ils pas les accents?

Si vous créez un article dont le titre a un accent et un autre caractère unicode, par exemple à 漢語 title thing, son slug (permalien) deviendra a-漢語-title-thing... c’est-à-dire que le à aura été converti en un a normal, mais ces caractères chinois unicodes ont été laissés intacts. Pourquoi WordPress ne laisse-t-il pas les caractères accentués? J'ai créé un extrait de code pour dire à WordPress de les laisser tranquille

function mn_sanitize_title($modified_title, $original_title, $context)
{
    // the $modified_title may have had accents removed, but not the $original_title
    return $original_title;
}
// set this filter to run BEFORE WP already ran the title through `sanitize_title_with_dashes`
add_filter('sanitize_title', 'mn_sanitize_title', 5, 3);

et cela semble fonctionner correctement (les caractères accentués sont laissés intacts dans les slug), alors je me demande pourquoi les développeurs WordPress ont supprimé les caractères accentués des slug post?

permalinksslug
3
thespacecamel

La fonction sanitize_title() utilise remove_accents() tout de suite. Ces deux fonctions remontent à <= v1.2.1. La fonction remove_accents() est une liste codée en dur de caractères d’accent pour remplacer explicitement une poignée de caractères dans quelques langues spécifiques. Le commentaire en ligne et la référence de la fonction dire simplement:

Convertit tous les caractères accentuels en ASCII caractères.

Selon RFC 3986, les URL valides ne sont que des fichiers ASCII.

Donc (bien que je ne trouve aucune preuve à ce sujet), je suppose que ce qui se passe ici est que les caractères d’accent sont remplacés pour créer une URL valide pour les langues qui ne comportent que des caractères peu presque-ascii . Et que cela vienne de loin.

L'URL invalide /à-b-c/ devient valide /a-b-c/ (au lieu de /%wtv-b-c/ titre codé valide).

Quant à savoir pourquoi les caractères chinois (qui ne sont pas ASCII) ne sont pas remplacés, rayés ou encodés/échappés par WordPress semble être intentionnel. Encore une fois, je ne trouve aucune documentation à ce sujet, mais les caractères ne sont même pas proches de la valeur ascii-valid comme le sont les caractères accentués susmentionnés, il n’ya donc rien pour les remplacer. Échapper à l'URL serait ridicule, presque inutilisable. Et ce fil entier , et notamment ce post , a jeté un peu de lumière sur ces caractères dans les URL:

[les adresses avec des caractères non-ASCII] ne sont pas des URI (et donc des URL, car les URL sont un type d'URI ). Si nous considérons que nous sommes redevables de la terminologie des normes IETF existantes, nous devrions alors les appeler correctement IRI (Internationalized Resource Identifiers), tels que définis dans RFC 3987 , qui ne sont techniquement pas des URI, mais qui peuvent être convertis en URI simplement par pourcentage. -codage de tous les caractères non-ASCII dans l'IRI.

Je suppose donc que WordPress ne dispose pas de gestionnaires pour ces caractères, il laisse le soin à l'utilisateur et au navigateur dans ces cas-là, mais cela nettoie les accents depuis le début.

(Je me rends compte que cette réponse ne satisfait pas la question, mais j'espère qu'elle fournira un peu plus d'informations pour vous rapprocher de votre réponse).

4
David Sword

Étant donné que nous avons déjà une "réponse", je vais ajouter une "réponse" personnelle, bien que ce ne soit pas davantage une supposition.

L’aspect important est l’état d’i18n il ya plus de 10 ans, et cela vaut non seulement pour les logiciels liés au Web, mais également pour les systèmes d’exploitation eux-mêmes. A l'époque, IDN n'était pas encore un standard et le Web était orienté ASCII. Il n'aurait pas fait beaucoup de bien au Web de devenir meilleur à i18n car presque aucun système d'exploitation majeur ne le supportait tel quel. Par exemple, si vous vouliez des fenêtres prenant en charge l'hébreu, vous deviez acheter une version spéciale ou installer un module linguistique. Mais même si tous les modules de langue appropriés étaient installés, si Browers avait un bogue, il aurait fallu des années avant que les navigateurs ne disposent de nouvelles versions pour les navigateurs. De plus, les serveurs Web avaient également des bogues dans le traitement correct des URL et leur transmission correcte au PHP couche.

La solution pour les scripts latins était simple, il suffit de convertir tout ce qui n’est pas ascii en équivalence morale correcte ASCII. Il est très révélateur que le code ne gère pas l'hébreu bien qu'il présente des problèmes d'accent similaires. Mon hypothèse à propos de l'hébreu est que les deux accents sont moins importants dans le texte lu normalement (les enfants apprennent très tôt à "imaginer" des accents basés sur la compréhension de la Parole dans son contexte, et les endroits où vous en avez réellement besoin sont les suivants: la langue utilise le script hébreu par exemple yiddish ), et que lorsque le Web a vraiment commencé à tourner en Israël, ces bugs étaient pour la plupart corrigés (bien qu’il y ait eu une période au cours de en utilisant de jolis permaliens qui ne sont devenus par défaut que dans 4.4, ou utilisez des slugs en anglais).

Aujourd'hui, je ne pense pas que cette fonction serve à quelque chose et, comme les autres parties du code wordpress, elle est maintenue comme faisant partie de l'inertie et non basée sur les besoins réels.

4
Mark Kaplun