Magento leitet auf die alte Website weiter, unabhängig davon, welche Änderungen vorgenommen wurden!

10

Wir haben das seltsamste Umleitungsproblem auf einer Magento-Site. Wir haben den Inhalt der Website von einer anderen Magento-Website auf eine neue URL kopiert. Wir haben dies in der Vergangenheit ohne Probleme getan, aber aus irgendeinem Grund leitet diese auf die alte Website weiter, sobald Sie versuchen, die Seite oder eine beliebige Seite zu laden.

Im Folgenden sind alle Schritte aufgeführt, die ich bisher unternommen habe, um diesen Schmerz zu beheben ...

www.Old-Domain.com = Die alte Site-URL, von der wir uns entfernt haben

www.NEW-Domain.com = Die neue Site, auf die wir Magento kopiert haben.

Bisherige Schritte zur Behebung eines Umleitungsproblems:

  • Durchsuchte die gesamte MySQL-Datenbank (Alle Tabellen) nach der Zeichenfolge www.Old-Domain.comund stellte sicher, dass keine vorhanden war, die die Umleitung verursachen könnte.
  • Die core_config_dataSpalten der Datenbanktabelle web/unsecure/base_urlund web/secure/base_urldie URL der neuen Site wurden aktualisiertwww.NEW-Domain.com
  • löschte alle Cache-Dateien aus /var/cache/dem Magento-Stammverzeichnis
  • Überprüfte die Cache-Ordner des Servers, um sicherzustellen, dass Dateien dort aufgrund von Berechtigungen oder anderen Fehlern nicht zwischengespeichert wurden.
  • Untersuchte .htaccessDatei, um sicherzustellen, dass es dort nicht passiert
  • Untersuchte auch die index.phpDatei und druckte einige Inhalte aus, gefolgt von einem exit()Aufruf, und verschob sie schrittweise auf der Seite nach unten, bis die Umleitung erfolgt. Es ist die allerletzte Zeile, in der dies aufgerufen wird, Mage::run($mageRunCode, $mageRunType);sobald die Seite geladen ist und zu dieser Zeile gelangt. Ich werde sofort zu unserer alten Website-URL weitergeleitet!

Irgendwelche Ideen?

JasonDavis
quelle
Debug für index.php. Was sind die Variablen $mageRunCodeund $mageRunTypegefüllt mit auf einer Ihrer normalen Lauf Websites und wie sie im Vergleich zum Umleiten Website?
Fiasco Labs
@ Jason: Ist dein Problem gelöst?
Zus

Antworten:

20

Oder die älteste im Buch, Ihre Datei- / Verzeichnisberechtigungen sind aus dem Ruder gelaufen, was dazu führt, dass Magento in den /tmpSystemordner schreibt. Dies bedeutet, dass Konfigurationsinformationen zwischengespeichert werden, bis Sie den gesamten Server neu starten oder den Magento-Cache aus dem /tmpSystemordner löschen .

Das Problem wird hier beschrieben. Die Magento-Basis-URL im Cache kann nicht geändert werden

Dies nur einschließen, da die Cache- Ordner des Servers nicht unbedingt in / tmp übersetzt werden

Es wird auch nicht vermerkt, ob dies eine andere Domäne auf demselben Server ist, sondern local.xmleine Änderung der Datenbankanmeldeinformationen erforderlich ist. Außerdem muss die Sicherungskopie nicht local.xmlso benannt werden backup-local.xml, dass sie vor Ihrer geänderten Datei geladen wird (Magento lädt alle .xmlDateien in app/etc)

Wenn dies eine direkte Kopie aller Dateien war und der Compiler aktiviert war, deaktivieren Sie ihn und löschen Sie seinen Codespeicher.

