Magento core_url_rewrite table excessivement grande

105

J'ai remarqué un grand nombre de rapports selon lesquels ce tableau lui-même peut devenir extrêmement encombré. Je gère un site avec environ 5 000 SKU et environ 250 catégories (magasin à magasin unique), ce qui entraîne core_url_rewrite tableau de plus de 600 000 lignes et de plus de 500 Mo, qui est fou.

Cela peut ralentir les performances du site et générer une base de données très volumineuse. J'ai creusé et trouvé quelques articles à ce sujet, notamment:

// Ces liens ont été supprimés depuis la mise en place des nouveaux conseils.

Je comprends maintenant que le tableau peut être tronqué et réindexé, mais cela ne résout pas le problème, il ne fait que prolonger le problème.

D'après ce que j'ai compris, une partie du problème concerne les produits qui ont la même clé URL basée sur le nom du produit, ce qui entraîne des liens indexés.

Un correctif mentionné est:

app/code/core/Mage/Catalog/Model/Url.php en ligne ~ 807:

Changement:

 if ($product->getUrlKey() == '' && !empty($requestPath)
       && strpos($existingRequestPath, $requestPath) === 0
 ) 

À:

 if (!empty($requestPath)
       && strpos($existingRequestPath, $requestPath) === 0
 ) 

Mais même cela ne résout pas complètement le problème.

Ma question est la suivante:

Si vous avez rencontré ce problème, avez-vous réussi à mettre en place un système efficace, logique et efficace? algorithme , qui ne consiste pas à "gérer" le problème de manière répétée, mais à résoudre le problème une fois pour toutes?

Serait vraiment apprécier un aperçu de ce sujet .

BTW: S'il vous plaît, faites-vous une faveur et vérifiez à quoi ressemble votre table, vous êtes peut-être confronté à ce problème et à l'impact sur les performances qui en résulte sans même le savoir - je ne l'ai pas fait.

Edit: j’ai été en contact avec www.Nexcess.net (un partenaire d’hébergement Magento Platinum) et ils ont confirmé que leurs clients avaient demandé à leur core_url_rewritetable d’être tronquée parce qu’elle était trop volumineuse.

L’un de mes soucis majeurs est l’impact SEO que cela peut avoir, c’est la raison pour laquelle je voudrais une solution plutôt que de remettre à plus tard la question.

Mise à jour: Nexcess a mentionné qu'avec les produits en double figurant dans le tableau, il pourrait en réalité nuire au référencement tel quel.

élan
la source
Wow, c'est une table incroyablement grande. J'ai vérifié moi-même (200 produits) et il ne contient qu'environ 800 lignes, mais nous n'avons pas de problème pour dupliquer le nom du produit / les URL. À titre de référence, nous avons environ 6,6 lignes par produit visible. Je vais admettre que cette comparaison n’est pas très réaliste, mais à ce rythme-là, avec 5 000 produits, nous n’avons que 30 000 lignes environ. Je peux bien comprendre votre besoin de solution et je regarderai cette question au moment de mettre en place un site beaucoup plus grand.
Pete855217
@ Pete855217: cette question vous semble intéressante même si vous ne l'aviez pas votée.
Mohammad Faisal
1
Il y avait un bogue dans EE1.12 qui provoquait la recréation de nouvelles écritures à chaque sauvegarde. Il est possible que votre version de 1.7 ait le même bogue. Si je me souviens bien, le correctif pour la version 1.12 a également fonctionné sur la version 1.7
brentwpeterson
1
Article très utile! Nous avons 130 000 produits actifs et 25 000 produits désactivés, notre core_url_rewrite_table contient 2744023 enregistrements ..... alors cette semaine, nous allons travailler pour remédier à cela !! Cet article semble être un bon point de départ.
MagentoMac
Modifié le message pour inclure comment ne pas supprimer vos réécritures personnalisées dans Magento.
Espradley

Réponses:

76

J'ai réussi à stabiliser le problème comme suit:

Étape 1: réécrivez le modèle d'URL de catalogue (à l'aide de votre propre module: Comment )

Remarque: Si vous écrasez le fichier principal sans utiliser de réécriture, cela rendra votre instance de Magento inutilisable.

