Inchoo’s compatibility extension for Magento 1 and PHP 7


As promised,  we prepared something that will spice up your holidays better than Christmas decorations and mulled wine. In this article you can find our open-source compatibility extension for Magento and PHP 7 (yes, you read that right!) as well as some of the experiences and performance tests.

We, at Inchoo, already have a few Magento 1 projects running fine on development servers with PHP 7. It’s alive, we say!

And quite lively, actually.

Despite the official status, Magento 1 loves working on a server with PHP 7. And we love PHP 7. Lots of love and liveliness everywhere, but most is already said here:

Show us the code!

So, how hard is it to patch Magento 1 to work on PHP 7? Very easy. Just install the Inchoo_PHP7 extension, and enjoy!

Yeah, you’ve patched the core, but the night is long and community and local folders are full of horrors!”, you say, with a sneer of someone who has seen many winters. Yes, sure, but here is something more for your pains:


This beautiful, readable piece of regex, ran against community and local folders will find a class of problematic code, which no longer works in PHP 7. If none found, your project is (probably) PHP 7 ready! Hooray!

Obligatory number crunching

Values in all tables are milliseconds to first byte. Cache, when turned on, was default core M CE cache. All other items in software stack (MySQL, Apache) were same.

Big (>70 extensions, thousands of products) M CE project, with all patches applied

cached category, filtered home page
PHP 5.6 800 320
PHP 7.0 420 120
uncached category, filtered home page
PHP 5.6 6200 7300
PHP 7.0 3450 3400

Small (~10 extensions, tens of products) M CE project

cached category, filtered checkout/cart
PHP 5.6 165 180
PHP 7.0 80 105
uncached category, filtered checkout/cart
PHP 5.6 310 360
PHP 7.0 100 200

Thanks to Marin Grizelj for crunching the numbers, which speak for themselves. Speedup was 2-3 times just from switching to PHP 7. And, we were comparing it with PHP 5.6, while many projects in the wild are still on 5.5 or even 5.4. (Mind you, compatibility fixes you need to do on older Magento 1 versions to make it work with 5.6, will also bring you a good deal closer to compatibility with 7.0).

Enough technobabble. It is alive and lively! Let it run into the wild, and scare the village folk!

About Ivan Curdinjakovic

Backend Developer

Backend Developer who tried everything from teaching to journalism, and now is immersed into PHP, SQL, Apache, HTML, Linux, Javascript, Git, PhpStorm. Father of two beautiful little girls and a husband of one, occasional basketball player and a lover of good coffee, good food and good music.