Fiasko-Labore
quelle
Laden Sie in Bezug auf die Datei local.xml eine Kopie auf Ihren Computer herunter, entfernen Sie sie vom Server und löschen Sie die Ordner in var / cache und var / session. Der Versuch, die Site zu laden, sollte einen Fehler ergeben. Nehmen Sie Änderungen an der Datei local.xml auf Ihrem Computer vor, laden Sie sie auf den Server hoch und löschen Sie die Cache- / Sitzungsordner erneut. Versuchen Sie, die Site mit Änderungen zu laden. Duplikate von local.xml (sogar umbenannt) können gefährlich sein.
Steven J
5

Ich hatte gerade dieses Problem, nachdem ich alles oben Aufgeführte und mehrere andere SO-Antworten ausprobiert hatte, stellte ich fest, dass die Tabelle core_config_data mehr als eine base_url-Definition enthält

wenn du läufst

select * from core_config_data where path like '%base_url%'

Sie sollten alle Definitionen sehen, deren Gültigkeitsbereich bei dieser Definition unterschiedlich war und die Standardeinstellung überschrieb, die ich bereits geändert hatte.

mrumair.com
quelle
1
Vielen Dank für die Veröffentlichung, hoffentlich hilft dies jemandem, der diese Frage sucht und findet. Ich möchte nur erwähnen, dass in meinem speziellen Fall nur 1 in der Datenbank vorhanden ist. Vielleicht hatte meine Installation, da es sich um einen einzelnen Bereich handelte, nur einen, was bedeutet, dass dies in meinem Fall nicht geholfen hat. Um ehrlich zu sein, kann ich mich nicht erinnern, wie ich meine repariert habe, die ich vor einiger Zeit hier veröffentlichen sollte! Wie auch immer, ich bin mir sicher, dass dies jemandem helfen wird und es ist etwas zu überprüfen, ob das Problem sicher
auftritt
Ich habe bald gesprochen, ich weiß, was die Lösung für meine war ... Es scheint, dass das DB-Ergebnis / die DB-Daten irgendwie auf unserem Server zwischengespeichert wurden. Nach ungefähr einem halben Tag, wenn der Schmerz aufgetreten ist, habe ich angenommen, dass alles funktioniert hat wie erwartet! Bis heute weiß ich nicht, warum oder was die DB veranlasst hat, den Wert zwischenzuspeichern. Wir hatten Varness auf dem ursprünglichen Server, aber der neue Server mit dem Problem hatte keinen Varness-Cache. Wer weiß, aber auf jeden Fall war es etwas auf unserem Server, der die Daten zwischenspeichert!
JasonDavis
2

Neben dem, was Sie bereits versucht haben, kann ich mir folgende mögliche Gründe vorstellen:

  • Der Konfigurationscache von Magento wird in einem anderen Backend gespeichert als Dateien in /var/cachebeispielsweise Memcache oder Redis. Überprüfen Sie die Datei app/etc/local.xmlund prüfen Sie, ob es einen Eintrag wie gibt

    <cache>
        <backend>memcached</backend>

    mit etwas anderem als fileszwischen den backendTags. Suchen Sie nach Informationen zum Bereinigen des Caches für Ihr spezifisches Backend. Wenn Sie das hervorragende n98-magerunBefehlszeilentool verwenden, geben Sie n98-magerun cache:flushIhr Magento-Stammverzeichnis ein. Sie können Magerun hier erhalten: https://github.com/netz98/n98-magerun

  • Das base_urlwird an einer anderen Stelle mit höherer Priorität als die Datenbank definiert. Dies kann eine app/etc/local.xmlbeliebige XML-Datei sein app/etc. Haben Sie in der Codebasis nach der alten Domain gesucht? Versuchen Sie es rgrep old-domain *im Magento-Stammverzeichnis.

Fabian Schmengler
quelle
Punkt zwei : Alles, was einen Konfigurationspfad in core_config_data verwendet, kann auch in jeder local.xml definiert werden. Dies ist eine gute Beobachtung, da ich gesehen habe, wie Leute versucht haben, Magento durch solche Aktionen zum Funktionieren zu bringen. Es wird ein oder zwei Jahre später vergessen.
Fiasco Labs
2

