Zauważyłem dużą liczbę raportów, że sama tabela może być bardzo zagracona, prowadzę witrynę z ~ 5000 SKU i ~ 250 kategoriami (w jednym sklepie) oraz wynikową core_url_rewrite
tabelą zawierającą ponad 600 000 linii i ponad 500 MB dużych, które jest szalony.
Może to spowolnić działanie witryny i spowodować powstanie bardzo obszernej bazy danych. Zrobiłem trochę kopania i znalazłem sporo postów na ten temat, w szczególności:
Błąd Core_url_rewrite: Ogromna ilość zduplikowanych adresów URL dla każdego produktu wygenerowanego na indeksieMagento Commerce - Śledzenie błędów - numer 29020
// Te linki zostały usunięte od czasu wdrożenia nowych płyt
Teraz rozumiem, że tabela może zostać obcięta i ponownie indeksowana, ale to nie rozwiązuje problemu, tylko przedłuża problem.
Z tego, co rozumiem, częścią problemu są produkty, które mają ten sam klucz adresu URL na podstawie nazwy produktu, co powoduje indeksowane linki.
Wspomniana poprawka to:
app/code/core/Mage/Catalog/Model/Url.php
on-line ~ 807:
Zmiana:
if ($product->getUrlKey() == '' && !empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
Do:
if (!empty($requestPath)
&& strpos($existingRequestPath, $requestPath) === 0
)
Ale nawet to nie rozwiązuje całkowicie problemu.
Moje pytanie jest następujące:
Jeśli doświadczyłeś tego problemu, czy udało Ci się skonfigurować skuteczny, logiczny i wydajny algorytm, który nie wymaga „zarządzania” wielokrotnie, ale faktyczne rozwiązanie problemu raz na zawsze?
Czy naprawdę docenić pewien wgląd w to.
BTW: Zrób sobie przysługę i sprawdź, jak teraz wygląda twój stół, możesz mieć ten problem i wpływ na wydajność, nawet o tym nie wiedząc - nie wiedziałem.
Edycja: Byłem w kontakcie ze stroną www.Nexcess.net (platynowy partner Magento) i potwierdzili oni, że klienci żądają, aby ich core_url_rewrite
tabela wymagała obcięcia ze względu na zbyt duże rozmiary.
Moim największym zmartwieniem jest to, że może to mieć wpływ na SEO, dlatego chciałbym rozwiązania, a nie odkładania problemu na później.
Aktualizacja: Nexcess wspomniał, że przy zduplikowanych produktach w tabeli może to w rzeczywistości zaszkodzić SEO.
Odpowiedzi:
Udało mi się ustabilizować problem w następujący sposób:
Krok 1: Przepisz model katalogu URL (używając własnego modułu: jak to zrobić )
Zgodnie z rozwiązaniem Jahnniego na
tablice MagentoCommerce(nie jest już aktywny z nową tablicą),app/code/core/Mage/Catalog/Model/Url.php
[wokół linii 807Mage_Catalog_Model_Url::getProductRequestPath()
]Od:
Do:
Krok 2: Obetnij
Obetnij
core_url_rewrite
stółKrok 3: Reindex i Flush Cache
Zainicjuj proces ponownej indeksacji w Core URL Rewrites. Następnie będziesz musiał opróżnić pamięć podręczną i pamięć podręczną Magento.
System
→Cache Management
→Flush Magento Cache
System
→Cache Management
→Flush Cache Storage
Voila, wszystko gotowe. Zauważysz, że jeśli uruchomisz ponownie indeksatora, tabela powinna pozostać na stałym poziomie (chyba że dodałeś więcej produktów między nimi lub jeśli masz zduplikowane nazwy kategorii).
źródło
core_url_rewrite
teraz na tabelę i zanotuj liczbę rekordów. Ponownie uruchom krok 3 (ponowne indeksowanie) i odśwież widok nacore_url_rewrite
stole. Jeśli numer jest taki sam, problem został rozwiązany. Następnie śmiało połącz ręcznie niestandardowe przepisywania. Wszystkiego najlepszego.Chociaż mam nadzieję, że ktoś tu znajdzie odpowiedź, nie wiem, czy ją znajdziesz. Ten stół robi się nieporęczny z wielu różnych powodów. Błędy we wcześniejszych (i prawdopodobnie aktualnych) wersjach Magento to jedno. Inna jest logika w tej tabeli, która próbuje śledzić zmiany wartości klucza adresu URL, dzięki czemu przepisywania 301/302 są konfigurowane dla starych produktów. Z tego powodu i komplikowanie rzeczy, obcinanie tabeli i regenerowanie może sprawić, że istniejące przepisywania adresów URL znikną, a to będzie miało nieznany wpływ na twoją listę wyszukiwarek (nie jest to zła konieczność, tylko trudne do przewidzenia).
Moja ogólna rada dla klientów, którzy pytają to:
Opuść gigantyczny stół do uprawy tak, jakbyś nie miał dobrego zdania na temat swojej URL / SEO
Dopóki rozmiar tabeli nie będzie stanowić problemu (na przykład generowanie map witryn). Kiedy tak się stanie, uzyskaj kontrolę nad swoją sytuacją dotyczącą adresów URL / SEO.
Po opanowaniu sytuacji dotyczącej adresu URL / SEO należy wykonać kopię zapasową tabeli, a następnie ją obciąć i zregenerować. Rozwiązuj wszelkie problemy związane z adresami URL / SEO spowodowane przycinaniem.
Zautomatyzuj krok 3
Próbowanie naprawy tego na poziomie kodu Magento jest godne podziwu, ale będziesz pływał pod prąd. Czasami lepiej jest zaakceptować, że „To tylko Magento jest Magento” i rozwiązać problem z procesem zewnętrznym.
źródło
Chciałbym dodać poprawkę do tego błędu indeksowania przepisywania adresów URL, który został opracowany podczas bugathonu w marcu 2013 r. I który został później ulepszony. To powinno rozwiązać ten problem. Jako odniesienie, oto plik łatki z linku:
Dodatkowo chciałbym dodać łatkę EE
PATCH_SUPEE-389_EE_1.12.0.2_v2.sh
, która jest teraz dostępna na GitHub :Jeśli chcesz używać tej poprawki z CE, sprawdź ją poprawnie, ponieważ została opracowana dla EE.
źródło
Po zastosowaniu poprawki opublikowanej przez Simona możesz użyć następującego zapytania, aby usunąć niepotrzebne dane:
W przeciwieństwie do zapytania Ashisha Hiry, wpływa to tylko na adresy URL, które mają liczbę całkowitą, ponieważ ostatnia część była - w moim przypadku - przyczyną bałaganu.
Próbuje nie dotykać poprawnych zapisów, które na przykład mogły zostać utworzone podczas aktualizacji klucza adresu URL.
źródło
Z powodzeniem zastosowałem przyjętą odpowiedź. Podczas kolejnej instalacji Magento musiałem zachować niektóre niestandardowe przepisywania, więc usunąłem wszystkie wpisy, które zakończyły się na - a następnie liczbę o długości do 5 cyfr z:
To w większości działało, ale nadal dostaję 2 kolejne wiersze przy każdym ponownym indeksowaniu. Nie pewny dlaczego. Myślałem, że podzielę się tym doświadczeniem.
źródło
$collection = Mage::getModel('catalog/product')->getCollection()->addAttributeToFilter('url_key', array('regexp' => '[0-9]$'));
Główna zmiana, o której wspomniałeś, wydaje się potrzebna tylko wtedy, gdy masz produkty bez kluczy url, jednak Magento zawsze powinno tworzyć dla Ciebie klucze url_keys. Jeśli masz importera, który tworzy produkty bez kluczy url_, to problem pojawi się w przypadku tych produktów. Spróbuj uruchomić następujące zapytanie, aby znaleźć takie produkty:
Jeśli jakiekolwiek produkty powrócą z tego zapytania, nie mają klucza url_ i będą stanowić problem.
źródło
entity_type_id
dla produktów jest 4, a nie 10.Postępowałem zgodnie z zatwierdzonym rozwiązaniem, aby zapobiec powtórnemu zapisywaniu adresów URL, a następnie eksportowałem
core_url_rewrite
jako plik CSV. Był w stanie otworzyć ten plik CSV i usunąć wszystkie oprócz ręcznie utworzonych przeróbek adresów URL.Następnie obciąłem
core_url_rewrite
tabelę i zaimportowałem zapisany plik CSV z ręcznie utworzonymi przepisem adresów URL.Po wszystkich zmianach zmieniono z 940 tys. Wierszy na 32 tys. Ogromna poprawa.
źródło
Oto łatka (lokalne przepisywanie) dla społeczności Magento, aby naprawić, że https://github.com/biotech/Magento-URL-Rewrite W rzeczywistości robi to samo, co łatka EE PATCH_SUPEE-389_EE_1.12.0.2_v2.sh - sprawdź każde przepisanie i unikaj tworzenia zduplikowanych rekordów. Działa dobrze przez ostatnie 2 miesiące w produkcji CE 1.9, 15 tys. Produktów, 4 sklepy, pełne ponowne indeksowanie każdej nocy po zmianach importu produktów masowych.
źródło
Ponieważ nie jest to jeszcze wspomniane w tym wątku, chciałem podzielić się fajną wiadomością, że ten problem został rozwiązany w Magento 1.9.3.9 i nowszych. Zobacz powiązane informacje o wersji :
Tak więc wszystkie poprawki dla tego problemu wspomniane tutaj nie są konieczne, gdy używasz wersji Magento większej lub równej niż 1.9.3.9. Nadal sugeruję usunięcie starych wartości zgodnie z opisem w odpowiedzi Alexa .
źródło
Uruchom to zapytanie
Pomoże to z pewnością zmniejszyć rozmiar
core_url_size
tabeli poprzez usunięcie niepotrzebnych danych.źródło
Pozbyć się
.html
.html
Ustaw w .htaccess
Usuń wszystkie
.html
przekierowania:źródło
Oficjalną odpowiedzią powinna być instalacja SUPEE-389. Proste.
Doskonale współpracuje z Magento CE, ponieważ dzielą ten sam kawałek kodu w tym obszarze.
Możesz znaleźć plik łatki tutaj, https://gist.github.com/piotrekkaminski/c348538ca91ba35773be#file-patch_supee-389_ee_1-12-0-2_v2-sh
Wystąpił ten problem i wygenerowano tysiące nowych wierszy po każdym ponownym indeksowaniu adresu URL katalogu. Teraz problem zniknął ... z wyjątkiem faktu, że musimy wyczyścić DB.
Przedstawiony tutaj skrypt wydaje się dobrym początkiem, ale nie jest to idealne rozwiązanie,
Zobacz https://www.atwix.com/magento/duplicated-product-url-keys-in-community-edition/
źródło
Istnieje również dedykowany moduł https://github.com/vladsmirnov/url-rewrites , więc nie musisz ponownie nakładać łaty po każdej aktualizacji Magento. Moduł składa się z dwóch części: aktualnego modułu, aby zapobiec duplikowaniu, oraz skryptu powłoki, aby wyczyścić istniejącą bazę danych.
źródło