Magento core_url_rewrite Tabelle zu groß

105

Ich habe eine große Anzahl von Berichten festgestellt, dass diese Tabelle selbst sehr überladen sein kann. Ich betreibe eine Website mit ~ 5000 SKUs und ~ 250 Kategorien (Einzelspeicher) und einer resultierenden core_url_rewriteTabelle mit über 600.000 Zeilen und einer Größe von über 500 MB ist verrückt.

Dies kann die Leistung der Site verlangsamen und zu einer sehr umfangreichen Datenbank führen. Ich habe ein bisschen gegraben und einige Posts zu diesem Thema gefunden, vor allem:

// Diese Links wurden seit der Implementierung der neuen Boards entfernt

Jetzt verstehe ich , dass die Tabelle abgeschnitten werden kann und indexiert, aber dies nicht löst das Problem, es verlängert nur das Problem nicht noch einmal passiert.

Soweit ich weiß, handelt es sich bei einem Teil des Problems um Produkte, die den gleichen URL-Schlüssel haben, der auf dem Produktnamen basiert, was zu indizierten Links führt.

Ein Fix erwähnt ist:

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

Veränderung:

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

Zu:

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

Aber auch dies löst das Problem nicht vollständig.

Meine Frage lautet wie folgt:

Wenn Sie dieses Problem festgestellt haben, haben Sie es geschafft, einen effektiven, logischen und effizienten Algorithmus einzurichten, bei dem das Problem nicht wiederholt "verwaltet" wird, sondern die Angelegenheit tatsächlich ein für alle Mal gelöst wird?

Würde mich wirklich über einen Einblick darüber freuen.

Übrigens: Bitte tun Sie sich selbst einen Gefallen und prüfen Sie, wie Ihr Tisch im Moment aussieht. Möglicherweise tritt dieses Problem und die daraus resultierende Beeinträchtigung der Leistung auf, ohne es überhaupt zu wissen - ich habe es nicht getan.

Bearbeiten: Ich habe Kontakt zu www.Nexcess.net (einem Magento-Platin-Hosting-Partner) aufgenommen und sie haben bestätigt, dass sie von Kunden angefordert wurden, dass ihre core_url_rewriteTabelle abgeschnitten werden muss, da sie zu umfangreich ist.

Eine große Sorge von mir ist die SEO-Auswirkung, die dies haben könnte, weshalb ich eine Lösung möchte, anstatt das Problem von neuem aufzuschieben.

Update: Nexcess erwähnte, dass es bei den doppelten Produkten in der Tabelle tatsächlich zu SEO-Schäden kommen kann.

Elch
quelle
Wow, das ist ein erstaunlich großer Tisch. Ich habe meine eigenen (200 Produkte) überprüft und es hat nur ~ 800 Zeilen, aber wir haben kein Problem damit, Produktnamen / URLs zu duplizieren. Als Referenz haben wir ungefähr 6,6 Zeilen pro sichtbarem Produkt. Ich gebe zu, dass dies kein schrecklich realistischer Vergleich ist, aber bei 5.000 Produkten hätten wir nur ungefähr 30.000 Zeilen. Ich kann Ihren Bedarf an einer Lösung gut verstehen und werde diese Frage beobachten, wenn ich im Begriff bin, eine viel größere Site zu implementieren.
Pete855217
@ Pete855217: diese frage hört sich interessant an obwohl du sie nicht upvoted hattest.
Mohammad Faisal
1
In EE1.12 ist ein Fehler aufgetreten, der dazu führte, dass bei jedem Speichervorgang neue Schreibvorgänge erstellt wurden. Es ist möglich, dass Ihre Version von 1.7 denselben Fehler aufweist. Wie ich mich erinnere, funktionierte der Patch für 1.12 auch am 1.7
Brentwpeterson
1
Sehr hilfreicher Artikel! Wir haben 130.000 aktive Produkte und 25.000 deaktivierte Produkte. In unserem core_url_rewrite_table sind 2744023 Datensätze enthalten. Dieser Artikel scheint ein guter Ausgangspunkt zu sein.
MagentoMac
Der Beitrag wurde bearbeitet, um anzugeben, wie Ihre benutzerdefinierten Änderungen in Magento nicht gelöscht werden sollen.
Espradley

