[ Résolu ] [ v 1.3 à 1.5 ] Problème URL sur partie CMS

[Loiseau2nuit]

Bonjour,

Je viens de faire un tour de forum pour voir si mon soucis avait déjà été abordé et il semble que non (ce qui me surprend d'ailleurs, vu la nature du problème)

Voila plusieurs boutiques presta, toutes versions confondues, que je me retrouve heurté à un bug autour de la gestion des url ré-écrite sur la partie CMS de prestashop.

En effet, il semble qu'à la base, lorsque nous créons et rédigeons une page CMS, l'url de celle-ci, en première instance, se constitue d'une version translitérée du titre. Jusque là tout est normal.
On peut à loisir intervenir sur cette URL pour la modifier, la raccourcir, etc... avant publication de la page, jusque là, tout est encore normal.

Ce qui n'est en revanche plus normal du tout, c'est que si dans 2 jours je dois pour X ou Y raison modifier le titre de la page, j'y perds l'url ré-écrite que j'avais paramétré, laquelle redevient la copie translitérée de mon nouveau titre oO ???????


Alors autant la première génération automatique de l'URL est bien, qu'une fois celle-ci générée pour la première fois, il me semble impératif de "casser" la liaison qui existe entre le champ titre et le champ "url simplifiée" non ?

Un correctif est-il prévu ? Sinon, existe t'il une procédure pour "casser" ce comportement erratique ?


Merci par avance pour tout retour

Edited September 11, 2013 by Loiseau2nuit (see edit history)

[Loiseau2nuit]

Personne ????

[Loiseau2nuit]

Mon collègue développeur m'a trouvé un fix en attendant mieux :

 

dans /admin/admin.js, rechercher :

 

function copyMeta2friendlyURL() {
   $('#input_link_rewrite_' + id_language).val(str2url($('#name_' + id_language).val().replace(/^[0-9]+\./, ''), 'UTF-8'));
}

 

et remplacer par :

 

function copyMeta2friendlyURL() {
// Ne générer l'url QUE lors de l'ajout d'une page et empêcher toute modification automatique ultérieure
if (!$('input[name="id_cms"]').val()) {
	  $('#input_link_rewrite_' + id_language).val(str2url($('#name_' + id_language).val().replace(/^[0-9]+\./, ''), 'UTF-8'));
}
}

 

En espérant que ca puisse aider

 

D'un point de vue un peu plus personnel, j'ajouterai qu'il me semble vraiment très important de corriger ce point car si c'est un comportement dit "normal" de l'outil (j'ose croire que non), il est juste hyper dangereux à plusieurs niveaux :

 

Pour le référencement en premier lieu :

Car si prestashop effectue de lui même la redirection 301 de l'ancienne URL vers la nouvelle (heureusement d'ailleurs), en revanche, il ne modifie pas tous les liens internes (menus de navigation, liens "in text", ...) pointant vers cette page, lesquels se retrouvent du coup partiellement erronés, sans parler du signal bien négatif qu'on envois à Google avec nos pages qui changent d'adresse toutes les 5 minutes ...

 

D'un point de vue ergonomie fonctionnelle ensuite :

Car quand je modifie un titre, je modifie un titre ! pas une url !

Comment expliquer au client que sa page s'est cassé la poire sur son principal mot clé parce que sa modif de titre a provoqué un changement d'adresse de la page alors que c'était pas du tout prévu (ni même prévisible) ??? oO

 

Bon week end à tous

 

 

PS : Je ne trouve pas comment editer le titre pour mettre [ Résolu ] :-X

si un modérateur passe par ici ... Merci d'avance

Edited August 23, 2013 by Loiseau2nuit (see edit history)

[indesign47]

Bonsoir Loiseau2nuit,

 

Je posterai ton correctif sur la forge de PrestaShop si tu n'y vois pas d'inconvénient.

 

Merci d'avoir posté la solution pour les lecteurs suivants

 

Si le problème est réglé, mettre le post en [Résolu],

 

Edit le premier post > Use Full Editor et rajouté devant le titre [Résolu]

[oNine]

Car si prestashop effectue de lui même la redirection 301 de l'ancienne URL vers la nouvelle (heureusement d'ailleurs), en revanche, il ne modifie pas tous les liens internes (menus de navigation, liens "in text", ...) pointant vers cette page, lesquels se retrouvent du coup partiellement erronés, sans parler du signal bien négatif qu'on envois à Google avec nos pages qui changent d'adresse toutes les 5 minutes ...

 