Selon la solution de Jahnni sur les forums MagentoCommerce(n'est plus actif avec le nouveau tableau), app/code/core/Mage/Catalog/Model/Url.php[autour de la ligne 807 Mage_Catalog_Model_Url::getProductRequestPath()]

De:

if ($product->getUrlKey() == '' && !empty($requestPath)
   && strpos($existingRequestPath, $requestPath) === 0
) 

À:

if (!empty($requestPath)
           && strpos($existingRequestPath, $requestPath) === 0
) 

Étape 2: tronquer

Tronquer la core_url_rewritetable

Étape 3: Réindexer et vider les caches

Lancer le processus de réindexation sur les réécritures d'URL principales. Ensuite, vous voudrez vider le cache de Magento et le cache de stockage.

SystemCache ManagementFlush Magento Cache

SystemCache ManagementFlush Cache Storage

Voilà, vous êtes tous ensemble. Vous remarquerez que si vous réexécutez l'indexeur, la taille de la table doit rester constante (à moins que vous n'ayez ajouté plus de produits entre les deux ou si vous avez des noms de catégorie en double).

élan
la source
5
Ma table core_url_rewrite était de 3,2 Go, elle est maintenant de 36,8 Mo: D par muppet
Fabian Blechschmidt
J'ai le même problème. La réécriture d'URL Magento ajoute un nombre aléatoire dans l'URL. Veuillez regarder la capture d'écran ci-jointe à partir de Google Web Master Tools. Comme vous pouvez le voir, le produit "Beige Embroidered Wedding Saree" a neuf URL différentes, mais il ne s'agit que d'un produit et pointant vers une seule URL se terminant par 878. La clé de l'URL actuelle ne comporte pas un nombre aléatoire à la fin (capture d'écran jointe ). Mon magasin est relativement nouveau et la taille de core_url_rewrite n’est pas si grande. Je ne suis donc pas sûr de devoir passer aux étapes 1 et 2 ou uniquement à l’étape 1. Si je réalise l’étape 2, je perdrai mes réécritures personnalisées.
Zoya
Je suis en cours d'exécution 1.9.1 et voici les URL de capture d'écran manquées. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
Zoya
2
Je voudrais d'abord exporter la table existante. Ensuite, je passerais aux étapes 1, 2 et 3. Examinez core_url_rewritemaintenant le tableau et notez le nombre d'enregistrements. Exécutez à nouveau l'étape 3 (la réindexation) et actualisez votre vue sur la core_url_rewritetable. Si le nombre est identique, vous avez résolu le problème. Puis poursuivez et fusionnez manuellement vos réécritures personnalisées. Bonne chance.
Moose
2
Ce correctif ne fonctionne que pour les produits, pas pour les catégories avec des clés URL identiques. Voir la réponse de @Simon s pour une meilleure solution (avec le fichier de correctif)
Giel Berkers
45

J'espère que quelqu'un ici apportera une réponse, mais je ne sais pas si vous en trouverez une. Cette table devient volumineuse pour différentes raisons. Les bogues dans les versions antérieures (et éventuellement actuelles) de Magento en sont un. Une autre solution réside dans la logique de ce tableau qui tente de suivre les modifications apportées à la valeur de la clé d'URL afin que les réécritures 301/302 soient configurées pour les anciens produits. Pour cette raison, et pour compliquer les choses, tronquer la table et la régénérer peut faire disparaître les réécritures d'URL existantes, et cela aura un effet inconnu sur la liste de votre moteur de recherche (pas nécessairement mauvais, mais difficile à prévoir).

Mon conseil général aux clients qui demandent est

  1. Laissez la table de croissance géante telle quelle si vous ne maîtrisez pas bien votre situation URL / SEO

  2. Jusqu'à ce que la taille de la table commence à poser problème (génération de cartes de site, par exemple). Lorsque cela se produit, obtenez un aperçu de votre situation URL / référencement.

  3. Une fois que vous avez un aperçu de votre situation URL / SEO, sauvegardez la table, puis tronquez la table et régénérez. Adressez tous les problèmes d'URL / SEO causés par la troncature.

  4. Automatiser l'étape 3

