I know how painful Magento upgrades are, so I am posting something that worked for me upgrading from v 126.96.36.199 stable to 188.8.131.52 stable both without sample data. Some errors did occur (posted below).
Hosting: Godaddy Shared;
Server API: CGI/FastCGI (I have disabled fastCGI for “Duplicate Header” issues)
PHP Version: 5.2.14
Zend Optimizer/-TS/Level: 3.3.3/3.3.3/15
php5.ini Non-Production! Settings :
register_globals = On | allow_url_fopen = On | register_long_arrays = On | output_buffering = On | max_input_time = 600 | upload_max_filesize = 104857600 | post_max_size = 104857600 | variables_order = “EGPCS” | rg_emulation = Off | short_open_tag = 0 | zlib.output_compression = Off | cgi.rfc2616_headers = 0 | memory_limit = 3221225472 | max_execution_time = 3600; | realpath_cache_size = 104857600 | magic_quotes_gpc = Off | session.auto_start = Off | suhosin.session.cryptua = Off | SecFilterEngine = Off | SecFilterScanPOST = Off | zend.ze1_compatibility_mode = Off | soap.wsdl_cache_enabled = 0 | soap.wsdl_cache_ttl = 0 | log_errors = On | ignore_repeated_errors = Off | ignore_repeated_source = Off | report_memleaks = On | track_errors = On | cgi.fix_pathinfo = 1
Store Settings: original version 184.108.40.206 without sample data | multi-website, single-store, multi-store-view | all caches disabled including external | exception.log and system.log are enabled | extensions are present, including resource-dependent | categories and products are present | custom attributes and attribute sets are present
NB Sequence below is important!
01) Backup current database via Godaddy Control Center >> MySQL, phpMyAdmin or shell using mysql command if you have mysql.sock access.
02) Create a new database via Godaddy Control Center >> MySQL, phpMyAdmin or shell.
03) Restore the backup database to the newly-created via shell using mysql command if you have mysql.sock access. For Godaddy account holders, just restore new database in phpMyAdmin to the backup database from step 01. To do this, you should choose the backup database name in Hosting Control Center >> MySQL >> Edit/View Details for new database >> Restore.
04) Rename .htaccess to .htaccessSOMETEXT to restore right after installation - the original is going to be overwritten.
05) Create site backup via shell and place above the current directory (e.g., /USER/PATH/xBackup-X.X.X.X). GoDaddy also stores up to 30-night backups in /home/content/.snapshot/YOURUSERPATH
06) Make sure .htaccess is not re-created in the backup directory for restore purposes.
07) Delete stats folder in the backup site folder.
08) (!) Modify html/app/etc/local.xml to point to the new database.
09) Make sure mage file in the current site folder is readable and executable.
10) Run the following commands in shell:
11) Replace #MAGE_PHP_BIN="php” with MAGE_PHP_BIN="/usr/local/php5/bin/php” (or, YOURPATH/TO/php5 binary) in mage file.
rm -rf var/cache/* var/session/*
./mage mage-setup .
./mage config-set preferred_state stable
12) Run command
./mage install http://connect20.magentocommerce.com/community Mage_All_Latest --force
13) Rename .htaccessSOMETEXT from step 04 to .htaccess
14) Run file access permission commands in shell as follows:
(Please check postings for other folders or more correct access levels).
chmod 755 php5.ini mage install.php get.php index.php cron.sh cron.php
chmod 772 var/log/*
chmod 770 var/report/
15) Empty (DO NOT DELETE!) table core_url_rewrite in the NEW database via phpMyAdmin.
16) Run database reindex command
in shell. If getting “Parse error: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR ‘}” error executing php code, use correct PATH in the following command:
/cgi-bin/php5 -f shell/indexer.php reindexall
17) If getting table errors related to reindexing or notice no re-write in category and product urls in browser, repeat steps 15-16.
YOURPATH/TO/php5 -f shell/indexer.php reindexall
18) Check site integrity and extension functioning.
19) Check logs in var/report and var/log for errors after browsing the site.
20) Update extensions via MagentoConnect or shell if needed.
01) SQLSTATE: Integrity constraint violation: 1062 Duplicate entry ‘9-General’ for key 2.
Solved by deleting attribute_group_name “General” with attribute_set_id “9” in eav_attribute_group table. The key is related to a custom attribute set and it was auto-recreated later.
02) Column “privileges” does not exists on table “api_rule”.
Solved by re-submitting the url when browsing. On checking the database, column “privileges” does not exist - empty “api_privileges” is there instead. At least one other unrelated installation had this issue so far.
01) API SOAP v2 retrieves operation list only when the newly-added WS-I compliance is activated in a third-party client. Have not been able to log in yet with or without WS-I compliance. No such issue with v. 220.127.116.11.
02) Browser access to FULLDOMAINPATH/api/xmlrpc or FULLDOMAINPATH/index.php/api/xmlrpc returns code 630, “Unable to read request” ...
Hope this helps!