Un nuevo parche de seguridad está disponible para Magento 1, que aborda 16 problemas de APPSEC: https://magento.com/security/patches/supee-9767

Siete de las vulnerabilidades tienen una puntuación de 8.0 o superior para CVSSv3 Severity , y están siendo explotadas en la naturaleza, por lo que este es un parche crítico. Los sitios pueden aplicar SUPEE-9767 o actualizar a la nueva versión CE 1.9.3.3 / EE 1.14.3.3.

¿Cuáles son los problemas comunes o las dificultades a tener en cuenta al aplicar SUPEE-9767?

ACTUALIZACIÓN 2017-07-12:

Magento ha lanzado SUPEE-9767 V2 y CE 1.9.3.4 para abordar muchos de los problemas del parche inicial. Si aplicó V1, debe revertir y luego aplicar V2. Si aún no ha parcheado, simplemente aplique V2, y la mayoría de los problemas mencionados aquí no serán relevantes.

Aquí está mi descripción general del parche después de profundizar en él

AHORRO DE TIEMPO : Experius proporciona un asistente de parches que lo ayuda a encontrar los archivos en temas personalizados, módulos personalizados o sobrescrituras locales que también pueden necesitar ser parcheados manualmente , puede encontrarlo aquí: https://github.com/experius/Magento- 1-Experius-Patch-Helper # magento

Teclas de formulario de pago

Como se dijo en la otra publicación, este parche agrega claves de formulario a los siguientes formularios:

Forma del carrito de envío:

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

Formulario de pago de facturación en varios puntos:

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

Formulario de pago y envío de envío múltiple:

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

Formulario de pago de direcciones de multipunto:

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

Formulario de pago de facturación:

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

Forma de pago del envío:

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

Formulario de pago:

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

Forma de pago y envío:

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

Formulario de pago de facturación persistente:

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

Además de eso, los siguientes archivos JS se han actualizado para que sean compatibles con ese cambio:

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

Qué hacer:

Si está utilizando versiones personalizadas de esas plantillas, deberá actualizarlas agregando el siguiente código:

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

Si está utilizando un módulo de pago de terceros, deberá ponerse en contacto con ellos para que puedan proporcionar una versión actualizada de su módulo.

Además, si tiene versiones personalizadas de los archivos JS enumerados anteriormente, también deberá actualizarlos.

Excepto su tiempo :

Fabian Schmengler escribió un pequeño y agradable script para actualizar todas esas cosas por usted, puede encontrarlo aquí:

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

NOTA IMPORTANTE : la validación de la clave de formulario de pago se puede cambiar en el backend a través de un nuevo campo de configuración en Sistema> Configuración> Administrador> Seguridad> Habilitar validación de clave de formulario al finalizar la compra . ¡ESTO NO ESTÁ HABILITADO POR DEFECTO, por lo que tendrá que habilitarlo para beneficiarse de esta característica de seguridad! Tenga en cuenta que recibirá un aviso en el backend si no está habilitado.

Devolución de llamada de carga de imagen

El controlador de la galería de imágenes se ha actualizado para agregar una devolución de llamada de validación.

Qué hacer

Si está utilizando un módulo personalizado que carga imágenes con un código similar al siguiente:

        $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);

Le sugiero que actualice ese código agregando la siguiente pieza después:

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

Enlaces simbólicos

Este parche elimina el campo de configuración del sistema que le permite permitir enlaces simbólicos de plantilla en el back-end. Solía ​​estar en Sistema> Configuración> Desarrollador> Plantilla> Permitir enlaces simbólicos . Ahora toda la sección de plantillas se ha ido.

Además de eso, ese campo ahora está deshabilitado de forma predeterminada a través de app/etc/config.xml

Lo curioso aquí es que recibirá un aviso en el backend si tiene ese campo de configuración habilitado antes del parche, pero no podrá desactivarlo cuando el campo desaparezca.