Essayer de résoudre ce problème au niveau du code Magento est admirable, mais vous nagerez en amont. Parfois, il est préférable d’accepter que "C’est juste que Magento soit Magento" et de résoudre le problème avec un processus externe.

Alan Storm
la source
merci pour le conseil, c'est dommage pour la situation mais je pense que cela va devoir être traité par un processus externe comme tu l'as mentionné, urgh.
Moose
2
Cette table géante peut déjà causer des problèmes de référencement, car la règle pour un produit donné changera constamment. Si vous avez une storeview séparée pour mobile et ordinateur de bureau, c'est encore pire car leurs URL diffèrent.
Melvyn
Un peu décevant réponse à moi ...
partir de
@Alan Storm, que pensez-vous de la réponse postée par Moose après avoir posté cette réponse? Voyez-vous les mêmes risques?
Goose
24

J'aimerais ajouter un correctif pour ce bogue d'indexeur de réécriture d'URL qui a été développé lors du bugathon en mars 2013 et qui a été amélioré par la suite. Cela devrait résoudre ce problème. À titre de référence, voici le fichier de correctif à partir du lien:

diff -rupN mage_org/app/code/core/Mage/Catalog/Model/Url.php src_shop/app/code/core/Mage/Catalog/Model/Url.php
--- mage_org/app/code/core/Mage/Catalog/Model/Url.php   2013-11-19 00:48:25.679009391 +0100
+++ src_shop/app/code/core/Mage/Catalog/Model/Url.php   2013-11-19 00:49:24.188005601 +0100
@@ -643,13 +643,24 @@ class Mage_Catalog_Model_Url
                 $this->_rewrite = $rewrite;
                 return $requestPath;
             }
+
+            // avoid unnecessary creation of new url_keys for duplicate url keys
+            $noSuffixPath = substr($requestPath, 0, -(strlen($suffix)));
+            $regEx = '#^('.preg_quote($noSuffixPath).')(-([0-9]+))?('.preg_quote($suffix).')#i';
+            $currentRewrite = $this->getResource()->getRewriteByIdPath($idPath, $storeId);
+            if ($currentRewrite && preg_match($regEx, $currentRewrite->getRequestPath(), $match)) {
+                $this->_rewrite = $currentRewrite;
+                return $currentRewrite->getRequestPath();
+            }
+
             // match request_url abcdef1234(-12)(.html) pattern
             $match = array();
             $regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
             if (!preg_match($regularExpression, $requestPath, $match)) {
                 return $this->getUnusedPath($storeId, '-', $idPath);
             }
-            $match[1] = $match[1] . '-';
+            $match[1] = $noSuffixPath . '-'; // always use full prefix of url_key
+            unset($match[3]); // don't start counting with a possible number in the url_key
             $match[4] = isset($match[4]) ? $match[4] : '';

             $lastRequestPath = $this->getResource()


De plus, j'aimerais ajouter le correctif EE PATCH_SUPEE-389_EE_1.12.0.2_v2.sh, qui est maintenant disponible sur GitHub :

#!/bin/bash
# Patch apllying tool template
# v0.1.2
# (c) Copyright 2013. Magento Inc.
#
# DO NOT CHANGE ANY LINE IN THIS FILE.

# 1. Check required system tools
_check_installed_tools() {
    local missed=""

    until [ -z "$1" ]; do
        type -t $1 >/dev/null 2>/dev/null
        if (( $? != 0 )); then
            missed="$missed $1"
        fi
        shift
    done

    echo $missed
}

REQUIRED_UTILS='sed patch'
MISSED_REQUIRED_TOOLS=`_check_installed_tools $REQUIRED_UTILS`
if (( `echo $MISSED_REQUIRED_TOOLS | wc -w` > 0 ));
then
    echo -e "Error! Some required system tools, that are utilized in this sh script, are not installed:\nTool(s) \"$MISSED_REQUIRED_TOOLS\" is(are) missed, please install it(them)."
    exit 1
fi

# 2. Determine bin path for system tools
CAT_BIN=`which cat`
PATCH_BIN=`which patch`
SED_BIN=`which sed`
PWD_BIN=`which pwd`
BASENAME_BIN=`which basename`

