Таблиця Magento core_url_rewrite надмірно велика


105

Я помітив велику кількість звітів про те, що ця таблиця сама по собі може стати надзвичайно захаращеною, я запускаю сайт із ~ 5000 SKU та ~ 250 категоріями (однократний магазин) та результуючою core_url_rewriteтаблицею, що містить понад 600 000 рядків і більше 500 Мб, які великі божевільно.

Це може уповільнити продуктивність сайту та призвести до дуже об'ємної бази даних. Я зробив кілька копань і знайшов досить багато публікацій щодо цього, особливо:

// Ці посилання видалено з моменту впровадження нових дощок

Тепер я розумію, що таблицю можна обрізати та повторно застосувати, але це не вирішує проблему, вона просто продовжує проблему повторюватися.

Як я розумію, частина випуску - це продукти, які мають той самий ключ URL-адреси, що базується на назві продукту, що призводить до індексованих посилань.

Згадане виправлення:

app/code/core/Mage/Catalog/Model/Url.php на лінії ~ 807:

Змінити:

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

До:

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

Але навіть це не повністю вирішує питання.

Моє запитання таке:

Якщо ви зіткнулися з цією проблемою, чи вдалося вам створити ефективний, логічний та ефективний алгоритм, який не передбачає "управління" проблемою повторно, а фактично вирішення питання раз і назавжди?

Був би дуже вдячний за деяке розуміння цього.

BTW: Будь ласка, зробіть собі послугу і перевірте, як виглядає ваша таблиця зараз, можливо, у вас виникає ця проблема та вплив на продуктивність внаслідок цього, навіть не знаючи про це - я цього не зробив.

Редагувати: Я був у контакті з www.Nexcess.net (Magento Platinum хостинг-партнер), і вони підтвердили, що у них були запити клієнтів про те, що їх core_url_rewriteстіл вимагає усікання внаслідок занадто громіздкого.

Моє велике занепокоєння - це вплив SEO, який це може мати, і саме тому я хотів би рішення, а не зволікати з повторним виникненням проблеми.

Оновлення: Nexcess згадав, що завдяки дублюючим продуктам у таблиці може насправді шкодити SEO, як це є.


Нічого собі, це приголомшливо великий стіл. Я перевірив власну (200 продуктів), і вона містить ~ 800 рядків, але у нас немає проблеми з копіюванням назви продукту / URL-адрес. В якості орієнтиру маємо приблизно 6,6 рядків на видимий продукт. Я визнаю це не жахливим реалістичним порівнянням, але з такою швидкістю, з 5000 продуктів у нас було б лише близько 30 000 рядків. Я цілком можу зрозуміти вашу потребу в рішенні і буду спостерігати за цим питанням, коли я збираюся реалізувати значно більший сайт.
Pete855217

@ Pete855217: це питання здається вам цікавим, навіть якщо ви його не відкликали.
Мохаммед Файсал

1
У EE1.12 виникла помилка, яка викликає перезаписи, створені заново при кожному збереженні. Можливо, що у вашій версії 1.7 є така сама помилка. Як я пам’ятаю, патч за 1.12 також працював 1,7
brentwpeterson

1
Дуже корисна стаття! У нас 130 000 активних продуктів та 25 000 продуктів з обмеженими можливостями, наш core_url_rewrite_table має в ньому 2744023 записів ..... тому на цьому тижні ми починаємо працювати над цим виправленням !! Ця стаття виглядає як хороша відправна точка.
MagentoMac

Відредагував публікацію, щоб вказати, як не видаляти власні переписані в Magento.
espradley

Відповіді:


76

Мені вдалося стабілізувати проблему наступним чином:

Крок 1. Перепишіть модель URL-адреси каталогу (Використовуючи власний модуль: Як зробити )

Примітка: Якщо ви перезапишете основний файл без використання переписування, це зробить ваш примірник Magento нездатним до майбутніх оновлень.

Згідно з рішенням Янні о дошки MagentoCommerce(більше не працює з новою дошкою), app/code/core/Mage/Catalog/Model/Url.php[навколо лінії 807 Mage_Catalog_Model_Url::getProductRequestPath()]

