Wyczyść wszystkie przepisane adresy URL - Enterprise (1.13)


27

Po kilku nieudanych próbach importu zostałem obciążony przepisem adresów URL, które muszę usunąć.

Używam Enterprise 1.13

Kiedy miałem ten problem w społeczności, po prostu core_url_rewriteobciąłem i ponownie zindeksowałem.

Jednak w Enterprise zauważam, że istnieje wiele różnych tabel kontrolujących przepisywanie.

  • 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

Czy mogę bezpiecznie obciąć je wszystkie?

W pełni oczekuję, że ktoś powie mi, że nigdy nie powinienem obcinać tych tabel, więc z góry przepraszam za naiwność.


Co rozumiesz przez „wiele różnych tabel sterujących przepisywaniem”? Na EE zwykle robiłem to samo, co na CE. Obetnij core_url_rewritei zadziałało.
Marius

Cześć Marius. Są to tabele, które wyglądają na kontrolę przepisywania. Obciąłem core_url_rewrites, ale nie wpłynęło to na te wymienione w admin. 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 Dzięki
JamesAllwood

Przepraszam. Mój błąd. Brakowało mi tego wiersza „Korzystam z Enterprise 1.13”. Nie mam (jeszcze) doświadczenia z EE 1.13. Zignoruj ​​mnie na razie.
Marius

1
Coś do rozważenia: gist.github.com/Vinai/5451584
B00MER

1
Niedawno zaktualizowaliśmy Magento EE 1.12 do EE 1.13 dla jednego z naszych sklepów i napisaliśmy post na naszej stronie internetowej o zmianach i problemach, które mogą się pojawić: code4business.de/update-magento-enterprise-edition-1-13-0-2 /… Post ma tłumaczenie na angielski na dole strony.
user2830524,

Odpowiedzi:


30

Jesteśmy w podobnej sytuacji jak ty James. Po wielu kopaniach wpadłem na to:

core_url_rewriteTabela jest obecnie przestarzała, zamiast Magento EE 1,13 teraz przechowuje przepisuje się enterprise_url_rewrite.

Tabele: enterprise_*_category_rewriteużyj catalog_*_entity_url_keytabel do przebudowania dwóch tabel przepisywania po uruchomieniuphp indexer.php --reindex catalog_url_*

Gdy dodasz „Przekierowanie URL” w katalogu Administrator-> Przekierowania URL dla niestandardowego adresu URL, zostanie on dodany do enterprise_url_rewrite_redirecttabeli, a flaga Magento informująca o tym, że indeks jest już nieaktualny, zostanie wprowadzona do enterprise_url_rewrite_redirect_cltabeli, która po uruchomieniu php indexer.php --reindex url_redirectodbuduje enterprise_url_rewrite_redirect_rewritetabelę.

Szybka uwaga, każda tabela z rozszerzeniem _cl jest bezpieczna do obcięcia, „CL” oznacza Dziennik zmian i jest używany przez Magento do sprawdzenia, czy wymagana jest ponowna indeksacja.

Jeśli chodzi o tabele kluczy URL, wciąż jestem trochę nieświadomy, dlaczego istnieją dwa wpisy klucza URL jeden do catalog_*_entity_url_keyjednego i jeden do catalog_*_entity_varchar(identyfikator atrybutu 90), ale zakładam, że tak się dzieje:

Podczas tworzenia nowego produktu / kategoria Magento używa nazwy wygenerować url_key który jest umieszczony w catalog_*_entity_url_keyaw catalog_*_entity_varchar, ale podstawowa tabela wykorzystywane przez Magento jest catalog_*_entity_url_keybo jeśli obciąć go i uruchomić php indexer.php --reindex catalog_url_*Twoje enterprise_*_category_rewritetabele będzie pusta i produkty / Kategorie frontend wyświetli brzydkie adresy URL, tj. http://example.com/catalog/product/view/id/123/etc/etc(nieprzyjazne dla SOE) Wierzę, że dwie tabele są ze sobą powiązane i są używane do budowania enterprise_url_rewritetabeli, ponieważ ta tabela przechowuje „ścieżkę_poprawki” najprawdopodobniej wewnątrz catalog_*_entity_varchartabeli i „identyfikator”, który jest podstawowym Klucz URL z catalog_*_entity_url_keytabeli. Mogę się całkowicie mylić co do tabel url_key i varchar, więc po prostu myślę na głos.

W każdym razie, aby pomyślnie obciąć i przebudować wszystkie tabele przepisywania, które możesz wykonać:

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;

a następnie uruchom:

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

Jeśli również obetniesz, enterprise_url_rewrite_redirectstracisz wszystkie niestandardowe przekierowania, które widzisz w panelu administracyjnym, być może jest to twój cel, ponieważ masz mnóstwo niepotrzebnych adresów URL. Dopóki NIE obetniesz tabel „* _entity_url_key”, nic ci nie będzie.

Nasza historia była nieco inna, ponieważ mieliśmy zduplikowane klucze URL i poważne problemy z nazwami produktów z importu Excela po aktualizacji do 1.13 z 1.11, więc napisałem ten szybki skrypt, aby zresetować catalog_product_entity_url_keytabelę oraz klucze URL i ścieżki URL w catalog_product_entity_varchartabeli za pomocą produktu nazwy. Załączam poniższy kod, ale jeśli go użyjesz, użyj go na własne ryzyko.

<?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.']';

