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

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?

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.

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.

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.

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

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

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.

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.

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!

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.

das funktioniert bei mir, ich denke muss bargeld abrechnen,

<?php 
require_once 'app/Mage.php';
$app = Mage::app();

echo "<pre-->";
if($app != null) {
        echo "The app was initialized.\n";
        $cache = $app->getCache();
        if($cache != null) {
                echo "The cache is not empty. Clean it.\n";
                $cache->clean();
        }
}
exit;
?>

http://www.w3bdeveloper.com/how-to/magento-redirects-to-old-url-after-moving-to-new-domain-solved/