The latest Magento 1 security patch SUPEE-8788 contains 17 APPSEC updates, so it is very important to apply it as soon as possible. On the other hand, there are many potential backward compatibility breaks, and given the history of patches over the last year I would not apply it carelessly.

Good thing is that this time there are no frontend templates involved, so it looks like we don't need to patch all our themes. This is only true for Magento 1.8 or higher.

Nonetheless: Did you encounter any compatibility problems or bugs after applying the patch?

  • 5
    "there are no frontend templates involved" - is not correct for older Magento versions. For example the 1.7.0.2 patch changes 9 frontend/base/default template files . – Kristof at Fooman Oct 13 '16 at 2:42
  • magento.stackexchange.com/questions/140571/… dupes this one? Maybe bundle all the info here... – 7ochem Oct 13 '16 at 8:44
  • 2
    For anyone having problems with the .swf updates of the patch, I simply removed lines 5951-9818 from the patch and manually removed the .swf files from /skin/adminhtml/default/default/media - since that's all the patch was doing anyway. – Liam McArthur Oct 13 '16 at 9:40
  • not sure why but after 8788 installation on 1.8.0.0 , patch 7405 reports as NOT installed. while v1 and v1.1 was previously installed – MagenX Oct 13 '16 at 12:19
  • 2
    @srinivas did you removed the media folder from this path skin/adminhtml/default/default ? – Priya Ponnusamy Nov 15 '16 at 13:03

30 Answers 30

Important notes

Please note that 1.9.3 is different than 1.9.2.4 + SUPEE-8788. Here's the diff between the two: https://gist.github.com/digitalpianism/14a15cd52baede0e5d600e8c653f33e9

Update October 14th: v2 of the patch has been released (see below) As of October 13th, the patches for 1.5.x to 1.8.x have been taken down from the Magento website because of the incompatibility with previous patches (see below):

https://community.magento.com/t5/Security-Patches/SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error/td-p/50434/highlight/false/page/2

V3 of the patch

This new version is only for Magento EE 1.13.0.x

Apply the V3:

  • revert SUPEE 1533 (if installed)
  • install SUPEE 3941 (if not installed)
  • install SUPEE 8788 v3

V2 of the patch

Apply the V2:

  • revert SUPEE 8788 v1
  • revert SUPEE 1533 (if installed)
  • install SUPEE 3941 (if not installed)
  • install SUPEE 8788 v2

DemacMedia developed a useful bash script to automate the process above you can find it here: https://github.com/DemacMedia/magento-SUPEE8788-patcher

Details of the patch

After digging into the patch here are the interesting parts (patching from 1.9.2.4):

  • Mage_Adminhtml_Block_Media_Uploader has been replaced with Mage_Uploader_Block_Multiple so there's a full Mage_Uploader module which drops Flash support. The old block is now deprecated and extends the new block.
  • Still regarding the uploader, the Mage_Downloadable module has been refactored to handle the new non-flash uploader. It uses Mage_Uploader_Block_Single as the upload block instead of using templates.
  • Following this change, the SWF files skin/adminhtml/default/default/media/flex.swf, skin/adminhtml/default/default/media/uploader.swf and skin/adminhtml/default/default/media/uploaderSingle.swf have been deleted.
  • Address deletion controller is now protected with form key directly via the getDeleteUrl from Mage_Customer_Block_Address_Book
  • Wishlist item removal controller is now protected with form key via the getRemoveUrl from Mage_Wishlist_Helper_Data
  • Paypal Express payment method now ensures that the customer email used exists in Magento when checking out and registering a new user. (understand: the new user is created before the new quote is processed)
  • The payment methods using cURL/HTTP Client now have CURLOPT_SSL_VERIFYHOST set to 2 (was 0 before) and the CURLOPT_SSL_VERIFYPEER flag is now added to the cURL calls. The Verify Peer flag can be enable/disable via the payment method configuration via the Enable SSL Verification dropdown.
  • Mage_Http_Client_Curl now has CURLOPT_SSL_VERIFYPEER set to true (was false before), beware if you have any custom module using it.
  • Max dimensions for product pictures are now configurable in the config. NB: it can result in a funny error message if you upload too big images: Disallowed file format in Magento 1.9.2.2 after patch upload

Known SUPEE-8788 v2 issues

Known SUPEE-8788 v1 issues

Known 1.9.3.0 issues

Edit: as the list is getting long and it's pretty much off-topic in this answer (as not SUPEE-8788 related) you can refer to this post for the list of known 1.9.3.0 issues: https://magento.stackexchange.com/a/140826/2380

  • 1
    Thanks for the extensive list! One question: are you sure that the fulltext search issue applies to the SUPEE-8788 patch? I can't find any changes related to this functionality. – Aad Mathijssen Oct 13 '16 at 12:52
  • 1
    @MageDev please refer to the third comment in the question ;) – Raphael at Digital Pianism Oct 13 '16 at 12:54
  • 1
    @RaphaelatDigitalPianism it's worked thanks – MageDev Oct 13 '16 at 13:04
  • 1
    If the product uploader does not work after successfully applying the patch and you are using the popular CreareSEO plugin then this fix will need to be applied also github.com/adampmoss/CreareSEO/pull/78 – joesk Oct 13 '16 at 14:18
  • 1
    I noticed you mentioned "Paypal Express payment method now ensures that the customer email used exists in Magento." Does that mean that Guest cannot checkot with PayPal express? You must be registered user? Am I missing something. – Icon Oct 13 '16 at 15:35

When applying the patch this error can happen:

checking file skin/adminhtml/default/default/media/flex.swf
checking file skin/adminhtml/default/default/media/uploader.swf
checking file skin/adminhtml/default/default/media/uploaderSingle.swf
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
checking file skin/adminhtml/default/default/xmlconnect/boxes.css

The 8788 patch contains binary content. As Magento does not provide any direct download links (I hate this policy ever since), you have to download the patch to your computer and upload it with an file-transfer application (like WinSCP on Windows) to your server. WinSCP for example will upload in TEXT-mode (WinSCP handles *.sh files as text by default).

So the workaround for this is, zip/tar the patch-file and unzip/untar again on the server. et voila.


Sorry I didn't have any way to answer this

  1. Download the correct magento version (Eg: CE 1.9.1.0)
  2. Replace the following files with downloaded location

skin/adminhtml/default/default/media/flex.swf skin/adminhtml/default/default/media/uploader.swf skin/adminhtml/default/default/media/uploaderSingle.swf

  1. Run the patch

Worked for me


  • 10
    Did you read the OPs question? fschmengler asked: "Nonetheless: Did you encounter any compatibility problems or bugs AFTER applying the patch?" I did encounter this problem WHILE applying the patch. I guess the sense of this thread is, to document the possible errors of SUPEE-8788. This includes - IMHO - problems with the patch itself too. – infabo Oct 13 '16 at 9:19
  • Worked a treat, thanks! Is it best to do this for ALL future Magento patches too? – KiwisTasteGood Oct 13 '16 at 11:39
  • or you just dos2unix PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh – fbtb Oct 13 '16 at 11:56
  • Generally it was not necessary before and I assume it will not be necessary in the future. I guess the uploader SWFs were the only binaries shipped with Magento 1.x - now they are gone. So I do not expect any issues like this one in the future again. – infabo Oct 13 '16 at 11:56
  • 3
    When using FileZilla to upload the .sh patch file to your Magento root, set transfer type to binary before uploading the patch file. Reference – ForMat Oct 15 '16 at 7:17

If you've previously applied SUPEE-1533 then the patch will fail on app/code/core/Mage/Adminhtml/controllers/DashboardController.php.

I solved this by...

  1. Manually revert the changes introduced to that file by SUPEE-1533
  2. Apply SUPEE-8788
  3. Manually reintroduce the changes introduced to that file by SUPEE-1533

Removing the change from the SUPEE-8788 is dangerous because the patch file contains binary data and saving it in an editor can cause issues (another gotcha).

  • As I understand you reverted the original 1533 patch, installed SUPEE 8788, and then again installed 1533?? Do I understand correctly? – Icon Oct 12 '16 at 22:29
  • I am also having issue with FAILED HUNK at 28 app/design/frontend/base/default/template/review/form.phtml – Icon Oct 12 '16 at 22:44
  • 9
    I do wonder why, when we take the time to properly apply official incremental patches, we get penalised for doing so by having to make manual fixes when patches do not work when previously supplied patches have been applied. A very odd approach. – Jon Holland Oct 13 '16 at 10:54
  • 1
    Most with versions below 1.9 that have SUPEE 1533 Installed, cannot instal the patch properly. SUPEE 8788 is not compatible with 1533 – Icon Oct 13 '16 at 13:56
  • 2
    @JonHolland Because, well, it's Magento. – Agop Oct 17 '16 at 2:11
up vote 22 down vote accepted

Here's a summary of what I (and others) encountered so far, I'm trying to keep it sorted, feel free to add or link anything that's missing, the post is a Community Wiki:

Reasons for failed patch

If you see "ERROR: Patch can't be applied/reverted successfully", look for "Hunk #1 FAILED" in the log messages to check at which file the patch failed.

  • Apparently v2 of the patch for Magento 1.7 expects SUPEE-3941 to present although it only exists for Magento 1.8 and 1.9. If you are on Magento 1.7 and see errors related to files in downloader, download SUPEE-3941 for 1.8 and apply it on 1.7, it should work. See comment thread here: Security Patch SUPEE 8788 problem
  • On Magento versions that have had SUPEE-1533 applied before, the patch fails at app/code/core/Mage/Adminhtml/controllers/DashboardController.php because the file is affected by both patches and SUPEE-8788 (incorrectly!) assumes that the unpatched version is present. This is still true with version 2 of the patch! Version 2 includes the changes from SUPEE-1533, so if you installed it before, you still have to revert it, but you don't have to manually apply it again afterwards.

  • If you deleted or renamed the "downloader" directory, the patch will fail because it patches a file within the downloader. The easiest workaround is to restore the original downloader directory, apply the patch, then delete the directory again. Alternatively, you could also remove the instructions for downloader/lib/Mage/HTTP/Client/Curl.php from the patch.

  • Other "Hunk FAILED" messages are usually due to changes in core files or missing previous patches. Make sure all previous patches for your Magento version are installed and you did not make changes in core files.

  • Another common problem is that the patch fails to delete .swf files because of their binary content. The error will look like this:

    checking file skin/adminhtml/default/default/media/uploaderSingle.swf
    Reversed (or previously applied) patch detected!  Assume -R? [n]
    Apply anyway? [n]
    Skipping patch.
    1 out of 1 hunk ignored
    

    or like this

    Patching file skin/adminhtml/default/default/media/uploader.swf using Plan A...
    No such line 2 in input file, ignoring
    Empty context always matches.
    Hunk #1 failed at 0.
    1 out of 1 hunks failed while patching skin/adminhtml/default/default/media/uploader.swf
    Hmm...  The next patch looks like a unified diff to me...
    The text leading up to this was:
    --------------------------
    

    or like this:

    Checking if patch can be applied/reverted successfully...
    /bin/patch: **** malformed patch at line 5790: ?rM]M??????&X㔮??v??Q;r?N?qJ??Y???I0?Y??4??'?????9?.??X?Ǒ?{??ax!G???I???q?u|????թ??????|
                                                   h??o?V@??|? ?g?H aꪭ??Ю???,I"?ğ????.??    yI?I\????)?X?
                         ?p???*?e?q?K8<DqD?H;|?
    ERROR: Patch can't be applied/reverted successfully.
    

    Possible solutions are given in this answer by @infabo. Downloading the patch directly to the system where I want to apply it, using curl as explained in https://gist.github.com/piotrekkaminski/9bc45ec84028611d621e always worked for me, except when I tried it on Cygwin