BASE_NAME=`$BASENAME_BIN "$0"`

# 3. Help menu
if [ "$1" = "-?" -o "$1" = "-h" -o "$1" = "--help" ]
then
    $CAT_BIN << EOFH
Usage: sh $BASE_NAME [--help] [-R|--revert] [--list]
Apply embedded patch.

-R, --revert    Revert previously applied embedded patch
--list          Show list of applied patches
--help          Show this help message
EOFH
    exit 0
fi

# 4. Get "revert" flag and "list applied patches" flag
REVERT_FLAG=
SHOW_APPLIED_LIST=0
if [ "$1" = "-R" -o "$1" = "--revert" ]
then
    REVERT_FLAG=-R
fi
if [ "$1" = "--list" ]
then
    SHOW_APPLIED_LIST=1
fi

# 5. File pathes
CURRENT_DIR=`$PWD_BIN`/
APP_ETC_DIR=`echo "$CURRENT_DIR""app/etc/"`
APPLIED_PATCHES_LIST_FILE=`echo "$APP_ETC_DIR""applied.patches.list"`

# 6. Show applied patches list if requested
if [ "$SHOW_APPLIED_LIST" -eq 1 ] ; then
    echo -e "Applied/reverted patches list:"
    if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
    then
        if [ ! -r "$APPLIED_PATCHES_LIST_FILE" ]
        then
            echo "ERROR: \"$APPLIED_PATCHES_LIST_FILE\" must be readable so applied patches list can be shown."
            exit 1
        else
            $SED_BIN -n "/SUP-\|SUPEE-/p" $APPLIED_PATCHES_LIST_FILE
        fi
    else
        echo "<empty>"
    fi
    exit 0
fi

# 7. Check applied patches track file and its directory
_check_files() {
    if [ ! -e "$APP_ETC_DIR" ]
    then
        echo "ERROR: \"$APP_ETC_DIR\" must exist for proper tool work."
        exit 1
    fi

    if [ ! -w "$APP_ETC_DIR" ]
    then
        echo "ERROR: \"$APP_ETC_DIR\" must be writeable for proper tool work."
        exit 1
    fi

    if [ -e "$APPLIED_PATCHES_LIST_FILE" ]
    then
        if [ ! -w "$APPLIED_PATCHES_LIST_FILE" ]
        then
            echo "ERROR: \"$APPLIED_PATCHES_LIST_FILE\" must be writeable for proper tool work."
            exit 1
        fi
    fi
}

_check_files

# 8. Apply/revert patch
# Note: there is no need to check files permissions for files to be patched.
# "patch" tool will not modify any file if there is not enough permissions for all files to be modified.
# Get start points for additional information and patch data
SKIP_LINES=$((`$SED_BIN -n "/^__PATCHFILE_FOLLOWS__$/=" "$CURRENT_DIR""$BASE_NAME"` + 1))
ADDITIONAL_INFO_LINE=$(($SKIP_LINES - 3))p

_apply_revert_patch() {
    DRY_RUN_FLAG=
    if [ "$1" = "dry-run" ]
    then
        DRY_RUN_FLAG=" --dry-run"
        echo "Checking if patch can be applied/reverted successfully..."
    fi
    PATCH_APPLY_REVERT_RESULT=`$SED_BIN -e '1,/^__PATCHFILE_FOLLOWS__$/d' "$CURRENT_DIR""$BASE_NAME" | $PATCH_BIN $DRY_RUN_FLAG $REVERT_FLAG -p0`
    PATCH_APPLY_REVERT_STATUS=$?
    if [ $PATCH_APPLY_REVERT_STATUS -eq 1 ] ; then
        echo -e "ERROR: Patch can't be applied/reverted successfully.\n\n$PATCH_APPLY_REVERT_RESULT"
        exit 1
    fi
    if [ $PATCH_APPLY_REVERT_STATUS -eq 2 ] ; then
        echo -e "ERROR: Patch can't be applied/reverted successfully."
        exit 2
    fi
}

REVERTED_PATCH_MARK=
if [ -n "$REVERT_FLAG" ]
then
    REVERTED_PATCH_MARK=" | REVERTED"
