Réécriture des URL - lequel choisir selon vous ?

[ManuelVoileux]

Bonjour tout le monde

... La principale action se fait dans le contenu qui est travaillé régulièrement, un maillage du site suffisamment étudié de façon à ce que les robots d'indexation puissent faire leur travail. Le niveau de réussite est parfois tellement intense que des fournisseurs obligent mes clients à déférencer des pages produits de leurs sites e-commerce qui font concurrence à leur propre site (c'est du vécu à rendre dingue car c'est le monde à l'envers !)...

Bravo !

[daneel]

Je ressors cette publication car je ne l'avais pas finalisée.
En fait, je retrouve les mêmes difficultés en ayant installé Route 66 sous Joomla 3...
(

Hello, j'ai du rater 2-3 épisodes car je ne vois pas vraiment de difficulté.

Je vais essayer d'être extrêmement simple... sans parler d'extensions mais uniquement joomla.

Pour éviter des urls moches avec des id, des view, component et tout le bazar que doit utiliser joomla, on le cache.
Activé Par défaut, le SEF (Réécriture d'URL en clair) permet de remplacer ces informations par le titre lien de menu, titre des articles ou catégorie donc meilleur pour nous, meilleur pour les moteurs... c'est donc activé par défaut dans la configuration générale donc pas de soucis.

sauf que l'on a index.php qui doit rester pour que le serveur la page à la racine, joomla s'occupe du reste.
La solution, c'est d'activer en plus l'option seo "la réécriture au vol" qui implique de renommer htaccess.txt en .htaccess
donc on le fait, on choisit également d'activer cette option dans configuration du site et ça marche.

Mais pourquoi ? tout simplement, le .htaccess permet de dialoguer avec le serveur pour lui indiquer des modifications par rapport
à la configuration standards comme activer un module php... Justement, le modèle de fichier htaccess.txt contient la ligne "rewriteengine on" qui permet d'activer le module de réécriture des urls donc sans cette ligne... Joomla ou toute extension ne pourront pas utiliser ces fonctions. De plus, dans le fichier .htaccess en lui-même, il est nécessaire d'activer la réécriture avant d'indiquer de créer une règle de redirection donc elle doit être placé au dessus dans les premières lignes du fichier.

Conclusion : le fichier htaccess est nécessaire pour activer la réécriture dans les serveurs apache et litespeed.
Les autres fichiers comme webconfig sont destinés à d'autres serveurs... en majorité, on est sur des configurations apache.

La troisième ligne de configuration seo dans joomla concerne l'ajout de suffixe, généralement j'ajoute le .html à mes pages pour les distinguer des catégories. On s'y retrouve beaucoup mieux !

La quatrième ligne de configuration concerne l'unicode. Cela permet d'avoir des accents dans les urls mais c'est une erreur de les utiliser car cela oblige à convertir en unicode donc on se retrouve avec d'autres urls aussi "moches" avec des % et autres joyeusetés de conversion... Cela ne fait pas terrible dans le partage sur les reseaux sociaux. Donc conclusion : "ne pas toucher !" .... Entre nous, cela sert plus aux langues cyrilliques qu'aux langues latines.

Concernant Gzip, vaut mieux travailler en evitant de l'activer dans joomla... On avisera uniquement après avoir réglé le seo.

En résumé, en activant les trois premières lignes et en renommant htaccess.txt par .htaccess, cela suffit à obtenir des urls propres.


Après que ce soit route66 ou 4seo, les extensions tierces vont permettre de personnaliser et d'améliorer ces urls. C'est vrai que 4SEO est bien joli et contient certainement plus de paramètres que route66 mais ils ne sont en aucun cas nécessaire pour être indexé tout comme avoir un plan de site n'est pas obligatoire... On est plus sur l'amélioration du référencement, avec des guides, de l'optimisation du positionnement... Évidemment que c'est plus séduisant d'avoir une belle interface et si l'outil tient ses promesses alors sans aucun doute, cela vaut la peine de s’intéresser.

Donc si on revient à ton sujet de base, tu n'as pas besoin d'extension pour indexer ton site !
Comme tu l'as compris, le .htaccess est obligatoire mais surtout la ligne qui permet d'activer la réécriture.
Parfois le fichier .htaccess provoque une erreur si celui-ci n'est pas adapté au serveur. Dans ce cas, il faut voir avec l'hebergeur ou d'autres utilisateurs ayant des sites joomla chez cet hebergeur. C'est le cas je crois de ionos.

A titre perso, je suis sur des serveurs litespeed, c'est l'équivalent de serveur apache mais en plus rapide notamment avec l'aide d'un cache spécifique. J'utilise des serveurs assez puissants pour fonctionner rapidement même sans cache. L'indexation se fait instantanément et je travaille mon seo avec suffisamment de connaissances et d'outils pour placer les sites en premiers dans les ventes de produits ou de présence locale. La principale action se fait dans le contenu qui est travaillé régulièrement, un maillage du site suffisamment étudié de façon à ce que les robots d'indexation puissent faire leur travail. Le niveau de réussite est parfois tellement intense que des fournisseurs obligent mes clients à déférencer des pages produits de leurs sites e-commerce qui font concurrence à leur propre site (c'est du vécu à rendre dingue car c'est le monde à l'envers !)...

Ma méthodologie est extrêmement simple, j'étudie ce qui a été fait, les pages déjà référencées, le positionnement par rapport à certains éléments souhaités mais aussi par rapport à la concurrence. J'examine également sur le plan local puis j'obtiens une cartographie du site dans son ensemble. De cette base, je retravaille le contenu, les urls avec les alias des liens de menu et des articles en tenant compte d'effectuer des redirections (j'utilise pour cela des expressions régulières pour éviter par exemple de prendre chaque alias des articles d'une même catégorie si je déplace ou change l'url de la catégorie). Toutes les pages ont des metadonnées description et surtout des titres cohérents mais pas forcément le même que alias. Je néglige pas non plus l'enrichissement de contenu ( balises json-ld ) et les open-graph générés sur mesure par des extensions tierces en attendant une intégration native ( ex : GSD & Social-magick).

Après il y a tout un suivi (notamment avec search console, etc) mais sans utiliser d'extension dédié seo, on peut donc fonctionner pour traiter les urls proprement. C'est seulement si tu veux faire le même travail de positionnement sans forcément connaître les subtilités que tu en auras l'utilité et un gain de temps appréciable.

Note : les alias d'article, catégorie et lien de menu sont des éléments faisant partie de l'url que l'on nomme "segment" que l'on retrouve après le nom de domaine. C'est justement ces mêmes segments que l'on a décrit dans l'explication sur route66.

Voilà, j'essaye juste de t'orienter mais c'est vrai que si je n'ai pas accès au site, je ne vois pas quoi ajouter de plus. Sincèrement, le succès est à la portée de tous ! Si tu rencontre encore des problèmes , contacte moi en pm et je devrai trouver assez rapidement ton erreur.

[gnosis]

Je ressors cette publication car je ne l'avais pas finalisée.

En fait, je retrouve les mêmes difficultés en ayant installé Route 66 sous Joomla 3...

Pour le coup, j'ai acheté 4SEO que je n'ai toujours pas testé ...
Je n'aime pas tester des heures une extension si elle ne marche pas du premier coup. :/
Ma patience se heurte relativement rapidement contre l'informatique

[gnosis]

Il est 23h51, je te remercie une nouvelle fois pour le temps passé à écrire tout cela.
Je suis toujours touché par l'implication mobilisée sur ce forum.
Pour moi c'est une corvée de tenter de comprendre et de régler des soucis informatiques. Mais je persiste !

Je te réponds demain.

Ce que je peux néanmoins ajouter c'est que j'ai réinstallé la dernière version de mon site avant mon passage à J4 pour tester Route 66 et j'étais confronté aux même problèmes.
Donc, j'en conclus que J4 n'est pas responsable du dysfonctionnement de Route 66 ni du https.

Là je n'ai ni le courage ni l'envie de faire de nouveau tests, ça patientera demain Manuel.

Encore merci à toi et vous tous.

[ManuelVoileux]

Bonjour,

• GZIP : oui GZIP est activé dans le htaccess, NON GZIP n'est pas activé dans Joomla, pour moi c'est cohérent.
• SEO Joomla, : les seules fonctions réécriture de Joomla donne des URL plus sympathiques OK. Oui Route 66 vient en surcharge de la ré-écriture de Joomla.

• Ma proposition suivante est de faire 2 tests: As tu un lien de menu vers la liste des articles d'une catégorie, ou le blog d'une catégorie ? A quoi ressemble l'url avec et sans Route 66 en ne mettant que {categoryAlias} dans le paramètre de l'affichage des catégories ?

• https : si ce n'est pas htaccess, ni Joomla, c'est une autre instance.
  • Y a t'il un seul htacess dans le répertoire racine ? Y a t'il d'autres htaccess dans les autres répertoires de ton site ?
  • Aesecure peut avoir installer des fichiers htaccess dans les différents répertoires du site pour les protéger. Supprimer le répertoire Aesecure, fait que tu n'as plus l'application, mais les fichiers que Aesecure a installé peuvent être toujours présents. Ce qui ne devrait pas être un problème. Aesecure installe des règles pour protéger l'accès à des répertoires ou des fichiers sensibles.
  • le https peut être activé directement depuis le site de ton fournisseur d'accès, lorsque tu as demandé un certificat SSL.

En espérant que celà aide

[gnosis]

Manuel,

Ensuite assures toi bien que tu as activé les options SEO Joomla.
Configuration globale, onglet site ,
Réécriture d'URL en clair (SEF) Oui
Réécriture au 'vol' des URL Oui

Désactives les différents plugin route 66.
A ce niveau , même sans route 66 tu devrais avoir des url "sympathiques" même si un peu longues , pas de id= etc.

Qu'en est il ?

Oui, si je n'active que les fonctions de Joomla l'url est comme tu dis plus "sympathique". La seule réécriture de Joomla a toujours fonctionné.

Seulement, je ne sais pas comment vérifier si les paramètres de Route 66 sont pris en compte si je les active.
Car l'association de Joomla ET Route 66 semblait nécessaire pour faire fonctionner Route66, de ce que j'ai cru comprendre dans les réponses précédentes.

D'après moi, Route66 ne fonctionne pas et j'ignore pourquoi.

Je ne comprends pas non plus aujourd'hui pourquoi mon site doit débute par un https systématiquement alors que l'option est désactivée.
Par ailleurs, j'utilisais aeSecure mais j'ai supprimé son répertoire, cela ne devrait pas avoir d'impact normalement.

[gnosis]

Encore merci.
C'est une nouvelle incompréhension dans ce cas car :

1. s'il s'agit bien de cette partie du code concernant GZIP ?Je dois comprendre que GZIP est ici activé :

## GZIP
## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
## directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this file, and you see
## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
## then your server is already gzipping css and js files and you don't need this
## block enabled in your .htaccess
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]

<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip

# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>

2. GZIP via la configuration globale de J4 est désactivée.



Résultat : GZIP semble ici bien configuré.

Par ailleurs : j'ai toujours un HTTPS alors que je ne devrai pas.
Je trouve cela inquiétant que des options aussi importantes ne soient pas prises en compte.

L'adresse de mon site : pardelalhorizon.fr

[ManuelVoileux]

Bonjour ,
c'est le htacess classique de Joomla. Jusqu'ici tout va bien. Attention le Htaccess contient les règles de compression GZIP ( la fin du hatccess) Il ne faut opérer la compression qu'une seule fois. Soit tu la gardes dans le htaccess, et tu désactives le GZIP de Joomla (mon choix), soit tu commentes (tu mets un # devant) les lignes GZIP jusqu'à la fin du htaccess, et tu actives le GZIP de Joomla. Mais pas les 2.
Vérifie Configuration globale, onglet serveur.
Pour le https, il ne vient pas d'une règle du htaccess que tu montres.
tu dois avoir activé Forcer HTTPS. Ce n'est pas un problème, au contraire.


Ensuite assures toi bien que tu as activé les options SEO Joomla.
Configuration globale, onglet site ,
Réécriture d'URL en clair (SEF) Oui
Réécriture au 'vol' des URL Oui

Désactives les différents plugin route 66.
A ce niveau , même sans route 66 tu devrais avoir des url "sympathiques" même si un peu longues , pas de id= etc.

Qu'en est il ?

[gnosis]

Bonsoir Manuel, merci pour ton investissement dans ce problème non résolu.

1.2 Test avec uniquement la réécriture de Route 66
monsite.fr/index.php?option=com_easblog&view=entry&Id=6 ... bref, l'url moche !

Comme tu reprends cette configuration, je la reteste avec :

1. Je désactive toutes les options de réécriture natives de Joomla 4

2. J'ai suivi ton paramétrage dans Route 66 avec :
{articleAlias}
{categoryAlias}



3. Je n'ai rien exclu non plus excepté Akeeba, comme toi.



Résultat : https://monsite.fr/index.php?option=...=27&Itemid=212

D'ailleurs, c'est étrange, c'est un https, c'est nouveau ça ? J'avais jamais remarqué, mais je ne suis pas convaincu que cela soit dû à Route 66.

Je ne sais pas si ceci est à prendre en compte mais avant j'avais SH404 d'installé et je l'ai supprimé avant de migrer vers J4 car SH404 posait problème pour la migration.



Une copie du contenu du htaccess.txt renommé en .htaccess car ceci semblait être un paramètre à prendre en compte :

# @package Joomla
# Copyright (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>
# @license GNU General Public License version 2 or later; see LICENSE.txt
##

##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line 'Options +FollowSymLinks' may cause problems with some server configurations.
# It is required for the use of Apache mod_rewrite, but it may have already been set by
# your server administrator in a way that disallows changing it in this .htaccess file.
# If using it causes your site to produce an error, comment it out (add # to the
# beginning of the line), reload your site in your browser and test your sef urls. If
# they work, then it has been set by your server administrator and you do not need to
# set it here.
##

## MISSING CSS OR JAVASCRIPT ERRORS
#
# If your site looks strange after enabling this file, then your server is probably already
# gzipping css and js files and you should comment out the GZIP section of this file.
##

## OPENLITESPEED
#
# If you are using an OpenLiteSpeed web server then any changes made to this file will
# not take effect until you have restarted the web server.
##

## Can be commented out if causes errors, see notes above.
Options +FollowSymlinks
Options -Indexes

## No directory listings
<IfModule mod_autoindex.c>
IndexIgnore *
</IfModule>

## Suppress mime type detection in browsers for unknown types
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>

## Protect against certain cross-origin requests. More information can be found here:
## https://developer.mozilla.org/en-US/...e_Policy_(CORP)
## https://web.dev/why-coop-coep/
#<IfModule mod_headers.c>
# Header always set Cross-Origin-Resource-Policy "same-origin"
# Header always set Cross-Origin-Embedder-Policy "require-corp"
#</IfModule>

## Disable inline JavaScript when directly opening SVG files or embedding them with the object-tag
<FilesMatch "\.svg$">
<IfModule mod_headers.c>
Header always set Content-Security-Policy "script-src 'none'"
</IfModule>
</FilesMatch>

## These directives are only enabled if the Apache mod_rewrite module is enabled
<IfModule mod_rewrite.c>
RewriteEngine On

## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site then comment out the operations listed
# below by adding a # to the beginning of the line.
# This attempts to block the most common type of exploit `attempts` on Joomla!
#
# Block any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root home page
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.

## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects

##
# Uncomment the following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##

# RewriteBase /

## Begin - Joomla! core SEF Section.
#
# PHP FastCGI fix for HTTP Authorization, required for the API application
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
# -- SEF URLs for the API application
# If the requested path starts with /api, the file is not /api/index.php
# and the request has not already been internally rewritten to the
# api/index.php script
RewriteCond %{REQUEST_URI} ^/api/
RewriteCond %{REQUEST_URI} !^/api/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the /api/index.php script
RewriteRule .* api/index.php [L]
# -- SEF URLs for the public frontend application
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.
</IfModule>

## These directives are only enabled if the Apache mod_rewrite module is disabled
<IfModule !mod_rewrite.c>
<IfModule mod_alias.c>
# When Apache mod_rewrite is not available, we instruct a temporary redirect
# of the start page to the front controller explicitly so that the website
# and the generated links can still be used.
RedirectMatch 302 ^/$ /index.php/
# RedirectTemp cannot be used instead
</IfModule>
</IfModule>

## GZIP
## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
## directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this file, and you see
## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
## then your server is already gzipping css and js files and you don't need this
## block enabled in your .htaccess
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]

<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip

# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>

Merci encore à vous tous si certains on des idées...

[ManuelVoileux]

Bonjour, je ne comprends pas bien non plus. Une piste peut être. Tu dis

1.2 Test avec uniquement la réécriture de Route 66
monsite.fr/index.php?option=com_easblog&view=entry&Id=6 ... bref, l'url moche !

Est ce que Easyblog a été déclaré comme exception pour Route 66 ?
voici ma copie d'écran des paramètres du composant, où j'ai activé les liens canoniques, les redirections 301, et écarté icagenda et Akeeba backup

[gnosis]

Encore merci à vous pour les explications illustrées de captures d'écran, c'est super sympa.

Pour ma part, je suis allé dans le FTP via Filezilla et j'ai

1. Remplacer le fichier .htaccess par _.htaccess afin qu'il ne soit plus pris en compte
2. Remplacer le fichier htaccess.txt par .htaccess
3. Configurer Route 66 comme sur mes captures d'écran avec :

Article URL Pattern : {articleAlias}
Category URL Pattern : {categoryAlias}

Tests:
1. Route 66 configuré comme sur mes captures d'écran + Réécriture de Joomla --> Des liens ne fonctionnent plus
2. Route 66 configuré comme sur mes captures d'écran + Réécriture de Joomla + réécriture au "vol" de Joomla --> Des liens ne fonctionnent plus
3. Route 66 configuré comme sur mes captures d'écran + Réécriture de Joomla + réécriture au "vol" de Joomla + suffixe aux URL de Joomla --> Des liens ne fonctionnent plus

4. Juste Joomla avec + Réécriture de Joomla + réécriture au "vol" de Joomla + suffixe aux URL de Joomla --> Des liens ne fonctionnent plus ou la mise en page à complètement changée
5. Juste Joomla avec + Réécriture de Joomla + réécriture au "vol" de Joomla --> Tous les liens fonctionnent
6. Juste Joomla avec + Réécriture de Joomla --> Tous les liens fonctionnent

J'ai fait ces tests en parfait débutant, naturellement.

Je ne comprends pas pourquoi cela ne fonctionne pas, l'association Joomla + Route 66.

Par ailleurs, je lis dans Joomla, dans la configuration global et la réécriture au vol des URLS, je n'ai pas touché au fichier web.config.txt mais je ne pense pas que cela soit nécessaire;

[daneel]

Bonjour tout le monde,


Est il possible d'imaginer que Route 66 soit intégré à un Joomla 5 ou 6 ? comme les champs personnalisés en son temps.

Il y a des pistes d'améliorations et du travail déjà engagé notamment lors des Google Summer of Code.

https://github.com/alisha-kamat/GSoC-2022-Work-Report

Voilà un exemple de ce que donnerait l'équivalent du guide de route66 dans Joomla :






Attention, ceci est un projet d'étudiant (avec preuve de concept tout de même) et le chemin est assez long mais cela donne envie, non ?...

[daneel]

gnosis

A mon humble avis et d'après mes souvenirs, route66 ne remplace pas la réécriture mais surcharge l'existant.
Comme expliqué par manuel.

Le fichier htaccess.txt doit être renommé en .htaccess obligatoirement si on veut l'activation du module php sur les serveurs apache ou litespeed.
On ne peut pas échapper à cette activation... dans le fichier .htaccess c'est tout simplement la ligne RewriteEngine On qui donne l'ordre d'activer la réécriture.

La gestion de la réécriture doit être active dans Joomla afin que le routeur soit fonctionnel :



1. La réécriture d'url en clair (SEF) : cela permet remplace les valeurs (option, view...) par le titre de l'article ou de la catégorie.

2. Réécriture au "vol" des URL : c'est la suppression d'index.php

3. Le suffixe aux url : c'est pour ajouter .html aux articles et les distinguer des url de catégorie

4. Unicode : ne pas activer sinon tu auras des accents dans les urls mais mal interprété dans le partage sur les reseaux sociaux ou la copie.
En réalité, cette option est plus pour les langues cyrilliques.

Le nouveau routeur a été ajouté dans joomla 3 et permet de supprimer les id des urls nativement.
En option dans J3 (par rapport à l'ancien), il est désormais par défaut dans joomla 4.
Fonctionne parfaitement, je n'ai pas rencontré de problème.

Note : si la réécriture SEF est active mais pas la réécriture au vol, on aura des url avec index.php
C'est la configuration à l'installation de joomla avant la personnalisation car joomla peut s'installer aussi sur d'autres configuration qui n'utilise pas le
fichier htaccess ( nginx, windows server ). Donc si tu veux faire disparaître index.php, c'est bien la réécriture au vol qu'il faut activer nécessairement (avec le .htaccess actif si ton serveur est un serveur apache ou litespeed). Bref, exactement comme sur la capture d'écran.

Certains liens internes ne sont pas toujours définis en lien de menu, cela peut provoquer de mauvaise url avec index.php.
Par exemple l'erreur courante, c'est de ne pas définir de lien de menu pour la page de création de compte ou de mot de passe oublié.
Pour éviter cela, il suffit simplement de créer un menu caché dans lequel on ajoutera les liens vers ces pages qui ne sont pas liés à un menu existant.

[gnosis]

Il y a dans vos réponses beaucoup d'informations, je vais relire ceci calmement.

1. Dans un premier temps et concernant "Route 66" (Merci à Sam et Manuel)

J'avais bien lu la doc et j'avais entré ces mêmes paramètres mais cela n'avait produit aucun effet avec
:
Article URL Pattern : {articleAlias}
Category URL Pattern : {categoryAlias}

J'ai réessayé ce matin et j'observe le même problème.

Pour moi, il fallait soit activer la réécriture proposée par Joomla OU BIEN activer la réécriture proposée par une extension tierce (comme c'était le cas avec SH404) mais jamais les deux.
Car, selon moi, une seule réécriture d'URL est possible et non pas par la combinaison de deux fonctionnalités.

Mais d'après toi, Manuel, ceci n'est pas incompatible avec la partie SEO de Joomla.

Au final, je n'observe aucune réécriture "courte" de tite site.fr/article ou site.fr/category que j'active Route 66 ou bien l'association Route 66 et Joomla

1.1 Test avec uniquement la réécriture de Joomla
monsite.fr/index.php/titre-menu/titre-sous-menu/menu/entry/nom-article

1.2 Test avec uniquement la réécriture de Route 66
monsite.fr/index.php?option=com_easblog&view=entry&Id=6 ... bref, l'url moche !

1.3 Test avec Route 66 et Joomla
Même effet que test 1.1

A noté que mes articles sont rédigés avec Easyblog mais je ne pense pas que cela ait une quelconque incidence.




2. Cette première sensibilisation au référencement (Merci à toi Daneel)

Je prends bien en compte toutes ces informations.
Je m'appliquerai et m'investirai par la suite pour améliorer l'écriture de mes urls et toute la stratégie nécessaire pour mettre en avant mon site.

Je comprends que XMAP peut aussi être installé, d'ailleurs une erreur se produisait à l'ouverture du composant. Je comprends que celui-ci est aujourd'hui obsolète.

[ManuelVoileux]

Bonjour tout le monde,

... route66 qui dispose d'un guide intégré (idéal lors de la rédaction de l'article) et d'outils comme la possibilité de définir un modèle (pattern) constitué de plusieurs segment indiqué dans l'édition du pattern de l'article ou de la catégorie d'article...

Est il possible d'imaginer que Route 66 soit intégré à un Joomla 5 ou 6 ? comme les champs personnalisés en son temps.