Новое исправление безопасности для Magento 1 устраняет 16 проблем APPSEC: https://magento.com/security/patches/supee-9767

Семь уязвимостей имеют оценку 8,0 или выше для CVSSv3 Severity , и они эксплуатируются в дикой природе, так что это критический патч. Сайты могут применять SUPEE-9767 или обновлять до новой версии CE 1.9.3.3 / EE 1.14.3.3.

На какие общие проблемы или подводные камни стоит обратить внимание при применении SUPEE-9767?

ОБНОВЛЕНИЕ 2017-07-12:

Magento выпустила SUPEE-9767 V2 и CE 1.9.3.4 для решения многих проблем из первоначального патча. Если вы применили V1, вы должны вернуться, а затем применить V2. Если вы еще не установили исправления, просто примените V2, и большинство вопросов, поднятых здесь, не будут актуальны.

Вот мой обзор патча после копания в нем

ЭКОНОМИЯ ВРЕМЕНИ : Experius предоставляет помощник по исправлению, который поможет вам найти файлы в пользовательских темах, пользовательских модулях или локальных перезаписях, которые также могут потребоваться исправлять вручную , вы можете найти его здесь: https://github.com/experius/Magento- 1-Experius-Patch-Helper # Magento

Оформить заказ ключами

Как сказано в другом посте, этот патч добавляет ключи форм к следующим формам:

Форма доставки:

app/design/frontend/<package>/<theme>/template/checkout/cart/shipping.phtml

Форма оформления платежа с несколькими отправлениями:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/billing.phtml

Форма оформления заказа на доставку:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/shipping.phtml

Форма оформления заказа по нескольким адресам:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/addresses.phtml

Форма оплаты счетов:

app/design/frontend/<package>/<theme>/template/checkout/onepage/billing.phtml

Форма оформления заказа на доставку:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping.phtml

Форма оплаты заказа:

app/design/frontend/<package>/<theme>/template/checkout/onepage/payment.phtml

Форма оформления заказа:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping_method.phtml

Форма оформления постоянного платежа:

app/design/frontend/<package>/<theme>/template/persistent/checkout/onepage/billing.phtml

Кроме того, следующие файлы JS были обновлены для совместимости с этим изменением:

• js/varien/payment.js
• skin/frontend/base/default/js/opcheckout.js

Что делать:

Если вы используете пользовательские версии этих шаблонов, вам придется обновить их, добавив в них следующий код:

<?php echo $this->getBlockHtml('formkey') ?>

Если вы используете сторонний модуль проверки, вам необходимо связаться с ним, чтобы они могли предоставить обновленную версию своего модуля.

Кроме того, если у вас есть пользовательские версии ранее перечисленных файлов JS, вам также придется их обновить.

СОХРАНИТЕ ВРЕМЯ :

Фабиан Шменглер написал хороший маленький сценарий, чтобы обновить все эти вещи для вас, вы можете найти его здесь:

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

ВАЖНОЕ ПРИМЕЧАНИЕ : проверка ключа формы проверки может быть изменена в бэкэнде через новое поле конфигурации в Системе> Конфигурация> Администратор> Безопасность> Включить проверку ключа формы при оформлении заказа . ЭТО НЕ ВКЛЮЧЕНО ПО УМОЛЧАНИЮ, поэтому вам нужно включить его, чтобы воспользоваться этой функцией безопасности !!! Обратите внимание, что вы получите уведомление в бэкэнде, если он не включен.

Обратный звонок при загрузке изображения

Контроллер галереи изображений был обновлен для добавления обратного вызова проверки.

Что делать

Если вы используете пользовательский модуль, который выполняет загрузку изображений с кодом, который выглядит следующим образом:

        $uploader = new Mage_Core_Model_File_Uploader('image');
        $uploader->setAllowedExtensions(array('jpg','jpeg','gif','png'));
        $uploader->addValidateCallback('catalog_product_image',
            Mage::helper('catalog/image'), 'validateUploadFile');
        $uploader->setAllowRenameFiles(true);
        $uploader->setFilesDispersion(true);

Я настоятельно рекомендую вам обновить этот код, добавив после него следующий фрагмент:

        $uploader->addValidateCallback(
            Mage_Core_Model_File_Validator_Image::NAME,
            Mage::getModel('core/file_validator_image'),
            'validate'
        );

Symlinks

Этот патч удаляет поле конфигурации системы, которое позволяет вам разрешить использование символьных ссылок в бэкэнде. Раньше это было в Системе> Конфигурация> Разработчик> Шаблон> Разрешить символические ссылки . Теперь весь раздел Шаблонов пропал.

Кроме того, это поле теперь отключено по умолчанию через app/etc/config.xml

Самое смешное в том, что вы получите уведомление в бэкэнде, если у вас было включено это поле конфигурации до патча, но вы не сможете его отключить, так как поле пропало.

Единственный способ сделать это - выполнить следующий запрос SQL

UPDATE core_config_data SET value = 0 WHERE path = "dev/template/allow_symlink";

осветление

Сначала я настоятельно рекомендую вам проверить эти два сообщения, которые помогут вам понять цель этой модификации Symlink:

• От Питера О'Коллагана: https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/
• От Макса Чедвика: https://maxchadwick.xyz/blog/what-allow-symlinks-actually-does

Эта модификация на самом деле предназначена для вызова загружаемого контента (например, изображений) с помощью шаблонных директив.

Проблема, связанная с символическими ссылками, может быть использована только с правами администратора, и Magento также добавил дополнительную защиту для загрузки изображений.

Обратите внимание, что они являются некоторыми средствами защиты от известного способа его использования в дополнение к самой настройке.

Что делать : если вы, как и я, используете modman или composer с шаблонными символическими ссылками, вы столкнетесь с некоторыми проблемами. Я все еще пытаюсь выяснить, что лучше делать здесь, кроме работы с SQL-запросами.

Основной пост по этому вопросу: SUPEE-9767, modman и символические ссылки

Список возможных проблем

V2 был выпущен с того самого поста. Не забудьте обновить

ошибки

Слово «подтверждено» используется для подтвержденных ошибок. Если его там нет, значит, это может быть ошибка, но она еще не подтверждена.

• Сбой регистрации клиента при оформлении заказа ПОДТВЕРЖДЕНО И ИСПРАВЛЕНО В V2
• Ошибка PHP7 и EE ПОДТВЕРЖДЕНА
• Ошибка с EE, FPC и исключениями дизайна ПОДТВЕРЖДЕНА
• Добавить в корзину и ошибка cookie в EE ПОДТВЕРЖДЕНО
• Многократный перерыв после патча ПОДТВЕРЖДЕН
• Отсутствует исправление ошибки вhead-simple.phtml ПОДТВЕРЖДЕНО И ИСПРАВЛЕНО В V2
• Предупреждение Admin Symlink не отображается в 1.9.2 ПОДТВЕРЖДЕНО И ИСПРАВЛЕНО В V2
• Водяной знак становится черным, когда прозрачный ПОДТВЕРЖДЕНО И ИСПРАВЛЕНО В V2
• Невозможно обновить через Magento Connect
• Бесконечный цикл перенаправления на 1.6.0.0

Hunk Failed Issues

Обратите внимание, что все эти проблемы могут быть вызваны тем, что вы изменили исходный файл, чтобы дважды убедиться, что это не так:

• Сделайте резервную копию файла, в котором вы получили ошибку Hunk Failed
• Загрузите оригинальный файл из вашей версии Magento
• Сравните оба файла

Если файлы различаются, вам придется применить исправление к исходному файлу, а затем повторно применить пользовательские изменения чистым способом, например:

• пользовательский шаблон в папке пользовательских тем
• local.xml
• приложение / код / ​​локальный файл

Если файлы не отличаются, то это либо проблема с правами доступа, либо «ошибка» в патче.

• исправление файла app / design / frontend / rwd / default / layout / page.xml Hunk # 1 FAILED в 36.
• патч файла приложения / дизайн / внешний интерфейс / предприятие / по умолчанию / шаблон / постоянный / оформить заказ / onepage / billing.phtml Hunk # 1 FAILED на 225.
• патч файла приложения / код / ​​ядро ​​/ Enterprise / PageCache / Model / Observer.php Блок № 6 не удалось в 1093.
• исправление файла app / code / core / Mage / Core / etc / system.xml Hunk # 3 FAILED на 1355.
• исправление файла приложения / кода / ядра / Mage / Sales / Model / Quote / Item.php Hunk # 1 FAILED на 500.
• Hunk не удалось на 1.8.0.0

Issue1: form_key недействителен на одной странице оформления заказа

Magento добавить form_keyв большинстве форм.

если у вас есть using default onepage and using custom theme, то вы начнете получать ** form_keyвопрос на кассе каждый шаг **;

Вы должны добавить ключ формы в <?php echo $this->getBlockHtml('formkey') ?>

формировать файлы каждого шага оформления заказа, если файлы ниже,

• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/billing.phtml
• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/payment.phtml

• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping.phtml

• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping_method.phtml

если файлы шаблона вызываются из базовой темы, это не создает проблем. Потому что патч автоматически обновит эти файлы.

Также обратите внимание: <?php echo $this->getBlockHtml('formkey') ?>всегда должен быть внутри тега формы

 <form action="" .....>
     <fieldset>
      .......
       <?php echo $this->getBlockHtml('formkey') ?>
     </fieldset>
 </form>

** Если вы используете многоразовую доставку Magento, необходимо сделать это на

ниже файлы:

Issue2: form_key выдает форму оценки доставки на странице корзины:

Добавить form_key в оценочную форму доставки на странице корзины

Затем необходимо добавить ключ формы <?php echo $this->getBlockHtml('formkey') ?>

в app/design/frontend/{Your_Package}/{YOUR_THEME]/template/checkout/cart/shipping.phtml

Проблема 3: Ошибка Magento Onepage Checkout opcheckout.js