Read more posts by Ivan / Visit Ivan's profile


  1. Hi,
    I ahave used the Compatinility Extension for 3 websites with Magento 1.9.3. The sites are pretty similar regarding templates and extensions. 1 siet works by only installing the PHP 7 Extesnion and the other obe doesn’t. It creates a blank page in Frontend and Admin. In the server Error log I see this:

    AH01071: Got error ‘PHP message: PHP Fatal error: Uncaught TypeError: Argument 1 passed to Mage_Core_Model_Store_Group::setWebsite() must be an instance of Mage_Core_Model_Website, null given, called in /var/www/vhosts/ on line 665

    Any idea what might be the issue here?

  2. This is great! thanks a lot
    so far working well in EE 1.14
    however, in EE, there’s another method to override concerning indirect variable access:

    another thing is I notice there’s a whole bunch of deprecated functions such as eregi and dl in lib esp. related to PEAR, would this matter ?

    1. That class is also fixed. Are you using the EE branch on Inchoo_PHP7?
      Incompatibilities in some Pear libraries are not fixed because they seem to not being used at all in Magento.

  3. First off, thanks for the work, but unfortunately it doesn’t work for me and gives error 500.

    I am using PHP Version 7.0.8 and Magento

    when showing the errors as described here I got the following:

    Error front end

    Fatal error: Uncaught Error: Function name must be a string in /home/parnis/public_html/app/code/core/Mage/Core/Model/Layout.php:555 Stack trace: #0 /home/parnis/public_html/app/code/core/Mage/Core/Controller/Varien/Action.php(390): Mage_Core_Model_Layout->getOutput() #1 /home/parnis/public_html/app/code/core/Mage/Cms/Helper/Page.php(137): Mage_Core_Controller_Varien_Action->renderLayout() #2 /home/parnis/public_html/app/code/core/Mage/Cms/Helper/Page.php(52): Mage_Cms_Helper_Page->_renderPage(Object(Mage_Cms_IndexController), 'porto_home_17') #3 /home/parnis/public_html/app/code/core/Mage/Cms/controllers/IndexController.php(45): Mage_Cms_Helper_Page->renderPage(Object(Mage_Cms_IndexController), 'porto_home_17') #4 /home/parnis/public_html/app/code/core/Mage/Core/Controller/Varien/Action.php(418): Mage_Cms_IndexController->indexAction() #5 /home/parnis/public_html/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254): Mage_Core_Controller_Varien_Action->dispatch('index') #6 /home/parnis/public_html/app/code/c in /home/parnis/public_html/app/code/core/Mage/Core/Model/Layout.php on line 555

    Error backend

    Fatal error: Uncaught Error: Function name must be a string in /home/parnis/public_html/app/code/core/Mage/Core/Model/Layout.php:555 Stack trace: #0 /home/parnis/public_html/app/code/core/Mage/Core/Controller/Varien/Action.php(390): Mage_Core_Model_Layout->getOutput() #1 /home/parnis/public_html/app/code/core/Mage/Adminhtml/controllers/System/ConfigController.php(119): Mage_Core_Controller_Varien_Action->renderLayout() #2 /home/parnis/public_html/app/code/core/Mage/Core/Controller/Varien/Action.php(418): Mage_Adminhtml_System_ConfigController->editAction() #3 /home/parnis/public_html/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254): Mage_Core_Controller_Varien_Action->dispatch('edit') #4 /home/parnis/public_html/app/code/core/Mage/Core/Controller/Varien/Front.php(172): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http)) #5 /home/parnis/public_html/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch() #6 /home/parnis/public_html in /home/parnis/public_html/app/code/core/Mage/Core/Model/Layout.php on line 555

  4. I followed your steps to get php7 and magento working properly and had no issues until i hit the backend of my site. I then found this in the sales order view page.

    It seems like the sales/order/view/form.phtml is never getting rendered into the page since the upgrade.

    Im assuming it’s an issue with layouts not getting called properly but I dont see any error’s to debug.

    Since upgrading to php7 has anyone else seen this issue?

    1. I have fixed this issue if anyone else runs into the similar problem. We had issues with isset and calling $this->getMethod(), for some reason error logging got turned of on the environment and i found the issue when it was back on.

  5. Have anyone tried PHP7 with the Ultimo theme on the latest Magento

    How am I supposed to run the regex code above to test for compatibility issues?

  6. hi
    from magento, uploaded Seven to the server, then change to PHP 7.0 and my side goes blank.
    No errors, just nothing on the screen.

    Any thoughts? What is the issue? thanks!!

  7. any idea why a 500 internal server error might be happening when switching to php 7 on magento

  8. I have the same problem as Alex Niculescu.

    After upgrading to php 7, I can’t login to Backend and the cart is empty after adding a product! Can be something related to Varnish?

    1. Hey Loviux, you had mentioned about the Issue of Login and Empty Cart; would you please help explain how did you solve the issue?

  9. “No use searching for app/code/core incompatibilities, as they are already patched by our extension.”

    Your extension makes no changes to the app/code/core:
    so i tried:
    grep -rnPe ‘->\$.+\[.+\]\(.*\)’ app/code/core/

    I got:
    app/code/core/Mage/Core/Model/Layout.php:555: $out .= $this->getBlock($callback[0])->$callback[1]();
    app/code/core/Mage/ImportExport/Model/Export/Entity/Product/Type/Abstract.php:9 : $data[‘filter_options’] = $this->$data[‘options_method’]();
    app/code/core/Mage/ImportExport/Model/Export/Entity/Customer.php:250: $data[‘filter_options’] = $this->$data[‘options_method’]();
    app/code/core/Mage/ImportExport/Model/Import/Uploader.php:135: $params[‘object’]->$params[‘method’]($filePath);

    1. Of course the extension doesn’t change the core files. It overwrites or replaces the classes, so that code you are mentioning is never reached after the extension is installed. But grep doesn’t know about that.
      Hence, “No use searching for app/code/core incompatibilities, as they are already patched by our extension.” – and, I’ll add now – it will give you false positives.

  10. I have issue with Grand Total, It was not added Tax on Total amount. Tax class applied properly. Below example Subtotal is Excl with tax. Grand total need to be £84 but it show only £70.

    Subtotal £70.00
    Grand Total Excl. Tax £56.00
    VAT £14.00
    Grand Total Incl. Tax £70.00

    1. I’m also experiencing this issue, Tax is properly calculated but it’s not added to Grand Total.
      Maybe it’s related to tax settings, mine are:
      Tax Calculation Method Based On: Total
      Apply Customer Tax: Before Discount
      Apply Discount On Prices: Excluding Tax
      Just switching back to php 5.6 makes everything work as expected, even with the extension installed.

  11. Hi, this is fantastic work – thank you.
    I’ve just ran the tool and all the extensions on one of my major clients seem OK based on the check apart from one with this line of code:
    $_response = $this->$params[‘type’]($params);

    Do you have any advise on how this could be changed to make it compatible with the current version of php (5.4) as well as php7 for when they upgrade?


  12. Thanks for this great post Ivan! I’m having problems with php 7.0 and Magento, when I have products in my cart and try to checkout, my cart gets empty. Do you have any ideas why that happens? You can see my staging website in the comment form. Cheers!

  13. I can confirm that this is 100% working for Magento CE.
    I already was making overwrites to make Magento compatible with PHP 7, but you beat me to it.

    I develop a fairly large module and PHP 7 works fine now in my development environment (PHP Storm + MAMP PRO). Debugging is a blaze compared to PHP 5.

    Thank you!

  14. I am new to use magento. I have server with PHP 7.Now, Magento 1.9.2 ready to install. Please provide the exact location where the contents of “” are to be placed.

    1. Contents are to be placed in root site folder (folder structure being maintained in zip).
      Though, if you have trouble with that, you may consider hiring a magento consultant to help you out setting up your store.

  15. Hi Ivan, I was the one who submitted the pull request for the discount/sorting fix, so am confident it works 😉

    1. What repository do you mean? Can you give the link to pull request?

    2. @Danil: the pull request for correct sorting is already merged. So, just get the newest version of extension, and try if it solves the discount problem. (It should.)

  16. Ok here’s an incompatibility between PHP 5.x and PHP 7 with Magento (with no other changes), following on from what Danil said.

    If you don’t do this – you will find that Magento does not apply discounts to the Grand Total – in other words discounts will be applied incorrectly (or not at all)

    The exact changes are here:
    A Magento module that has this change and doesn’t modify core can be found here:

    Unsure whether this is something that Inchoo should include in their PHP7 patch or not… if it’s not included, discounts won’t work (but they will on PHP 5.x)

  17. Thanks for article. But I have a small point about PHP 7. There are less obvious problem than an error in the syntax which may be encountered. In particular, I was faced with incorrect sorting in the calculation of the discount. This strange behavior is due to a change in the work function uasort. I described it in detail on the SO, please see… Do not you have encountered a similar problem? And if so, how do you solve it?

    1. We have just merged a pull request that claims to fix the sorting problem. Danil, Darren, if you can try it from the master branch, please report if it fixes your problems.

  18. It appears to work on PHP 5.3.3, at least I was able to access the website, log in to the backend and upload images. Haven’t tested every fix but on the basis that the principal ought to be the same I feel confident that it is working.

    I don’t suppose there is any chance of you creating a Magento Connect module out of this? I don’t use modman myself, and would like to be able to be informed of updates, etc.

    1. Glad to hear it works on 5.3.3. I don’t know about Magento Connect yet, but we may try submitting the extension there. As a workaround for the time being, you can watch our GitHub repository to be informed of updates.

  19. Is this safe to use on pre-PHP 5.6.x installations? Currently using 5.3.3 (RPM) but looking to get the install ready for transition to PHP 7.0, so figured I’d install your extension now and have it in place ready for the move.

    1. It’s safe on 5.5+, and installing it before actually transitioning to 7.0 is a good idea. However, I’m not sure about 5.3. If you try it on 5.3, please let us know how it went.

    1. In html root, you would want to run the following:
      grep -rnPe '->\$.+\[.+\]\(.*\)' app/code/local/
      grep -rnPe '->\$.+\[.+\]\(.*\)' app/code/community/

      No use searching for app/code/core incompatibilities, as they are already patched by our extension.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <blockquote cite=""> <code> <del datetime=""> <em> <s> <strike> <strong>. You may use following syntax for source code: <pre><code>$current = "Inchoo";</code></pre>.