Від:

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

До:

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

Крок 2: Обрізати

Обріжте core_url_rewriteстіл

Крок 3: Reindex & Flush Caches

Ініціюйте процес повторної індексації у програмі Core URL Rewrites. Після цього ви захочете очистити кеш-пам'ять Magento та кеш-пам'ять.

SystemCache ManagementFlush Magento Cache

SystemCache ManagementFlush Cache Storage

Вуаля, ти все налаштований. Ви помітите, якщо повторно запустити індексатор, таблиця повинна залишатися незмінною за розміром (якщо ви не додали більше продуктів між ними або якщо у вас є дублюючі назви категорій).


5
Чудово, моя таблиця core_url_rewrite становила 3,2 ГБ, зараз - 36,8 Мб: D від muppet
Фабіан Блешшмідт

У мене схожа проблема. URL-адреса Magento перезаписує додавання випадкового числа в Url. Перегляньте скріншот, що додається з інструментів веб-майстер google. Як ви бачите, у продукту "Бежева вишита весільна сарі" є дев'ять різних URL-адрес, але це лише один продукт, який вказує лише на одну URL-адресу, що закінчується 878. Дійсний ключ URL-адреси в кінці кінців не має випадкового числа (скріншот додається ). Мій магазин досить новий, і розмір core_url_rewrite не такий вже й великий. Тож я не впевнений, чи варто мені робити вперед і робити крок 1 і 2 або лише крок 1. Якщо я виконую крок 2, я втрачу свої власні переписування.
Зоя

У мене працює 1.9.1, і тут пропущені URL-адреси скріншота. monosnap.com/image/duL0f64WWlACtlt9kcn04BWqY3L5Xl monosnap.com/image/osFk8kYNAr00XLdFTGTIOaydaW5yqS
Зоя,

2
Я спочатку експортував би існуючу таблицю. Тоді я б перейшов до кроків 1, 2 і 3. Погляньте на core_url_rewriteтаблицю і запишіть кількість записів. Знову виконайте крок 3 (повторна індексація) та оновіть свій погляд на core_url_rewriteтаблиці. Якщо число однакове, ви вирішили успішно. Потім вперед і з’єднайте власні переписувачі вручну. Все найкраще.
Лось

2
Це виправлення працює лише для продуктів, а не для категорій з однаковими ключами URL-адреси. Дивіться відповідь @Simon s для кращого рішення (з файлом виправлень)
Giel Berkers,

45

Хоча я сподіваюся, що хтось тут придумає відповідь, я не знаю, що ви знайдете його. Ця таблиця стає об'ємною з безлічі різних причин. Помилки в більш ранніх (і, можливо, поточних) версіях Magento - це одна. Ще одна логіка в цій таблиці, яка намагається відстежувати зміни значень ключа URL, щоб 301/302 переписувань були налаштовані для старих продуктів. Через це і ускладнення речей, обрізання таблиці та відновлення можуть призвести до того, що існуючі переписування URL-адрес відійдуть, і це матиме невідомий вплив на перелік вашої пошукової системи (не потрібно погано, просто важко передбачити).

Моя загальна порада для клієнтів, які просять

  1. Залиште гігантський зростаючий стіл так, як якщо у вас не дуже добре впоратися з URL-адресою та ситуацією з SEO

  2. Поки розмір таблиці не стане проблемою (наприклад, генеруючи карти сайту). Коли це станеться, перегляньте ситуацію з URL-адресою та SEO.

  3. Як тільки ви вирішите ситуацію з URL-адресою та SEO, створіть резервну копію таблиці, а потім обріжте таблицю та відновіть її. Вирішіть будь-які проблеми URL-адреси / SEO, викликані скороченням.

  4. Автоматизувати крок 3

Спроба виправити це на рівні коду Magento захоплююча, але ви будете плавати вгору за течією. Іноді краще прийняти те, що "Це просто Магенто є Магенто", і вирішити проблему з і зовнішнім процесом.