Если вы используете одностраничный заказ по умолчанию и opcheckout.js затем должны проверить

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {доступно на opcheckout.js

Если не выходить то заменить

if (elements [i] .name == 'payment [method]') {

с участием

if (elements [i] .name == 'payment [method]' || elements [i] .name == 'form_key') {

Для случая проблема 1, проблема 2, проблема 3 проблема может быть легко решена с помощью скрипта @FabianSchmengler add-checkout-form-key.sh . Это исправит проблему с вашими восприимчивыми файлами темы.

Проблема 4: неверный ключ формы после входа в систему клиента при перезаписи Mage_Customer_Model_Session

Если Mage_Customer_Model_Sessionкласс переписать или позвонили из

app/code/local/Mage/Customer/Model/Session.phpтогда у вас может возникнуть проблема с form_key, когда мы назначаем клиента для сеанса, используя setCustomerAsLoggedIn()/ или после того, как клиент установил сеанс.

В этом случае вы должны добавить

Mage :: getSingleton ( 'ядро / сессия') -> renewFormKey ();

в setCustomerAsLoggedIn () перед вызовом

Mage::dispatchEvent('customer_login', array('customer'=>$customer));

  public function setCustomerAsLoggedIn($customer)
    {
        $this->setCustomer($customer);
        $this->renewSession();
        // add this  for patch -9767
        Mage::getSingleton('core/session')->renewFormKey();
       // end this for patch 9767
        Mage::dispatchEvent('customer_login', array('customer'=>$customer));
        return $this;
    }

Проблема 5: проблема с ключом формы после выхода из системы

После выхода клиента из сеанса вы можете начать выпуск сеанса, если Mage_Customer_Model_Sessionкласс переписан или вызван из

app/code/local/Mage/Customer/Model/Session.php

В тех же нуждах для этого случая:

   protected function _logout()
    {
        $this->setId(null);
        $this->setCustomerGroupId(Mage_Customer_Model_Group::NOT_LOGGED_IN_ID);
        $this->getCookie()->delete($this->getSessionName());
// add this  for patch -9767
Mage::getSingleton('core/session')->renewFormKey();
        return $this;
    }

Рекомендация:

Рекомендация 1: для исправления проблемы с supee-9767 вы можете использовать патч https://github.com/experius/Magento-1-Experius-Patch-Helper

Это одно из лучших решений на данный момент.

Обратите внимание , перед тем, как сделать это, настоятельно рекомендуется сделать резервную копию файлов и базы данных или полную резервную копию системы.

Рекомендация 2: Используйте функцию исправления на вашем ONESTEP CHECKOUT

Мы знаем, что патч supee-9767 выпущен в целях безопасности, если вы используете ONESTEP CHECKOUT, вам нужно добавить валидацию form_key в SAVE-действие вашего одноступенчатого контроллера извлечения .

Предположим, что для сохранения информации о способе доставки, в вашем шаге вы должны использовать saveShippingmethod (). Затем к этому вы должны добавить

if ($this->isFormkeyValidationOnCheckoutEnabled() && !$this->_validateFormKey()) {
           return;
      }

Кроме того, вы должны добавить ключ формы <?php echo $this->getBlockHtml('formkey') ?> на вашем шаге оформить заказ phtml файлов соответствующего раздела

Некоторая связанная ссылка

https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/

Основываясь на моем первом проходе при просмотре файла патча ...

• Новый параметр admin/security/validate_formkey_checkoutбыл добавлен. При включении формы проверки проверяются на наличие ключа формы. Если файлы шаблонов переопределены в теме, их нужно будет обновить там. Эта настройка по умолчанию отключена
• Симлинки, по-видимому, запрещены по умолчанию (в app/etc/config.xml). Кроме того, возможность разрешить их, похоже, была удалена из конфигурации администратора. Однако, если на вашем сайте ранее были явно включены символические ссылки, настройка будет сохранена в базе данных, отменяя это изменение.
• При применении этого патча вам необходимо очистить как кеш, так и кеш полной страницы. Исключения дизайна сохраняются в формате, несовместимом с декодированием. Вы увидите ошибку типа «Ошибка декодирования: синтаксическая ошибка», если вы не очистите кэш страницы.

Ниже base/defaultфайл, затронутый этим патчем, если эти файлы были в вашей теме, пожалуйста, внесите соответствующие изменения

app/design/frontend/base/default/template/checkout/cart/shipping.phtml

app/design/frontend/base/default/template/checkout/multishipping/billing.phtml

app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/billing.phtml

app/design/frontend/base/default/template/checkout/onepage/payment.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml

app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml

во всех приведенных phtmlниже файлах формы добавлена ​​ключевая строка, поэтому, пожалуйста, добавьте эту строку в ваш соответствующий файл phtml.

 <?php echo $this->getBlockHtml('formkey') ?>

Для вышеупомянутой проблемы @fabian создал скрипт, который добавит ключ формы даже в ваш файл темы.

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

после применения исправления безопасности, если вы получили ошибку для ключа формы, вы можете применить это исправление, поскольку применение этого исправления аналогично исправлению безопасности

  sh filename.sh

и одно base/defaultизменение в Jsфайле

  skin/frontend/base/default/js/opcheckout.js

так что, если этот jsфайл загружается из вашей темы, выполните следующие действия

удалить линию удара

 if (elements[i].name=='payment[method]') {

и добавьте ниже строки вместо выше

 if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {

РЕДАКТИРОВАТЬ

И если вы используете какое-либо расширение checkout, которое переопределяет указанные ниже файлы, добавьте строку ключа формы в phtml-файл расширения checkout.

EDIT2 - Проблемы

1) Ошибка при saveBillingAction () или получении нулевого ключа формы или проблеме с ключом формы: исправление 9767 получает недопустимый ключ формы

2) Hunk # 1 FAILED на 225. 1 из 1 Hunk FAILED - сохранение отклоняет в файл app / design / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtml: SUPEE-9767 - Hunk # 1 Сбой в 225. 1 из 1 ломтик не удалось

3) сохранение отклоняет в файл app / code / core / Enterprise / PageCache / Model / Observer.php.rej: ОШИБКА SUPEE-9767: исправление не может быть успешно применено / отменено

4) SUPEE-9767, модман и символические ссылки : SUPEE-9767, модман и символические ссылки

5) app / design / frontend / rwd / default / layout / page.xml Hunk # 1 FAILED на 36. Hunk # 2 FAILED на 54. 2 из 2 блоков СБОЙ : ошибка SUPEE-9767

