SUPEE-10975 a été publié, il serait bon de savoir si quelqu'un rencontre des problèmes en essayant de l'appliquer, est-ce que cela entrera en conflit avec le dernier patch qui ajoute le support 7.2?

Jusqu'à présent, ce sont les fichiers modifiés que je peux voir

app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
app/code/core/Mage/Adminhtml/Block/Newsletter/Template/Edit.php
app/code/core/Mage/Adminhtml/controllers/Cms/BlockController.php
app/code/core/Mage/Adminhtml/controllers/Customer/GroupController.php
app/code/core/Mage/Adminhtml/controllers/SitemapController.php
app/code/core/Mage/Adminhtml/controllers/System/BackupController.php
app/code/core/Mage/Captcha/Model/Observer.php
app/code/core/Mage/Captcha/Model/Zend.php
app/code/core/Mage/Captcha/etc/config.xml
app/code/core/Mage/Catalog/Model/Api2/Product/Image/Rest/Admin/V1.php
app/code/core/Mage/Catalog/Model/Product/Attribute/Media/Api.php
app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
app/code/core/Mage/Core/etc/config.xml
app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.7.1.1-1.6.0.7.1.2.php
app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
app/code/core/Mage/ImportExport/Model/Import/Entity/Customer.php
app/code/core/Mage/ImportExport/Model/Import/Entity/Customer/Address.php
app/code/core/Mage/Payment/etc/config.xml
app/code/core/Mage/Payment/etc/system.xml
app/code/core/Mage/Payment/sql/payment_setup/upgrade-1.6.0.0.1.1-1.6.0.0.1.2.php
app/code/core/Mage/Sendfriend/Block/Send.php
app/code/core/Mage/Wishlist/controllers/IndexController.php
app/code/core/Zend/Controller/Request/Http.php
app/design/adminhtml/default/default/template/cms/browser/content/files.phtml
app/design/frontend/base/default/layout/captcha.xml
app/design/frontend/base/default/template/wishlist/sharing.phtml
app/design/frontend/rwd/default/layout/page.xml
app/design/frontend/rwd/default/template/sendfriend/send.phtml
app/etc/modules/Mage_All.xml
app/etc/modules/Mage_Captcha.xml
app/locale/en_US/Mage_Wishlist.csv
js/lib/jquery/jquery-1.12.0.js
js/lib/jquery/jquery-1.12.0.min.js
js/lib/jquery/jquery-1.12.0.min.map
js/lib/jquery/jquery-1.12.1.js
js/lib/jquery/jquery-1.12.1.min.js
js/lib/jquery/jquery-1.12.1.min.map

Quelqu'un a-t-il rencontré des problèmes avec ces changements?

Jusqu'à présent, j'ai rencontré les problèmes suivants avec le correctif SUPEE-10975:

• Il n'est plus possible de supprimer des groupes de clients via l'administrateur en raison d'une déclaration de retour manquante dans la nouvelle méthode Mage_Adminhtml_Block_Customer_Group_Edit::getDeleteUrl (problème trouvé par @ mikhail-chelevich). C'est le cas lorsque les clés secrètes sont activées pour l'administrateur, ce qui est la valeur par défaut. Le problème est également présent dans 1.9.4.0. Ce problème est résolu par le correctif SUPEE-11043, qui n'a pas été officiellement publié, mais est disponible sous forme de GitHub Gist .
• Le Mage_Sendfriendmodule ne peut pas être désactivé sans désactiver également leMage_Captcha module. Sinon, l'exception principale suivante se produit: Module "Mage_Captcha" requires module "Mage_Sendfriend".(problème trouvé par @zlep)
• Les modifications apportées au sendfriend/send.phtmlmodèle qui ont été apportées dans le rwd/defaultthème ne sont pas apportées dans lebase/default thème. Cela signifie que pour le base/defaultthème, le CAPTCHA ne peut pas être activé, et également que les noms et les e-mails des destinataires précédemment saisis ne sont pas affichés sur la page (pour le cas typique d'une soumission de formulaire qui déclenche une erreur de validation côté serveur).
• La nouvelle méthode Mage_Sendfriend_Block_Send::getRecipientsCountintroduit une incompatibilité PHP 7.2 car un countest effectué sur unNULL valeur lors du chargement de la page sans aucun destinataire (ce qui est la valeur par défaut lors du chargement d'une nouvelle page). Ce problème a été corrigé dans 1.9.4.0.

Notez que je n'ai vérifié le correctif que pour la version 1.9.3.10, mais je soupçonne que les problèmes sont présents dans toutes les versions du correctif.

Manquant return parent::getDeleteUrl()dans app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php

+    public function getDeleteUrl()
+    {
+        if (!Mage::getSingleton('adminhtml/url')->useSecretKey()) {
+            return $this->getUrl('*/*/delete', array(
+                $this->_objectId => $this->getRequest()->getParam($this->_objectId),
+                'form_key' => Mage::getSingleton('core/session')->getFormKey()
+            ));
+        } else {
+            parent::getDeleteUrl();
+        }
+    }

J'ai rencontré un problème avec le patch 10975. Après une enquête, j'ai été en mesure de trouver la réponse quant à savoir où le patch était en panne et pourquoi.

Pour résumer la vérification ci-dessous et assurez-vous d' avoir correctement corrigé SUPEE 9767 V2 . C'est la racine de mon problème.

sh PATCH_SUPEE-10975_EE_v1.12.0.2_v1-2018-11-27-10-36-30.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file app/code/core/Enterprise/PageCache/Model/Processor.php
Hunk #1 succeeded at 690 (offset -3 lines).
patching file app/code/core/Enterprise/Pci/etc/config.xml
patching file app/code/core/Enterprise/Wishlist/Block/Customer/Sharing.php
patching file app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
patching file app/code/core/Mage/Adminhtml/Block/Newsletter/Template/Edit.php
patching file app/code/core/Mage/Adminhtml/controllers/Cms/BlockController.php
patching file app/code/core/Mage/Adminhtml/controllers/Customer/GroupController.php
patching file app/code/core/Mage/Adminhtml/controllers/SitemapController.php
patching file app/code/core/Mage/Adminhtml/controllers/System/BackupController.php
patching file app/code/core/Mage/Captcha/Model/Observer.php
patching file app/code/core/Mage/Captcha/Model/Zend.php
patching file app/code/core/Mage/Captcha/etc/config.xml
patching file app/code/core/Mage/Catalog/Model/Api2/Product/Image/Rest/Admin/V1.php
patching file app/code/core/Mage/Catalog/Model/Product/Attribute/Media/Api.php
patching file app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
patching file app/code/core/Mage/Core/etc/config.xml
Hunk #1 FAILED at 28.
1 out of 3 hunks FAILED -- saving rejects to file app/code/core/Mage/Core/etc/config.xml.rej
patching file app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.2.1.2-1.6.0.2.1.3.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
patching file app/code/core/Mage/ImportExport/Model/Import/Entity/Customer.php
patching file app/code/core/Mage/ImportExport/Model/Import/Entity/Customer/Address.php
patching file app/code/core/Mage/Payment/etc/config.xml
patching file app/code/core/Mage/Payment/etc/system.xml
patching file app/code/core/Mage/Payment/sql/payment_setup/upgrade-1.6.0.0.1.1-1.6.0.0.1.2.php
patching file app/code/core/Mage/Wishlist/controllers/IndexController.php
patching file app/code/core/Zend/Controller/Request/Http.php
patching file app/design/adminhtml/default/default/template/cms/browser/content/files.phtml
patching file app/design/adminhtml/default/default/template/enterprise/cms/page/preview/revision.phtml
patching file app/design/adminhtml/default/default/template/enterprise/customersegment/report/detail/grid/container.phtml
patching file app/design/adminhtml/default/default/template/enterprise/giftregistry/customer/form.phtml
patching file app/design/adminhtml/default/default/template/enterprise/staging/log/information/merge.phtml
patching file app/design/adminhtml/default/default/template/enterprise/staging/log/information/rollback.phtml
patching file app/design/frontend/base/default/layout/captcha.xml
patching file app/design/frontend/base/default/template/wishlist/sharing.phtml
patching file app/design/frontend/enterprise/iphone/template/downloadable/sales/order/creditmemo/items/renderer/downloadable.phtml
patching file app/etc/modules/Mage_All.xml
patching file app/etc/modules/Mage_Captcha.xml
patching file app/locale/en_US/Enterprise_Wishlist.csv
patching file app/locale/en_US/Mage_Wishlist.csv
patching file js/enterprise/adminhtml/staging.js

Ci-dessus, l'erreur que j'ai rencontrée qui est spécifique à ce fichier.

Mage / Core / etc / config.xml

L'erreur vient de cette ligne du patch.

diff --git app/code/core/Mage/Core/etc/config.xml app/code/core/Mage/Core/etc/config.xml
index 4aebdcdc2cf..4b28f2765a1 100644
--- app/code/core/Mage/Core/etc/config.xml
+++ app/code/core/Mage/Core/etc/config.xml
@@ -28,7 +28,7 @@
 <config>
     <modules>
         <Mage_Core>
-            <version>1.6.0.2.1.2</version>
+            <version>1.6.0.2.1.3</version>
         </Mage_Core>
     </modules>
     <global>

La version répertoriée ici ne correspond pas correctement en raison des correctifs manuels

SUPEE 9767 v2

Ce patch est venu avec cette ligne que j'ai manquée lors du patch manuel.

diff --git app/code/core/Mage/Core/etc/config.xml app/code/core/Mage/Core/etc/config.xml
index 4a0ff1b..d0de702 100644
--- app/code/core/Mage/Core/etc/config.xml
+++ app/code/core/Mage/Core/etc/config.xml
@@ -28,7 +28,7 @@
 <config>
     <modules>
         <Mage_Core>
-            <version>1.6.0.2</version>
+            <version>1.6.0.2.1.2</version>
         </Mage_Core>
     </modules>
     <global>

Tout d'abord, désolé pour le double de la réponse d' erej , je ne peux pas commenter ni modifier à cause de mon score de réputation.

Le patch crée un nouveau fichier ici: app/code/core/Zend/Controller/Request/Http.php

Qui est ajouté pour remplacer ce fichier: lib/Zend/Controller/Request/Http.php

Le problème est pour Magento sous 1.9.0.0 (EE 1.14.0.0):

Cette méthode :

/**
 * Everything in REQUEST_URI before PATH_INFO
 * <form action="<?=$baseUrl?>/news/submit" method="POST"/>
 *
 * @return string
 */
public function getBaseUrl($raw = false)
{
    if (null === $this->_baseUrl) {
        $this->setBaseUrl();
    }

    return (($raw == false) ? urldecode($this->_baseUrl) : $this->_baseUrl);
}

Est remplacé dans le fichier Magento Core app/code/core/Mage/Core/Controller/Request/Http.php

public function getBaseUrl()
{
    $url = parent::getBaseUrl();
    $url = str_replace('\\', '/', $url);
    return $url;
}

Ce qui ne prend aucun argument.

Il déclenche donc cette notification stricte sur n'importe quelle URL de site Web, avant et administrateur:

Strict Notice: Declaration of Mage_Core_Controller_Request_Http::getBaseUrl() should be compatible with Zend_Controller_Request_Http::getBaseUrl($raw = false) in /var/www/htdocs/app/code/core/Mage/Core/Controller/Request/Http.php on line 36

Si quelqu'un sait si une version V2 de ce patch est en cours, faites-le moi savoir.

En attendant leur mise à jour, vous pouvez redéfinir la méthode app/code/core/Mage/Core/Controller/Request/Http.phpcomme ceci:

/**
 * @param bool $raw - Added manually to correct SUPEE-10975 oversight
 *      See /magento/251317/supee-10975-potential-issues
 *      for more information
 *
 * @return mixed|string
 */
public function getBaseUrl($raw = false)
{
    $url = parent::getBaseUrl($raw); // Argument added manually to correct SUPEE-10975 oversight
    $url = str_replace('\\', '/', $url);
    return $url;
}

Avec la version 1.8.1.0 après avoir appliqué ce patch, nous avons également dû changer de app/code/core/Mage/Core/Controller/Request/Http.php::getBaseUrl()fonction pour

public function getBaseUrl($raw = false)
{
    $url = parent::getBaseUrl($raw);
    $url = str_replace('\\', '/', $url);
    return $url;
}

car ce patch ajoute un app/code/core/Zend/Controller/Request/Http.phpfichier et la getBaseUrl()fonction est déclarée avec le paramètre $raw = false.

J'ai un problème avec 'Hunk # 1 FAILED at 28'

Les rejets sont censés être enregistrés dans config.xml.rej mais ce fichier n'existe pas, il n'y a pas non plus de description de la partie du script qui a échoué dans ma fenêtre de terminal. Fondamentalement, le patch échoue et rien n'indique pourquoi - du moins pas à un imbécile comme moi!

Lors de la première exécution, le correctif a tenté de supprimer trois fichiers jquery v 1.12.0 qui n'existaient pas, je les ai remplacés et j'ai appliqué le correctif à nouveau, mais il échoue maintenant sans aucune description utile.

Magento 1.9.0.1 entièrement corrigé en dehors de la mise à jour de compatibilité PHP 7.2, il restera non corrigé à moins que je puisse le travailler ou que quelqu'un ici puisse me donner un indice (s'il vous plaît!) Merci H

PS Je ne suis pas sûr que mon article contrevienne aux directives SE, je réponds à la question d'origine mais je demande aussi de l'aide.

Le Mage_Backupmodule sera désactivé par le patch.

Ceci est mentionné dans les notes de version officielles ( https://devdocs.magento.com/guides/m1x/ce19-ee114/ce1.9_release-notes.html#ce19-1940 ).

Cependant, la solution suggérée pour la réactiver est erronée:

("Vous pouvez également utiliser l' une de ces deux méthodes pour activer les sauvegardes de base de données")

Vous devez réellement utiliser les deux méthodes mentionnées pour le réactiver complètement.

Il peut y avoir des problèmes avec la gestion correcte du calcul de la taxe .

Comme il est d'usage dans de nombreux pays, notre client utilise les " prix TTC configuration " de Magento.

Ainsi, après la mise à jour du 1.9.3.10 au 1.9.4.0, la taxe a été ajoutée au grand total lors du paiement, en plus des prix des articles comprenant déjà les taxes.

J'ai suivi le problème jusqu'à un changement de configuration dans le fichier app / code / core / Mage / Sales / etc / config.xml , où " msrp " a été ajouté au nœud sales / quote / totals / shipping / after .

Je n'ai rien trouvé concernant MSRP dans les notes de version et j'espère qu'il s'agit d'un changement isolé sans aucun effet secondaire.

Ma solution a été de redonner à ce nœud sa valeur d'origine " sous-total, livraison gratuite, sous-total tax " sans le " msrp ". Je l'ai fait dans le fichier etc / config.xml de mon propre module.

Problème spécifique, mais si vous avez désactivé Mage_Sendfriend (qui était auparavant un module que vous pouviez désactiver en toute sécurité), il générera une erreur d'exception.

J'ai essayé de passer de Magento CE 1.9.3.10 à 1.9.4.0 aujourd'hui et j'ai eu plusieurs erreurs. Heureusement, cela n'a pas gâché l'installation. Après l'installation, j'ai eu la redoutée - Erreur de serveur interne. J'ai été verrouillé et j'ai dû réinitialiser toutes mes autorisations de fichiers et de dossiers via SSH et supprimer le fichier maintenance.flag. J'ai ensuite réindexé et réactivé le cache. De plus, je devais revenir à mon ancien fichier .htaccess dans le dossier Root and Download. Vous ne savez pas quelle doit être l'action corrective pour réussir l'installation. J'ai oublié de copier le texte de la fenêtre de ligne de commande. Je ne peux donc pas publier toutes les erreurs. J'ai vu des messages incompatibles.

Ont-ils supprimé la sauvegarde planifiée?

Ou j'ai un problème? Pourquoi n'y a-t-il aucune mention de cela dans aucune des notes? Cela semble être un modèle avec Magento où ils ne mentionnent pas de changements comme ceux-ci lorsque les mises à jour sortent.

MISE À JOUR: on dirait qu'ils l'ont complètement supprimé de toutes les versions.

MISE À JOUR: a dû faire les sauvegardes différemment. Si quelqu'un est intéressé, j'ai posté certaines des commandes CRON ici: Message de stratégie de sauvegarde SUPEE-10975?

Nous avons vu un problème sur un site qui utilisait une configuration multi-magasins personnalisée par un développeur précédent. Toutes les URL des magasins autres que le magasin de base étaient 404ing. Il a défini la variable serveur / HTTP HTTP "HTTP_X_REWRITE_URL", qui a changé l'URL telle que traitée par la demande Magento.

Cette variable est / était utilisée par \ Zend_Controller_Request_Http :: setRequestUri (), mais la nouvelle version dans app / code / core / Zend / Controller / Request / Http.php ne l'utilise plus. Les correctifs possibles étaient:

• Réglez $ _SERVER ["IIS_WasUrlRewritten"] sur '1' et définissez plutôt $ _SERVER ["UNENCODED_URL"]
• Définissez $ _SERVER ["REQUEST_URI"] à la place

L'un ou l'autre fonctionnerait probablement, mais le premier est probablement moins susceptible d'avoir des conséquences inattendues car il fonctionne plus près du système précédent.

Une erreur spécifique avec la méthode de paiement n'est pas disponible

Nous avons eu beaucoup d' The requested Payment Method is not availableerreurs lancées par Magento. Tout sur les commandes où le mode de paiement dans le retour du produit était ccsave, ce qui a été supprimé par ce supee en config.xml.

L'erreur est lancée parce que Magento est à la recherche d'un $keyen vérifiant les chemins xml (dans ce cas , le mode de paiement ccsave): payment/ccsave/model. S'il ne le trouve pas, il lance une erreur. Nous avons donc fait un git checkout [insert supee commit]^ app/code/core/Mage/Payment/etc/config.xmlet poussé à maîtriser pour corriger l'erreur.

app / code / core / Mage / Payment / Helper / Data.php

public function getMethodInstance($code)
{
    $key = self::XML_PATH_PAYMENT_METHODS.'/'.$code.'/model';
    $class = Mage::getStoreConfig($key);
    return Mage::getModel($class);
}

app / code / core / Mage / Payment / etc / config.xml

<default>
  <payment>
      <ccsave>
        <model>payment/method_ccsave</model>
      </ccsave>
  </payment>
  ...
</default>

Changement de app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.phpcause (un autre) bogue que les vignettes ne sont pas générées correctement ... détails 1.9.4 vignettes non générées correctement dans le répertoire média

Probablement pas, mais la version 1.9.4.0 a déjà été implémentée de toute façon.