Advanced way to deal with failed patches: @PeterOCallaghan suggested to comment out the dry-run line and manually deal with the *.rej files. This way the patch can partially be applied and if it fails to delete the swf files, you can do that manually. Or if it fails to update files in downloader because you deleted that directory, you can just ignore that.

  1. vi PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh (or similar file name) change _apply_revert_patch dry-run to look like #_apply_revert_patch dry-run

  2. run the patch by issuing ./PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh

That will patch your files

  1. Comment _apply_revert_patch to #_apply_revert_patch

  2. run the patch again, to add the app/etc/app/etc/applied.patches.list entry

  3. grep for all .rej files with

    git status | grep *.rej

  4. manually work in those changes

Issues after applying patch

Form keys

  • For Magento versions prior to 1.8 there are changes in frontend/base/default templates. Make sure that you manually apply the same changes in your theme if it overrides these files

    More specifically, a form key has been added for frontend actions such as:

    • Removing an item from the wishlist
    • Deleting a customers address from the store view
    • Updating a quote item in your basket

    See this answer by @LukeRogers if you encounter problems with these actions.

Custom uploader

Unirgy_Rapidflow and other extensions with custom upload forms are not working anymore.

See this answer by @mpchadwick and comment by @lloiacono

I fixed it by replacing $this->getUploader()->getConfig() with $this->getUploader()->getUploaderConfig() in Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload

To find out if any of your extensions use this, you can run the following on the command line:

grep -R 'getUploader()->getConfig();' app/code/community

Reported error messages

  • PHP Fatal error: Call to undefined function hash_equals()

    happens if you are on a PHP version prior to 5.6 and override code/core/Mage/core/functions.php in code/local/Mage/core/functions.php (which might be the case if you use Fishpig extensions). See this answer by @ClaudiuCreanga


Problems solved in v2 of the patch

If you encounter any of these issues, you probably use version 1 of the patch ("v1" in the filename). Download the patch again to get "v2" which fixes these issues:

  • There was a compatibility issue with SUPEE-3941 and downloader/lib/Mage/HTTP/Client/Curl.php

  • 'Exception' with message 'Unsupported data type N' in /lib/Unserialize/Reader/ArrValue.php

  • The patch for EE 1.14.2.0 accidently contained a new file test_oauth.php which you should delete! See this answer by @MatthiasZeis

  • Form key added when updating quote item in the basket is not something that has been added with SUPEE-8788 (not from 1.9.2.4 at least) – Raphael at Digital Pianism Oct 13 '16 at 14:50
  • @RaphaelatDigitalPianism at the very least the 1.13.0.1 patch adds form key validation to Mage_Checkout_CartController::updatePostAction, potentially other patch versions as well. – Luke Rodgers Oct 22 '16 at 14:25

If you get

Call to undefined function hash_equals() error

even if your patch was successful then it may mean that you have copied functions.php in app/code/local/Mage/Core.

You will have to insert that function there too because that file overwrites the core one.

So insert in app/code/local/Mage/Core/functions.php at the end:

if (!function_exists('hash_equals')) {
    /**
     * Compares two strings using the same time whether they're equal or not.
     * A difference in length will leak
     *
     * @param string $known_string
     * @param string $user_string
     * @return boolean Returns true when the two strings are equal, false otherwise.
     */
    function hash_equals($known_string, $user_string)
    {
        $result = 0;

        if (!is_string($known_string)) {
            trigger_error("hash_equals(): Expected known_string to be a string", E_USER_WARNING);
            return false;
        }

        if (!is_string($user_string)) {
            trigger_error("hash_equals(): Expected user_string to be a string", E_USER_WARNING);
            return false;
        }

        if (strlen($known_string) != strlen($user_string)) {
            return false;
        }

        for ($i = 0; $i < strlen($known_string); $i++) {
            $result |= (ord($known_string[$i]) ^ ord($user_string[$i]));
        }

        return 0 === $result;
    }
}
  • 1
    Offhand I know that Fishpig requires you to do this. So if you have that installed this will be an issue for you. – mpchadwick Oct 13 '16 at 12:09
  • 1
    Note: I was confused and it is MWI that asks you to override functions.php, not Fishpig mwi-plugin.com/documentation/installation – mpchadwick Oct 21 '16 at 13:28

