Очистити всі перезаписи URL-адрес - Enterprise (1.13)


27

Після декількох заплутаних імпортів у мене залишилось безліч перезаписів URL-адрес, які мені потрібно видалити.

Я працюю Enterprise 1.13

Коли у мене з’явилася ця проблема у спільноті, я просто усічений core_url_rewriteі перероблений.

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

  • enterprise_url_rewrite
  • enterprise_url_rewrite_category_cl
  • enterprise_url_rewrite_product_cl
  • enterprise_url_rewrite_redirect
  • enterprise_url_rewrite_redirect_cl
  • enterprise_url_rewrite_redirect_rewrite

Чи безпечно усі вони усікати?

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


Що ви маєте на увазі під "низкою різних таблиць, які керують переписуваннями"? На EE я робив те саме, що і на CE. Урізати, core_url_rewriteі це спрацювало.
Маріус

Привіт Маріус. Це таблиці, за допомогою яких можна контролювати переписування. У мене був усічений core_url_rewrites, але це не вплинуло на ті, що вказані в адміністраторі. enterprise_url_rewrite enterprise_url_rewrite_category_cl enterprise_url_rewrite_product_cl enterprise_url_rewrite_redirect enterprise_url_rewrite_redirect_cl enterprise_url_rewrite_redirect_rewrite Подяки
JamesAllwood

Ой, вибачте. Моє ліжко. Я пропустив цей рядок "Я запускаю Enterprise 1.13". Я не маю досвіду (EE) 1,13. Ігноруйте мене поки що.
Маріус

1
Що - то розглянути: gist.github.com/Vinai/5451584
B00MER

1
Нещодавно ми оновили Magento EE 1.12 до EE 1.13 для одного з наших магазинів, і ми написали повідомлення на своєму веб-сайті про зміни та проблеми, які можуть виникнути: code4business.de/update-magento-enterprise-edition-1-13-0-2 /… У публікації в нижній частині сторінки є переклад англійською мовою.
користувач2830524

Відповіді:


30

Ми в подібній ситуації, як ти, Джеймс. Після багатого копання ось що я придумав:

core_url_rewriteТаблиця тепер засуджується, а Magento EE 1,13 тепер зберігає в переписує в enterprise_url_rewrite.

Таблиці: enterprise_*_category_rewriteвикористовуйте catalog_*_entity_url_keyтаблиці для відновлення двох таблиць перезапису при запускуphp indexer.php --reindex catalog_url_*

Коли ви додаєте "Перенаправлення URL-адрес" в адміністраторі Каталог-> Перенаправлення URL-адрес для користувацької URL-адреси, він додається до enterprise_url_rewrite_redirectтаблиці, а прапор Magento, що індекс зараз застарів, вводиться в enterprise_url_rewrite_redirect_clтаблицю, яка під час запуску php indexer.php --reindex url_redirectвідновлює enterprise_url_rewrite_redirect_rewriteтаблицю.

Швидке зауваження: будь-яку таблицю, що закінчується на _cl, можна безпечно скоротити, "CL" означає "Журнал змін" і Magento використовується для перевірки, чи потрібна повторна індексація.

Що стосується таблиць з ключовими адресами URL, я все ще трохи зрозумілий, чому існують дві записи "Ключ URL", одна - catalog_*_entity_url_keyі одна - catalog_*_entity_varchar(атрибут id 90), але я припускаю, що це відбувається:

Коли ви створюєте новий продукт / категорію, Magento використовує ім'я для створення url_key, який розміщується в catalog_*_entity_url_keyAND у catalog_*_entity_varchar, але основна таблиця, яку використовує Magento, це catalog_*_entity_url_keyтому, що якщо ви врізаєте її та запустите php indexer.php --reindex catalog_url_*ваші enterprise_*_category_rewriteтаблиці, вони будуть порожніми, а товари / категорії в frontend відображатиме некрасиві URL-адреси, тобто http://example.com/catalog/product/view/id/123/etc/etc(не сприятливо до SOE). Я вважаю, що дві таблиці пов'язані та використовуються для створення enterprise_url_rewriteтаблиці, оскільки ця таблиця зберігає "request_path", швидше за все, url_key всередині catalog_*_entity_varcharтаблиці та "ідентифікатор", який є основним URL-ключ із catalog_*_entity_url_keyтаблиці. Я можу бути абсолютно невірним щодо таблиць url_key та varchar, тому я просто роздумую вголос.

У будь-якому випадку для успішного обрізання та відновлення всіх таблиць перезапису, які ви можете виконати:

SET FOREIGN_KEY_CHECKS = 0;
TRUNCATE TABLE `core_url_rewrite`;
TRUNCATE TABLE `enterprise_catalog_category_rewrite`;
TRUNCATE TABLE `enterprise_catalog_product_rewrite`;
TRUNCATE TABLE `enterprise_url_rewrite`;
TRUNCATE TABLE `enterprise_url_rewrite_category_cl`;
TRUNCATE TABLE `enterprise_url_rewrite_product_cl`;
TRUNCATE TABLE `enterprise_url_rewrite_redirect_cl`;
TRUNCATE TABLE `enterprise_url_rewrite_redirect_rewrite`;
SET FOREIGN_KEY_CHECKS = 1;

а потім запустіть:

sudo php indexer.php --reindex catalog_url_product
sudo php indexer.php --reindex catalog_url_category
sudo php indexer.php --reindex url_redirect

Якщо ви також урізаєте, enterprise_url_rewrite_redirectви втратите всі свої власні переадресації, які ви бачите на панелі адміністратора, можливо, це ваша мета, оскільки вам залишилось безліч марних URL-адрес. Поки ви НЕ обрізаєте таблиці '* _entity_url_key', у вас все буде добре.

Наша історія була дещо іншою, тому що у нас були повторювані ключі URL-адрес і основні проблеми з іменами продуктів від імпорту excel після оновлення до 1,13 з 1,11, тому я написав цей швидкий сценарій, щоб скинути catalog_product_entity_url_keyтаблицю та URL-адреси та URL-адреси в catalog_product_entity_varcharтаблиці за допомогою продукту імена. Я додав код нижче, але якщо ви його використовуєте, використовуйте його на свій страх і ризик.

<?php
include_once('app/Mage.php');
Mage::app();

$dbHandle          = Mage::getSingleton('core/resource')->getConnection('core_write');
$productCounter    = 0;
$nameFixCounter    = 0;
$vUrlKeyFixCounter = 0;
$urlPathCounter    = 0;
$urlKeyCounter     = 0;
$productCollection = $dbHandle->query("SELECT entity_id, sku FROM catalog_product_entity");

while($product = $productCollection->fetch()) {    
  $dataString       = null;

  $oldProductName   = $dbHandle->query("SELECT value FROM catalog_product_entity_varchar WHERE entity_id = '".$product['entity_id']."' AND attribute_id = 65")->fetch();
  $oldVarcharUrlKey = $dbHandle->query("SELECT value FROM catalog_product_entity_varchar WHERE entity_id = '".$product['entity_id']."' AND attribute_id = 90")->fetch();
  $oldUrlPath       = $dbHandle->query("SELECT value FROM catalog_product_entity_varchar WHERE entity_id = '".$product['entity_id']."' AND store_id = 0 AND attribute_id = 91")->fetch();
  $oldUrlKey        = $dbHandle->query("SELECT value FROM catalog_product_entity_url_key WHERE entity_id = '".$product['entity_id']."'")->fetch();

  $newProductName   = preg_replace('/\s+/', ' ', trim(preg_replace('/[^\x20-\x21\x23-\x2B\x2D-\xE7]/', ' ', $oldProductName['value'])));
  $newUrlKey        = preg_replace('/\s+/', '-', trim(preg_replace('/[^\x30-\x39\x61-\x7A]/', ' ', strtolower($newProductName))));

  if (strcmp($oldProductName['value'], $newProductName)) {
    echo "-[".$oldProductName['value']."]\n";
    echo "+[".$newProductName."]\n";
    $dbHandle->query('UPDATE catalog_product_entity_varchar SET value = "'.$newProductName.'" WHERE entity_id = "'.$product['entity_id'].'" AND attribute_id = 65');
    ++$nameFixCounter;
  }

  if (strcmp($oldVarcharUrlKey['value'], $newUrlKey)) {
    echo "-[".$oldVarcharUrlKey['value']."]\n";
    echo "+[".$newUrlKey."]\n";
    if ($oldVarcharUrlKey['value'] === null) {
      $dbHandle->query("INSERT INTO catalog_product_entity_varchar (entity_type_id, attribute_id, store_id, entity_id, value) VALUES ('4', '90', '0', '".$product['entity_id']."', '".$newUrlKey."')");
    } else {
      $dbHandle->query("UPDATE catalog_product_entity_varchar SET value = '".$newUrlKey."' WHERE entity_id = '".$product['entity_id']."' AND attribute_id = 90");
    }
    ++$vUrlKeyFixCounter;
  }

  if (strcmp($oldUrlPath['value'], $newUrlKey.'.html')) {
    echo "-[".$oldUrlPath['value']."]\n";
    echo "+[".$newUrlKey.".html]\n";
    if ($oldUrlPath['value'] === null) {
      $dbHandle->query("INSERT INTO catalog_product_entity_varchar (entity_type_id, attribute_id, store_id, entity_id, value) VALUES ('4', '91', '0', '".$product['entity_id']."', '".$newUrlKey.".html')");
    } else {
      $dbHandle->query("UPDATE catalog_product_entity_varchar SET value = '".$newUrlKey.".html' WHERE entity_id = '".$product['entity_id']."' AND store_id = 0 AND attribute_id = 91");
    }
    ++$urlPathCounter;
  }

  if (strcmp($oldUrlKey['value'], $newUrlKey)) {
    echo "-[".$oldUrlKey['value']."]\n";
    echo "+[".$newUrlKey."]\n";
    if ($oldUrlKey['value'] === null) {
      $dbHandle->query("INSERT INTO catalog_product_entity_url_key (entity_type_id, attribute_id, store_id, entity_id, value) VALUES ('4', '90', '0', '".$product['entity_id']."', '".$newUrlKey."')");
    } else {
      $dbHandle->query("UPDATE catalog_product_entity_url_key SET value = '".$newUrlKey."' WHERE entity_id = '".$product['entity_id']."'");
    }
    ++$urlKeyCounter;
  }

  $report  = "[".++$productCounter."] ";
  $report .= "NAME: [".(strcmp($oldProductName['value'], $newProductName)?'!=':'==')."] ";
  $report .= "V_KEY: [".(strcmp($oldVarcharUrlKey['value'], $newUrlKey)?'!=':'==')."] ";
  $report .= "PATH: [".(strcmp($oldUrlPath['value'], $newUrlKey.'.html')?'!=':'==')."] ";
  $report .= "KEY: [".(strcmp($oldUrlKey['value'], $newUrlKey)?'!=':'==')."]\n";
  echo $report;

}
echo 'Total Products: ['.$productCounter.'] Names: ['.$nameFixCounter.'] V_Keys: ['.$vUrlKeyFixCounter.'] Paths: ['.$urlPathCounter.'] Keys: ['.$urlKeyCounter.']';