дякую за пораду, шкода щодо ситуації, але я думаю, що це доведеться вирішувати зовнішнім процесом, як ви згадали, ургу.
Лось

2
Ця гігантська таблиця вже може спричинити проблеми з SEO, оскільки канонічне для певного товару буде постійно змінюватися. Якщо у вас є окремий перегляд магазину для мобільних пристроїв та настільних ПК, це ще гірше, оскільки їх URL-адреси будуть відрізнятися.
Мельвін

Трохи невтішну відповідь мені ...
Фра

@Alan Storm, як ви ставитесь до відповіді, яку опублікував Moose після того, як ви опублікували цю відповідь? Ви бачите однакові ризики?
Гуска

24

Я хотів би додати виправлення для цієї помилки індексатора перезапису URL-адреси, яка була розроблена на bugathon у березні 2013 року та яка була вдосконалена згодом. Це має вирішити це питання. В якості довідки, ось файл виправлення за посиланням:

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


Крім того, я хотів би додати патч EE PATCH_SUPEE-389_EE_1.12.0.2_v2.sh, який тепер доступний на 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
             );
         }

Якщо ви хочете використовувати цей патч із CE, переконайтесь, що його правильно перевірити, оскільки він розроблений для EE.


Ви самі випробували цей патч EE на CE?
Тайлер В.

@TylerV. Ні ...
Саймон

3
Я спробував цей патч в EE 1.9.1.1 і можу він відповідати, що він працює. Він вирішує проблему з продуктами та категоріями з однаковими ключами URL-адреси. Будемо сподіватися, що вони незабаром реалізують це у майбутньому випуску.
Giel Berkers

1
Дякую Саймон, щойно перейшов від 1 ГБ до 3 Мб на одному клієнтському веб-сайті ... Довелося вкорочувати його раніше кожні 6 місяців, сподіваюся, що він тепер залишиться малим :)
willem wigman

1
Я тільки що спробував це на своєму 1.9 СЕ, і хоча це працює для продуктів - категорії не зовсім вірні. Якщо у мене є категорія під назвою "Тест", яка дає URL-адресу "... / test", а потім я створюю інший під назвою "Тест", він повинен дати URL-адресу "... / test-2", але натомість дає просто число не назва: '... / - 2'
odd_duck

11

Після застосування патча, розміщеного Simon, ви можете використовувати наступний запит для видалення непотрібних даних:

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

На відміну від запиту Ашиша Хіра, це впливає лише на URL-адреси, які мають ціле число, оскільки остання частина - це, в моєму випадку, - причина неспокою.

Він намагається не торкатися дійсних переписувань, які, наприклад, могли бути створені при оновленні ключа URL-адреси.


6

Я успішно реалізував прийняту відповідь. В іншому встановленні Magento мені потрібно було зберегти деякі власні переписування, тому я видалив усі записи, які закінчились a -, а потім число довжиною до 5 цифр із:

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

Здебільшого це спрацювало, але я все одно отримую ще 2 ряди на кожному повторному індексі. Не знаю чому. Я думав, що поділюсь цим досвідом.


1
Ви, ймовірно, видалили дійсні URL-адреси, але їх кількість закінчується. Ти знайдеш таких,$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
Мелвін,

5

Основна зміна, про яку ви згадали, здається, потрібна лише в тому випадку, якщо у вас є продукти без url_keys, проте Magento завжди повинен створювати url_keys для вас. Якщо у вас є якийсь імпортер, який створює продукцію без url_keys, тоді ця проблема буде вирішена для цих продуктів. Спробуйте запустити наступний запит, щоб знайти такі продукти:

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

Якщо якісь продукти повертаються з цього запиту, у них немає url_key, і це стане проблемою.


2
Майте на увазі, що за замовчуванням entity_type_idдля товарів - 4, а не 10.
Саймон

3

Я дотримувався схваленого рішення, щоб запобігти повторному переписуванню дублікатів, потім експортував core_url_rewriteу файл CSV. Вдалося відкрити цей CSV та видалити всі перезаписані URL-адреси, окрім створених вручну.