La única forma de hacerlo es ejecutando la siguiente consulta SQL

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

Aclaración

Primero, le sugiero que verifique esas dos publicaciones que lo ayudarán a comprender el propósito de esa modificación de Symlink:

• De Peter O'Collaghan: https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/
• De Max Chadwick: https://maxchadwick.xyz/blog/what-allow-symlinks-actually-does

Esta modificación se trata realmente de llamar contenido descargable (como imágenes) a través de directivas de plantilla.

El problema relacionado con los enlaces simbólicos solo se puede explotar con acceso de administrador y Magento también agregó más protección en la carga de imágenes.

Tenga en cuenta que son algunas protecciones contra la forma conocida de explotarlo, además de la configuración en sí.

Qué hacer : si como yo, estás usando Modman o Composer con enlaces simbólicos de plantillas, enfrentarás algunos problemas. Todavía estoy tratando de averiguar qué es lo mejor que se puede hacer aquí, aparte de tratar con consultas SQL.

Publicación principal sobre este tema: SUPEE-9767, modman y enlaces simbólicos

Lista de posibles problemas

V2 fue lanzado desde esa publicación original. No olvides actualizar

Loco

La palabra 'confirmado' se usa para errores confirmados. Si no está allí, eso significa que podría ser un error, pero aún no se ha confirmado.

• El registro del cliente falla al finalizar la compra CONFIRMADO Y FIJO EN V2
• PHP7 y EE error CONFIRMADO
• Error con EE, FPC y excepciones de diseño CONFIRMADAS
• Agregar al carrito y error de cookies en EE CONFIRMADO
• Multichip roto después del parche CONFIRMADO
• Falta corrección de errores enhead-simple.phtml CONFIRMADO Y FIJO EN V2
• La advertencia de enlace de administrador no se muestra en 1.9.2 CONFIRMADO Y FIJO EN V2
• La marca de agua obtiene fondo negro cuando es transparente CONFIRMADO Y FIJO EN V2
• No se puede actualizar a través de Magento Connect
• Bucle de redireccionamiento infinito en 1.6.0.0

Problemas fallidos de Hunk

Tenga en cuenta que todos esos problemas podrían deberse simplemente a que modificó el archivo original, para verificar que este no sea el caso:

• Haga una copia de seguridad del archivo donde obtiene el error Fallo de Hunk
• Descargue el archivo original de su versión de Magento
• Compara ambos archivos

Si los archivos son diferentes, tendrá que aplicar el parche con el archivo original y luego volver a aplicar los cambios personalizados de forma limpia, como:

• plantilla personalizada en una carpeta de tema personalizado
• local.xml
• aplicación / código / archivo local

Si los archivos no son diferentes, se trata de un problema de permiso o un "error" en el parche.

• aplicación de archivo de parches / design / frontend / rwd / default / layout / page.xml Hunk # 1 FALLÓ en 36.
• aplicación de archivo de parches / diseño / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtml Hunk # 1 FALLÓ en 225.
• aplicación de parches de archivos / código / core / Enterprise / PageCache / Model / Observer.php Hunk # 6 FALLÓ en 1093.
• aplicación de parches de archivos / code / core / Mage / Core / etc / system.xml Hunk # 3 FALLÓ en 1355.
• aplicación de parches de archivos / código / core / Mage / Sales / Model / Quote / Item.php Hunk # 1 FALLÓ en 500.
• Hunk falló el 1.8.0.0

Problema1: form_key inválido en la página de pago

Magento agrega form_keyen la mayoría de las formas.

si es así using default onepage and using custom theme, comenzará a recibir ** form_keyproblema al finalizar cada paso **;

debe agregar clave de formulario en <?php echo $this->getBlockHtml('formkey') ?>

para formar cada paso de pago si hay archivos debajo,

• 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

si los archivos de plantilla están llamando desde el tema base, entonces no crea un problema. Porque el parche actualizará automáticamente esos archivos.