Ich hatte das gleiche Problem

Versuchen Sie, was ich getan habe

SCHRITT 1: Melden Sie sich bei SSH an und löschen Sie den Cache mit diesem Befehl:

rm -rf /var/tmp/magento/*

SCHRITT 2 - DATEIERLAUBNISSE ZURÜCKSETZEN

Um sicherzustellen, dass alle Javascript-Dateien, CSS und Bilder korrekt geladen werden, sollten Sie die Dateiberechtigungen auf die empfohlenen Einstellungen für Ihren neuen Server zurücksetzen.

Führen Sie die folgenden Befehle in Ihrem Magento-Stammverzeichnis aus (z. B. public_html):

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Dadurch werden die Berechtigungen für alle Dateien auf CHMOD 644 und CHMOD 755 für Verzeichnisse zurückgesetzt.

PS: Um den Magento Connect Manager verwenden zu können, müssen Sie möglicherweise die PEAR-Konfigurationseinstellungen zurücksetzen. Entfernen Sie dazu einfach die Datei downloader / pearlib / pear.ini , und es wird automatisch eine neue erstellt.

PS 2: Vergessen Sie nicht, die .htaccess-Datei zu überprüfen, wenn eine Umleitung zum alten Domainnamen erfolgt

Sagte Erraoudy
quelle
2

Kurz : Starten Sie Ihren Webserver neu.

Long: Ich habe base_urls geändert, aber es wurde immer noch auf die alte Site umgeleitet. Also habe ich var / cache gelöscht und es mit einem Browser im privaten Modus versucht -> leite immer noch zur alten Site weiter.

Die Lösung bestand darin, meinen Apache2-Server mit neu zu starten systemctl restart apache2

Schwarz
quelle
0

Ich hatte auch dieses Problem. Ich habe bereits alle Dateien in der gelöscht var/cache, var/sessionund das verändert die base_urlin der Tabelle core_config_dataauf die neue URL. Trotzdem wurde die Site auf die alte Site umgeleitet.

Ich hatte vergessen, die Datenbankdetails (Benutzername, Passwort und Datenbankname) config.xmlim Ordner zu bearbeiten app/etc/:

   <username><![CDATA[myusername]]></username>
   <password><![CDATA[mypassword]]></password>
   <dbname><![CDATA[mydbname]]></dbname>

Jetzt läuft meine Seite gut, nachdem ich sie bearbeitet habe config.xml.

Agus
quelle
0

Ich erinnere mich nicht, dass ich dies für frühere Versionen von Magento tun musste, aber seit der Implementierung von EE 1.14.3.3 muss ich URLs neu indizieren, um dieses Problem zu beheben.

TylersSN
quelle
0

Oh ja !

Für mich funktionierte schließlich:

php shell / indexer.php --reindexall via ssh.

Es scheint logischerweise, dass die URLs nach dem Kopieren der Dateien aus einer früheren Live-Installation immer noch auf den alten Speicher verweisen und daher neu indiziert werden müssen. Da in diesem Fall auch auf die Administrationsseite nicht zugegriffen werden kann, muss die Neuindizierung über ssh erfolgen

Hoffe, es funktioniert auch für andere!

Aps G.
quelle
Oder verwenden Sie magerun (./n98-magerun.phar index: reindex: all)
Schwarz
0

Wenn Sie Google Chrome verwenden, verwenden Sie einen anderen Browser (Firefox, Edge usw.), bevor Sie eine dieser anderen Methoden ausprobieren. Möglicherweise stellen Sie fest, dass die Adressen wie beabsichtigt funktionieren. Chrome scheint eine Art Caching durchzuführen. Ich habe mindestens eine Stunde meiner Zeit damit verschwendet, Konfigurationsdateien durchzugehen und Dinge zu testen.

Kevin Sadler
quelle