Код можна змінити, щоб використовувати метод Magentos formatKey тут: http://www.magentocommerce.com/wiki/3_-_store_setup_and_management/seo/url_key_characters_conversion, на жаль, я натрапив на вікі після оновлення всіх клавіш, тому я не турбувався повторним оновленням все знову.

Сподіваюся, що це допомагає :)!


sudo php indexer.php --reindex catalog_url_catalogповинно бути sudo php indexer.php --reindex catalog_url_category.
Маттіас Зейс

Я зараз намагаюся зробити те саме. Після обрізання всіх таблиць повторно додаються лише прямі URL-адреси категорій та продуктів. Я не зміг знайти жодної записи для товарів у таких категоріях catalog/product/view/id/XXX/category/YYY. Чи можете ви підтвердити, що це для вас однаково? Я якось незрозумілий щодо цього ... Це помилка, чи я щось роблю не так? Я намагався зробити те ж саме в новому встановленні 1.13.0.2, те ж саме сталося. Rewrites працює добре в інтернеті, але категорія не встановлена.
fmrng

9

Виходячи з того, що я бачив возитися з EE 1.13 в тестовому середовищі, і щойно я зробив невеликі тести, ви повинні мати можливість просто урізати ці таблиці, а потім вручну відновити всі індекси URL-адреси CLI.

Таблиці * _cl використовуються в TRIGGERS, знайдених на catalog_product_entity_url_keyтаблиці. Записи, які вони вставляють у цю таблицю * _cl, - це, на мою думку, використовується для вказівки того, що потрібно повторно індексувати після збереження.

Ось що я зробив. Після використання інструменту CLI для відновлення індексів, здавалося, все було добре. Урізання MySql…

TRUNCATE TABLE `enterprise_url_rewrite_redirect_rewrite`;
TRUNCATE TABLE `enterprise_url_rewrite_redirect_cl`;
TRUNCATE TABLE `enterprise_url_rewrite_redirect`;
TRUNCATE TABLE `enterprise_url_rewrite_product_cl`;
TRUNCATE TABLE `enterprise_url_rewrite_category_cl`;
TRUNCATE TABLE `enterprise_url_rewrite`;
TRUNCATE TABLE `enterprise_catalog_product_rewrite`;
TRUNCATE TABLE `enterprise_catalog_category_rewrite`;
TRUNCATE TABLE `core_url_rewrite`;

