Des lignes étranges non système ajoutées à core_url_rewrite

Notre core_url_rewritetableau semble augmenter de manière excessive (21 millions de lignes actuellement) - je sais qu'il y a eu d'autres questions à ce sujet, mais aucune d'entre elles ne semble mentionner cette bizarrerie particulière: beaucoup de nouvelles lignes ajoutées l'ont été is_system = 0, et id_pathc'est quelque chose comme " 97704000_1422557940 ". Le nombre après le trait de soulignement semble être l'horodatage auquel la ligne a été ajoutée, mais je ne sais pas quel est le premier nombre.

Le conseil pour les core_url_rewriteproblèmes semble toujours être de tronquer la table et de réindexer, et cela peut arriver à cela, mais nous avons beaucoup de réécritures personnalisées dans la table, donc devoir constamment les rajouter va être une vraie douleur , et je préfère de loin aller à la racine du problème.

Nous venons de passer à la version 1.9.1.0, mais il y a des lignes dans le tableau qui remontent à près de deux ans (!).

Des idées?

Il s'agit d'un problème classique avec les réécritures. La cause première n'est pas d'avoir des clés URL uniques. Généralement causé par la présence de produits simples configurables avec le même nom.

Pour des raisons évidentes, un chemin de requête (URL) doit correspondre à une action dans Magento. Par conséquent, tous les chemins de demande doivent être uniques. Les chemins d'URL de produit et de catégorie sont créés à partir de leurs clés d'URL et, généralement, lorsque vous avez des produits configurables, les propriétaires de magasin / travailleurs principaux ne prennent pas le temps de s'assurer que les produits simples sous un configurable ont des clés d'URL différentes. Cela oblige Magento à insérer un tiret et un numéro de séquence. Étant donné un produit configurable avec 4 simples, cela signifie qu'au moins 4 URL avec une séquence sont ajoutées à chaque itération (car Magento ne fait pas / ne peut pas distinguer entre les exécutions qu'une séquence est déjà créée). Cela s'additionne rapidement dans un grand catalogue.

Le workflow à récupérer est le suivant:

1. Assurez-vous que toutes les clés URL sont uniques et corrigez votre saisie et effectuez une nouvelle réindexation des réécritures.
2. Supprimez toutes les réécritures qui correspondent WHERE id_path LIKE "%_%" AND options="RP" AND (catalog_id IS NOT NULL OR product_id IS NOT NULL) AND target_path NOT IN (temp_table).
3. Pour les réécritures correspondantes restantes, WHERE id_path LIKE "%_%" AND options="RP" AND (catalog_id IS NOT NULL OR product_id IS NOT NULL)définissez request_path sur target_path et définissez target_path sur request_path qui correspond à la combinaison category_id-product_id et où les options SONT NULES.
4. Installez cette extension et activez toutes les optimisations
5. La réindexation réécrit au moins deux fois, en vérifiant que le nombre de lignes est cohérent (sans changement de produits ou de catégories).
6. Surveillez les outils pour les webmasters et les 404 pour les URL périmées supplémentaires qui sont toujours dans les araignées et doivent être redirigées. Implémentez de préférence le 301 dans votre serveur Web pour rester core_url_rewritepropre.

Remarques: Ce script aide à créer des clés URL uniques, en itérant les valeurs d'attribut et en les ajoutant jusqu'à ce qu'une clé unique soit générée. Notez que ce script ne vérifie pas les conflits entre une catégorie et un produit. En règle générale, ce n'est pas un problème, car les catégories sont naturellement nommées au pluriel, mais si vous vendez par exemple des moutons ou du poisson, cela peut toujours être un problème. Un autre cas d'angle est un conflit entre les URL de catalogue et les pages CMS. Ce script ne le vérifie pas, mais il n'a pas non plus d'impact sur les réécritures car les identifiants de page CMS ne s'y trouvent pas. Cela se traduira simplement par l'affichage de la page CMS ou de la page catégorie / produit là où l'on s'attend à voir l'autre.

La table_temp mentionnée doit être remplie d'URL qui se trouvent dans tous les plans de site. Cela atténue une partie de l'impact SEO en conservant la variante actuelle du tiret et du numéro de séquence et à l'étape 3, elle est ensuite réécrite dans l'URL correcte. L'extension de l'étape 4 empêche un certain nombre d'URL d'entrer dans la table core_url_rewrite, notamment les produits qui ne sont pas définis sur la visibilité "catalogue / recherche". Lorsque vous avez des produits simples qui font partie d'un configurable et qui ne sont pas répertoriés séparément, ceux-ci doivent être marqués "non visibles individuellement" et cette extension les empêche alors d'entrer des réécritures. Il s'agit d'une optimisation précieuse pour les magasins avec des produits configurables, indépendamment de leur problème de réécriture d'URL. Concernant l'étape 5, si aucune modification n'est apportée aux clés URL des produits et catégories, alors chaque indexation doit générer le même nombre de réécritures. Si ce n'est pas le cas, vous avez toujours un conflit quelque part et devez le traquer.

J'espère que cela clarifie un peu les choses.

Je pense que ce sont généralement des redirections générées par programme lorsque vous modifiez des produits et des catégories dans le catalogue. Ils sont destinés à conserver les anciens liens pour envoyer des clients vers les nouveaux emplacements, mais vous pouvez probablement les purger après un certain temps car ils ont tendance à se développer au fil du temps, surtout si vous avez plusieurs sites Web / magasins / vues et beaucoup de produits.