2012-05-31 6 views
0

У меня есть свежий magento 1.7, используя скопированный sql из магазина онлайн. Магазин использует Mag 1.4, поэтому идея состоит в том, чтобы обновить DB до 1.7. После связывания магазина 1.7 с БД на локальном хостинге это безошибочно, однако 127.0.0.1/shop перенаправляет в интернет-магазин.Mangento на localhost указывает на сайт

Изменение base_url не помогает.

БД все еще имеет ссылки на онлайн-сайт, но я не вижу никаких ссылок, которые могли бы изменить ситуацию.

Это, по-видимому, общая проблема с любыми решениями? http://www.magentocommerce.com/boards/viewthread/280257/#t387542 http://www.magentocommerce.com/boards/viewthread/224658/#t313216

ОБНОВЛЕНИЕ -

Вопрос в http://www.magentocommerce.com/boards/viewthread/280257/#t387542 был обновлен с исчерпывающий ответ по chiefair, как и один дал от Fiasco Labs ниже - если вы нуждаетесь в дополнительной информации

ответ

1

Изменил настройки базового URL-адреса в базе данных Magento, и он по-прежнему относится к старым базовым URL-адресам. Сначала вы начали Magento, прежде чем менять их, и он кэшировал старую конфигурацию, и теперь вы заблокированы на старом сайте.

Для Linux измените структуру var/directory на chmod -R 777. У вас нет разрешений на запись, и Magento установил кэш в/tmp, где ему нужно где-то писать файлы кеша. Он кэширует настройки конфигурации и не перечитывает их до тех пор, пока кеш находится в правильном расположении каталога. Если в var/cache есть подкаталоги, удалите их все. Возможно, вам придется искать охоту за/tmp/*/var/cache и удалять их.

Редактировать: То же самое касается Mac и Windows, если вы изменили базу данных и видите изменения, внесенные в phpMyAdmin, вы вручную очистили свои подкаталоги var/cache, если Apache перезапустили, а система все еще перенаправляя, вы на ранней стадии, имели неправильную конфигурацию, которая написала кэш Magento в другом месте. Вот почему он настойчив. Обычно перезагрузка компьютера очищает ее на компьютерах Mac и Linux, так как они выполняют домашнее хозяйство в своих временных папках при перезагрузке ОС.

Вот скриншоты системы /tmp Хранилище кэш-памяти Magento на сервере Linux с плохими правами доступа к файлам.

Обратите внимание на верхнюю адресную строку на обоих изображениях ...

Pay attention to the top address bar in the image...

А вот ваш скрытый тайник, который причиняет вам трудности.

And here's your hidden cache that's causing you difficulties.

+0

Делает смысл - спасибо. если im на localhost, что вы подразумеваете под chmod -R 777, я бы сделал это на ftp? – Jon

+0

Какая ОС работает на этом тестовом сервере? –

+0

apache XAMPP win 7 и т. Д. – Jon

1

Пожалуйста, попробуйте выполнить следующие действия:

  1. Очистить куки вашего браузера
  2. Заглянуть в БД в таблице core_config_data в строках web/unsecure/base_url и web/secure/base_url
  3. вручную очистить var/session и var/cache папки

Для полного учебника см here.

+0

, как я упомянул base_url не помогает. Я даже заменил все упоминания старого URL-адреса на всем сайте, и он не помог. Я использовал совершенно новый браузер, и он не помог. Я использовал свой собственный файл local.xml, и я сделал установку с помощью моей БД, но пусть маг создаст файл local.xml и, похоже, работает. Но не могу решить, в чем проблема: – Jon

+0

Вы можете видеть из сообщений magentocommerce, что они также изменили base_url и не повезло – Jon

+0

Ну, в этом случае есть много вещей, которые могут пойти не так. Вам нужно сделать это шаг за шагом и убедиться, что проблема не вызвана чем-то жестко закодированным в определенном файле, например htaccess. Сделайте grep для всех файлов. Вы используете плагин компиляции? Вы используете JS & CSS minification? Попытайтесь очистить кеш браузера, перезапустить его и удалить кеш пуповины каждый раз, когда вы выполняете один из этих тестов. –

0

Повторная установка с одного и того же БД, удаление приложения/etc/local.xml и указание новой установки на эту БД. Но я не могу понять, почему локальный файл отправлял сайт в другом месте. Может быть, в зашифрованном ключе?

+0

Он заставил перечитать настройки конфигурации в базе данных и кэшировать эти новые настройки, которые вы поместили в базу данных. Вам все равно необходимо проверить разрешения на var/и убедиться, что веб-сервер может писать им. Это может привести только к изменениям в/tmp, и у вас возникнут проблемы позже, пока разрешения не будут корректными. –

Смежные вопросы