6) 1 из 1 блока терпит неудачу - сохранение отклоняет в файл app / code / core / Mage / Sales / Model / Quote / Item.php: Magento 1.9.2.2 ОШИБКА исправления SUPEE-9767

7) ошибка проверки одного шага (опять же, это проблема с ключом формы): SUPEE-9767 Magento CE 1.9.3.3 Проверка на одном шаге не работает с включенной проверкой ключа формы при проверке

8) проблема регистрации клиента в один шаг: SUPEE-9767 Patch / CE 1.9.3.3 - оформление заказа на одной странице - проблема регистрации клиента

9) приложение / код / ​​ядро ​​/ маг / ядро ​​/ модель / файл / валидатор / Image.php: Magento SUPEE 9697 1.9.2.2 не работает в Image.php

Обратите внимание, что символические ссылки всегда были отключены по умолчанию в новых установках Magento. Администратор ДА / НЕТ значения конфигурации по умолчанию «НЕТ». Обновление теперь явно отключает символические ссылки в config.xml и в качестве дополнительной меры предосторожности также удаляет раздел шаблона из раздела admin-> developer, в котором содержится параметр конфигурации.

Это не повлияет на ваши текущие настройки символических ссылок, если вы вручную включили символические ссылки до 1.9.3.2, они останутся включенными, хотя вы больше не сможете видеть настройки в admin.

Пользователи, использующие modman для управления модулями Magento 1.x, должны убедиться, что они не отключают символические ссылки, так как это отключит модули modman.

Ответственные администраторы могут снова включить раздел администрирования символической ссылки, выполнив поиск изменений в разделе шаблона в app / code / core / Mage / Core / etc / system.xml и добавив этот раздел в ваш system.xml примерно на строке 600. Или двойная проверка символьных ссылок все еще включена с

Конфигурация n98-magerun.phar: дамп | grep symlink

Вот файл diff для magento1933 и magento1932, чтобы помочь идентифицировать изменения в теме по умолчанию, которые могут повлиять на ваши пользовательские / расширенные темы.

diff -r magento1933 magento1932> https://pastebin.com/ADzMBLhr

Проблема: использование php7 иногда приводит к следующей ошибке:

Decoding failed: Syntax error

#0 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(179): Zend_Json::decode('')
#1 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(215): Enterprise_PageCache_Model_Observer->_loadDesignExceptions()
#2 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(125): Enterprise_PageCache_Model_Observer->_saveDesignException()
#3 /______/app/code/core/Mage/Core/Model/App.php(1358): Enterprise_PageCache_Model_Observer->cacheResponse(Object(Varien_Event_Observer))
#4 /______/app/code/core/Mage/Core/Model/App.php(1337): Mage_Core_Model_App->_callObserverMethod(Object({custom extensio}_Model_Rewrite_PageCache_Observer), 'cacheResponse', Object(Varien_Event_Observer))
#5 /______/app/Mage.php(456): Mage_Core_Model_App->dispatchEvent('controller_fron...', Array)
#6 /______/app/code/core/Mage/Core/Controller/Varien/Front.php(182): Mage::dispatchEvent('controller_fron...', Array)
#7 /______/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#8 /______/app/Mage.php(691): Mage_Core_Model_App->run(Array)
#9 /______/index.php(105): Mage::run('brandfield_nl', 'store')
#10 {main}

Совершенно очевидно, что версия Zend должна что-то с этим делать. Это быстрое решение, но оно точно не правильно:

-> app / code / core / Enterprise / PageCache / Model / Observer.php: 244 замените его следующим:

    if ($cachedSslOffloaderHeader !== false) {
        $cachedSslOffloaderHeader = trim(@Zend_Json::decode($cachedSslOffloaderHeader));
    }

-> и app / code / core / Enterprise / PageCache / Model / Observer.php: 177 с:

    if ($exceptions !== false) {
        $exceptions = Zend_Json::decode($exceptions);
    }