Antworten:

76

Ich habe es geschafft, das Problem wie folgt zu stabilisieren:

Schritt 1: Umschreiben des Katalog-URL-Modells (Verwenden Ihres eigenen Moduls: Vorgehensweise )

Hinweis: Wenn Sie die Core-Datei überschreiben, ohne ein erneutes Schreiben durchzuführen, kann Ihre Instanz von Magento künftig nicht mehr aktualisiert werden.

Nach Jahnni's Lösung weiter die MagentoCommerce-Boards(nicht mehr aktiv mit neuem Board), app/code/core/Mage/Catalog/Model/Url.php[um Zeile 807 Mage_Catalog_Model_Url::getProductRequestPath()]

Von:

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

Zu:

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

Schritt 2: Abschneiden

Schneiden Sie die core_url_rewriteTabelle ab

Schritt 3: Caches neu indizieren und leeren

Initiieren Sie den Neuindizierungsprozess für Core URL Rewrites. Danach möchten Sie den Magento-Cache und den Speicher-Cache leeren.

SystemCache ManagementFlush Magento Cache

SystemCache ManagementFlush Cache Storage

Voila, du bist fertig. Wenn Sie den Indexer erneut ausführen, wird Ihnen auffallen, dass die Größe der Tabelle konstant bleibt (es sei denn, Sie haben dazwischen weitere Produkte hinzugefügt oder Sie haben doppelte Kategorienamen).

Elch
quelle
5
Toll, meine core_url_rewrite Tabelle war 3,2 GB jetzt ist 36,8 MB: D von Muppet
Fabian Blechschmidt
Ich habe ein ähnliches Problem. Magento URL umschreiben Zufallszahl in URL anhängen. Bitte schauen Sie sich den Screenshot an, der von den Google Web Master Tools angehängt wurde. Wie Sie sehen können, hat das Produkt "Beige Embroidered Wedding Saree" neun verschiedene URLs, aber es ist nur ein Produkt und verweist nur auf eine URL, die mit 878 endet. Der tatsächliche URL-Schlüssel hat am Ende keine Zufallszahl (Screenshot im Anhang) ). Mein Geschäft ist ziemlich neu und die Größe von core_url_rewrite ist nicht so groß. Ich bin mir also nicht sicher, ob ich Schritt 1 und 2 oder nur Schritt 1 ausführen soll. Wenn ich Schritt 2 durchführe, gehen meine benutzerdefinierten Änderungen verloren.
Zoya
Ich lasse 1.9.1 laufen und hier sind verpasste Screenshot-URLs. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
Zoya
2
Ich würde zuerst die vorhandene Tabelle exportieren. Dann würde ich mit den Schritten 1, 2 und 3 fortfahren. Schauen Sie sich core_url_rewritejetzt die Tabelle an und notieren Sie die Anzahl der Datensätze. Führen Sie Schritt 3 erneut aus (Neuindizierung), und aktualisieren Sie die Ansicht der core_url_rewriteTabelle. Wenn die Anzahl gleich ist, haben Sie erfolgreich aufgelöst. Führen Sie dann Ihre benutzerdefinierten Änderungen manuell zusammen. Alles Gute.
Elch
2
Dieser Fix funktioniert nur für Produkte, nicht für Kategorien mit identischen URL-Schlüsseln. Siehe @ Simons Antwort für eine bessere Lösung (mit der Patch-Datei)
Giel Berkers
45