Потім я урізав core_url_rewriteтаблицю та імпортував збережений CSV із створеними вручну переписами URL-адрес.

Після всіх змін перейшов з 940K рядків до 32K. Величезне поліпшення.


3

Ось патч (локальний перепис) для спільноти Magento для виправлення, що https://github.com/biotech/Magento-URL-Rewrite Фактично те саме, що і патч EE PATCH_SUPEE-389_EE_1.12.0.2_v2.sh - перевіряйте кожне перезапис і уникати створення дублюваних записів. Добре працює останні 2 місяці на виробництві CE 1.9, 15 тис. Товарів, 4 магазини, повний переіндексацію щовечора після зміни масового імпорту продукції.


Наскільки ретельно це було випробувано? Схоже, це було розміщено лише годину тому ....
SR_Magento

Це було виправлено в 1.9.2.x, тому нам більше не потрібно турбуватися про роздуття таблиці?
Лабораторії Фіаско

Відповіді на одне посилання - не найкращі відповіді, навіть якщо вони можуть вирішити проблему. Будь ласка, поясніть трохи, що робить ваш код.
Маріус

@FiascoLabs так, добре працює на всіх CE 1.9.x
FireBear

1
@FiascoLabs: 1.9.2.x все ще має цю проблему "переписати роздуття", і вона не включає це виправлення, однак, як сказав FireBear, патч EE буде працювати з CE 1.9.2.x. (я не намагався особисто; хотів лише уточнити, що 1.9.2.2, безумовно, все ще має цю проблему)
Eric Seastrand

2

Оскільки це ще не згадується в цій темі, я хотів поділитися цікавою новиною про те, що ця проблема виправлена ​​в Magento 1.9.3.9 та пізніших версіях. Дивіться відповідні примітки до випуску :

Magento більше не виконує зайвих операцій запису в таблиці core_url_rewrite.

Тому всі виправлення цього питання, згадані тут, не потрібні при використанні версії Magento, більшої або рівної, ніж 1.9.3.9. Я все ще пропоную видалити старі значення, як описано у відповіді Алекса .


1

Запустіть цей запит

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

Це напевно допоможе вам зменшити розмір core_url_sizeтаблиці, видаливши непотрібні дані.


Ви впевнені, що це непотрібні дані? Я думаю, що це видалено також переписує, які були створені при зміні ключа URL!
Алекс

Перевірте регулярний вираз. це означає, що не мають дійсного ідентифікатора
Asish Hira

Але ці ідентифікатори також створюються при ручному зміні ключа URL в сервісному режимі. Дивіться також мою відповідь.
Алекс

0

Позбутися .html

  1. Не використовуйте суфікс .html
  2. Встановити .htaccess

    ## Redirect all htmls.
    RewriteRule (.+)\.html$ /$1 [L,R=301]
  3. Стерти всі .htmlпереадресації:

    DELETE FROM core_url_rewrite WHERE request_path LIKE '%.html'

0

Офіційною відповіддю має бути встановлення SUPEE-389. Просто як це.

Він прекрасно працює з Magento CE, оскільки вони поділяють той самий фрагмент коду в цій області.

Ви можете знайти файл виправлення тут, https://gist.github.com/piotrekkaminski/c348538ca91ba35773be#file-patch_supee-389_ee_1-12-0-2_v2-sh

У нас виникла ця проблема, і вона створила тисячі нових рядків після кожного переіндексації URL-адреси Каталогу. Зараз проблеми вже немає ... окрім того, що ми повинні очистити БД.

Наданий тут сценарій здається гарним початком, але це не ідеальне рішення,

php shell / rewrites_doctor.php --remove_rewrites 4

Дивіться https://www.atwix.com/magento/duplicate-product-url-keys-in-community-edition/


-2

Існує також виділений модуль https://github.com/vladsmirnov/url-rewrites , тому вам не доведеться повторно застосовувати патч після кожного оновлення Magento. Модуль містить дві частини: власне модуль для запобігання дублювання відтепер і сценарій оболонки для очищення існуючої бази даних.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.