Alle URL-Umschreibungen löschen - Enterprise (1.13)


27

Nach mehreren durcheinandergebrachten Importen habe ich eine Menge URL-Änderungen hinterlassen, die ich entfernen muss.

Ich verwende Enterprise 1.13

Wenn ich dieses Problem in der Community hatte, habe ich einfach abgeschnitten core_url_rewriteund das neu indiziert.

In Enterprise stelle ich jedoch fest, dass es eine Reihe verschiedener Tabellen gibt, die das Umschreiben steuern.

  • 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

Bin ich sicher, sie alle abzuschneiden?

Ich erwarte voll und ganz, dass mir jemand sagt, ich solle diese Tabellen niemals kürzen, also entschuldige mich im Voraus für die Naivität.


Was meinen Sie mit "einer Reihe von verschiedenen Tabellen, die das Umschreiben steuern"? Auf EE habe ich normalerweise dasselbe gemacht wie auf CE. Abschneiden core_url_rewriteund es hat funktioniert.
Marius

Hallo Marius. Dies sind die Tabellen, die das Umschreiben steuern sollen. Ich hatte core_url_rewrites abgeschnitten, aber die in admin aufgelisteten hatten keine Auswirkungen. enterprise_url_rewrite enterprise_url_rewrite_category_cl enterprise_url_rewrite_product_cl enterprise_url_rewrite_redirect enterprise_url_rewrite_redirect_rewrite Thanks
JamesAllwood

Oh, Entschuldigung. Mein Fehler. Ich habe diese Zeile "Ich verwende Enterprise 1.13" verpasst. Ich habe (noch) keine Erfahrung mit EE 1.13. Ignoriere mich jetzt.
Marius


1
Wir haben kürzlich Magento EE 1.12 für einen unserer Shops auf EE 1.13 aktualisiert und auf unserer Website einen Beitrag über Änderungen und Probleme verfasst, die auftreten können: code4business.de/update-magento-enterprise-edition-1-13-0-2 /… Der Beitrag hat eine englische Übersetzung am Ende der Seite.
user2830524

Antworten:


30

Wir sind in einer ähnlichen Situation wie du, James. Nach vielem Graben habe ich mir Folgendes ausgedacht:

Die core_url_rewriteTabelle ist jetzt veraltet, stattdessen speichert Magento EE 1.13 jetzt die Umschreibungen in enterprise_url_rewrite.

Tabellen: enterprise_*_category_rewriteVerwenden Sie catalog_*_entity_url_keyTabellen, um die beiden Umschreibtabellen bei der Ausführung neu zu erstellenphp indexer.php --reindex catalog_url_*

Wenn Sie in admin Catalog-> URL Redirects eine 'URL Redirect' für eine benutzerdefinierte URL hinzufügen, wird diese zur enterprise_url_rewrite_redirectTabelle hinzugefügt und das Flag für Magento, dass der Index jetzt veraltet ist, wird in die enterprise_url_rewrite_redirect_clTabelle eingegeben, die beim Ausführen php indexer.php --reindex url_redirectdie enterprise_url_rewrite_redirect_rewriteTabelle neu erstellt.

Kurz gesagt, jede Tabelle, die mit _cl endet, kann sicher abgeschnitten werden. 'CL' steht für Change Log (Änderungsprotokoll) und wird von Magento verwendet, um zu überprüfen, ob eine Neuindizierung erforderlich ist.

Was die URL Key Tabellen gehen, ich bin immer noch ein bisschen ratlos, warum es zwei URL Schlüsseleinträge einen in catalog_*_entity_url_keyund einen in catalog_*_entity_varchar(Attribut - ID 90), aber ich nehme an, das ist , was passiert:

Wenn Sie ein neues Produkt / eine neue Kategorie erstellen, verwendet Magento den Namen, um einen url_key zu generieren, der in catalog_*_entity_url_keyAND in platziert catalog_*_entity_varcharwird. Die von Magento verwendete Primärtabelle ist jedoch die, catalog_*_entity_url_keyda php indexer.php --reindex catalog_url_*Ihre enterprise_*_category_rewriteTabellen leer sind und Produkte / Kategorien in leer sind, wenn Sie sie abschneiden und ausführen Das Frontend zeigt hässliche URLs an, dh http://example.com/catalog/product/view/id/123/etc/etc(nicht SOE-freundlich) Ich glaube, die beiden Tabellen sind miteinander verwandt und werden zum Erstellen der enterprise_url_rewriteTabelle verwendet, da in dieser Tabelle ein 'request_path' gespeichert ist, höchstwahrscheinlich der url_key in der catalog_*_entity_varcharTabelle und ein 'identifier', der der primäre ist URL-Schlüssel aus der catalog_*_entity_url_keyTabelle. Ich könnte mich bei url_key- und varchar-Tabellen völlig irren, also denke ich nur laut nach.

Wie auch immer, um alle Umschreibtabellen erfolgreich abzuschneiden und neu zu erstellen, können Sie Folgendes ausführen:

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;

und dann laufen:

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

Wenn Sie auch kürzen enterprise_url_rewrite_redirect, verlieren Sie alle benutzerdefinierten Weiterleitungen, die Sie in Ihrem Admin-Bereich sehen. Vielleicht ist dies Ihr Ziel, da Sie eine Menge nutzloser URLs hinterlassen haben. Solange Sie die Tabellen '* _entity_url_key' NICHT abschneiden, ist alles in Ordnung.

Unsere Geschichte war etwas anders, da wir nach dem Upgrade von 1.11 auf 1.13 doppelte URL-Schlüssel und größere Probleme mit Produktnamen hatten. Deshalb habe ich dieses schnelle Skript geschrieben, um die catalog_product_entity_url_keyTabelle und die URL-Schlüssel und URL-Pfade in der catalog_product_entity_varcharTabelle mit product zurückzusetzen Namen. Ich habe den folgenden Code angehängt, aber wenn Sie ihn verwenden, verwenden Sie ihn auf eigenes Risiko.

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

Der Code kann so angepasst werden, dass die Magentos-FormatKey-Methode hier verwendet wird: http://www.magentocommerce.com/wiki/3_-_store_setup_and_management/seo/url_key_characters_conversion Leider bin ich auf das Wiki gestoßen, nachdem ich alle Schlüssel aktualisiert habe, sodass ich mich nicht darum gekümmert habe, sie zu aktualisieren alles wieder.

Hoffentlich hilft das :)!


sudo php indexer.php --reindex catalog_url_catalogsollte sein sudo php indexer.php --reindex catalog_url_category.
Matthias Zeis

Ich versuche jetzt das Gleiche zu tun. Nach dem Abschneiden aller Tabellen werden jedoch nur direkte Kategorie- und Produkt-URLs neu indiziert. Ich konnte keinen Eintrag für Produkte in Kategorien wie finden catalog/product/view/id/XXX/category/YYY. Können Sie bitte bestätigen, dass dies für Sie dasselbe ist? Ich bin ein bisschen ahnungslos ... Ist es ein Fehler oder mache ich etwas falsch? Ich habe versucht, dasselbe bei einer Neuinstallation von 1.13.0.2 zu tun, dasselbe geschah. Rewrites funktioniert im Frontend, aber es ist keine Kategorie festgelegt.
10.

9

Basierend auf dem, was ich in einer Testumgebung mit EE 1.13 gesehen habe, und ein paar kurzen Tests, die ich gerade durchgeführt habe, sollten Sie in der Lage sein, diese Tabellen einfach abzuschneiden und dann alle URL-Indizes von der CLI aus manuell neu zu erstellen.

Die * _cl-Tabellen werden in den in der Tabelle gefundenen TRIGGERS verwendet catalog_product_entity_url_key. Die Datensätze, die sie in diese * _cl-Tabelle einfügen, werden meiner Meinung nach verwendet, um anzugeben, was nach dem Speichern neu indiziert werden muss.

Hier ist was ich getan habe. Nachdem die Indizes mit dem CLI-Tool neu erstellt wurden, schien alles in Ordnung zu sein. MySQL-Kürzung…

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

Dann auf der CLI…

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