Obwohl ich hoffe, dass jemand hier eine Antwort findet, weiß ich nicht, dass Sie eine finden werden. Dieser Tisch wird aus vielen verschiedenen Gründen sperrig. Ein Fehler in früheren (und möglicherweise aktuellen) Versionen von Magento ist einer. Zum anderen enthält diese Tabelle eine Logik, mit der versucht wird, Änderungen am URL-Schlüsselwert zu verfolgen, sodass 301/302-Überschreibungen für alte Produkte eingerichtet werden. Aus diesem Grund und aufgrund von Komplikationen kann das Abschneiden der Tabelle und das erneute Erstellen von URLs dazu führen, dass vorhandene URLs nicht mehr geschrieben werden. Dies hat eine unbekannte Auswirkung auf die Auflistung in Ihrer Suchmaschine (nicht unbedingt schlecht, nur schwer vorherzusagen).

Mein allgemeiner Rat an Kunden, die fragen, ist

  1. Verlassen Sie den riesigen wachsenden Tisch so, als ob Sie Ihre URL / SEO-Situation nicht gut im Griff hätten

  2. Bis die Tabellengröße ein Problem darstellt (z. B. das Generieren von Site-Maps). In diesem Fall sollten Sie Ihre URL / SEO-Situation im Griff haben.

  3. Sobald Sie Ihre URL / SEO-Situation im Griff haben, sichern Sie die Tabelle, kürzen Sie sie und erstellen Sie sie neu. Beheben Sie alle URL- / SEO-Probleme, die durch das Abschneiden verursacht wurden.

  4. Schritt 3 automatisieren

Der Versuch, dies auf der Magento-Code-Ebene zu beheben, ist bewundernswert, aber Sie werden flussaufwärts schwimmen. Manchmal ist es besser zu akzeptieren, dass "Das ist nur Magento, das ist Magento", und das Problem mit einem externen Prozess zu lösen.

Alan Storm
quelle
danke für den rat, es ist schade um die situation, aber ich denke, dass es, wie du erwähnt hast, von einem externen prozess erledigt werden muss, urgh.
Moose
2
Diese riesige Tabelle kann bereits zu SEO-Problemen führen, da sich die Kanonik für ein bestimmtes Produkt ständig ändert. Wenn Sie eine separate Speicheransicht für Mobilgeräte und Desktops haben, ist dies noch schlimmer, da sich die URLs unterscheiden.
Melvyn
Ein wenig enttäuschend Antwort auf mich ...
Ab
@ Alan Storm, wie findest du die Antwort von Moose, nachdem du diese Antwort gepostet hast? Sehen Sie die gleichen Risiken?
Gans
24

Ich möchte einen Fix für diesen Fehler im Url Rewrite Indexer hinzufügen , der beim Bugathon im März 2013 entwickelt und anschließend weiter verbessert wurde. Es sollte dieses Problem lösen. Als Referenz ist hier die Patch-Datei aus dem Link:

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()


Zusätzlich möchte ich den EE-Patch hinzufügen PATCH_SUPEE-389_EE_1.12.0.2_v2.sh, der jetzt auf GitHub verfügbar ist :

#!/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
             );
         }

Wenn Sie diesen Patch mit CE verwenden möchten, stellen Sie sicher, dass Sie ihn ordnungsgemäß testen, da er für EE entwickelt wurde.

Simon
quelle
Haben Sie diesen EE-Patch selbst auf CE getestet?
Tyler V.
@TylerV. Nein ...
Simon
3
Ich habe diesen Patch in EE 1.9.1.1 ausprobiert und kann ihn verwenden. Es behebt das Problem mit Produkten und Kategorien mit identischen URL-Schlüsseln. Hoffen wir, dass sie dies bald in einer zukünftigen Version implementieren.
Giel Berkers,
1
Dank Simon, ging gerade von 1GB bis 3 MB auf einer Kunden - Website ... Hätte es vor allen 6 Monaten zu verkürzen, hofft , dass es jetzt klein bleiben :)
willem wigman
1
Ich habe dies gerade auf meinem 1.9 CE ausprobiert und obwohl es für Produkte funktioniert, stimmen die Kategorien nicht ganz. Wenn ich eine Kategorie mit dem Namen 'Test' habe, die die URL '... / test' enthält, und dann eine andere mit dem Namen 'Test' erstelle, sollte sie die URL '... / test-2' enthalten, gibt aber stattdessen nur die Nummer nicht an der Name: '... / - 2'
odd_duck
11

