Upgrading from EE 1.12 to EE 1.13

Question

With the new release of Magento, a lot of questions have been flying around the office.

My one biggest concern is third party integrations and compatibility with the latest version.

A couple of things

1. Does upgrading typically break third party modules?

2. Should we be considering upgrading right after the release, or should we wait until our third party modules have been verified to work with the latest version?

3. Does upgrading typically go smoothly, or is it a nightmare?

4. Does upgrading typically effect theming?

5. Is there anything else I should be considering before upgrading?

Answer 1

Typically upgrade from last version to current should be smooth, more or less.

Since 1.13 is EE only there is good chance that most free modules will not rush to test with it. Therefore best thing to do (and you should always do) is to perform update on test copy of your site and see if it breaks.

If it breaks see if it is something you can fix, else address (module) support (if module is broken).

Answer 2

1) Does upgrading typically break third party modules?

Depends if they have something to do with indexing. The biggest change in EE 1.13 is that the indexer works with database triggers instead of php-files. If you or your module changed anything in standard indexers it is almost certain to fail. Otherwise I see the usual risk.

2) Should we be considering upgrading right after the release, or should we wait until our third party modules have been verified to work with the latest version?

We have updated very early because we needed the speed of the new indexers on an update from an erp-system. If you do not need the speed I would wait for the modules.

3) Does upgrading typically go smoothly, or is it a nightmare?

It is normal I would say.

4) Does upgrading typically effect theming?

Typically no. If you have a theme that is overriding a lot then some of the new features might be hidden. I don't remember too many new features that the customer would see though.

5) Is there anything else I should be considering before upgrading?

There are three areas to look into (from http://www.code4business.de/update-magento-enterprise-edition-1-13-0-2/):

• API change for partial indexing
• Unique product url keys
• shell_exec dependency in cronjob

API change for partial indexing

The most obvious change in EE 1.13 is the new indexing system. We paid special attention to it since we are triggering the partial indexer in a custom import script to allow seamless imports over the day. But this went surprisingly well, there was only one point in the code that had to be adjusted for the new indexer API.

Before we used the processEntityAction() method to trigger the indexer for a single product, that has been replaced with logEvent() and the following parameters:

Mage::getSingleton('index/indexer')->logEvent(
  new Varien_Object(array(
    'id' => $product->getId(),
    'store_id' => $product->getStoreId(),
    'rule' => $product->getData('rule'),
    'from_date' => $product->getData('from_date'),
    'to_date' => $product->getData('to_date')
  )),
  Enterprise_TargetRule_Model_Index::ENTITY_PRODUCT,
  Enterprise_TargetRule_Model_Index::EVENT_TYPE_REINDEX_PRODUCTS
);

Unique product url keys

The change that had most impact was that there is now a UNIQUE index on the URL key in the URL rewrite table. This is actually also true for Magento CE 1.8. Now if like us you have multiple store views and import your products so that for each store view the URL key is saved, you automatically have duplicate keys. The update script is smart enough to not just throw an error but renames all the keys so you’ll end up with something like:

• de.example.com/someproduct.html
• en.example.com/someproduct1.html
• nl.example.com/someproduct2.html

To avoid that, the URL rewrites have to be fixed before the update, so that there is one rewrite per product and URL key, and the store views use “Use default”. We managed that with a single SQL query before the update:

DELETE nondefault
FROM catalog_product_entity_varchar AS nondefault
INNER JOIN catalog_product_entity_varchar AS def ON def.value = nondefault.value
AND def.entity_id = nondefault.entity_id
WHERE def.attribute_id =86
AND nondefault.attribute_id =86
AND nondefault.store_id 0
AND def.store_id =0

Note that 86 is the id of the URL key attribute. If you already had updated without running this query first you have to remove the wrongly created URL keys first, this can be done with the following query:

DELETE url_table
FROM catalog_product_entity_url_key url_table
INNER JOIN catalog_product_entity_varchar old_url_table ON url_table.store_id = old_url_table.store_id
AND url_table.store_id 0
AND old_url_table.store_id 0
AND url_table.attribute_id = old_url_table.attribute_id
AND url_table.entity_id = old_url_table.entity_id;

As we found out later, the update also contains two scripts hidden in /shell which address the same topic:

• url_migration_to_1_13.php
• url_migration_from_1_13_0_0_to_1_13_0_2.php

shell_exec dependency in cronjob

Another minor tricky thing was that cron.php has a new feature to allow parallel execution. It tries to run the shell script cron.sh as a background process with shell_exec() which again runs cron.php. Unfortunately the detection if shell_exec() is active does not work reliable. The possible solutions are:

Make sure that shell_exec is not on the list of disabled function in your PHP configuration

OR

Remove any whitespace in the disabled functions configuration value OR Change cron.php and manually set $isShellDisabled to true