Teilen Sie uns Ihre Ergebnisse mit ... wie Marius habe ich noch keine EE 1.13-Site erstellt und seit Imagine nur die Erfahrung aus dem Herumspielen damit. :)


1
Hallo David, Danke für deine ausführliche Antwort. Ich habe deine Anweisungen ausprobiert, aber leider kein Glück. Alle Änderungen wurden gelöscht, aber indexer.php konnte nicht neu generiert werden. Über Nacht hat sich der Magento-Support tatsächlich an mich gewandt, und der Rat lautete, dass URL-Umschreibungen jetzt gespeichert werden in: - catalog_product_entity_url_key für Produkte - catalog_category_entity_url_key für Kategorien Ich habe auch versucht, diese zu löschen, obwohl es tatsächlich nur 2 Einträge in ihnen gab, aber jetzt wieder glück. Ich habe sie um eine weitere Klärung gebeten, also werde ich Sie informieren, sobald sie sich bei mir melden.
JamesAllwood

Als ich mir das ansah, bemerkte ich, dass die URL-Umschreibungen in enterprise_url_rewritevs gespeichert sind, core_url_rewritewie sie vorher waren. Die catalog_*_entity_url_keyTabellen scheinen eine replizierte Tabelle mit den URL-Schlüsseln zu sein, die vom Indexer verwendet werden, und sie sind auch die Tabellen mit den Auslösern, die sich auf die URL-Neuschreibungen beziehen.
Davidalger

@Francesco, haben Sie dieses Skript nach dem Upgrade von 1.12 bereits ausgeführt? Wenn nicht, wird erwartet, dass Sie es ausführen müssen, und ich würde es nicht als fehlerhaft bezeichnen, da es Teil des dokumentierten Aktualisierungsprozesses ist, der von 1.12 auf 1.13 übergeht.
Davidalger

@davidalger: Sie haben Recht, das Skript funktioniert fast gut (es erzeugt einige seltsame URLs, aber nur wenige). Die Funktionalität zum Umschreiben von URLs ist in dieser EE-Version jedoch recht schwach (zum Beispiel Ändern des URL-Schlüssels für ein Produkt und Speichern, nicht wahr?). funktioniert nicht wie erwartet)
Fr.

Diese Antwort sollte akzeptiert werden. Ich kann bestätigen, dass dies auf EE 1.13 funktioniert.
Musicliftsme

4

Ein Hinweis zur Verwendung von TRUNCATE:

TRUNCATE TABLE `enterprise_url_rewrite`;

gibt einen Fehler wegen Fremdschlüsselreferenzen aus:

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)

Das Ausführen von Kürzungs- / Löschbefehlen funktioniert folgendermaßen:

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

Verwenden Sie SET FOREIGN_KEY_CHECKS = 0;vor TRUNCATE ...und SET FOREIGN_KEY_CHECKS = 1;ganz unten, nachDELETE FROM ...
Oleg

4

Die einfache Antwort lautet: Nein, es ist nicht sicher, diese Tabellen abzuschneiden, zumindest wenn Sie die Konsequenz nicht kennen:

  • Kürzen Sie alle Umschreibtabellen, und führen Sie einen Neuindex durch, der zu einer Arbeitsstelle führt

Jedoch:

  • Sie verlieren alle benutzerdefinierten Überschreibungen (das ist normal)
  • Catalog -> Url Redirectwird leer sein (in EE 1.13.1) (das sieht aus wie ein Bug in Magento, dies ist das erwartete Verhalten in 1.13.1) (siehe auch Kommentar unten)

2
Ich möchte nur hinzufügen, dass Catalog -> Url Redirectnur Nicht-System-Umschreibungen angezeigt werden. Daher werden hier nur Ihre benutzerdefinierten Änderungen angezeigt. dh Zeilen mit enterprise_url_rewrite.system = 0.
musicliftsme

Ja, Sie haben Recht. Ich habe die Antwort mit den letzten Informationen verbessert, die ich vom Magento-Support-Team erhalten habe. Fühlen Sie sich frei, meine Antwort zu verbessern, wenn Sie möchten
Fra
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.