Nachdem Sie den von Simon bereitgestellten Patch angewendet haben, können Sie mit der folgenden Abfrage Junk-Daten entfernen:

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);

Im Gegensatz zu Ashish Hiras Abfrage betrifft dies nur URLs, die wie im letzten Teil eine Ganzzahl haben - in meinem Fall war dies der Grund für das Durcheinander.

Es wird versucht, gültige Umschreibungen nicht zu berühren, die beispielsweise beim Aktualisieren eines URL-Schlüssels erstellt wurden.

Alex
quelle
6

Ich habe die akzeptierte Antwort mit Erfolg umgesetzt. Bei einer anderen Magento-Installation musste ich einige benutzerdefinierte Neuschreibungen beibehalten, damit ich alle Einträge löschte, die mit einem - endeten, und dann eine bis zu fünfstellige Zahl mit:

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

Das hat meistens funktioniert, aber ich bekomme immer noch 2 weitere Zeilen für jeden Neuindex. Nicht sicher warum. Ich dachte, ich würde diese Erfahrung teilen.

Andy Myers
quelle
1
Sie haben wahrscheinlich gültige URLs gelöscht, die jedoch mit einer Zahl enden. Sie finden diese mit$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
Melvyn
5

Die Kernänderung, die Sie erwähnt haben, scheint nur erforderlich zu sein, wenn Sie Produkte ohne url_keys haben. Magento sollte jedoch immer url_keys für Sie erstellen. Wenn Sie einen Importeur haben, der Produkte ohne url_keys erstellt, tritt dieses Problem bei diesen Produkten auf. Versuchen Sie, die folgende Abfrage auszuführen, um solche Produkte zu finden:

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 = ''

Wenn Produkte von dieser Abfrage zurückkehren, haben sie keinen url_key und werden ein Problem darstellen.

Tyler V.
quelle
2
Beachten Sie, dass die Standardeinstellung entity_type_idfür Produkte 4 und nicht 10 ist.
Simon
3

Ich habe die genehmigte Lösung befolgt, um doppelte URL-Überschreibungen zu vermeiden, und dann core_url_rewriteals CSV-Datei exportiert . Konnte diese CSV öffnen und alle bis auf manuell erstellten URL-Änderungen löschen.

Dann habe ich die core_url_rewriteTabelle abgeschnitten und meine gespeicherte CSV mit manuell erstellten URL-Änderungen importiert.

Nach allen Änderungen wurde von 940.000 Zeilen auf 32.000 Zeilen gewechselt. Riesige Verbesserung.

JonW
quelle
3

Hier Patch (lokale Rewrite) für Magento Community für Updates , das https://github.com/biotech/Magento-URL-Rewrite In der Tat macht die gleichen wie EE Patch PATCH_SUPEE-389_EE_1.12.0.2_v2.sh - jede Rewrite überprüfen und Vermeiden Sie die Erstellung doppelter Datensätze. Funktioniert gut in den letzten 2 Monaten bei der Produktion von CE 1.9, 15.000 Produkten, 4 Filialen, jede Nacht nach Änderungen des Massenproduktimports wird ein vollständiger Neuindex erstellt.