También tenga en cuenta: <?php echo $this->getBlockHtml('formkey') ?>siempre debe estar dentro de la etiqueta del formulario

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

** Si utiliza el pago de envío múltiple de Magento, debe hacerlo en

archivos a continuación:

Problema 2: problema de form_key con el formulario de estimación de envío en la página del carrito:

Agregue form_key en el formulario de envío estimado en la página del carrito

Luego debe agregar clave de formulario <?php echo $this->getBlockHtml('formkey') ?>

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

Problema 3: Magento onepage checkout opcheckout.js error

Si usa el pago predeterminado de una página y tiene, opcheckout.js entonces debería verificar

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {está disponible en opcheckout.js

Si no sale, reemplace

if (elementos [i] .name == 'pago [método]') {

con

if (elementos [i] .name == 'pago [método]' || elementos [i] .name == 'form_key') {

Para el caso del problema1, problema2, problema3, el problema se puede solucionar fácilmente usando el script add-checkout-form-key.sh de @FabianSchmengler . Solucionará el problema en sus archivos de tema receptivo

Problema 4: Clave de formulario inválida después del inicio de sesión del cliente cuando Mage_Customer_Model_Session reescribe

Si la Mage_Customer_Model_Sessionclase reescribe o ha llamado desde

app/code/local/Mage/Customer/Model/Session.phpentonces es posible que tenga un problema de form_key cuando configuramos un cliente para la sesión usando setCustomerAsLoggedIn()/ o después de que un cliente configuró en la sesión.

En este caso, debes agregar

Mage :: getSingleton ('core / session') -> renewFormKey ();

en setCustomerAsLoggedIn () antes de la llamada de

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;
    }

Problema 5: problema de Form_key después de cerrar sesión

Después de cerrar la sesión del cliente de la sesión , puede comenzar el problema de la sesión si If Mage_Customer_Model_Sessionclass reescribe o ha llamado desde

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

En esas mismas necesidades para este caso:

   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;
    }

Recomendación:

Recomendación 1: para solucionar el problema de supee-9767 , puede usar el parche https://github.com/experius/Magento-1-Experius-Patch-Helper

Esta es una mejor solución por ahora.

Tenga en cuenta que , antes de hacerlo, se recomienda encarecidamente realizar copias de seguridad de archivos y bases de datos o copias de seguridad completas del sistema.

Recomendación 2: Use la función de parche en su COMPROBACIÓN DE ONESTEP

Sabemos que la versión del parche supee-9767 por razones de seguridad, si usa ONESTEP CHECKOUT, entonces debe agregar la validación form_key para GUARDAR la acción de su controlador de pago onestep .

Suponga que para guardar los detalles del método de envío, su pago en este paso ha utilizado saveShippingmethod () Luego, en esto, debe agregar

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

También debe agregar la clave de formulario <?php echo $this->getBlockHtml('formkey') ?> en la sección respectiva de los archivos phtml de pago de onestep

Algún enlace relacionado

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

Basado en mi primer pase en la revisión del archivo de parche ...

• Se admin/security/validate_formkey_checkoutha agregado una nueva configuración . Cuando se activa, se verifica la presencia de una clave de formulario en los formularios de pago. Si los archivos de plantilla se anulan en el tema, deberán actualizarse allí. Esta configuración parece estar desactivada por defecto
• Los enlaces simbólicos parecen no estar permitidos por defecto (en app/etc/config.xml). Además, la capacidad de permitirlos parece haberse eliminado de la configuración del administrador. Sin embargo, si su sitio anteriormente habilitaba explícitamente enlaces simbólicos, la configuración se guardaría en la base de datos, anulando este cambio.
• Debe borrar tanto el caché como el caché de página completa al aplicar este parche. Las excepciones de diseño se guardan en un formato incompatible con la decodificación. Verá un error como este "Error de decodificación: error de sintaxis" si no vacía la memoria caché de la página.

Debajo del base/defaultarchivo afectado con este parche, si estos archivos estaban en su tema, haga los cambios correspondientes

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

en todos los phtmlarchivos anteriores , se agrega la línea de clave de formulario, así que agregue esta línea en su archivo phtml respectivo.

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

Para el problema anterior, @fabian creó un script que agregará la clave de formulario incluso en su archivo de tema

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

después de aplicar el parche de seguridad si obtiene un error para la clave de formulario, puede aplicar este parche, para aplicar este proceso de parche es igual que el parche de seguridad solo

  sh filename.sh

y un base/defaultcambio en el Jsarchivo

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

así que si este jsarchivo se está cargando desde su tema, siga los pasos a continuación

quitar la línea de soplado

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

y agregue debajo de la línea en lugar de arriba

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

EDITAR

Y si está utilizando cualquier extensión de pago que anula debajo de los archivos, agregue la línea de clave de formulario en el archivo phtml de la extensión de pago.

EDIT2 - Problemas

1) Error en saveBillingAction () u obtener clave de formulario nula o problema de clave de formulario: Parche 9767 obteniendo clave de formulario no válida