je viens de remarquer en testant les en-têtes sur prestashop 1.4 que les redirection 301 vers l'URL canonique que ce soit CMS ou produit (fonction par défaut dans presta) présente une en-tête 200...

 

Quelqu'un a-t-il corrigé cela ?

[Gregory Roussac]

Bonsoir Loiseau2nuit,

 

Je posterai ton correctif sur la forge de PrestaShop si tu n'y vois pas d'inconvénient.

 

Merci d'avoir posté la solution pour les lecteurs suivants

 

Si le problème est réglé, mettre le post en [Résolu],

 

Edit le premier post > Use Full Editor et rajouté devant le titre [Résolu]

Hello,

 

Merci pour la remontée.

 

Sorry si je débarque un peu, @indesign on l'a vu passer ça ou non ? Ma mémoire me lâche un peu sur le coup.

 

@onine, après une 301 c'est une 200 non ? Ou alors je n'ai pas compris.

 

Cordialement.

[indesign47]

Sorry si je débarque un peu, @indesign on l'a vu passer ça ou non ? Ma mémoire me lâche un peu sur le coup.

 

Bonjour Greg,

 

Non, je n'ai pas posté sur la Forge, car je n'ai pas pu (su) reproduire l'erreur lors de la modification du titre de la page CMS.

[Gregory Roussac]

Merci on regarde cela dès que possible.

 

Cordialement

[Loiseau2nuit]

Désolé les gars, je débarque 3 métros après la bataille (pour une raison que j'ignore je n'ai eu que la dernière notif de cette discussion, les autres ont du tomber en spam ou whatever... EDIT : je confirme. mon filtre anti spam est un peu violent ^^)

 

 

@indesign : non absoluement aucun soucis, vas-y gogogo

 

 

@onine comment as tu testé tes entêtes ? Logiquement, quand tu cliques sur un lien interne qui pointe vers une page qui a changé d'adresse, l'onglet réseaux de firebug renvoit bien une 301 avant de se fixer ensuite sur une 200 lorsqu'il est arrivé sur la page de destination

 

Bon après, je vous cache pas que j'ai beau être un casse Fouilles de première sur certains aspects techniques SEO (c'est mon taff) que presta, je connais encore assez peu (plutôt issu du monde spip et thélia moi à l'origine ^^) donc peut être qu'un moyen plus propre de faire des liens internes existe (des liens qui se mettent à jour tout seul en cas de changement d'url) mais je ne l'ai pas encore trouvé :-X

 

@Gregory Roussac alors non 301 et 200 sont 2 entêtes antagonistes. En substance :

 

301 = j'ai changé d'adresse maintenant j'habite ici 

200 = oui, je suis bien là, entrez !

 

Dans le meilleur des mondes possible, tous les liens devraient aboutir direct sur une page en 200. Si vraiment une page DOIT changer d'adresse, la 301 est le meilleur moyen de la rediriger pour ne pas perdre le traffic généré par les liens extérieurs et pour transférer la visibilité acquise de la vieille page vers la nouvelle, mais en interne sur le site, quand trop de liens passent d'abord par une 301 avant d'atterrir sur une 200, pour Google c'est louche et potentielement pénalisant pour la qualité qu'il estime de ton site.

 

@indesign pour ce que j'en ai vu ici, ca impactait tous nos presta de la 1.3 à la 1.5

 

A ce propos, le correctif proposé fonctionne sur les 3 branches. Seul le n° de ligne change

 

 

 

A votre disposition pour toute info complémentaire si besoin

Edited September 11, 2013 by Loiseau2nuit (see edit history)

[indesign47]

Désolé les gars, je débarque 3 métros après la bataille (pour une raison que j'ignore je n'ai eu que la dernière notif de cette discussion

En effet, j'attendais ton retour pour poster sur la forge.

 

@indesign : non absoluement aucun soucis, vas-y gogogo

Maintenant, ce n'est plus la peine...

C'est dans les meilleures mains (tête : houppette ) qu'ils soient : celles de Gregory Roussac.

Edited September 11, 2013 by indesign (see edit history)

[Gregory Roussac]

Hello people,

 

Bon ce qui est bizarre c'est que j'ai du faire une autre modification dans le contrôleur.

 

https://github.com/PrestaShop/PrestaShop/commit/90091d4f2c7d2ae53e2c934489843d1d17c35adb

 

Attention il me semble que $('input[name=id_cms]').val() ne sera pas défini quand on crée un cms. A priori si le champ est présent c'est que c'est une édition et non une création.

 

Merci pour cette remontée et contribution.

 

Cordialement