Feuerbär
quelle
Wie gründlich wurde dies getestet? Es sieht so aus, als ob es erst vor einer Stunde gepostet wurde ....
SR_Magento
Wurde dies in 1.9.2.x behoben, sodass wir uns keine Sorgen mehr über das Aufblähen von Tischen machen müssen?
Fiasco Labs
Single-Link-Antworten sind nicht die besten Antworten, auch wenn sie das Problem möglicherweise lösen. Bitte erläutern Sie kurz, was Ihr Code bewirkt.
Marius
@FiascoLabs Ja, funktioniert auf allen CE 1.9.x
FireBear
1
@FiascoLabs: 1.9.2.x hat immer noch das Problem des "Rewrite Bloat" und enthält dieses Update nicht. Wie FireBear sagte, funktioniert der EE-Patch jedoch mit CE 1.9.2.x. (habe es nicht persönlich versucht; wollte nur klären, dass 1.9.2.2 definitiv noch dieses Problem hat)
Eric Seastrand
2

Da dies in diesem Thread noch nicht erwähnt wurde, wollte ich die coolen Neuigkeiten mitteilen, dass dieses Problem in Magento 1.9.3.9 und höher behoben wurde. Siehe die zugehörigen Versionshinweise :

Magento führt keine unnötigen Schreibvorgänge mehr für die Tabelle core_url_rewrite aus.

Alle hier genannten Fixes für dieses Problem sind daher nicht erforderlich, wenn Sie eine Magento-Version größer oder gleich 1.9.3.9 verwenden. Ich schlage immer noch vor, die alten Werte zu löschen, wie in Alex Antwort beschrieben .

Simon
quelle
1

Führen Sie diese Abfrage aus

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

Dies wird Ihnen sicherlich dabei helfen, die Größe der core_url_sizeTabelle zu reduzieren, indem Sie Junk-Daten löschen.

Asish Hira
quelle
Sind Sie sicher, dass es sich um Junk-Daten handelt? Ich denke, es wurden auch Umschreibungen gelöscht, die beim Ändern eines URL-Schlüssels erstellt wurden!
Alex
Überprüfen Sie den regulären Ausdruck. das heißt, die keine gültige ID haben
Asish Hira
Diese IDs werden jedoch auch beim manuellen Ändern des URL-Schlüssels im Backend erstellt. Siehe auch meine Antwort.
Alex
0

Beseitigen, abschütteln .html

  1. Verwenden Sie kein Suffix .html
  2. Stellen Sie .htaccess ein

    ## Redirect all htmls.
    RewriteRule (.+)\.html$ /$1 [L,R=301]
  3. Alle .htmlWeiterleitungen löschen :

    DELETE FROM core_url_rewrite WHERE request_path LIKE '%.html'
lycenok
quelle
0

Die offizielle Antwort sollte sein, SUPEE-389 zu installieren. So einfach ist das.

Es funktioniert perfekt mit Magento CE, da sie in diesem Bereich denselben Code verwenden.

Die Patch-Datei finden Sie hier: https://gist.github.com/piotrekkaminski/c348538ca91ba35773be#file-patch_supee-389_ee_1-12-0-2_v2-sh

Wir hatten dieses Problem und es wurden Tausende neuer Zeilen nach jeder Neuindizierung der Katalog-URL generiert. Jetzt ist das Problem weg ... bis auf die Tatsache, dass wir die DB bereinigen müssen.

Das hier bereitgestellte Skript scheint ein guter Anfang zu sein, ist jedoch keine perfekte Lösung.

PHP-Shell / rewrites_doctor.php --remove_rewrites 4

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

Frédéric Gauthier-Boutin
quelle
-2

Es gibt auch ein spezielles Modul https://github.com/vladsmirnov/url-rewrites , sodass Sie den Patch nicht nach jedem Magento-Update erneut anwenden müssen. Das Modul besteht aus zwei Teilen: dem eigentlichen Modul, um Duplizierungen von nun an zu verhindern, und dem Shell-Skript, um die vorhandene Datenbank zu bereinigen.

Vladyslav Smirnov
quelle