Невозможно изменить базовый URL Magento, застрял в кеше

Question

Я только что установил действующий сайт в домен разработки. Я изменил поля web/unsecure/base_url и web/secure/base_url в core_config_data, но случайно ошибся в новом домене. Затем я загрузил сайт и заметил мою ошибку. С тех пор я исправил орфографию, но, похоже, кешировал не ту область. Я попытался повторно импортировать базу данных и изменить URL-адреса, я удалил все в каталоге кеша, но все же файлы js и css используют неправильный домен в каждой ссылке в административной части. И админ-сервер тоже указывает на неправильный домен.

Есть предложения? Это старая версия Magento 1.3.

Answer 1

Если у вас нет необходимых прав доступа к папкам var/, Magento может записать информацию о своем кэше в папку system /tmp.

Это может привести к ситуации, когда вы изменили базовые URL в базе данных Magento, очистили кеш (ручное удаление всех папок mage-?? в var/cache), (очистили кэш APC, если вы запускаете кэш кода операции), (вручную отключил компилятор (1.4.xx и более поздние версии)), и система по-прежнему ищет оригинальный сайт.

Большинство людей, владеющих собственным сервером, обнаруживают, что сайт волшебным образом начинает работать после исправления, очистки и сброса разрешений, а затем перезагрузки сервера. Перезагрузка сервера очищает /tmp файлов кэша Magento, и Magento наконец начинает искать свою собственную конфигурацию, чтобы найти, где он находится.

Снимки экрана в действии ...

Каталог Magento находится в /tmp ...

И кеш, живущий в этом каталоге. Запишите путь -> /tmp/magento/var/cache

Чтобы найти этот неуместный каталог кэша, если вы можете установить n98-magerun, используйте команду n98-magerun.phar sys:info, чтобы получить список основных сведений о системе с одним элементом Cache Directory location.

Answer 2

Когда вы перемещаете или изменяете установку Magento на новое доменное имя, вам необходимо убедиться в четырех вещах:

1) Заменить любой экземпляр старого домена в любых файлах на сервере. Это может быть сделано на некоторых (если не на всех) * nix следующим образом:

 find ./ -type f -exec sed -i ‘s/olddomain/newdomain/’ {} \;

2) Удалите файлы var / cache и var / session.

3) Обновите web / unsecure / base_url и web / secure / base_url в вашей базе данных. (И любой другой экземпляр вашего домена - обычно больше не будет)

4) Но в конечном итоге для папок требуются разрешения 775, а для файлов - не менее 664. Это можно сделать с помощью следующих команд * nix: (Примечание: папка var и sub могут нуждаться в более высоких разрешениях)

 find . -type d -exec chmod 775 {} ;
 find . -type f -exec chmod 664 {} ;

Небольшая история того, как я это узнал. Пришлось перенести сайт Magento с одного сервера на другой. Это должно было проверить, чтобы убедиться, что все прошло правильно. Потратив час на массовый импорт базы данных (~ 3 970 000 строк - самая большая база данных, которую я когда-либо видел для любой CMS, и я создал / изменил home-brew и другие распространенные CMS), я остался на www.domain.com, когда захотел developer.domain.com.

Answer 3

когда вы что-то меняете всегда rm -rf var/cache/* если вы меняете базовый URL, то также восстанавливайте все индексы

Answer 4

Это может привести к ситуации, когда вы изменили базовые URL-адреса в базе данных Magento, очистили кеш (ручное удаление всех папок mage-?? в var / cache), (очистили кеш APC, если вы запускаете кэш кода операции), (вручную отключил компилятор (1.4.xx и более поздние версии)), и система все еще ищет исходный сайт.%

Answer 5

Проверьте ваш config.xml - он, вероятно, имеет конфигурацию базы данных живого сайта.

Для Magento путь - /app/etc/config.xml, но я не уверен, что в вашей версии то же самое.