2) Hunk # 1 FALLÓ en 225. 1 de 1 trozo FALLÓ - guardar rechazos en la aplicación de archivo / diseño / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtml: SUPEE-9767 - Hunk # 1 FALLÓ en 225. 1 de 1 trozo FALLÓ

3) guardar rechazos en la aplicación de archivo / código / core / Enterprise / PageCache / Model / Observer.php.rej: SUPEE-9767 ERROR: el parche no se puede aplicar / revertir con éxito

4) SUPEE-9767, modman y enlaces simbólicos: SUPEE-9767, modman y enlaces simbólicos

5) app / design / frontend / rwd / default / layout / page.xml Hunk # 1 FAILED at 36. Hunk # 2 FAILED at 54. 2 de 2 hunks FAILED: SUPEE-9767 Error

6) 1 de 1 trozo FALLIDO - guardando rechazos en la aplicación de archivo / código / core / Mage / Sales / Model / Quote / Item.php: Magento 1.9.2.2 SUPEE-9767 ERROR de parche

7) error de pago de onestep (de nuevo, este es el problema clave del formulario): SUPEE-9767 Magento CE 1.9.3.3 El pago en un solo paso no funciona con la validación de la tecla de formulario al finalizar la compra habilitada

8) problema de registro de cliente de pago en un solo paso: SUPEE-9767 Patch / CE 1.9.3.3 - Pago de una página - Problema de registro de cliente

9) app / code / core / Mage / Core / Model / File / Validator / Image.php: Magento SUPEE 9697 1.9.2.2 falla en Image.php

Tenga en cuenta que los enlaces simbólicos siempre se han deshabilitado de manera predeterminada en las nuevas instalaciones de Magento admin. Los valores de configuración SI / NO están predeterminados en 'NO'. La actualización ahora deshabilita explícitamente los enlaces simbólicos en config.xml y, como precaución adicional, también elimina la sección de plantilla de admin-> developer que contenía la opción de configuración.

Esto no afectará su configuración actual de enlaces simbólicos, si habilitó manualmente los enlaces simbólicos anteriores a 1.9.3.2, permanecerán habilitados, aunque ya no podrá ver la configuración en admin.

Los usuarios que usan modman para administrar los módulos Magento 1.x deben asegurarse de no deshabilitar los enlaces simbólicos, ya que esto deshabilitará los módulos modman.

Los administradores responsables pueden habilitar nuevamente la sección de administración del enlace simbólico buscando los cambios de diferencias en la sección de plantilla en app / code / core / Mage / Core / etc / system.xml y agregando la sección a su system.xml en la línea 600. O los enlaces simbólicos de doble verificación todavía están habilitados con

n98-magerun.phar config: volcado | enlace simbólico grep