Kod można zmodyfikować, aby używał metody Magentos formatKey tutaj: http://www.magentocommerce.com/wiki/3_-_store_setup_and_management/seo/url_key_characters_conversion niestety natrafiłem na wiki po zaktualizowaniu wszystkich kluczy, więc nie zawracałem sobie głowy ponowną aktualizacją wszystko znowu.

Mam nadzieję, że to pomoże :)!


sudo php indexer.php --reindex catalog_url_catalogpowinno być sudo php indexer.php --reindex catalog_url_category.
Matthias Zeis,

Próbuję teraz zrobić to samo. Po obcinaniu wszystkich tabel ponownie indeksowane są tylko bezpośrednie adresy URL kategorii i produktów. Nie mogłem znaleźć żadnego wpisu dla produktów w kategoriach takich jak catalog/product/view/id/XXX/category/YYY. Czy możesz potwierdzić, że to samo dotyczy Ciebie? Nie mam pojęcia o tym ... Czy to błąd, czy robię coś złego? Próbowałem zrobić to samo na świeżej instalacji 1.13.0.2, to samo się stało. Rewrites działa poprawnie w interfejsie użytkownika, ale żadna kategoria nie jest ustawiona.
fmrng,

9

W oparciu o to, co widziałem, gdy bawię się w EE 1.13 w środowisku testowym i krótkie testy, które właśnie wykonałem, powinieneś być w stanie obciąć te tabele, a następnie ręcznie odbudować wszystkie indeksy URL z CLI.

Tabele * _cl są używane w TRIGGERS znalezionych w catalog_product_entity_url_keytabeli. Rekordy, które wstawiają do tabeli * _cl są, jak sądzę, używane do wskazania, co należy ponownie zindeksować po zapisach.

Oto co zrobiłem. Po użyciu narzędzia CLI do odbudowania indeksów wszystko wyglądało na dobre. Obcinanie 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`;

Następnie na CLI…

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

Poinformuj nas o swoich wynikach ... tak jak Marius, jeszcze nie zbudowałem strony EE 1.13 i mam tylko doświadczenie w tym, że można się nią bawić od Imagine. :)


1
Cześć David, dziękuję za twoją szczegółową odpowiedź. Próbowałem twoich instrukcji, ale niestety niestety. Usunęło wszystkie przepisania, ale uruchomienie indexer.php nie wygenerowało żadnego. W ciągu nocy wsparcie Magento faktycznie do mnie wróciło, a ich rada była taka, że ​​zapisywanie adresów URL jest teraz zapisywane w: - catalog_product_entity_url_key dla produktów - catalog_category_entity_url_key dla kategorii Próbowałem też je wyczyścić, chociaż w rzeczywistości były tylko 2 wpisy, ale znowu teraz szczęście. Poprosiłem ich o dalsze wyjaśnienia, więc dam ci znać, gdy tylko do mnie wrócą.
JamesAllwood

Jedną z rzeczy, które zauważyłem, patrząc na to, było to, że przepisywanie adresów URL jest przechowywane w enterprise_url_rewriteporównaniu z core_url_rewritepoprzednimi wersjami. Te catalog_*_entity_url_keytabele wydają się być replikowane tabela z URL kluczy do wykorzystania przez indekser, a są też stoliki z wyzwalaczy związanych z przepisuje URL.
davidalger

@Francesco, czy wcześniej uruchomiłeś ten skrypt po aktualizacji z wersji 1.12? Jeśli nie, to należy oczekiwać, że musisz go uruchomić, a ja nie nazwałbym tego błędem, ponieważ jest to część udokumentowanego procesu aktualizacji z wersji 1.12 do 1.13.
davidalger

@davidalger: masz rację, skrypt działa prawie dobrze (tworzy dziwne adresy URL, ale tylko kilka). Jednak funkcja przepisywania adresów URL jest dość słaba w tej wersji EE (np. zmiana klucza adresu URL produktu i zapisanie go, nie t działa zgodnie z oczekiwaniami)
Fra

Ta odpowiedź powinna zostać zaakceptowana. Mogę potwierdzić, że działa na EE 1.13.
musicliftsme

4

Uwaga dotycząca używania TRUNCATE:

TRUNCATE TABLE `enterprise_url_rewrite`;

daje błąd z powodu odwołania do klucza obcego:

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)

Uruchamianie poleceń obcinania / usuwania w ten sposób działałoby:

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

Użyj SET FOREIGN_KEY_CHECKS = 0;przed TRUNCATE ...i SET FOREIGN_KEY_CHECKS = 1;na samym dole, poDELETE FROM ...
Oleg

4

Odpowiedź jest prosta: No to nie jest bezpieczne, aby obciąć te tabele, przynajmniej jeśli nie znają konsekwencje:

  • Obetnij wszystkie tabele przepisywania i uruchom ponownie indeksowanie prowadzi do działającej witryny

Jednak:

  • Utracisz wszystkie niestandardowe przepisywania (to normalne)
  • Catalog -> Url Redirectbędzie pusty (na EE 1.13.1) (który wygląda jak błąd według Magento, takie jest oczekiwane zachowanie na 1.13.1) (patrz również komentarz poniżej)

2
Chciałbym tylko dodać, że Catalog -> Url Redirectpokazuje tylko przepisywanie niesystemowe. Wyświetlane będą tutaj tylko niestandardowe przepisywania. tzn. wiersze z enterprise_url_rewrite.system = 0.
musicliftsme

tak, masz rację, poprawiłem odpowiedź ostatnimi informacjami, które otrzymałem od Zespołu Wsparcia Magento. Jeśli chcesz,
Fra
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.