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:
'id' => $product->getId(),
'store_id' => $product->getStoreId(),
'rule' => $product->getData('rule'),
'from_date' => $product->getData('from_date'),
'to_date' => $product->getData('to_date')
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:
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:
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:
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:
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
Remove any whitespace in the disabled functions configuration value OR
Change cron.php and manually set $isShellDisabled to true