Aquí está el archivo diff para magento1933 y magento1932 para ayudarlo a identificar cambios en el tema predeterminado que pueden afectar sus temas personalizados / extendidos.

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

Problema: el uso de php7 a veces arroja el siguiente error:

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}

Es bastante seguro de que la versión de Zend tiene que hacer algo con él. Una solución rápida es esto, pero seguramente no es correcta:

-> app / code / core / Enterprise / PageCache / Model / Observer.php: 244 reemplácelo con:

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

-> y app / code / core / Enterprise / PageCache / Model / Observer.php: 177 con:

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

Por supuesto, cree un complemento para reescribir esto. Pero estoy seguro de que hay algo mejor que hacer aquí.

ACTUALIZACIÓN (Mejor solución)

-> Ve a: lib / Zend / Json.php y después de la línea 76 agrega esto:

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

Cree su extensión para anularla y no edite el archivo principal.

Problema: el código dinámico o CSS desactiva el elemento de entrada de clave de formulario al finalizar la compra

Un problema que he visto es cuando el código dinámico (paypal plus) en el proceso de pago de una página sobrescribe el elemento del conjunto de campos en el formulario de método de pago de un solo paso html: eliminar o deshabilitar (con css) el elemento oculto form_key.

La solución es asegurar que el elemento formkey no esté siendo deshabilitado por ningún código dinámico o CSS. Mover el código de la tecla de formulario fuera del elemento del conjunto de campos también puede ayudar

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

Puede confirmar fácilmente si la clave_formulario se está detectando y enviando al controlador de una página inspeccionando las solicitudes de red ajax en su navegador a medida que avanza por los métodos de pago, cada método debe incluir la clave del formulario en los datos del formulario ajax, si el formulario La clave no está allí, pero el código fuente de Magento ha sido parcheado.

Problema: faltan correcciones en head-simple.phtml

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

necesita las mismas soluciones que

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

PROBLEMA: El registro del cliente falla cuando se utiliza el pago genérico de 5 pasos de Magento.

Este problema solo se presenta cuando HABILITAMOS la autenticación de clave de formulario. Versión utilizada: 1.7.0.2, pero parece que alguien ha publicado que el mismo problema también ocurre en la versión 1.9.3. SUPEE-9767 Patch / CE 1.9.3.3 - Pago de una página - Problema de registro del cliente

Cuando vaya a pagar, se nos presentan 2 opciones: PAGAR COMO INVITADO O REGISTRARSE Una vez que haga clic en "Registrarse" y complete el formulario junto con la contraseña, proceda a través de todos los pasos y complete el pedido. El pedido se realiza, PERO el cliente nunca se registra en magento. Parece que el huésped hizo un pedido.

Cuando regresé y desactivé la autenticación de clave de formulario, e intenté hacer un pedido mientras me registraba como cliente, se realizó sin ningún problema y el cliente se registró en el back-end.

ACTUALIZACIÓN 13/07/2017 [EL PROBLEMA ESTÁ FIJO]

El equipo de Magento ha lanzado SUPEE-9767 V2 en esta versión del parche. Se solucionó el problema con los gifs transparentes y png.

Debe revertir todos los cambios en el archivo que se discutió en este hilo. Luego revierta el parche V1 aplicado y finalmente aplique la nueva versión V2.

PRE - SUPEE-9767 V2

No utilice el código que se describe a continuación, en su lugar, aplique V2 del parche, el problema que se describe a continuación ya está solucionado en esta versión

Si alguien experimenta un problema con png transparentes, cuando se carga desde el panel de administración, el fondo se vuelve negro. (En los productos) está relacionado con la devolución de llamada de Image Upload introducida en:

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

Por el momento no estoy seguro de qué es exactamente lo que está causando este comportamiento, pero estoy tratando de resolverlo, puedo confirmar que cuando se elimina la devolución de llamada, el extraño comportamiento desaparece.

ACTUALIZAR

