У 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'
        );

Символьні посилання

Цей патч видаляє поле конфігурації системи, яке дозволяє дозволити посилання шаблону в бекенд. Раніше це було в розділі Система> Конфігурація> Розробник> Шаблон> Дозволити посилання . Тепер увесь розділ Шаблон пропав.

Крім цього, це поле тепер за замовчуванням вимкнено через 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 додав ще деякий захист щодо завантаження зображень.

Зауважте, що вони є деяким захистом від відомого способу його експлуатації, крім самого налаштування.

Що робити : якщо, як я, ви використовуєте модмана чи композитора з символічними посиланнями, ви зіткнетесь з деякими проблемами. Я все ще намагаюся з’ясувати, що найкраще тут робити, окрім роботи із запитами SQL.

Основна публікація щодо цього питання: SUPEE-9767, модем та символьні посилання

Перелік можливих питань

V2 був випущений з того часу. Не забудьте оновити

Клопи

Слово "підтверджено" використовується для підтверджених помилок. Якщо його немає, це означає, що це може бути помилка, але ще не підтверджено.

• Клієнт не видає реєстрації під час оформлення замовлення ПІДТВЕРДЖЕНО І ВІДКЛЮЧЕНО У V2
• PHP7 і EE помилка ПІДТВЕРДЖЕНО
• Виправлені з EE, FPC і дизайн Винятки ПІДТВЕРДЖЕНО
• Додати у кошик та помилку cookie у EE ПОВЕРЕНО
• Зламаний мультиспінг після виправлення ПЕЧЕНЬ
• Відсутнє виправлення помилки уhead-simple.phtml ПІДТВЕРДЖЕНОМУ І ВІДКЛЮЧЕНОМ В V2
• Попередження адміністратора Symlink не відображається на 1.9.2 ПІДТВЕРДЖЕНО І ВІДКЛЮЧЕНО В V2
• Водяний знак отримує чорний фон, коли прозорий ПІДТВЕРДЖЕНО & ВІДКЛЮЧЕНО В V2
• Неможливо оновити через Magento Connect
• Нескінченний цикл переадресації на 1.6.0.0

Невдалі проблеми

Зауважте, що всі ці проблеми можуть бути просто тому, що ви змінили оригінальний файл, щоб перевірити, чи це не так:

• Створіть резервну копію файлу, де ви отримали помилку Hunk Failed
• Завантажте оригінальний файл зі своєї версії Magento
• Порівняйте обидва файли

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

• нестандартний шаблон у спеціальній папці тем
• local.xml
• додаток / код / ​​локальний файл

Якщо файли не відрізняються, це або проблема дозволу, або "помилка" в патчі.

• додаток для виправлення файлів / дизайн / frontend / rwd / за замовчуванням / макет / page.xml Hunk №1 ЗНАНИЛО в 36.
• додаток для виправлення файлів / дизайн / frontend / підприємство / за замовчуванням / шаблон / стійкий / checkout / onepage / billing.phtml Hunk # 1 ЗНАНИЛО у 225.
• додаток для виправлення файлів / код / ​​core / Enterprise / PageCache / Model / Observer.php Hunk # 6 ЗНАНИЛО в 1093.
• додаток для виправлення файлів / код / ​​core / Mage / Core / тощо / system.xml Hunk №3 ЗНАНИЛО в 1355.
• додаток для виправлення файлів / код / ​​core / Mage / Продажі / Модель / Quote / Item.php Hunk №1 ЗНАНИЛО в 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 на замовлення з доставкою, то це потрібно зробити в

нижче файлів:

Випуск 2: випуск form_key до форми оцінки доставки на сторінці кошика:

Додайте form_key за формою доставки кошторисів на сторінку кошика

Потім потрібно додати ключ форми <?php echo $this->getBlockHtml('formkey') ?>

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

Випуск3: Помилка Magento на одній сторінці opcheckout.js

Якщо ви користуєтеся карткою на одній сторінці за замовчуванням, і opcheckout.js тоді слід перевірити

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

Якщо не виходить, то замініть

if (елементи [i] .name == 'платіж [метод]') {

з

if (елементи [i] .name == 'платеж [метод]' || елементи [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 ('core / session') -> 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: Випуск Form_key після виходу

Після виходу клієнта з сеансу , ви можете почати випуск сесії, якщо 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 до ЗБЕРІГАННЯ дії вашого односторінкового контролера оформлення замовлення .

Припустимо, щоб зберегти деталі способу доставки, у вашій одночасному оформленні замовлення використовується saveShippingmethod (). Потім для цього слід додати

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

Крім того, ви повинні додати ключ форми <?php echo $this->getBlockHtml('formkey') ?> у вашому onestep checkout 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') {

EDIT

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

EDIT2 - Випуски

1) Помилка при saveBillingAction () або отримання ключа форми null Або проблема клавіші форми: Патч 9767 отримання недійсного ключа форми

2) Hunk №1 ЗНАНИЛО в 225. 1 з 1 парка НЕПОЛАДЕНА - збереження відхилень у файлі 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) додаток / дизайн / frontend / rwd / за замовчуванням / макет / page.xml Hunk №1 ЗНАНИЛО в 36. Hunk # 2 ЗНАНИЛО в 54. 2 з 2-х загиблих ПОСЛУГА : помилка SUPEE-9767

6) 1 з 1 парки НЕВЕРШЕНО - збереження відхилень у файлі програми / код / ​​core / Mage / Продаж / Модель / Цитата / Item.php: Magento 1.9.2.2 SUPEE-9767 Patch ERROR