fi

_apply_revert_patch dry-run
_apply_revert_patch

# 9. Track patch applying result
echo "Patch was applied/reverted successfully."
ADDITIONAL_INFO=`$SED_BIN -n ""$ADDITIONAL_INFO_LINE"" "$CURRENT_DIR""$BASE_NAME"`
APPLIED_REVERTED_ON_DATE=`date -u +"%F %T UTC"`
APPLIED_REVERTED_PATCH_INFO=`echo -n "$APPLIED_REVERTED_ON_DATE"" | ""$ADDITIONAL_INFO""$REVERTED_PATCH_MARK"`
echo -e "$APPLIED_REVERTED_PATCH_INFO\n$PATCH_APPLY_REVERT_RESULT\n\n" >> "$APPLIED_PATCHES_LIST_FILE"

exit 0


SUPEE-389 | EE_1.12.0.2 | v1 | 53c8ca52583358953b143aaa1a78cf409e8dd846 | Thu Jun 20 10:36:39 2013 +0300 | v1.12.0.2..HEAD

__PATCHFILE_FOLLOWS__
diff --git app/code/core/Mage/Catalog/Model/Url.php app/code/core/Mage/Catalog/Model/Url.php
index fa55fc5..a755b46 100644
--- app/code/core/Mage/Catalog/Model/Url.php
+++ app/code/core/Mage/Catalog/Model/Url.php
@@ -609,6 +609,23 @@ class Mage_Catalog_Model_Url
      */
     public function getUnusedPath($storeId, $requestPath, $idPath)
     {
+        $urlKey = '';
+        return $this->getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey);
+    }
+
+    /**
+     * Get requestPath that was not used yet.
+     *
+     * Will try to get unique path by adding -1 -2 etc. between url_key and optional url_suffix
+     *
+     * @param int $storeId
+     * @param string $requestPath
+     * @param string $idPath
+     * @param string $urlKey
+     * @return string
+     */
+    public function getUnusedPathByUrlkey($storeId, $requestPath, $idPath, $urlKey = '')
+    {
         if (strpos($idPath, 'product') !== false) {
             $suffix = $this->getProductUrlSuffix($storeId);
         } else {
@@ -645,21 +662,22 @@ class Mage_Catalog_Model_Url
             }
             // match request_url abcdef1234(-12)(.html) pattern
             $match = array();
-            $regularExpression = '#^([0-9a-z/-]+?)(-([0-9]+))?('.preg_quote($suffix).')?$#i';
+            $regularExpression = '#(?P<prefix>(.*/)?' . preg_quote($urlKey) . ')(-(?P<increment>[0-9]+))?(?P<suffix>'
+                . preg_quote($suffix) . ')?$#i';
             if (!preg_match($regularExpression, $requestPath, $match)) {
-                return $this->getUnusedPath($storeId, '-', $idPath);
+                return $this->getUnusedPathByUrlkey($storeId, '-', $idPath, $urlKey);
             }
-            $match[1] = $match[1] . '-';
-            $match[4] = isset($match[4]) ? $match[4] : '';
+            $match['prefix'] = $match['prefix'] . '-';
+            $match['suffix'] = isset($match['suffix']) ? $match['suffix'] : '';

             $lastRequestPath = $this->getResource()
-                ->getLastUsedRewriteRequestIncrement($match[1], $match[4], $storeId);
+                ->getLastUsedRewriteRequestIncrement($match['prefix'], $match['suffix'], $storeId);
             if ($lastRequestPath) {
-                $match[3] = $lastRequestPath;
+                $match['increment'] = $lastRequestPath;
             }
-            return $match[1]
-                . (isset($match[3]) ? ($match[3]+1) : '1')
-                . $match[4];
+            return $match['prefix']
+                . (isset($match['increment']) ? ($match['increment']+1) : '1')
+                . $match['suffix'];
         }
         else {
             return $requestPath;
@@ -699,7 +717,7 @@ class Mage_Catalog_Model_Url
     {
         $storeId = $category->getStoreId();
         $idPath  = $this->generatePath('id', null, $category);
-        $suffix  = $this->getCategoryUrlSuffix($storeId);
+        $categoryUrlSuffix = $this->getCategoryUrlSuffix($storeId);

         if (isset($this->_rewrites[$idPath])) {
             $this->_rewrite = $this->_rewrites[$idPath];
@@ -713,27 +731,27 @@ class Mage_Catalog_Model_Url
             $urlKey = $this->getCategoryModel()->formatUrlKey($category->getUrlKey());
         }

-        $categoryUrlSuffix = $this->getCategoryUrlSuffix($category->getStoreId());
         if (null === $parentPath) {
             $parentPath = $this->getResource()->getCategoryParentPath($category);
         }
         elseif ($parentPath == '/') {
             $parentPath = '';
         }
-        $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
-                                                                           true, $category->getStoreId());
+        $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath, true, $storeId);