Ok, encontré la función que también se actualiza desde SUPEE-9767, esto en realidad está rompiendo la transparencia en los png, se crea una copia de la imagen original sin transparencia.

+++ 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.'));

ACTUALIZAR

Aquí está la versión actualizada de la función para preservar la transparencia png

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

Estas dos líneas deben agregarse al parche. Actualiza la función enapp/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.'));
}

ACTUALIZACIÓN 23/06/17

Esta versión actualizada de la función corrige la transparencia PNG y 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.'));
}

Problema: Permitir notificación de enlace simbólico no se muestra a los administradores

La notificación de enlace simbólico no se mostrará en el área de notificación del administrador ya que no está incluida en el <block type="core/text_list" name="notifications" as="notifications">

El parche para CE y EE a continuación:

--- 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() -->

El problema es </block>al final de checkout_formkey(que es automático) y, por lo tanto, cierra al padre notifications. Esto hace notification_symlinkque no se incluya en el core/text_listy no se represente.

Pequeño consejo para #patchday; después de copiar 1.9.3.3 sobre su instalación, ejecute git diff -w --stat | grep -v " 2 +" | grep -v " 0"para ver rápidamente cambios más grandes en los archivos.

Problema: plantilla de envío EE no parcheada

Parcheé una instalación EE 1.13.1.0, y la plantilla de envío empresarial ( app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) no tenía la clave de formulario agregada, pero las plantillas de facturación y pago sí.

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

Hay un problema con las versiones de Magento EE que están parcheadas con SUPEE-9767 (por lo que no con las actualizaciones a 1.14.3.3). La clave de formulario en esa página se almacenará en caché. Entonces, cuando vacío mi caché y luego voy a la página de un producto y me aseguro de que la página esté completamente en caché (actualizar un par de veces), debería poder agregar ese producto a mi carrito.

Ahora, cuando abro un navegador diferente (o modo incógnito), abra la misma página e intente agregar el producto al carrito nuevamente. El producto no se agregará al carrito debido a la clave de formulario. Ahora, cuando vuelva a vaciar el caché, el producto puede agregarse nuevamente al carrito.

Gracias a Jasper Zeinstra

Para los desarrolladores que usan Magento Composer Intaller, puede cambiar la estrategia de implementación a Copiar en lugar de Enlace simbólico. También puede configurar para agregar los archivos del módulo a su .gitignore, para que su repositorio se mantenga limpio.

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 } }

Tuve un problema en EE 1.14.2.2 con FPC habilitado y se aplicó este parche.

Intermitentemente, los usuarios no pueden agregar al carrito.

Explicación y solución aquí: SUPEE-9767 problema: problema de agregar al carrito, caché de página completa empresarial

Problema: Patch estaba trabajando en Vanilla Magento 1.7.0.0 [editado]

Durante la prueba de nuestro script de parche descubrimos un problema en el parche para Magento 1.7.0.0. No sé si alguien todavía lo usa, pero de todos modos es un problema en SUPEE-9767. Utilizamos una instalación de vainilla e instalamos primero todos los parches anteriores.

Archivo de parche utilizado: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh El archivo de parche no funciona para Magento 1.7.0.1 y 1.7.0.2

Resumen de problemas:

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
...

Para el registro, esto en el 1.7.0.0 probamos el parche en:

$ 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

Solo tuve que revertir este parche debido a un comportamiento extraño. Por alguna razón, ciertos usuarios no pueden agregar ciertos artículos a su carrito.

Supongo que tiene algo que ver con las viejas cotizaciones que chocan con la cotización actual para ese cliente. Verifiqué este problema iniciando sesión como usuario para asegurarme de que no era solo un 1D10T.

Ha sido un problema desde que tomé ese parche el viernes pasado. Estamos utilizando 1.14.2.4 . Estamos muy modificados, por lo que podría funcionar bien para otros usuarios. ¡Sólo una advertencia!

Problema: bucle de redireccionamiento infinito en 1.6.0.0