Конечно, создайте аддон, чтобы переписать это. Но я уверен, что здесь есть что-то лучше.

ОБНОВЛЕНИЕ (Лучшее решение)

-> Перейти к: lib / Zend / Json.php и после строки 76 добавить это:

    if ((float)phpversion() >= 7.0
        && empty($encodedValue)
    ) {
        return null;
    }

Создайте свое расширение, чтобы переопределить его и не редактируйте основной файл.

Проблема: динамический код или css отключает элемент ввода ключа формы при оформлении заказа

Проблема, с которой я столкнулся, заключается в том, что динамический код (paypal plus) в процессе оформления одной страницы перезаписывает элемент fieldset в форме одностадийного способа оплаты html - удаление или отключение (с помощью css) скрытого элемента form_key.

Исправление состоит в том, чтобы гарантировать, что элемент formkey не отключен никаким динамическим кодом или CSS. Перемещение кода formkey за пределы элемента fieldset также может помочь

<form>
    <?php echo $this->getBlockHtml('formkey') ?>
    <fieldset>
        <?php echo $this->getChildHtml('methods') ?>
    </fieldset>
</form>

Вы можете легко проверить, обнаружен ли form_key и отправлен ли он на одностраничный контроллер, проверяя сетевые запросы ajax в вашем браузере, когда вы переходите через методы извлечения, каждый метод должен включать ключ формы в данные формы ajax, если форма Ключ не существует, но в исходном коде Magento была исправлена ​​проверка на наличие внешнего кода, влияющего на элемент ключа формы, то есть на css или динамические изменения на стороне клиента.

Проблема: отсутствуют исправления в head-simple.phtml

app/design/adminhtml/default/default/template/oauth/authorize/head-simple.phtml

нужны те же исправления, что и

app/design/adminhtml/default/default/template/page/head.phtml

ПРОБЛЕМА: Сбой регистрации клиента при использовании универсальной 5-ступенчатой ​​проверки Magento.

Эта проблема возникает только тогда, когда мы включаем аутентификацию с помощью ключа формы. Используемая версия: 1.7.0.2, но похоже, что кто-то опубликовал эту же проблему и в версии 1.9.3. Патч SUPEE-9767 / CE 1.9.3.3 - оформление заказа на одной странице - проблема с регистрацией клиента

При переходе к оформлению заказа у нас есть 2 варианта: ВЫБЕРИТЕ В КАЧЕСТВЕ ГОСТЯ ИЛИ РЕГИСТРАЦИИ После того, как вы нажмете «Зарегистрироваться» и заполните форму вместе с паролем, вы пройдете все этапы и выполните заказ. Заказ размещается, НО клиент никогда не регистрируется в magento. Похоже, Гость разместил заказ.

Когда я вернулся и отключил проверку подлинности с помощью ключа формы и попытался разместить заказ при регистрации в качестве клиента, он был размещен без каких-либо проблем, и клиент был зарегистрирован в бэкэнде.

ОБНОВЛЕНИЕ 13/07/2017 [ПРОБЛЕМА ИСПРАВЛЕНА]

Команда Magento выпустила SUPEE-9767 V2 в этой версии патча, проблема с прозрачными GIF и PNG исправлена.

Вы должны отменить все изменения в файле, который обсуждался в этой теме. Затем отмените примененный патч V1 и, наконец, примените новую версию V2.

PRE - SUPEE-9767 V2

Пожалуйста, не используйте код, описанный ниже, вместо этого примените V2 патча, проблема, обсуждаемая ниже, уже исправлена ​​в этой версии

Если у кого-то возникают проблемы с прозрачными png-файлами, то при загрузке с панели администратора фон становится черным. (На продуктах) относится к обратному вызову загрузки изображений, представленному в:

app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php

В настоящий момент я не уверен, что именно вызывает это поведение, но я пытаюсь выяснить это, я могу подтвердить, что, когда обратный вызов удален, странное поведение исчезает.

ОБНОВИТЬ

Хорошо, я нашел функцию, которая также обновлена ​​с SUPEE-9767, это фактически нарушает прозрачность в png, копия оригинального изображения создается без прозрачности.

