Gsyfuy

Missing return parent::getDeleteUrl() in 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();

+        }

+    }

So far, I have come across the following issues with the SUPEE-10975 patch:

• It is not possible anymore to delete customer groups via the admin because of a missing return statement in the new method Mage_Adminhtml_Block_Customer_Group_Edit::getDeleteUrl (issue found by @mikhail-chelevich). This is the case when secret keys are enabled for the admin, which is the default. The issue is also present in 1.9.4.0. This issue is fixed by the SUPEE-11043 patch, which has not been offically released, but is available as a GitHub Gist.


• The Mage_Sendfriend module cannot be disabled without also disabling the Mage_Captcha module. Otherwise, the following core exception occurs: Module "Mage_Captcha" requires module "Mage_Sendfriend". (issue found by @zlep)


• The changes to the sendfriend/send.phtml template that have been made in the rwd/default theme are not made in the base/default theme. This means that for the base/default theme the CAPTCHA cannot be enabled, and also that names and emails of previously entered recipients are not shown on the page (for the typical case of a form submit that triggers a server-side validation error).


• The new method Mage_Sendfriend_Block_Send::getRecipientsCount introduces a PHP 7.2 incompatibility because a count is performed on a NULL value when loading the page without any recipients (which is the default on fresh page load). This issue has been fixed in 1.9.4.0.

Note that I have only checked the patch for 1.9.3.10, but I suspect the issues are present in all versions of the patch.

I ran into an issue with the 10975 patch.
After some investigation I was able to track down the answer as to where the patch was messing up and why.

To summarize the below check and make sure you patched SUPEE 9767 V2 properly.
That is the root of my issue.

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

Above is the error I hit which is specific to this file.

Mage/Core/etc/config.xml

The error comes from this line of the 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>

The version listed here doesn't match correctly because of manually patching

SUPEE 9767 v2

That patch came with this line that I missed when manually patching.

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>

Firstly, sorry for the duplicate of erej's answer, i can't comment nor edit because of my reputation score.

The patch creates a new file here : app/code/core/Zend/Controller/Request/Http.php

Which is added to override this file : lib/Zend/Controller/Request/Http.php

Problem is for Magento under 1.9.0.0 :

This method :

/**

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

}

Is overridden in Magento Core file app/code/core/Mage/Core/Controller/Request/Http.php

public function getBaseUrl()

{

    $url = parent::getBaseUrl();

    $url = str_replace('\', '/', $url);

    return $url;

}

Which does'nt take any arguments.

So it fires this strict notice on any website url, front & admin :

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

If someone knows if any V2 of that patch is on the way, please let me know.

Waiting for their update, you can redefine method in app/code/core/Mage/Core/Controller/Request/Http.php like that:

/**

 * @param bool $raw - Added manually to correct SUPEE-10975 oversight

 *      See https://magento.stackexchange.com/questions/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;

}

With version 1.8.1.0 after applying this patch we also had to change
app/code/core/Mage/Core/Controller/Request/Http.php::getBaseUrl() function
to be

public function getBaseUrl($raw = false)

{

    $url = parent::getBaseUrl($raw);

    $url = str_replace('\', '/', $url);

    return $url;

}

because this patch adds app/code/core/Zend/Controller/Request/Http.php file and getBaseUrl() function is declared with parameter $raw = false.

I have a problem with 'Hunk #1 FAILED at 28'

Rejects are supposedly saved to config.xml.rej but this file doesn't exist, neither is there any description of what part of the script failed in my terminal window. Basically the patch fails and there is no indication why - at least not to a dumbass like me!

On first run the patch attempted to delete three jquery v 1.12.0 files which didn't exist, I replaced these and applied the patch again but it now fails without any useful description.

Magento 1.9.0.1 fully patched apart from the PHP 7.2 compatibility update, it will remain unpatched unless I can work it out or someone on here can give me a clue (please!)
Thanks
H

PS I'm not sure if my post contravenes SE guidelines, I am answering the original question but I'm also asking for help.

The Mage_Backup Module will be disabled by the patch.

This is mentioned in the official release notes (https://devdocs.magento.com/guides/m1x/ce19-ee114/ce1.9_release-notes.html#ce19-1940).

However the suggested solution to re-enable it is wrong:

("Alternatively, you can use one of these two methods to enable database backups")

You actually need to use both methods mentioned to fully re-enable it.

Specific problem, but if you disabled Mage_Sendfriend (which previously was a module you could safely disable) it will throw an exception error.

There can be issues with handling tax calculation correctly.

As is customary in many countries, our customer uses the "prices include taxes" configuration of Magento.

So, after the update from 1.9.3.10 to 1.9.4.0, the tax got added to the grand total in checkout, on top of the item prices already including taxes.

I tracked the issue down to a change in the configuration in file app/code/core/Mage/Sales/etc/config.xml, where "msrp" was added to the node sales/quote/totals/shipping/after.

I did not find anything regarding MSRP in the release notes and I hope that this is an isolated change without any side-effects.

My solution was to change this node back to its original value "subtotal,freeshipping,tax_subtotal" without the "msrp". I did so in the etc/config.xml of my own module.

I tried to upgrade from Magento CE 1.9.3.10 to 1.9.4.0 today and I had multiple errors. Fortunately it didn't mess up the installation. After the installation I got the dreaded - Internal Server Error. I did get locked out and I had to reset all of my file and folder permissions via SSH along with removing the maintenance.flag. I then reindexed and re-enabled the cache. Plus I had to revert to my old .htaccess file in the Root and Download folder. Not sure what the corrective action should be to get a successful installation. I forgot to copy the text from the command-line window. So I can't post all the errors. What I did see was incompatible messages.

Did they remove Scheduled Backup?

Or I have some kind of a problem? Why is there no mention of this in any of the notes? This seems to be a pattern with Magento where they dont mention changes like these when updates come out.

UPDATE: looks like they removed it completely from all versions.

UPDATE: had to do backups differently. If anybody interested I posted some of the CRON commands here: Back-up strategy post SUPEE-10975?

We saw an issue on a site that was using a custom multi-store configuration by a previous developer. All URLs for stores other than the base store were 404ing. It set the "HTTP_X_REWRITE_URL" server variable/HTTP Header, which changed the URL as processed by the Magento Request.

This variable is/was used by Zend_Controller_Request_Http::setRequestUri(), but the new version in app/code/core/Zend/Controller/Request/Http.php no longer uses this. The possible fixes were:

• Set $_SERVER["IIS_WasUrlRewritten"] to '1' and instead set $_SERVER["UNENCODED_URL"]


• Set $_SERVER["REQUEST_URI"] instead

Either would probably work, but the former is probably less likely to have unintended consequences as it functions closer to the previous system.