Arreglo rapido

Encuentre las siguientes líneas dentro de la función de método protegido _checkBaseUrl ($ request) en el archivo 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
 ) {  

Cambia estas líneas a

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

Después de eso, guarde el archivo (comprométase a su REPO), borre el caché (elimine todo lo que está dentro de la carpeta var / cache) y vuelva a cargar el frente de su tienda. Debería encontrar que el sitio se carga sin más problemas de redireccionamiento 302 después de aplicar el parche SUPEE 9767.

Causa principal

La diferencia en el valor SCHEME entre la solicitud real y el URI después de la redirección. Por ejemplo: la solicitud real devuelve el esquema HTTP pero el esquema en el URI puede ser HTTPS.

Posibles razones subyacentes

1. Es probable que tenga una regla de redireccionamiento en el archivo .htaccess para redirigir todas las solicitudes http a https. El usuario solicita http://yourdomain.com y es posible que haya cambiado el esquema y lo haya redirigido a https: // yourdomain en lugar de http://yourdomain.com que realmente había solicitado.

2. Las URL seguras y no seguras de la base comienzan con https

El ERROR CONFIRMADO "El registro del cliente falla al finalizar la compra" ocurrió un poco diferente de mi parte.

Si el cliente elige registrarse en el proceso de pago, su contraseña no se almacena correctamente. El cliente se creó correctamente solo porque la contraseña no está almacenada. Detecté esto por el hecho de que la contraseña no se mostraba en el correo electrónico de bienvenida. La gente no puede iniciar sesión debido a esto también.

Corrección de errores vinculada en SUPEE-9767 Patch / CE 1.9.3.3 - Pago de una página - El problema de registro del cliente también ha hecho el trabajo por mí.

¿Alguien puede decirme para qué diablos ... esto es ... en supee-9767?

El parche no funciona incluso para un Magento 1.7.0.2 de vainilla.

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

incluso después de aplicar parches más antiguos manualmente.

$ 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

La solución / problema que encontré es que algunos de los cambios en el parche para 1.7.0.2 son para archivos que no existen antes de 1.9.2.3. Así que copié los siguientes archivos de una nueva instalación 1.9.2.3 antes de ejecutar el script de parche:

• app / code / core / Mage / Core / Model / File / Validator / Image.php
• app / code / core / Mage / Sales / Model / Quote / Item.php

Solo una adición a https://magento.stackexchange.com/a/176930/46249

Tenga en cuenta que los enlaces simbólicos siempre se han deshabilitado de manera predeterminada en las nuevas instalaciones de Magento admin. Los valores de configuración SÍ / NO están predeterminados en 'NO'. La actualización ahora desactiva explícitamente los enlaces simbólicos en config.xml y, como precaución adicional, también elimina la sección de plantilla de admin-> developer que contenía la opción de configuración.

Esto no afectará su configuración actual de enlaces simbólicos, si habilitó manualmente los enlaces simbólicos anteriores a 1.9.3.2, permanecerán habilitados, aunque ya no podrá ver la configuración en admin.

El texto en negrita no es correcto. Si se actualiza a 1.9.3.4 (SUPEE-9767 V2) o se eliminará la configuración actual más reciente:

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

Los administradores responsables pueden habilitar nuevamente la sección de administración del enlace simbólico buscando los cambios de diferencias en la sección de plantilla en app / code / core / Mage / Core / etc / system.xml y agregando la sección a su system.xml en la línea 600. O los enlaces simbólicos de doble verificación todavía están habilitados con

Solo hacer que la opción de configuración sea visible nuevamente no resuelve el problema. Aparece la opción, pero no puede cambiar la configuración ya que el modelo de backend recientemente introducido evita guardar el valor. Ver:

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

y

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

Entonces, debe eliminar o anular este modelo de back-end, consulte ¿Cómo habilitar los enlaces simbólicos después de la instalación de SUPEE-9767 V2?