+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
@@ -87,10 +87,33 @@ public function setAllowedImageTypes(array $imageFileExtensions = array())
      */
     public function validate($filePath)
     {
-        $fileInfo = getimagesize($filePath);
-        if (is_array($fileInfo) and isset($fileInfo[2])) {
-            if ($this->isImageType($fileInfo[2])) {
-                return null;
+        list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
+        if ($fileType) {
+            if ($this->isImageType($fileType)) {
+                //replace tmp image with re-sampled copy to exclude images with malicious data
+                $image = imagecreatefromstring(file_get_contents($filePath));
+                if ($image !== false) {
+                    $img = imagecreatetruecolor($imageWidth, $imageHeight);
+                    imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
+                    switch ($fileType) {
+                        case IMAGETYPE_GIF:
+                            imagegif($img, $filePath);
+                            break;
+                        case IMAGETYPE_JPEG:
+                            imagejpeg($img, $filePath, 100);
+                            break;
+                        case IMAGETYPE_PNG:
+                            imagepng($img, $filePath);
+                            break;
+                        default:
+                            return;
+                    }
+                    imagedestroy($img);
+                    imagedestroy($image);
+                    return null;
+                } else {
+                    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
+                }
             }
         }
         throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));

ОБНОВИТЬ

Вот обновленная версия функции для сохранения прозрачности PNG

  imagealphablending($img, false);
  imagesavealpha($img, true);

эти две строки должны быть добавлены к патчу. Обновите функцию вapp/code/core/Mage/Core/Model/File/Validator/Image.php

/**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                imagealphablending($img, false);
                imagesavealpha($img, true);  
                imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

ОБНОВЛЕНИЕ 23/06/17

Эта обновленная версия функции исправляет прозрачность PNG и GIF.

    /**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagecolortransparent($img, imagecolorallocatealpha($img, 0, 0, 0, 127));
                        imagealphablending($img, false);
                        imagesavealpha($img, true);
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagealphablending($img, false);
                        imagesavealpha($img, true);  
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

Проблема: разрешить администратору не показывать уведомления по символическим ссылкам

Уведомление по символической ссылке не будет отображаться в области уведомлений администратора, поскольку оно не включено в <block type="core/text_list" name="notifications" as="notifications">

Патч для CE и EE ниже:

--- app/design/adminhtml/default/default/layout/main.xml
+++ app/design/adminhtml/default/default/layout/main.xml
@@ -119,7 +119,8 @@ Default layout, loads most of the pages
<block type="adminhtml/cache_notifications" name="cache_notifications" template="system/cache/notifications.phtml"></block>
<block type="adminhtml/notification_survey" name="notification_survey" template="notification/survey.phtml"/>
<block type="adminhtml/notification_security" name="notification_security" as="notification_security" template="notification/security.phtml"></block>
-            </block>
+                <block type="adminhtml/checkout_formkey" name="checkout_formkey" as="checkout_formkey" template="notification/formkey.phtml"/></block>
+                <block type="adminhtml/notification_symlink" name="notification_symlink" template="notification/symlink.phtml"/>
<block type="adminhtml/widget_breadcrumbs" name="breadcrumbs" as="breadcrumbs"></block>
<!--<update handle="formkey"/> this won't work, see the try/catch and a jammed exception in Mage_Core_Model_Layout::createBlock() -->

Проблема </block>в конце checkout_formkey(который самозавершается) и, следовательно, закрывает родителя notifications. Это приводит к notification_symlinkтому, что они не включаются в core/text_listи не отображаются.

Небольшой совет на #patchday; после копирования 1.9.3.3 поверх вашей установки, запустите, git diff -w --stat | grep -v " 2 +" | grep -v " 0"чтобы быстро увидеть большие изменения в файлах.

Проблема: шаблон доставки EE не пропатчен

Я пропатчил установку EE 1.13.1.0, и в шаблон корпоративной доставки ( app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) не был добавлен ключ формы, но в шаблонах биллинга и оплаты это было сделано.

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml был исправлен

Существует проблема с версиями Magento EE, которые исправлены с SUPEE-9767 (поэтому не с обновлениями до 1.14.3.3). Ключ формы на этой странице будет кэширован. Поэтому, когда я очищаю свой кэш, а затем перехожу на страницу продукта и проверяю, что страница полностью кэширована (обновите пару раз), я смогу добавить этот продукт в свою корзину.

Теперь, когда я открываю другой браузер (или режим инкогнито), открываю ту же страницу и пытаюсь снова добавить товар в корзину. Товар не будет добавлен в корзину из-за ключа формы. Теперь, когда вы снова очистите кеш, товар можно снова добавить в корзину.

Благодаря Джасперу Зейнстре

Для разработчиков, использующих Magento Composer Intaller, вы можете изменить стратегию развертывания на Копировать вместо Symlink. Вы также можете настроить добавление файлов модуля в ваш .gitignore, чтобы ваш репозиторий оставался чистым.

https://github.com/Cotya/magento-composer-installer/blob/master/doc/Deploy.md#deploy-per-copy-instead-of-symlink

{ "extra":{ "magento-root-dir": "htdocs/", "magento-deploystrategy": "copy", "auto-append-gitignore": true } }

У меня была проблема в EE 1.14.2.2 с включенным FPC и этим исправлением.

Периодически пользователи не могут добавлять в корзину.

Объяснение и исправление здесь: проблема SUPEE-9767: добавьте в корзину проблему, Enterprise Full Page Cache

Проблема: патч работал на ванильном Magento 1.7.0.0 [отредактировано]

Во время тестирования нашего патча мы обнаружили проблему в патче для Magento 1.7.0.0. Не знаю, использует ли кто-нибудь еще, но в любом случае это проблема в SUPEE-9767. Мы использовали ванильную установку и сначала установили все предыдущие патчи.

Patch файл используется: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh Файл патч делает работу для Magento 1.7.0.1 и 1.7.0.2

Краткое изложение проблем:

ERROR: Patch can't be applied/reverted successfully.
...
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
...
checking file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED
...

Для записи, это на 1.7.0.0 мы попробовали патч:

$ grep SUPEE app/etc/applied.patches.list
2017-06-01 12:59:49 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
-e 2017-06-01 12:59:49 UTC | SUPEE-1049 | EE-1.12.0.2 | v1 | 6d06f286f461562fa6d6573349f1491f7bf89859 | Wed Feb 13 17:46:13 2013 -0800 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-01 12:59:49 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-01 12:59:49 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-01 12:59:49 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-01 12:59:49 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-01 12:59:49 UTC | SUPEE-6788 | CE_1.7.0.1 | v1 | 04d237d56b116989e46839c41691585d927f99db | Fri Oct 23 13:52:50 2015 +0300 | f69136a
2017-06-01 12:59:49 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-01 12:59:50 UTC | SUPEE-8788 | CE_1.7.0.0 | v2 | 6b5ef4fc5b09af74d0fd401440948d0a54dd203d | Fri Oct 14 19:27:22 2016 +0300 | 84fa3dd598466fa5c482965a3f8e5395af33bf9d
2017-06-01 12:59:50 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-01 12:59:50 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523

Мне просто пришлось отменить этот патч из-за странного поведения. По какой-то причине определенные пользователи не могут добавлять определенные товары в свою корзину.

Я предполагаю, что это как-то связано со старыми цитатами, сталкивающимися с текущей цитатой для этого клиента. Я подтвердил эту проблему, войдя в систему как пользователь, чтобы убедиться, что это был не просто 1D10T.

Это было проблемой с тех пор, как я взял этот патч в прошлую пятницу. Мы используем 1.14.2.4 . Мы сильно изменены, поэтому он может отлично работать для других пользователей. Просто предупреждение!

Проблема: бесконечный цикл перенаправления на 1.6.0.0

Быстрая починка

Найдите следующие строки внутри защищенной методом метода _checkBaseUrl ($ request) в файле app / code / core / Mage / Core / Controller / Varien / Front.php

 if (isset($uri['scheme']) && $uri['scheme'] != $request->getScheme()
        || isset($uri['host']) && $uri['host'] != $request->getHttpHost()
        || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) {  

Измените эти строки на

 if (isset($uri['host']) && $uri['host'] != $request->getHttpHost()
            || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) { 

После этого сохраните файл (подтвердите свое REPO), очистите кеш (удалите все, что находится в папке var / cache) и перезагрузите ваш магазин. После применения исправления SUPEE 9767 вы должны найти, что сайт загружается без проблем с перенаправлением 302.

Основная причина

Разница в значении SCHEME между фактическим запросом и URI после перенаправления. Например: фактический запрос возвращает схему HTTP, но схема в URI может быть HTTPS.

Возможные основные причины

1. Скорее всего, в файле .htaccess есть правило перенаправления для перенаправления всех http-запросов в https. Пользователь запрашивает http://yourdomain.com, и вы, возможно, изменили схему и перенаправили его на https: // yourdomain вместо http://yourdomain.com, который он фактически запрашивал.

2. Как базовые, так и незащищенные URL-адреса начинаются с https

ПОДТВЕРЖДЕННАЯ ОШИБКА «Регистрация клиента не удалась при оформлении заказа» произошла немного по-другому с моей стороны.

Если клиент выбирает зарегистрироваться в кассе, его пароль хранится неправильно. Клиент создан правильно, просто пароль не сохраняется. Я обнаружил это по тому, что пароль не был показан в приветственном письме. Люди не могут войти из-за этого тоже.

Исправлена ошибка, связанная с патчем SUPEE-9767 / CE 1.9.3.3 - одностраничная проверка - проблема с регистрацией клиентов также выполнила эту работу и для меня.

Может кто-нибудь сказать мне, что это за ... это в supee-9767?

Патч не работает даже для ванильного Magento 1.7.0.2.

martins@martinsmac.local:/var/www/magento1702-original$ ./PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file app/code/core/Mage/Admin/Model/Session.php
Hunk #1 succeeded at 109 (offset -29 lines).
patching file app/code/core/Mage/Adminhtml/Block/Checkout/Formkey.php
patching file app/code/core/Mage/Adminhtml/Block/Notification/Symlink.php
patching file app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Filter/Date.php
patching file app/code/core/Mage/Adminhtml/Model/Config/Data.php
patching file app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php
patching file app/code/core/Mage/Checkout/controllers/MultishippingController.php
patching file app/code/core/Mage/Checkout/controllers/OnepageController.php
Hunk #1 succeeded at 293 (offset -34 lines).
Hunk #2 succeeded at 313 (offset -34 lines).
Hunk #3 succeeded at 363 (offset -34 lines).
Hunk #4 succeeded at 392 (offset -34 lines).
Hunk #5 succeeded at 431 (offset -34 lines).
patching file app/code/core/Mage/Checkout/etc/system.xml
patching file app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
patching file app/code/core/Mage/Core/Controller/Front/Action.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
Hunk #1 succeeded at 141 (offset -7 lines).
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
patching file app/code/core/Mage/Core/etc/config.xml
patching file app/code/core/Mage/Core/etc/system.xml
patching file app/code/core/Mage/Customer/Model/Session.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Adapter/Zend/Cache.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php
patching file app/code/core/Mage/ImportExport/Model/Import/Uploader.php
patching file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php.rej
patching file app/code/core/Mage/Widget/Model/Widget/Instance.php
patching file app/code/core/Mage/XmlConnect/Helper/Image.php
patching file app/design/adminhtml/default/default/layout/main.xml
patching file app/design/adminhtml/default/default/template/notification/formkey.phtml
patching file app/design/adminhtml/default/default/template/notification/symlink.phtml
patching file app/design/adminhtml/default/default/template/page/head.phtml
patching file app/design/frontend/base/default/template/checkout/cart/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/billing.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/billing.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/payment.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml
patching file app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml
patching file app/etc/config.xml
patching file app/locale/en_US/Mage_Adminhtml.csv
patching file app/locale/en_US/Mage_Core.csv
patching file app/locale/en_US/Mage_Dataflow.csv
patching file downloader/Maged/Connect.php
patching file downloader/Maged/Controller.php
Hunk #1 succeeded at 400 (offset -5 lines).
Hunk #2 succeeded at 923 (offset -5 lines).
patching file downloader/Maged/Model/Session.php
Hunk #2 succeeded at 235 with fuzz 2 (offset -13 lines).
patching file js/varien/payment.js
patching file skin/frontend/base/default/js/opcheckout.js

даже после применения старых патчей вручную.

$ grep '|' app/etc/applied.patches.list
2017-06-19 04:01:42 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-19 04:03:26 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
2017-06-19 04:04:12 UTC | SUPEE-1049 | EE_1.12.0.2 | v1 | 5cd884653325315804056d4c591572385b3c1d03 | Thu Mar 20 16:33:19 2014 +0200 | v1.12.0.2..HEAD
2017-06-19 04:05:01 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-19 04:06:38 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-19 04:07:10 UTC | SUPEE-1533 | EE_1.12 | v1 | _ | n/a | SUPEE-1533_EE_1.12_v1.patch
2017-06-19 04:08:41 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-19 04:09:29 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-19 04:10:00 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-19 04:11:22 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-19 04:11:50 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-19 04:12:12 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-19 04:14:30 UTC | SUPEE-8167 | EE_1.12.0.2 | v1 | b1be28f9cd8c2ecba2aa403e59ad9e3d2855eb95 | Thu May 4 13:52:13 2017 +0300 | 8d12ea6fe564b6dc9ed1affb6de990f81aca3796..HEAD
2017-06-19 04:16:21 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-19 04:16:44 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523
2017-06-19 04:19:35 UTC | SUPEE-6788 | CE_1.7.0.2 | v1 | 0398c4b951d9a0f64495e7b8b3b8ca480952dd70 | Fri Oct 23 13:50:23 2015 +0300 | cfc252b

Решение / проблема, которую я нашел, состоит в том, что некоторые изменения в патче для 1.7.0.2 предназначены для файлов, которых не было до 1.9.2.3. Поэтому я скопировал следующие файлы из новой установки 1.9.2.3 перед запуском сценария исправления:

• Приложение / код / ​​ядро ​​/ Mage / Ядро / Модель / Файл / Оценщик / image.php
• Приложение / код / ​​ядро ​​/ Mage / Sales / модель / Quote / Item.php

Просто дополнение к https://magento.stackexchange.com/a/176930/46249

Обратите внимание, что символические ссылки всегда были отключены по умолчанию в новых установках Magento. Администратор ДА / НЕТ значения конфигурации по умолчанию «НЕТ». Обновление теперь явно отключает символические ссылки в config.xml и в качестве дополнительной меры предосторожности также удаляет раздел шаблона из раздела admin-> developer, в котором содержится параметр конфигурации.

Это не повлияет на ваши текущие настройки символических ссылок, если вы вручную включили символические ссылки до 1.9.3.2, они останутся включенными, хотя вы больше не сможете видеть настройки в admin.

Жирный текст не является правильным. Если обновление до 1.9.3.4 (SUPEE-9767 V2) или более новых текущих настроек будет удалено:

# app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.6-1.6.0.7.php
$connection->delete(
    $this->getTable('core_config_data'),
    $connection->prepareSqlCondition('path', array(
        'like' => 'dev/template/allow_symlink'
    ))
);

Ответственные администраторы могут снова включить раздел администрирования символической ссылки, выполнив поиск изменений в разделе шаблона в app / code / core / Mage / Core / etc / system.xml и добавив этот раздел в ваш system.xml примерно на строке 600. Или двойная проверка символьных ссылок все еще включена с

Просто сделайте опцию config видимой снова, это не решит проблему. Опция появляется, но вы не можете изменить конфигурацию, так как недавно представленная модель бэкэнда не позволяет сохранить значение. Видеть:

# app/code/core/Mage/Core/etc/system.xml
<backend_model>adminhtml/system_config_backend_symlink</backend_model>

а также

# Mage_Adminhtml_Model_System_Config_Backend_Symlink
public function save()
{
    return $this;
}

Поэтому вам нужно удалить или переопределить эту базовую модель, см. Как включить символические ссылки после установки SUPEE-9767 V2?