In PATCH_SUPEE-8788_EE_1.14.2.0_v1-2016-10-10-02-27-03.sh, a file test_oauth.php is created in the Magento root directory. You will want to delete this one (or at least not deploy it to production) because it could expose a complete exception stack trace to the person calling the URL https://thedomain.tld/test_oauth.php.

  • Nice catch, Matthias! Would be somewhat bad form to deploy 17 APPSEC patches and open up another vector at the same time. Did you report this to Magento yet? – Bryan 'BJ' Hoffpauir Jr. Oct 13 '16 at 15:22
  • I did open a ticket about this with Magento Support, as I'm sure others have at this point. Haven't heard back about a v2 version of the patch, but they should be aware of the issue. – quasiobject Oct 13 '16 at 16:05
  • 1
    There will be a v2, should be published very soon. Yes, I reported it when I posted here. – Matthias Zeis Oct 13 '16 at 18:35
  • 1
    Looks like that is fixed now – Erfan Oct 14 '16 at 3:44

THIS APPLIES FOR 1.7 MAGENTO VERSIONS


If you are running 1.7.0.2 version 2 of SUPEE 8788 will fail on line 372 trying to apply changes to Curl.php:

patching file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client

The instructions say that we should revert SUPEE-1533 and install SUPEE-3941

PROBLEM: SUPEE-3941 is only available for Magento CE 1.8-1.9. You can try applying it for 1.7, and it will apply. I think patch developers Magento should either release a version 3 of SUPEE-8788 for those running magento's below 1.8 or create an additional SUPEE-3941 patch that is designed for version below 1.8.

B.t.w. version 1 of SUPEE-8788 did not have the Curl.php error on 1.7.0.2 (I tested it on many installs)

Tip: if you are facing .swf errors at the end, make sure you Compress your patch, upload to the server and decompress there.SWF error will be gone.

UPDATE:

Magento said that basically it is okay to install the SUPEE-3941 patch on a Magento 1.7.0.2 version to avoid errors on applying SUPEE-8788

  • We've been given up – datasn.io Oct 16 '16 at 3:49
  • @kavoir.com you also get same CURL.PHP error when installing on 1.7.0.2 ?? – Icon Oct 16 '16 at 4:42
  • 1
    Same issue here install 8788 V2 on 1.7.0.2 , although interesting we get the same curl.php error on our newer 1.9.2.1 version sites which do not have SUPEE-3941 available . reverting 1533 doesn't help that problem either – Jon Holland Oct 17 '16 at 13:47
  • @JonHolland I wrote to magento team... I hope they will respond – Icon Oct 17 '16 at 14:21
  • 2
    I got a reply from magento community leader, basically it is okey to install 3941 patch on 1.7.0.2 version.. – Icon Oct 19 '16 at 5:17

Half tempted to flag this post as primarily opinion based or without a clear answer ;)

Form keys have been added to a couple of controllers, the number varies depending on your magento version.

If you experience trouble

  • Removing an item from the wishlist
  • Deleting a customers address from the store view
  • Updating a quote item in your basket

You'll need to check your themes .phtml file and make sure you're POSTing over the form key parameter so it will pass the check in the controller actions like:

class Mage_Checkout_CartController extends Mage_Core_Controller_Front_Action

     public function updatePostAction()
     {
+        if (!$this->_validateFormKey()) {
+            $this->_redirect('*/*/');
+            return;
+        }
+

These problems tripped a lot of people up in previous patches, custom frontend themes with overridden templates are easily missed when applying the patches.

Form keys are often added to the .phtml template containing the form as an extra input like

<input name="form_key" type="hidden" value="<?php echo $this->getFormKey() ?>" />
  • Is there a full list of forms that this affect? So I can test and get them ALL fixed once and for all. Don't want secretly stupid dysfunctions such as this to annoy customers or drive down conversion rate. – datasn.io Oct 14 '16 at 2:00
  • If a SUPEE 8788 installs perfectly on 1.7 and it does make changes in (app/design/frontend/base/default/template.....). But despite the change website frontend wishlist, add remove buttons all work perfectly. Do we still need to manually patch theme files? Or, as long patch doesn't break anything on frontend we can leave as-is? – Icon Oct 14 '16 at 20:46

Original DashboardController.php (1.7.0.2- Not pached, Fresh from magento)

  if ($params = unserialize(base64_decode(urldecode($gaData)))) {

1533 Patched DashboardController.php contains the following change

 if ($newHash == $gaHash) {
            $params = json_decode(base64_decode(urldecode($gaData)), true);
            if ($params) {

8788 patch makes the following change in DashboardController.php

 if (hash_equals($newHash, $gaHash)) {
            if ($params = unserialize(base64_decode(urldecode($gaData)))) {

As you can see 8788 has a modified change compared to 1533, I am NOT sure whther its ideal to modify the file as mpchadwick suggests, by manually replacing 8788 change with 1533 after installing 8788. Basically removing 8788 change.

Any suggestions?

  • 2
    IMO The desired end result is a mix of the two. It should be json_decode, but it should use the hash_equals rather than ==. This prevents a timing attacking (which would be extremely hard to exploit). – Peter O'Callaghan Oct 13 '16 at 5:57
  • Agree with @Peter. If you use Git, revert the commit for SUPEE-1533, apply the new patch, commit, then revert the reverting commit again. The conflict in DashboardController.php should be solved automatically then. – Fabian Schmengler Oct 13 '16 at 9:44
  • 1
    Could you please provide a piece of code for DashboardController.php that we should replace after installing 8788? I am not exactly sure what to edit, like I have mentioned above, 1533 and 8788 patchd lines look different. Could you please provide how a Manually modified version should look like? – Icon Oct 13 '16 at 13:24
  • Is this how 8788 code should look like after manual modification with 1533 update? if (hash_equals($newHash, $gaHash)) { if ($params = json_decode(base64_decode(urldecode($gaData)))) { – Icon Oct 13 '16 at 13:26
  • 1
    Note regarding reverting commits two times: you may be able to use git revert -n 123456ab and git cherry-pick -n 123456ab to temporarily undo SUPEE-1533 without creating extra commits for it. – Matthias Zeis Oct 13 '16 at 14:03

I met the same problem in swf in 1.9.2.4.

Fox Fixed - Please follow below steps.

Step 1. Download security patch 8788 SSH file to this Link :- https://magento.com/tech-resources/downloads/magento/

Step 2. After download security patch 8788 SSH file Please put into one folder and make same folder Zip file.

Step 3. Please upload Zip folder to root magento folder and Unzip through SSH Putty.

Step 4. Run the patch :- $ bash PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh

*Note : he patch file contains entire binary files in text format.That's why when you upload security patch 8788 SSH file without zip file, the same file will be corrupt. *

After appyling SUPEE-8788 I was no longer able to load "Import" profiles using Unirgy_RapidFlow 2.0.0.18, getting a 500 error (nothing in Apache or HTTPD logs).

I am still in the process of debugging and working with Unirgy to resolve, but it appears that the uploader block is causing the issue (Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload).

The patch introduced several changes to Mage_Adminhtml_Block_Catalog_Product_Helper_Form_Gallery_Content, the parent.

In addition to uRapidFlow, other 3rd party modules that allow for file upload could break as a result of SUPEE-8788.

  • have you find a solution for this already? I fixed it by replacing $this->getUploader()->getConfig() with $this->getUploader()->getUploaderConfig() in Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload – lloiacono Oct 18 '16 at 9:09
  • Good to now. Unirgy also seems to have fixed it in 2.0.0.23. secure.unirgy.com/release-notes.php?m=1#RapidFlow I'm working with a client to purchase additional upgrades and haven't been able to validate. – mpchadwick Oct 18 '16 at 17:27
  • run this on your docroot to find which other files needs to be fixed: grep -r 'getUploader()->getConfig()' ./ – lloiacono Oct 19 '16 at 10:29

I got the following message when executing the patch script:

can't find file to patch at input line 4753
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
|index 6d0607e..5757be3 100644
|--- downloader/lib/Mage/HTTP/Client/Curl.php
|+++ downloader/lib/Mage/HTTP/Client/Curl.php

I think this is because I renamed the "downloader" folder, following recommendations from https://www.magereport.com.

I temporarily renamed the folder to "downloader", applied the patch correctly and then renamed it with its secret name.

Patch on 1.9.0.0 fails too (probably 1.8.0.0 until 1.9.0.1 affected) because of SUPEE-3941. 3941 patches downloader/lib/Mage/HTTP/Client/Curl.php and now the 8788 fails.

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 378.
1 out of 1 hunk FAILED
checking file js/lib/uploader/flow.min.js

Workaround for 1.9.0.1 below. Changes are too thorough, maybe need to adjust the 8788 patch itself.

edit: Edit the patch, search for Curl.php and replace

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         }

         $this->curlOption(CURLOPT_URL, $uri);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, FALSE);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');

         // force method to POST if secured
         if ($isAuthorizationRequired) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js 

with

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         $uriModified = $this->getSecureRequest($uri, $isAuthorizationRequired);
         $this->_ch = curl_init();
         $this->curlOption(CURLOPT_URL, $uriModified);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, false);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');
         $this->getCurlMethodSettings($method, $params, $isAuthorizationRequired);

         if(count($this->_headers)) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js

Here's what I'm getting

Hunk #1 FAILED at 373.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client/Curl.php.rej
patching file js/lib/uploader/flow.min.js
patching file js/lib/uploader/fusty-flow-factory.js
patching file js/lib/uploader/fusty-flow.js
patching file js/mage/adminhtml/product.js
patching file js/mage/adminhtml/uploader/instance.js
patching file skin/adminhtml/default/default/boxes.css
patching file skin/adminhtml/default/default/media/flex.swf
patching file skin/adminhtml/default/default/media/uploader.swf
patching file skin/adminhtml/default/default/media/uploaderSingle.swf
patching file skin/adminhtml/default/default/xmlconnect/boxes.css
  • Getting the exact same error io an install. Would love to know if you figured anything out. – TunaMaxx Oct 14 '16 at 0:25
  • Nope, still waiting for someone else to figure this out – Haim Oct 14 '16 at 0:36
  • 2
    See magento.stackexchange.com/a/73957/9276. If your Curl.php file has this fix, then undo that change (revert the line to CURLOPT_SSL_CIPHER_LIST / 'TLSv1'), apply the patch, and the redo the change. – Joe Oct 14 '16 at 12:56
  • Thanks @Joe. Was just coming back here to post the same info. You beat me to it! That's what I get for going to sleep. :) – TunaMaxx Oct 14 '16 at 18:15
  • Had the same issue, this resolved it. Thanks! – dafyddPrys Oct 18 '16 at 14:15

Looks like Magento will be releasing updated version of the SUPEE 8788, to fix the SUPEE 1533 compatibility. I am not sure if its good idea to apply manually fixes right now. Manual changes may compromise future patch updates. Would like to hear your thoughts.

It has been confirmed by Magento Community Manager. As oct 13, 3pm EST.. all patches for versions below 1.9 are deleted from download list https://www.magentocommerce.com/download?_ga=1.236497153.1889606568.1445610645 See post: https://community.magento.com/t5/Security-Patches/SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error/m-p/50514/highlight/false#M1805

  • 1
    If the updated patch has exactly the same result than our manual fixes, and I hope that's the case, then I don't see a problem. The updated patch won't be necessary and future patches won't see a difference. – Fabian Schmengler Oct 13 '16 at 14:40
  • 1
    @fschmengler pretty similar to the PHP 5.5 incompatibility for SUPEE-7405 IMO. The patch will reflect the manual fix. – Raphael at Digital Pianism Oct 13 '16 at 14:42
  • 1
    @fschmengler To my knowledge magento will release exactly the same patch again with fixes. I gues its best to remove old patch (self modified) and install new (probably release next day. By tomorrow we should have update. Thanks for help! – Icon Oct 13 '16 at 14:46
  • I'm not doubting the value of this contribution, but sticking to Q&A style, this answer doesn't seems like an answer to me, more of an update that @fschmengler could add to his original question (or you can add it to the Community Wiki answer). – 7ochem Oct 14 '16 at 6:51

We are getting reports of the following new issues that I don't see in other posts:

  • Exception in the new releases in some cases - addCrumbs() method call (in case getStoreConfig(web/default/show_cms_breadcrumbs) is undefined). Should not affect the patch, only the 1.9.3/1.14.3 release

'Exception' with message 'Unsupported data type N' in /lib/Unserialize/Reader/ArrValue.php in 1.9.1.0 and possibly earlier versions when patch is applied. resolved in patch version 2.

There are currently no known easy workarounds for those issues. We are working to resolve them in a new patch version.

Yes, I did encounter other issue when login, it will always return this:

I found that is because on class Enterprise_Pci_Model_Observer line 165,

Instead of:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPassword())) {

This will fix:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPasswordHash())) {

Since I don't like changing core (even move to local), it's best if Magento fix this or clarify this. At the moment mine is creating new extensions to extend this and create function for getPassword() (since I want to make sure all devs use Developer mode on).

  • 2
    Having now applied the V2 of the patch, I am encountering the same issue patching EE1.12. It looks like this file has changed at some point between 1.12 and 1.14 but not as part of the patches – Chris Oct 17 '16 at 15:24
  • 1
    Raised this with Magento and they supplied a further patch to address the issue. The change is identical to that above. – Chris Oct 21 '16 at 9:32

Editing Patch File

If anyone has to edit the patch file, you should not being do it in an editor as this will break the binary files encapsulated in the patch.

If you have a command line handy ie. linux/*unix try using sed utility to remove specific lines.

Props to @fooman for the tip. See his original gist

Example sed -ie '101,111d' PATCH_SUPEE-8788_CE_1.7.0.2_v1-2016-10-11-06-36-18.sh

This will delete line 101 to 111 inclusively.

Form Submission Issues.

If you are seeing the above mentioned for issue you can also you:

<?= $this->getBlockHtml('formkey'); ?>

For more information refer to this post What is getBlockHtml('formkey')?

  • 4
    Be careful with <?= it is not enabled on every php configuration – Raphael at Digital Pianism Oct 13 '16 at 5:53
  • @RaphaelatDigitalPianism you're correct. Although <?= is enabled by default in most php.ini configurations some hosts do choose to disabled it. – Sergei Filippov Oct 19 '16 at 1:10

Uploader breaks when you upload the same file for samples and links at the same time for downloadable products. Note that this only happens if you use the same file in both areas. (It used to work correctly before the patch.)

To reproduce, edit a downloadable product and click on the Downloadable Information tab:

  1. Open the Samples row of the accordion and browse for a sample file.
  2. On the Links row of the accordion, browse for a download link
  3. Click Upload Files from within the Links section.

The uploader uploads the sample file instead of the downloadable link file, and the file you browsed for in the downloadable link section disappears.

I was able to reproduce this on a vanilla, patched 1.7.0.2 CE install.

For 1533 Patched site just replace below line from PATCH_SUPEE-8788*****.sh :

diff --git app/code/core/Mage/Adminhtml/controllers/DashboardController.php app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index 09ffc4c..367bf8e 100644
--- app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,7 +91,7 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
+            if (hash_equals($newHash, $gaHash)) {
                 if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params) 

by:

diff --git a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index ab2d654..367bf8e 100644
--- a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,9 +91,8 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
-                $params = json_decode(base64_decode(urldecode($gaData)), true);
-                if ($params) {
+            if (hash_equals($newHash, $gaHash)) {
+                if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params)
                             ->setConfig(array('timeout' => 5))
diff --git a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
index da1b14a..b6d72c0 100644
--- a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
+++ b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
@@ -444,7 +444,7 @@ class Mage_Adminhtml_Block_Dashboard_Graph extends Mage_Adminhtml_Block_Dashboar
             }
             return self::API_URL . '?' . implode('&', $p);
         } else {
-            $gaData = urlencode(base64_encode(json_encode($params)));
+            $gaData = urlencode(base64_encode(serialize($params)));
             $gaHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
             $params = array('ga' => $gaData, 'h' => $gaHash);
             return $this->getUrl('*/*/tunnel', array('_query' => $params));

Basically it just reverted the 1533 and left 8788 along.

  • As I understand the 8788 overrides changes in DashboardController.php, and original 1533 changes will be eliminated? – Icon Oct 13 '16 at 3:35
  • 2
    Yes the purpose of 1533 replacing serialize() by json_encode() was to reduce the chance of attack pass ($newHash == $gaHash). While 8788 adds hash_equals() for the same purpose – William Zhao Oct 13 '16 at 4:01
  • Great, I was thinkin of doing slightly other way, on my test site I uploaded clean DashboardController.php (stock magento file) and installed SUPEE 8788. However, I read on this forum and a gentleman mentioned to manually reintroduce supee 1533 changes to Supee 8988 modified file. What you think about my method? – Icon Oct 13 '16 at 4:16
  • Icon, look at my diff above, in your way you need to change back the line updated by SUPEE 1533 in 'app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php' as well if you already have SUPEE 1533 patched. Otherwise Graph.php will fire out json format params and you wont be able to decode it by unserialize() – William Zhao Oct 13 '16 at 4:47

CE 1.6.2.0 & SUPEE-3941

To apply security patch SUPEE-8788 (Version 2), (http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html#apply-8788-new) it is suggested to apply SUPEE-3941 first.

However, on the patch download page, there is no SUPEE-3941 patch for CE 1.6.2.0. The patch is available only for CE 1.8 and 1.9.

As mentioned in this thread, it seems to be okay to apply the available SUPEE-3941 patch (for CE 1.8 & 1.9) on CE 1.7.

Is it also okay to apply SUPEE-3941 (for CE 1.8 & 1.9) on CE 1.6.2.0? I tried applying it on CE 1.6.2.0 and got the following error:

Checking if patch can be applied/reverted successfully...
-e ERROR: Patch can't be applied/reverted successfully.

checking file downloader/Maged/Model/Connect.php
Hunk #1 succeeded at 489 (offset 3 lines).
checking file downloader/lib/Mage/Connect/Backup.php
checking file downloader/lib/Mage/Connect/Command.php
Hunk #1 FAILED at 64.
Hunk #2 succeeded at 205 with fuzz 2 (offset -44 lines).
Hunk #3 succeeded at 382 (offset -53 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Command/Install.php
Hunk #1 FAILED at 90.
Hunk #2 succeeded at 333 with fuzz 1 (offset 17 lines).
Hunk #3 succeeded at 363 (offset 17 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Packager.php
Hunk #4 FAILED at 268.
Hunk #5 FAILED at 290.
Hunk #6 succeeded at 369 with fuzz 2.
Hunk #7 FAILED at 377.
Hunk #9 FAILED at 428.
4 out of 10 hunks FAILED
checking file downloader/lib/Mage/Connect/Rest.php
Hunk #1 succeeded at 71 with fuzz 2 (offset -11 lines).
checking file downloader/lib/Mage/Connect/Singleconfig.php
Hunk #1 succeeded at 100 (offset -36 lines).
checking file downloader/lib/Mage/Connect/Validator.php
Hunk #1 succeeded at 418 (offset -41 lines).
Hunk #2 succeeded at 431 (offset -41 lines).
checking file downloader/lib/Mage/HTTP/Client/Curl.php
checking file downloader/template/settings.phtml

Authorize.net capture is broken after applying the patch. Authorizing works good, but when capturing the payment to invoice it gives "Gateway error: Credit card number is required". Payment log file shows x_type param passes value auth_capture now, but before the patch it used to pass prior_auth_capture which worked well. Anyone experiencing this issue?

UPDATE: Fix for this issue - Authorize.net not capturing

A little late but we found a problem in patch SUPEE-8788 V2 which at least applies to the patch files for Magento 1.7.0.2 and 1.7.0.1. Probably this also applies to all prior versions for which a patch version exists. Magento version from 1.8 on are not affected as the patch doesn't change templates for those.

In detail

The patch is missing a formkey for file app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml

Without it login doesn't work on onepage checkout (it just doesn't work without error).

Fix

A formkey has to be inserted like in following patch:

diff --git a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
index 9d15a577b..18483a3c5 100644
--- a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
+++ b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
@@ -71,6 +71,7 @@
         <h3><?php echo $this->__('Login') ?></h3>
         <?php echo $this->getMessagesBlock()->getGroupedHtml() ?>
         <form id="login-form" action="<?php echo $this->getPostAction() ?>" method="post">
+        <?php echo $this->getBlockHtml('formkey'); ?>
         <fieldset>
             <h4><?php echo $this->__('Already registered?') ?></h4>
             <p><?php echo $this->__('Please log in below:') ?></p>

Applied PATCH_SUPEE-8788_CE_1.9.2.1_v1-2016-10-11-07-00-43 on test copy of site running 1.9.2.1 and it has broken the checkout. Revert the patch and the checkout works normally again.

When submitting the order it takes you back to the cart instead of checkout success. Think I'll be waiting for the .1 version before trying again.

  • sounds like an exception is thrown while the order is saved, have you checked your logs? – simonthesorcerer Oct 13 '16 at 15:35
  • Looks that way... PHP Fatal error: Class 'Mage_Core_Helper_UnserializeArray' not found in .../public_html/app/Mage.php on line 547 – Adam Lavery Oct 13 '16 at 15:52
  • @AdamLavery Go to Var/cache and delete the cache folder. I get that error when I revert the paches back to original. Its a cache thing. – Icon Oct 13 '16 at 16:10
  • New patch should be out soon. This is a huge patch update to expect no errors... Yeah... fingers crossed. – Icon Oct 13 '16 at 16:12
  • 1
    This is likely because you're missing app/code/core/Mage/Core/Helper/UnserializeArray.php This was added in SUPEE-6788, which you may not have installed. It looks like SUPEE-8788 has an undocumented dependency on SUPEE-6788. – Tyler V. Oct 18 '16 at 22:33

New email in the early hours from Magento states that they will be producing new patch versions to deal with the SUPEE-1533 and SUPEE-3941 compatibility issues. So maybe just hold your horses for a bit.

ENTERPRISE EDITION 1.14.3, COMMUNITY EDITION 1.9.3, AND SUPEE-8788 Enterprise Edition 1.14.3 and Community Edition 1.9.3 deliver over 120 quality improvements, as well as support for PHP 5.6. They also resolve critical security issues, including: ...

...The SUPEE-8788 patch addresses these security issues in earlier Magento versions. Unfortunately, we have discovered that the SUPEE-8788 patches for Community Edition 1.8 and earlier releases and Enterprise Edition 1.13 and earlier releases fail if a store has previously applied SUPEE-1533 or SUPEE-3941 security patches. We are working to correct this issue and will provide new patches in the next one to three days. Until then, we are removing these versions of the SUPEE-8788 patch from distribution...

However I am concerned that my active Magento versions fall between the CE 1.9.3 that they say works and the new versions coming soon for V1.8 and below. I have contacted them so will wait and see what they say.

  • Not really an "answer" but useful info hopefully. – Jon Holland Oct 14 '16 at 8:39
  • Hi Jon, you could also edit @fschmengler's original question and add this on the bottom as an UPDATE. I think he would be fine with that and approve that edit. – 7ochem Oct 14 '16 at 8:59
  • Good idea but someone has already added something :) – Jon Holland Oct 14 '16 at 9:02

I am not a big fan of patching. Personally I remove all Magento files from their directories then upload the new version (using a shell script). All the files installed over the years like modules or themes are still there. For database I make a comparison between fresh installed versions. One way is creating or removing the columns/tables into the database, the other way is installing again Magento just changing /app/etc/local.xml file name. I prefer the first one.

If you do not change the database structure to version 1.9.3.0 you will get some errors or you cannot load admin area. If anyone is interested in some comparisons for Magento directories and databases between Magento CE 1.9.2.4 and 1.9.3.0 just download the file from here:

Magento Comparison: versions 1.9.2.4 - 1.9.3.0

There are two html files with very nice visual results.

I updated 4 stores today using my method instead of patching. All are running without any issues.

  • That's nice if you are on the most recent version and there is a new release for the patch, as it was the case with 1.9.2.2, 1.9.2.3 and 1.9.2.4 - however for this patch there was no new release 1.9.2.5. Version 1.9.3.0 contains a bunch of additional changes that are not security related. – Fabian Schmengler Oct 16 '16 at 20:34
  • With my method I got two in one, security updates and new features. The only problem is you have to understand what is happening into the file system and database between releases. It is not a big deal when you know what you are doing. And you have a better control. I am doing this method since 1.7 version. – ADDISON74 Oct 17 '16 at 7:46

Not having any luck on most installs of Magento CE (6 total). Different versions: 1.9.1, 1.9.0.1, 1.8.1.

I've downloaded the correct corresponding 8788 patch. I've made sure to revert 1533 when applicable.

I get the following key notable outputs that are questionable:

Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

...

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.

... checking file app/code/core/Mage/Adminhtml/controllers/IndexController.php Hunk #1 succeeded at 373 (offset -19 lines). ...

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.ph

Same as above for: lib/Unserialize/Reader/Arr.php lib/Unserialize/Reader/ArrValue.php And says those hunks ignored.

note: There is nothing in my Unserialized/Reader dir. Completely empty. note: the Curl.php is in downloader dir. Not renamed. It finishes, but I don't see the SWF files removed. I don't see the patch applied in the list of applied.patches.list

Makes no sense.

  • Ok.. figured it all out. Definitely need to work thru ALL old patches, in order. I had a couple older patches that hadn't been applied. Once I pulled down those, and applied on up the line, things started patching sucessfully. However, I did find that whenever I got a hunk error on a file for ANY patch, I had to go into the patch and find what it was trying to replace and manually do it in my magento install. THEN remove those "diff" lines from the patch and rerun. Essentially any time you see a hunk error, go into the patch and see what it's attempting to +/- from it, and then do it yourself. – Rich Yessian Oct 21 '16 at 0:24

I've patched about 10 websites today, and every site where the SUPEE-8788 patch failed had the SUPEE-6788 MISSING.

This resulted in (example) the following error:

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.php

After installing SUPEE-6788 the SUPEE-8788 patched correctly.

I have patched a copy of Magento 1.9.2.4 using SSH with SUPEE-8788 I have patched another copy of Magento 1.9.2.4 using ftp with SUPEE-8788 I have patched a copy of magento 1.9.1.0 using SSH with SUPEE-8788 I have used a fresh copy of magento 1.9.3.1

In all these magento web sites with SUPEE-8788 i experience the same problem (maybe a bug of the patch)

Using downloadable products and going in Downloadable information->Samples when i try to Add a new row (one or more) by clicking on the "X" i'm not able anymore to remove the rowenter image description here

I'm not so expert in Magento i'm trying to find a solution. If i will find i will post, if anyone of you have some solution it will be very very usefull for me

UPDATE: using Chrome inspector i saw this error:enter image description here

******* I FOUND THE SOLUTION *******

I spent 2 days and i hope this can help someone else, this is a bug in SUPEE-8788

Open samples.phtml inside app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable

Find the function

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        element.down('div.flex').remove();
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

and replace it with

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        Element.select(element, 'div.flex').each(function(elm){
            elm.remove();
        });
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

This will solve the BUG

If you are getting Hunk #1 failed at xxx Error , This is what i did

I got Hunk #1 failed at 373. Error !! after the line

checking file downloader/lib/Mage/HTTP/Client/Curl.php

So i checked the Curl.php file and found that i had modified the file before (commented one line ). I restored the original file and ran the patch again. Then the patch was successful. ;) .

Then i checked :

/app/etc/applied.patches.list & everything seems good

protected by Community Oct 13 '16 at 8:35

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.