Я обновляю magento с 1.4.0.1 до 1.7.0.2. Первоначально были некоторые ошибки; после их исправления теперь обновление выполняется в течение 5 часов и никогда не завершается. Ошибка не отображается. Любая идея, почему это происходит?
Недавно я обновил клиентов magento с V1.4 до V1.7.2.0, и я выполнил следующие шаги: – Ниже перечислены основные моменты обновления веб-сайта от Magento v1.4.0.0 до v1.7.2.0:
Собирайте резервную копию в реальном времени в формате zip, без следующих таблиц:
«Log_visitor_online»
Разархивируйте архивированную резервную копию в своей файловой системе в любой папке.
Запустите локальный WAMP / XAMPP и создайте тестовую базу данных «test_something» или любое другое имя, используя веб-приложение «phpMyAdmin».
Откройте окно командной строки и введите «mysql», чтобы запустить командную строку MySQL.
Импортируйте распакованную базу данных в тестовую базу данных, используя командную строку, чтобы она была намного быстрее без ошибок.
После успешного импорта запустите SQL, упомянутый в файле «DB Changes.txt», из phpMyAdmin.
Извлеките свежий Magento v1.7.2.0 в локальный WAMP / XAMPP и начните установку этого Magento, используя тестовую базу данных со старыми данными.
После успешной установки Magento экспортируйте и удалите новую обновленную базу данных в зашифрованном виде с помощью командной строки, чтобы она была намного быстрее без ошибок.
Извлеките свежий заархивированный Magento или загрузите свежий отпущенный Magento v1.7.2.0 в файловую систему live-сервера, не устанавливая ничего.
Загрузите эту ZIP-базу в файловую систему live-сервера, а затем откройте PuTTY для живого сервера.
Загрузите копию файла «Magento» локального WAMP / XAMPP «app / etc / local.xml», чтобы заменить файл «app / etc / local.xml» в реальном времени Magento. Не забудьте изменить все учетные данные БД этого файла в соответствии с новым живым сервером, прежде чем загружать его на живой сервер.
Помните, что не просматривайте Magento из веб-браузера для веб-сервера в реальном времени, пока не будет завершен этап №14.
Используя команды PuTTY, распакуйте базу данных zipped и импортируйте ее в новую базу данных веб-сайта.
После успешного импорта найдите таблицу базы данных «core_config_data» со значением столбца «путь» как «% base_url%». Замените все значения столбца «значение» полным URL-адресом живого сайта «http://www.livesite.com/» без упоминания «index.php».
Загрузите тему и связанные с ней файлы в файловую систему нового сервера.
Загрузите расширение / модуль, проверьте совместимость.
Обязательно настройте необходимые модули в Системной конфигурации с панели администратора.
DB Changes.txt выглядит следующим образом: – CREATE TABLE, если NOT EXISTS log_customer ( log_id int (10) unsigned NOT NULL AUTO_INCREMENT, visitor_id bigint (20) unsigned DEFAULT NULL, customer_id int (11) NOT NULL DEFAULT '0', login_at datetime NOT NULL DEFAULT '0000-00-00 00:00:00', logout_at datetime DEFAULT NULL, store_id smallint (5) unsigned NOT NULL, PRIMARY KEY ( log_id ), KEY IDX_VISITOR ( visitor_id )) ENGINE = InnoDB DEFAULT CHARSET = utf8 КОММЕНТАРИЙ = «Информация о журналах клиентов»;
–
log_quote CREATE TABLE, ЕСЛИ НЕ log_quote ( quote_id int (10) unsigned NOT NULL DEFAULT '0', visitor_id bigint (20) unsigned DEFAULT NULL, created_at datetime NOT NULL DEFAULT '0000-00-00 00:00:00', deleted_at datetime DEFAULT NULL, PRIMARY KEY ( quote_id )) ENGINE = InnoDB DEFAULT CHARSET = utf8 КОММЕНТАРИЙ = 'Данные журнала комментариев';
–
log_summary CREATE TABLE, если NOT EXISTS log_summary ( summary_id bigint (20) unsigned NOT NULL AUTO_INCREMENT, store_id smallint (5) unsigned NOT NULL, type_id smallint (5) unsigned DEFAULT NULL, visitor_count int (11) NOT NULL DEFAULT '0', customer_count int ( 11) NOT NULL DEFAULT '0', add_date datetime NOT NULL DEFAULT '0000-00-00 00:00:00', PRIMARY KEY ( summary_id )) ENGINE = InnoDB DEFAULT CHARSET = utf8 КОММЕНТАРИЙ = 'Сводная информация журнала;
–
log_url CREATE TABLE, ЕСЛИ НЕ log_url ( url_id bigint (20) unsigned NOT NULL DEFAULT '0', visitor_id bigint (20) unsigned DEFAULT NULL, visit_time datetime NOT NULL DEFAULT '0000-00-00 00:00:00', ПЕРВИЧНЫЙ КЛЮЧ ( url_id ), KEY IDX_VISITOR ( visitor_id )) ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT = 'История посещений URL';
–
log_url_info CREATE TABLE, если не EXISTS log_url_info ( url_id bigint (20) unsigned NOT NULL AUTO_INCREMENT, url varchar (255) NOT NULL DEFAULT '', referer varchar (255) DEFAULT NULL, PRIMARY KEY ( url_id )) ENGINE = InnoDB DEFAULT CHARSET = utf8 КОММЕНТАРИЙ = 'Информация о посещении url';
–
log_visitor CREATE TABLE, ЕСЛИ НЕ log_visitor ( visitor_id bigint (20) unsigned NOT NULL AUTO_INCREMENT, session_id char (64) NOT NULL DEFAULT '', first_visit_at datetime DEFAULT NULL, last_visit_at datetime NOT NULL DEFAULT '0000-00-00 00:00:00' , last_url_id bigint (20) unsigned NOT NULL DEFAULT '0', store_id smallint (5) unsigned NOT NULL, PRIMARY KEY ( visitor_id )) ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT = 'Журнал посетителей системы;
–
log_visitor_info CREATE TABLE, если не EXISTS log_visitor_info ( visitor_id bigint (20) unsigned NOT NULL DEFAULT '0', http_referer varchar (255) DEFAULT NULL, http_user_agent varchar (255) DEFAULT NULL, http_accept_charset varchar (255) DEFAULT NULL, http_accept_language varchar (255) DEFAULT NULL, server_addr bigint (20) DEFAULT NULL, remote_addr bigint (20) DEFAULT NULL, PRIMARY KEY ( visitor_id )) ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT = 'Дополнительная информация посетителя;
–
log_visitor_online CREATE TABLE, ЕСЛИ НЕ log_visitor_online ( visitor_id bigint (20) unsigned NOT NULL AUTO_INCREMENT, visitor_type char (1) NOT NULL, remote_addr bigint (20) NOT NULL, first_visit_at datetime DEFAULT NULL, last_visit_at datetime DEFAULT NULL, customer_id int (10) unsigned DEFAULT NULL, last_url varchar (255) DEFAULT NULL, PRIMARY KEY ( visitor_id ), KEY IDX_VISITOR_TYPE ( visitor_type ), KEY IDX_VISIT_TIME ( first_visit_at , last_visit_at ), KEY IDX_CUSTOMER ( customer_id )) ENGINE = InnoDB DEFAULT CHARSET = utf8;
TRUNCATE report_event ;
TRUNCATE report_viewed_product_index ;
TRUNCATE report_compared_product_index ;
TRUNCATE dataflow_batch_export ;
ALTER TABLE orders CHANGE url parent_id VARCHAR (255) CHARACTER SET latin1 COLLATE latin1_swedish_ci NULL DEFAULT NULL;
I В журнале запросов, изменив следующие строки в файле lib \ Varien \ Db \ Adapter \ Pdo \ Mysql.php
protected $_debug = true; protected $_logAllQueries = true; protected $_debugFile = 'var/debug/pdo_mysql.log';
Затем, проанализировав файл pdo_myql.log, я понял, что запрос выполняется с ошибкой, и поэтому установщик magento запускает его снова и снова.
Ошибка.
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ''11199-1' for key 'UNQ_INCREMENT_ID'
Поэтому я удалил запись в таблице базы данных, а в pdo_mysql.log теперь отображаются другие запросы и завершена градация.
Работая много дней на обновлении magento, я подытоживаю шаги для успешного обновления magento с 1.4.0.1 до 1.7.0.2. Эти ошибки будут отличаться для других проектов, потому что каждый проект имеет разные данные.
Создайте новую базу данных для новой версии. (Я использую SQLyog, потому что это хорошо для импорта и экспорта больших баз данных).
Извлечь и установить новую версию 1.7.0.1 в www или htdocs . Название моего проекта – magento171 .
Создайте новую базу данных, потому что нам понадобится новый db на этапе восстановления .
Импортируйте старые данные базы данных в новую базу данных .
Измените новое имя базы данных в etc / local.xml в новой установленной версии magento.
В etc / local.xml найдите и измените SET NAMES utf8 для SET NAMES utf8; SET FOREIGN_KEY_CHECKS = 0; SET UNIQUE_CHECKS = 0; ,
Скопируйте старый файл проекта в новую версию magento. У меня есть тема в пустой папке. Скопируйте по умолчанию, если у вас есть файлы шаблонов в папке по умолчанию.
• app \ design \ frontend \ default \ blank
• app \ code \ local
• skin \ frontend \ default / blank
• app \ etc \ modules (скопируйте файлы, которые не находятся в новой версии).
В журнале запросов MySql, изменив следующие строки в lib \ Varien \ Db \ Adapter \ Pdo \ Mysql.php
protected $_debug = true; protected $_logAllQueries = true; protected $_debugFile = 'var/debug/pdo_mysql.log';
Поиск и изменение CREATE TABLE для СОЗДАНИЯ ТАБЛИЦЫ, ЕСЛИ НЕ СУЩЕСТВУЕТСЯ В коде / ядре / маге /.
Измените следующие записи в таблице core_config_data (используйте имя папки проекта).
• web/unsecure/base_url | http://localhost/magento171/ • web/secure/base_url | http://localhost/magento171/
Переименуйте /errors/local.xml.sample в /errors/local.xml, чтобы включить error_reporting.
Очистите кэш magento, удалив все данные в var \ cache .
Перейдите в браузер и введите путь к проекту. http: // localhost / magento171 / и следить за браузером и в файле var / debug / pdo_mysql.log .
Первая ошибка возникла у меня: Ошибка в файле: «D: \ xampp \ htdocs \ magento171 \ app \ code \ core \ Mage \ Sales \ sql \ sales_setup \ mysql4-upgrade-1.3.99-1.4.0.0.php"
Исправлено: в файле pdo_mysql.log я обнаружил, что проблема находится в таблице sales_flat_order , что означает, что у вас есть много повторяющихся записей для первичного ключа, поэтому я усекаю все таблицы продаж. На самом деле это ошибка в моей старой БД. В новой версии increment_id UNIQUE. Мы не можем пропустить проверки первичного ключа, поэтому я усекал все таблицы, связанные с продажами. Если у вас есть такая же проблема, то обрезайте все таблицы, связанные с этой функцией, например, если дублировать в клиенте, затем обрезайте всю таблицу клиентов или, если в каталоге, обрезайте таблицы каталога. Но помните, что усечение должно выполняться в момент возникновения ошибки, потому что если усекается до начала установки, установщик не будет считывать существующие данные и, наконец, вы пропустите некоторые записи, например, некоторые заказы или счета-фактуры.
SET FOREIGN_KEY_CHECKS = 0; TRUNCATE `sales_flat_creditmemo`; TRUNCATE `sales_flat_creditmemo_comment`; TRUNCATE `sales_flat_creditmemo_grid`; TRUNCATE `sales_flat_creditmemo_item`; TRUNCATE `sales_flat_invoice`; TRUNCATE `sales_flat_invoice_comment`; TRUNCATE `sales_flat_invoice_grid`; TRUNCATE `sales_flat_invoice_item`; TRUNCATE `sales_flat_order`; TRUNCATE `sales_flat_order_address`; TRUNCATE `sales_flat_order_grid`; TRUNCATE `sales_flat_order_item`; TRUNCATE `sales_flat_order_payment`; TRUNCATE `sales_flat_order_status_history`; TRUNCATE `sales_flat_quote`; TRUNCATE `sales_flat_quote_address`; TRUNCATE `sales_flat_quote_address_item`; TRUNCATE `sales_flat_quote_item`; TRUNCATE `sales_flat_quote_item_option`; TRUNCATE `sales_flat_quote_payment`; TRUNCATE `sales_flat_quote_shipping_rate`; TRUNCATE `sales_flat_shipment`; TRUNCATE `sales_flat_shipment_comment`; TRUNCATE `sales_flat_shipment_grid`; TRUNCATE `sales_flat_shipment_item`; TRUNCATE `sales_flat_shipment_track`; SET FOREIGN_KEY_CHECKS = 1;
Установка занимает слишком много времени, поэтому я проверяю файл pdo_mysql.log, и следующая ошибка отображается снова и снова. Отображается ошибка: SQLSTATE [23000]: Нарушение ограничения целостности: 1062 Дублирующая запись '' 11199-1 'для ключа' UNQ_INCREMENT_ID '' Fix: Таким образом, я удаляю первую запись в таблице.
База данных Rapair Шаг. Необходимо восстановить новую базу данных с помощью новой базы данных с помощью magento-db-repair-tool-1.1 (http://www.magentocommerce.com/wiki/1_-_installation_and_configuration/db-repair-tool). В конце отчета будут показаны все исправления.
Теперь вы можете просто перенести веб-сайт на живой сервер.
Я думаю, что наиболее полное описание модернизации Magento 1.4 до 1.7.x – это путь, предлагаемый сайтом «под ключ»:
Прежде чем приступить к этой части обновления Magento, важно посмотреть, в какой версии сценарии обновления Magento будут обновлять ваш магазин. Введите эту команду, чтобы проверить это:
1 ./mage list-upgrades
Если вы увидите этот результат:
Updates for community: Mage_All_Latest: 1.4.2.1 => 1.7.0.2 Lib_Js_Mage: 1.4.2.0 => 1.7.0.2 Lib_Varien: 1.4.2.0 => 1.7.0.2
Это означает, что ваш Magento будет обновлен до версии 1.7.0.2. Если это не то, что вам нужно, вы можете изменить канал обновления на «бета» и обновить версию Magento до RC (бета).
1 – Введите эту команду, чтобы изменить канал обновления на стабильный (помните, «стабильный» канал обновит ваш Magento до последней версии версии 1.7.x):
1 ./mage config-set preferred_state stable
После этого команда «./mage list-updates» покажет вам этот результат:
Обновления для сообщества:
Mage_All_Latest: 1.4.2.1 => 1.7.0.2. Lib_Js_Mage: 1.4.2.0 => 1.7.0.2. Lib_Varien: 1.4.2.0 => 1.7.0.2. Lib_Phpseclib: 1.4.2.0 => 1.7.0.2. Mage_Core_Adminhtml: 1.4.2.0 => 1.7.0.2. Mage_Core_Modules: 1.4.2.0 => 1.7.0.2.
2 – После выбора канала вы можете обновить Magento до Magento 1.7.0.2), используя следующую команду:
1 ./mage upgrade-all --force
Если «./mage upgrade-all -force» не будет работать, вы можете попробовать выполнить эту команду:
1 ./mage install connect20.magentocommerce.com/community Mage_All_Latest --force
На экране вы увидите обновленные пакеты:
… Package upgraded: community/Mage_Locale_en_US 1.7.0.2 Package upgraded: community/Lib_Mage 1.7.0.2 Package upgraded: community/Lib_ZF 1.11.1.0 Package upgraded: community/Lib_Js_Prototype 1.7.0.2. Package upgraded: community/Lib_ZF_Locale 1.11.1.0
Теперь обновление завершено, и вы можете выполнить обновление базы данных, посещая магазин Magento в своем браузере, этот процесс займет несколько минут, поэтому будьте терпеливы. Если все будет обновлено правильно, вы увидите обновленный магазин в своем браузере. Перед обновлением базы данных рекомендуется увеличить время и пределы памяти вашего механизма PHP.
Если это невозможно увеличить, вы можете попробовать выполнить обновление базы данных через SSH, например:
1 php -f ./index.php
Когда обновление базы данных будет завершено, вы можете проверить версию своего магазина в нижнем колонтитуле панели администрирования Magento.
Проверьте свои журналы apache. Однако, похоже, что он попадает в процесс обновления. Убедитесь, что все ваши файлы являются новой версией, создайте резервную копию своей базы данных и убедитесь, что информация о подключении к базе данных верна.
Вы также можете дважды проверить размер своей базы данных. Если ваша база данных огромна, magento может быть отключен.
Насколько велика текущая (1.4.0.1) база данных? Недавно, когда мне пришлось обновить базу данных 7 ГБ, на локальном сервере потребовались целые выходные – причина такого длительного процесса в том, что в версии 1.6 появились новые индексы и была восстановлена структура базы данных – сценарии установки, которые предназначены для запуска первой загрузки обновленного кода вызывают много внешних ключей и создают новые с большим количеством ограничений.