23rd February 2016 Update: The patch has been updated to V1.1, which fixes a number of important issues listed in this post, here is the list:
- Cart Merge Patch (SUPEE-7978) : Carts with identical items now merge correctly. Previously, when a cart with one item was merged with another cart that contained the same item, Magento did not merge the cart totals correctly. The cart now includes only one item, and the total is correct.
- SOAP API Patch (SUPEE-7822) : The Magento SOAP API now works as expected. Previously after installing the SUPEE-7405 v1.0 patch, an API request would cause a 500 error, and Magento would log an exception.
- PHP 5.3 Compatibility (SUPEE-7882) : The patch was not compatible with PHP 5.3 for earlier versions of Magento that were still supporting this version. Merchants experiencing this issue were unable to view sales information in the Admin.
- Upload File Permissions : The patch restores less restrictive file permissions (0666 for files and 0777 for directories) as more strict permissions introduced by the original SUPEE-7405 patch caused many merchants not to be able to view uploaded product images, depending on hosting provider configuration.
After digging into the patch, here are the relevant / interesting things I've found (N.B.: this list has been made by analyzing the patch for CE 1.9.2.0-1.9.2.2, there's probably more for patches affecting older versions of Magento) :
- (fixed in V1.1 of the patch)
The use of [] instead of array() in this patch makes it backward incompatible with PHP < 5.4 (see known issues below)
- As stated, most of the changes are html escaping and data sanitizing regarding XSS issues.
- Form key validation has been added to the admin login in
Mage_Admin_Model_Observer
- Form key validation has been added to the admin forgot password in
Mage_Adminhtml_IndexController
- Form key validation has been added to the admin reset password in
Mage_Adminhtml_IndexController
- Form key validation has been added to the frontend cart delete action. Form key is added to the
getDeleteUrl of Mage_Checkout_Block_Cart_Item_Renderer and validated in the deleteAction of Mage_Checkout_CartController.
- Events are now dispatched all lower case (every config files affected have been modified e.g.
controller_action_postdispatch_checkout_onepage_saveOrder becomes controller_action_postdispatch_checkout_onepage_saveorder). This does not affect your local observers configuration. More information here: https://twitter.com/foomanNZ/status/689924329065164800
- A new validator to check if an uploaded file is an image has been added:
Mage_Core_Model_File_Validator_Image
- A new Import/Export section appears :
System => Configuration =>Advanced > System => Escape CSV Fields
- New event dispatched:
admin_user_validate under Mage_Admin_Model_User
- SVG is not a valid favicon extension anymore
- For those using Authorizenet (I don't) it seems like a few changes have been made, not sure how it impacts the system though. Changes include a new admin helper (
Mage_Authorizenet_Helper_Admin) used to get the success order url.
- New Zend class:
Zend_Xml_Security. Its purpose is to scan XML string for potential XXE and XEE attacks. However I did not find any reference to it in the other modified files.
- Files uploaded via admin panel (i.e. product image upload) are now not world readable by default (before: 777 / after: 640).
- Directories are also not world executable (before 755 / after: 750). This two can cause issues with images not appearing on the website if the webserver runs as a different user from php (credits: @Rob Mangiafico)
- Regarding frontend templates: the only modifications made are data escaping, which are not system breakers but still recommended to implement on your custom theme (and there's only two frontend files affected not that much work ;) )
Known issues after patching:
I'll try to keep this list as up to date as possible.
Before starting a new issue/question, please ensure you've applied all the previous patches as it seems like a lot of issues comes from missing patches.
Another thing is: if you have modified core files, applying the patch may fail. If you're having a Hunk # failed at error for a specific file and you're 100% sure you've applied all the previous patches, please ensure you have the original file from your Magento version by checking the mirror: https://github.com/OpenMage/magento-mirror/
List of affected files
It can be found on this page here: https://magento.stackexchange.com/a/98232/2380 (credits @MagenX)
EE Only
- If you updated from Magento EE 1.14.2.x to Magento EE 1.14.2.3 instead of applying the patch, and also applied the support patch SUPEE-5984 before, you have to reapply it again because it is not included in the release. => https://magento.stackexchange.com/a/98805/2380
Regarding Patch 7616:
Good resources about Magento patches
Feel free to let me know if I miss something.
Here's my overview of the patch after digging into it
TIME SAVER : Experius provides a patch helper that helps you finding the files in custom themes, custom modules or local overwrites that also might need to be patched manually, you can find it here: https://github.com/experius/Magento-1-Experius-Patch-Helper#magento
Checkout form keys
As said in the other post, this patch adds form keys to the following forms:
Shipping cart form:
app/design/frontend/<package>/<theme>/template/checkout/cart/shipping.phtml
Multishipping billing checkout form:
app/design/frontend/<package>/<theme>/template/checkout/multishipping/billing.phtml
Multishipping shipping checkout form:
app/design/frontend/<package>/<theme>/template/checkout/multishipping/shipping.phtml
Multishipping addresses checkout form:
app/design/frontend/<package>/<theme>/template/checkout/multishipping/addresses.phtml
Billing checkout form:
app/design/frontend/<package>/<theme>/template/checkout/onepage/billing.phtml
Shipping checkout form:
app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping.phtml
Payment checkout form:
app/design/frontend/<package>/<theme>/template/checkout/onepage/payment.phtml
Shipping method checkout form:
app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping_method.phtml
Persistent Billing checkout form:
app/design/frontend/<package>/<theme>/template/persistent/checkout/onepage/billing.phtml
On top of that the following JS files have been updated to be compatible with that change:
js/varien/payment.jsskin/frontend/base/default/js/opcheckout.js
What to do:
If you're using with custom versions of those templates you'll have to update them by adding the following code into them:
<?php echo $this->getBlockHtml('formkey') ?>
If you're using a 3rd party checkout module, you'll have to get in touch with them so they can provide an updated version of their module.
Also if you have custom versions of the previously listed JS files, you'll have to update them too.
SAVE YOUR TIME:
Fabian Schmengler wrote a nice little script to update all those things for you, you can find it here:
https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b
IMPORTANT NOTE : the checkout formkey validation can be changed in the backend via a new config field under System > Configuration > Admin > Security > Enable Form Key Validation On Checkout . THIS IS NOT ENABLED BY DEFAULT so you'll have to enable it to benefit from this security feature!!! Note that you'll get a notice in the backend if it's not enabled.
Image Upload callback
The image gallery controller has been updated to add a validation callback.
What to do
If you're using a custom module that does image upload with code that looks like this:
$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);
I strongly suggest you update that code by adding the following piece after it:
$uploader->addValidateCallback(
Mage_Core_Model_File_Validator_Image::NAME,
Mage::getModel('core/file_validator_image'),
'validate'
);
Symlinks
This patch removes the system configuration field that allows you to allow template symlinks in the backend. It used to be under System > Configuration > Developer > Template > Allow Symlinks . Now the entire Template section is gone.
On top of that, that field is now disabled by default via the app/etc/config.xml
The funny thing here is that you'll get a notice in the backend if you have that configuration field enabled prior to the patch but you won't be able to disable it as the field is gone.
Only way of doing it is by running the following SQL query
UPDATE core_config_data SET value = 0 WHERE path = "dev/template/allow_symlink";
Clarification
First I strongly suggest you check those two posts that will help you understand the purpose of that Symlink modification:
This modification is really about calling uploadable content (like images) via template directives.
The issue related to symlinks is exploitable only with admin access and Magento added some more protection around image uploads as well.
Please note that they are some protections against known way to exploit it in addition to the setting itself.
What to do: if like me, you're using modman or composer with template symlinks, you're gonna face some issues. I'm still trying to find out what's the best thing to do here apart from dealing with SQL queries.
Main post regarding this issue: SUPEE-9767, modman and symlinks
List of possible issues
V2 was released since that original post. Don't forget to upgrade
Bugs
The word 'confirmed' is used for confirmed bugs. If it's not there, that means it could be a bug but hasn't been confirmed yet.
Hunk Failed Issues
Note that all those issues could be simply because you modified the original file, to double check that this is not the case:
- Backup the file where you get the Hunk Failed error
- Download the original file from your Magento version
- Compare both files
If files are different you'll have to apply the patch with the original file then reapply your custom changes the clean way such as:
- custom template in a custom theme folder
local.xml- app/code/local file
If files are not different then this is either a permission issue or a "bug" in the patch.
Best Answer
Below files have been changed/created after the patch is applied