-        $requestPath = $parentPath . $urlKey . $categoryUrlSuffix;
-        if (isset($existingRequestPath) && $existingRequestPath == $requestPath . $suffix) {
+        $requestPath = $parentPath . $urlKey;
+        $regexp = '/^' . preg_quote($requestPath, '/') . '(\-[0-9]+)?' . preg_quote($categoryUrlSuffix, '/') . '$/i';
+        if (isset($existingRequestPath) && preg_match($regexp, $existingRequestPath)) {
             return $existingRequestPath;
         }

-        if ($this->_deleteOldTargetPath($requestPath, $idPath, $storeId)) {
+        $fullPath = $requestPath . $categoryUrlSuffix;
+        if ($this->_deleteOldTargetPath($fullPath, $idPath, $storeId)) {
             return $requestPath;
         }

-        return $this->getUnusedPath($category->getStoreId(), $requestPath,
-                                    $this->generatePath('id', null, $category)
+        return $this->getUnusedPathByUrlkey($storeId, $fullPath,
+            $this->generatePath('id', null, $category), $urlKey
         );
     }

@@ -798,7 +816,8 @@ class Mage_Catalog_Model_Url
             $this->_rewrite = $this->_rewrites[$idPath];
             $existingRequestPath = $this->_rewrites[$idPath]->getRequestPath();

-            if ($existingRequestPath == $requestPath . $suffix) {
+            $regexp = '/^' . preg_quote($requestPath, '/') . '(\-[0-9]+)?' . preg_quote($suffix, '/') . '$/i';
+            if (preg_match($regexp, $existingRequestPath)) {
                 return $existingRequestPath;
             }

@@ -836,7 +855,7 @@ class Mage_Catalog_Model_Url
         /**
          * Use unique path generator
          */
-        return $this->getUnusedPath($storeId, $requestPath.$suffix, $idPath);
+        return $this->getUnusedPathByUrlkey($storeId, $requestPath.$suffix, $idPath, $urlKey);
     }

     /**
@@ -891,8 +910,8 @@ class Mage_Catalog_Model_Url
                 $parentPath = Mage::helper('catalog/category')->getCategoryUrlPath($parentPath,
                     true, $category->getStoreId());

-                return $this->getUnusedPath($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
-                    $this->generatePath('id', null, $category)
+                return $this->getUnusedPathByUrlkey($category->getStoreId(), $parentPath . $urlKey . $categoryUrlSuffix,
+                    $this->generatePath('id', null, $category), $urlKey
                 );
             }

@@ -913,14 +932,14 @@ class Mage_Catalog_Model_Url
                 $this->_addCategoryUrlPath($category);
                 $categoryUrl = Mage::helper('catalog/category')->getCategoryUrlPath($category->getUrlPath(),
                     false, $category->getStoreId());
-                return $this->getUnusedPath($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
-                    $this->generatePath('id', $product, $category)
+                return $this->getUnusedPathByUrlkey($category->getStoreId(), $categoryUrl . '/' . $urlKey . $productUrlSuffix,
+                    $this->generatePath('id', $product, $category), $urlKey
                 );
             }

             // for product only
-            return $this->getUnusedPath($category->getStoreId(), $urlKey . $productUrlSuffix,
-                $this->generatePath('id', $product)
+            return $this->getUnusedPathByUrlkey($category->getStoreId(), $urlKey . $productUrlSuffix,
+                $this->generatePath('id', $product), $urlKey
             );
         }

Si vous souhaitez utiliser ce correctif avec CE, assurez-vous de le tester correctement, car il a été développé pour EE.

Simon
la source
Avez-vous vous-même testé ce correctif EE sur CE?
Tyler V.
@TylerV. Nope ...
Simon
3
J'ai essayé ce correctif dans EE 1.9.1.1 et je peux me conformer, cela fonctionne. Il corrige le problème avec les produits et les catégories avec des clés d’URL identiques. Espérons qu'ils l'implémenteront dans une prochaine version bientôt.
Giel Berkers
1
Merci Simon, je viens de passer de 1 Go à 3 Mo sur un site Web client ...
Je devais
1
Je viens d’essayer cela sur mon 1.9 CE et bien que cela fonctionne pour les produits - les catégories ne sont pas tout à fait correctes. Si j’ai une catégorie appelée 'Test' qui donne l’URL '... / test' et que j’en crée une autre appelée 'Test', elle devrait donner l’URL '... / test-2' mais qui donne simplement le nombre non le nom: '... / - 2'
odd_duck
11

Après avoir appliqué le correctif publié par Simon, vous pouvez utiliser la requête suivante pour supprimer les données indésirables:

DELETE FROM core_url_rewrite
WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$" AND
      (request_path REGEXP ".*-[0-9]*\.html" 
          OR target_path = request_path);

Contrairement à la requête d'Ashish Hira, cela n'affecte que les URL dont le dernier chiffre est un entier, c'est-à-dire, dans mon cas, la raison de l'encombrement.

Il essaie de ne pas toucher les réécritures valides, qui pourraient par exemple avoir été créées lors de la mise à jour d'une clé d'URL.

Alex
la source
6

J'ai implémenté la réponse acceptée avec succès. Sur une autre installation de Magento, j'avais besoin de conserver certaines réécritures personnalisées. J'ai donc supprimé toutes les entrées qui se terminaient par un - puis un nombre comportant jusqu'à 5 chiffres comportant:

DELETE FROM `core_url_rewrite` WHERE `request_path` REGEXP '\\-[0-9]{1,5}$';

La plupart du temps, cela a fonctionné, mais il me reste encore 2 lignes à chaque réindexation. Pas certain de pourquoi. Je pensais partager cette expérience.

Andy Myers
la source
1
Vous avez probablement supprimé les URL valides, mais se terminant par un nombre. Vous trouverez ceux qui ont$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
Melvyn
5

Le changement fondamental que vous avez mentionné ne semble être nécessaire que si vous avez des produits sans url_keys. Cependant, Magento devrait toujours créer url_keys pour vous. Si vous avez un importateur qui crée des produits sans url_keys, alors ce problème se posera pour ces produits. Essayez d'exécuter la requête suivante pour trouver de tels produits:

SELECT cpe.entity_id, cpe.sku, cpev.value
FROM catalog_product_entity cpe
LEFT JOIN catalog_product_entity_varchar cpev
ON cpe.entity_id = cpev.entity_id AND cpev.attribute_id = (
    SELECT attribute_id
    FROM eav_attribute
    WHERE `entity_type_id` = 4
    AND `attribute_code` = 'url_key'
)
WHERE cpev.value IS NULL OR cpev.value = ''

Si des produits renvoient à partir de cette requête, ils n'ont pas de clé url et vont poser problème.

Tyler V.
la source
2
Notez que la valeur entity_type_idpar défaut pour les produits est 4 et non pas 10.
Simon
3

J'ai suivi une solution approuvée pour empêcher les réécritures d'URL en double, puis exporté core_url_rewritesous forme de fichier CSV. A pu ouvrir ce fichier CSV et supprimer toutes les réécritures d'URL créées manuellement.

Ensuite, j'ai tronqué la core_url_rewritetable et importé mon CSV enregistré avec les réécritures d'URL créées manuellement.

Après tous les changements, est passé de 940K lignes à 32K. Énorme amélioration.

JonW
la source
3

Voici le correctif (réécriture locale) de la communauté Magento pour le correctif que https://github.com/biotech/Magento-URL-Rewrite est identique au correctif EE PATCH_SUPEE-389_EE_1.12.0.2_v2.sh . éviter la création d'enregistrements dupliqués. Fonctionne bien depuis 2 mois sur la production CE 1,9, 15 000 produits, 4 magasins, réindexation complète chaque nuit après modification de l'importation de produits en vrac.

Ours de feu
la source
Dans quelle mesure cela a-t-il été testé? On dirait que ça a été posté il y a à peine une heure ....
SR_Magento
Est-ce que cela a été corrigé dans la version 1.9.2.x afin que nous n'ayons plus besoin de nous inquiéter à propos du gonflement des tables?
Fiasco Labs
Les réponses à un seul lien ne sont pas les meilleures, même si elles pourraient résoudre le problème. Veuillez expliquer un peu ce que votre code fait.
Marius
@FiascoLabs oui, fonctionne bien sur tous les CE 1.9.x
FireBear
1
@FiascoLabs: 1.9.2.x a toujours ce problème de «réécriture bloat» et n'inclut pas ce correctif. Cependant, comme l'a dit FireBear, le correctif EE fonctionnera avec CE 1.9.2.x. (Je n'ai pas essayé personnellement; je voulais seulement préciser que le 1.9.2.2 a toujours ce problème)
Eric Seastrand
2

Comme cela n’est pas encore mentionné dans ce fil de discussion, j’ai voulu partager la bonne nouvelle que ce problème est résolu dans Magento 1.9.3.9 et versions ultérieures. Voir les notes de publication associées :

Magento n'effectue plus d'opérations d'écriture inutiles sur la table core_url_rewrite.

Ainsi, tous les correctifs pour ce problème mentionné ici ne sont pas nécessaires lors de l'utilisation d'une version de Magento supérieure ou égale à 1.9.3.9. Je suggère toujours de supprimer les anciennes valeurs comme décrit dans la réponse d'Alex .

Simon
la source
1

Exécuter cette requête

DELETE FROM core_url_rewrite WHERE is_system <> 1 AND id_path REGEXP "^[0-9]+_[0-9]+$";

Cela vous aidera sûrement à réduire la taille de la core_url_sizetable en supprimant les données indésirables.

Asish Hira
la source
Êtes-vous sûr que ce sont des données indésirables? Je pense qu'il a également supprimé les réécritures créées lors du changement d'une clé d'URL!
Alex
Vérifiez la regex. ce moyen qui n'a pas d'identité valide
Asish Hira
Mais ces identifiants sont également créés lors du changement manuel de la clé d'URL dans le backend. Voir aussi ma réponse.
Alex
0

Se débarrasser de .html

  1. Ne pas utiliser de suffixe .html
  2. Mettre en .htaccess

    ## Redirect all htmls.
    RewriteRule (.+)\.html$ /$1 [L,R=301]
  3. Effacer toutes les .htmlredirections:

    DELETE FROM core_url_rewrite WHERE request_path LIKE '%.html'
Lycenok
la source
0

La réponse officielle devrait être d'installer SUPEE-389. Aussi simple que cela.

Cela fonctionne parfaitement avec Magento CE, car ils partagent le même code dans ce domaine.

Vous pouvez trouver le fichier de correctif ici: https://gist.github.com/piotrekkaminski/c348538ca91ba35773be#file-patch_supee-389_ee_1-12-0-2_v2-sh

Nous avons eu ce problème et il a généré des milliers de nouvelles lignes après chaque réindexation des URL du catalogue. Maintenant, le problème a disparu ... sauf que nous devons nettoyer la base de données.

Le script fourni ici semble être un bon début, mais ce n’est pas une solution parfaite,

php shell / rewrites_doctor.php --remove_rewrites 4

Voir https://www.atwix.com/magento/duplicated-product-url-keys-in-community-edition/

Frédéric Gauthier-Boutin
la source
-2

Un module dédié , https://github.com/vladsmirnov/url-rewrites , vous évite de réappliquer le correctif après chaque mise à jour Magento. Le module contient deux parties: le module actuel, pour éviter la duplication dorénavant, et le script shell pour nettoyer la base de données existante.

Vladyslav Smirnov
la source