Потім на CLI ...

php shell/indexer.php --reindex catalog_url_product
php shell/indexer.php --reindex catalog_url_category
php shell/indexer.php --reindex url_redirect

Дайте нам знати ваші результати… як Маріус, я ще не створив EE 1.13-сайт і маю лише досвід, коли з цим возитись із часу уявлення. :)


1
Привіт, Давиде, дякую за детальну відповідь. Я спробував ваші вказівки, але, на жаль, не пощастило. Це очистило всі перезаписи, але запуск indexer.php не відновив жодного. За ніч підтримка Magento фактично повернулася до мене, і їхня порада полягала в тому, що переписування URL-адрес тепер зберігається в: - catalog_product_entity_url_key для продуктів - catalog_category_entity_url_key для категорій Я також намагався їх очистити, хоча насправді в них було лише 2 записи, але знову ж таки удача. Я попросив їх отримати додаткові роз'яснення, тому я повідомляю вас, як тільки вони повернуться до мене.
JamesAllwood

Одне, що я помітив, дивлячись на це, це те, що переписування URL зберігається в enterprise_url_rewriteпорівнянні з тим, core_url_rewriteяк було раніше. У catalog_*_entity_url_keyтаблицях , як видається, реплицируются таблиця з URL-ключів для використання індексатор, і вони також є таблиці з тригерами , пов'язаних з URL переписування.
davidalger

@Francesco, чи раніше ви запускали цей сценарій після оновлення до 1,12? Якщо ні, то слід було б очікувати, що вам потрібно запустити його, і я б не називав цю помилку, оскільки це частина документально підтвердженого процесу оновлення, який проходить з 1.12 до 1.13.
davidalger

@davidalger: ви праві, сценарій працює майже добре (він створює деякі дивні URL-адреси, але лише декілька). Однак функція перезапису URL-адреси є досить слабкою у цьому випуску EE (наприклад, зміна ключа-ключа для продукту та збереження його, чи не ' t працювати, як очікувалося)
Фр.

Цю відповідь слід прийняти. Я можу підтвердити це на EE 1.13.
musicliftsme

4

Примітка щодо використання TRUNCATE:

TRUNCATE TABLE `enterprise_url_rewrite`;

видає помилку через закордонні ключові посилання:

ERROR 1701 (42000): Cannot truncate a table referenced in a foreign key constraint (`customerx_dev`.`enterprise_catalog_category_rewrite`, CONSTRAINT `FK_415B32DA3DF924D5C803CF24EB3AC1D9` FOREIGN KEY (`url_rewrite_id`) REFERENCES `customerx_dev`.`enterprise_url_rewrite` (`url_rewrite_i)

Запуск команд обрізати / видалити так, як це працювало:

TRUNCATE TABLE `enterprise_url_rewrite_redirect_rewrite`;
TRUNCATE TABLE `enterprise_url_rewrite_redirect_cl`;
TRUNCATE TABLE `enterprise_url_rewrite_redirect`;
TRUNCATE TABLE `enterprise_url_rewrite_product_cl`;
TRUNCATE TABLE `enterprise_url_rewrite_category_cl`;
TRUNCATE TABLE `enterprise_catalog_product_rewrite`;
TRUNCATE TABLE `enterprise_catalog_category_rewrite`;
TRUNCATE TABLE `core_url_rewrite`;
DELETE FROM `enterprise_url_rewrite`;

Використовуйте SET FOREIGN_KEY_CHECKS = 0;перед своїм TRUNCATE ...і SET FOREIGN_KEY_CHECKS = 1;в самому дні, післяDELETE FROM ...
Олег

4

Проста відповідь - Ні, усі ці таблиці не є безпечним, принаймні, якщо ви не знаєте наслідків:

  • Обрізання всіх таблиць перезапису та запуску повторного індексування веде на робочий сайт

Однак:

  • Ви втратите всі власні переписування (це нормально)
  • Catalog -> Url Redirectбуде порожнім (на EE 1.13.1) (це виглядає як помилка згідно з Magento. Це очікувана поведінка на 1.13.1) (див. також коментар нижче)

2
Я хотів би лише додати, що Catalog -> Url Redirectпоказує лише несистемні переписування. Отже, тут відображатимуться лише ваші користувацькі переписувачі. тобто рядки з enterprise_url_rewrite.system = 0.
musicliftsme

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