Таблиця 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 та кеш-пам'ять.

System→ Cache Management→Flush Magento Cache

System→ Cache Management→Flush 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.