7) помилка оформлення одномоментного замовлення (знову це ключовий вигляд форми): SUPEE-9767 Magento CE 1.9.3.3 Onestep Checkout не працює, якщо увімкнено перевірку ключа класу під час оформлення замовлення

8) випуск з реєстрацією клієнта в один крок: SUPEE-9767 Patch / CE 1.9.3.3 - Оформлення однієї сторінки - Випуск реєстрації клієнта

9) додаток / код / ​​core / Mage / Core / Модель / Файл / Validator / Image.php: Magento SUPEE 9697 1.9.2.2 не працює на Image.php

Зауважте, що символьні посилання завжди були відключені за замовчуванням у нових установниках Magento Адміністратор ТАК / НІ значення конфігурації за замовчуванням до "НІ". Тепер оновлення явно вимикає посилання на config.xml і в якості додаткової обережності також видаляє розділ шаблону від адміністратора- розробника, який містив параметр конфігурації.

Це не вплине на ваші поточні налаштування символьного посилання, якщо ви вручну ввімкнули символьні посилання до 1.9.3.2, вони залишаться ввімкненими, хоча ви більше не можете бачити налаштування в адміністраторі.

Користувачі, які використовують модуль для управління модулями Magento 1.x, повинні гарантувати, що вони не відключають символьні посилання, оскільки це відключить модулі модулів.

Відповідальні адміністратори можуть знову ввімкнути розділ адміністратора symlink, шукаючи різні зміни в розділі шаблону в застосунку / код / ​​ядро ​​/ Mage / Core / тощо / system.xml і додавши розділ до системи.xml приблизно в рядку 600. Або подвійні контрольні посилання все ще увімкнено

n98-magerun.phar config: дамп | 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 повинна щось робити з цим. Швидке виправлення - це, але точно не правильно:

-> додаток / код / ​​core / Enterprise / PageCache / Model / Observer.php: 244 замініть його на:

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

-> і додаток / код / ​​core / Enterprise / PageCache / Модель / 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 плюса) в процесі оформлення замовлення одна сторінки перезаписує Fieldset елемента в один крок спосіб оплати форми HTML - видалення або відключення (з CSS) прихованим form_key елемент.

Виправлення полягає в забезпеченні formkey елемент не відключається будь-яким динамічним кодом або CSS. Переміщення коду formkey поза Fieldset елемента також може допомогти

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

Ви можете легко підтвердити, якщо форма_кей виявлена ​​та надіслана контролеру однієї сторінки, перевіривши запити мережі 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 Patch / CE 1.9.3.3 - Оформлення однієї сторінки - Реєстрація клієнта

Коли Ви переходите до оформлення замовлення, нам пропонується 2 варіанти: ПЕРЕВІРИТИСЯ ЯК ГОСТІВ ТА РЕЄСТРАЦІЯ Після натискання кнопки «Зареєструватися» та заповніть форму разом із паролем, Ви переходите до всіх етапів та виконуєте замовлення. Замовлення розміщено, АЛЕ замовник ніколи не реєструється у магенто. Це схоже на замовлення гостей.

Коли я повернувся назад і відключив автентифікацію клавіш із форми та спробував розмістити замовлення під час реєстрації як клієнт, він розмістився без проблем і клієнт зареєструвався в бекенді.

ОНОВЛЕННЯ 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, ви можете змінити стратегію розгортання на Copy замість 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: Додати до кошика випуск, Кеш повного сторінки підприємства

Випуск: Patch працював над ванільним 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 ($ запит) у файлі 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) і перезавантажте фронтальну частину магазину. Ви повинні знайти завантаження сайту без більше 302 проблем з переадресацією після застосування SUPEE 9767 Patch.

Першопричина

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

Можливі основні причини

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

2. Базові захищені та незахищені URL-адреси починаються з https

ПІДТВЕРДЖЕНИЙ БУГ " Не вдалося зареєструвати клієнта при оформленні каси" стався трохи по-іншому з мого боку.

Якщо клієнт вибирає реєстрацію в касі, то його пароль неправильно зберігається. Клієнт створений правильно лише в тому, що пароль не зберігається. Я виявив це через те, що пароль не відображався в вітальному листі. Люди також не можуть увійти через це.

Виправлена помилка в SUPEE-9767 Patch / 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 перед запуском сценарію патча:

• app / code / core / Mage / Core / Model / File / Validator / Image.php
• app / code / core / Mage / Продажі / Модель / Quote / Item.php

Отримайте додаток до https://magento.stackexchange.com/a/176930/46249

Зауважте, що символічні посилання завжди були відключені за замовчуванням у нових установленнях Magento Адміністратор ТАК / НІ значення конфігурації за замовчуванням "НІ". Тепер оновлення явно вимикає посилання на config.xml і в якості додаткової обережності також видаляє розділ шаблону від адміністратора- розробника, який містив параметр конфігурації.

Це не вплине на ваші поточні налаштування символьного посилання, якщо ви вручну ввімкнули символьні посилання до 1.9.3.2, вони залишаться ввімкненими, хоча ви більше не можете бачити налаштування в адміністраторі.

Жирний текст невірний. Якщо оновлення до 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'
    ))
);

Відповідальні адміністратори можуть знову ввімкнути розділ адміністратора symlink, шукаючи різні зміни в розділі шаблону в додатку / код / ​​core / Mage / Core / тощо / system.xml і додаючи розділ до системи.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?