The following post are simple notes I took during the process of upgrading Magento from version 220.127.116.11 to 18.104.22.168. Please feel free to send in a comment if you have any questions. It’s been a while, but if I can be of help, I’ll definitely reply.
I started with 22.214.171.124 to 126.96.36.199 and with this being a Magento upgrade, I of course had problems. I then tried 188.8.131.52 to 184.108.40.206 and had the same problems. So most of the documentation here will be for a 220.127.116.11 to 18.104.22.168 upgrade path.
Things to do:
- I might want to run the database repair/compare tool in Development.
- Also, will want to finish up testing the upgrade so I know all the table ALTERs I’ll need to do. Maybe the work in step one above will help?
The idea below is that some of these tables so far that had been having problems updating/upgrading seem to be “index” tables. So, what I can do is completely drop these tables and then rebuild using the table schema of version 22.214.171.124.
This is my process:
1. block website
2. follow prep from Upgrade Procedure
3. run update script
4. update local.xml
<![CDATA[SET NAMES utf8]]> <![CDATA[mysql4]]> <![CDATA[pdo_mysql]]>
cp local.xml public/app/etc/local.xml sudo chown apache:apache public/app/etc/local.xml
5. php -f public/shell/log.php clean (this helps me get smaller tables to work with during the upgrade)
6. Fix error: Column “date” does not exists on table “catalog_product_index_website”
This fix for the issue is here: http://www.magentocommerce.com/boards/viewthread/246359/ (which reloading the entire table in step 7 above fixes)
There are a number of these issues with additional tables (oddly they are all tables that can be emptied). This is taken care of by dropping and recreating the tables (see: next step).
First skip the catalog_product_index_website table column name change (we’re doing this because we’ll be dropping and rebuilding the table)
vi public/app/code/core/Mage/Catalog/sql/catalog_setup/mysql4-upgrade-126.96.36.199-188.8.131.52.php lines: 4169-4177
This is what we’re commenting out:
$installer->getConnection()->changeColumn( $installer->getTable('catalog/product_index_website'), 'date', 'website_date', array( 'type' => Varien_Db_Ddl_Table::TYPE_DATE, 'comment' => 'Website Date' ) );
*Note: in the post below the author suggests commenting out many more of the upgrade that is causing error, in which some in the comments advised against since what you’re doing is actually skipping pretty important stuff. This is the only instance that I agree with and had went ahead and skipped as part of the upgrade procedure.
seen here: http://www.magentocommerce.com/wiki/1_-_installation_and_configuration/magento_1.5_to_1.6_upgrade
7. update/alter the problem tables
DROP these tables in the new database. These are empty on a clean install. IMPORT them via phpMyAdmin. They'll fill when Indexes are rebuilt: DROP TABLE `catalog_product_index_website`, `core_url_rewrite`, `report_viewed_product_index`;
You’ll first want to EMPTY the sale_flat_quote tables:
SET FOREIGN_KEY_CHECKS=0; TRUNCATE `sales_flat_quote`; TRUNCATE `sales_flat_quote_address`; TRUNCATE `sales_flat_quote_address_item`; TRUNCATE `sales_flat_quote_item`; TRUNCATE `sales_flat_quote_item_option`; TRUNCATE `sales_flat_quote_payment`; TRUNCATE `sales_flat_quote_shipping_rate`; SET FOREIGN_KEY_CHECKS=1;
Here’s some notes on the foreign key checks: http://stackoverflow.com/questions/9172677/can-i-truncate-the-sales-flat-quote-table-in-magento-database
This helps avoid a pesky foreign key constraint error. Unfortunately this will destroy your Wishlist and old Cart data/stats (this is something I was personally willing to do).
** I was actually able to skip this next part:
SET FOREIGN_KEY_CHECKS=0; DROP TABLE `sales_flat_quote`; SET FOREIGN_KEY_CHECKS=1;
Now start recreating the tables we just dropped:
/media/sf_VirtualBoxShare/catalog_product_index_website.sql /media/sf_VirtualBoxShare/core_url_rewrite.sql /media/sf_VirtualBoxShare/report_viewed_product_index.sql /media/sf_VirtualBoxShare/sales_flat_quote.sql
9. php public/shell/indexer.php reindexall (mentioned as import BEFORE instantiation: http://www.magentocommerce.com/wiki/1_-_installation_and_configuration/magento_1.5_to_1.6_upgrade)
10. instantiate the upgrade
This will inevitably fuckup and throw an error that you can see in var/reports/. Re-run the indexer and then reinstantiate:
php public/shell/indexer.php reindexall
11. return to Upgrade Procedure to cleanup:
In production I had a issue trying to “Reindex Data” getting an error message like:
Product Flat Data Index process is working now. Please try run this process later.
The fix is to remove everything in /var/locks/
During the process I almost always end up at the point in which I’m instantiating the upgrade and then an error is thrown. These errors are usually unfollowable at first. Here is a list of ways I’ve gotten to move forward:
The last time this happened it failed on sales_flat_quote because I was unable to fully delete it before the instantiation.
- run the reindexall tool and then re-instantiate (it may eventually show you where it fails)
It’ll fuckup, so re-run the reindex tool the re-instantiated (after fixing sales_flat_quote), then you’re good.
Issues after the Upgrade:
Default Sort Order Newest
Default sort order was off. I wanted to atleast get it to go back to using the entity_id (last added product first). I used a comment from this StackExchange post:
So in the following file:
I essentially changed this:
$_productCollection=$this->getLoadedProductCollection()->clear()->addAttributeToSort( 'entity_id', 'DESC' )->load();
PayPal NVP API Errors
-rwxrwxrwx 1 apache apache 131460 Jul 23 17:34 exception.log -rwxrwxrwx 1 apache apache 6258 Jul 23 16:44 googleshopping.log -rwxrwxrwx 1 apache apache 20894 Jul 23 16:44 system.log
Seeing the following errors in /var/reports/exception.og
One thing I did was to update Configuration > SALES > PayPal > API/Integration Settings (select “Get Credentials from PayPal” and enter). I used email@example.com as the PayPal account to get the API information.
PayPal Guest Checkout Issue
PayPal Guest Checkouts are going out without an email address. Therefore, emails are being sent out as “Guest” and that’s in the To: field, so basically the To: field is filled with “Guest” and not an actual email.
Going into Sales > Orders, under Account Information shows no Email, however, under Payment Information it does log the PayPal Payer Email.
The 2 comments here are the fix:
Editing the PayPal Guest Checkout Confirmation Page:
This is the confirmation page after I used PayPal to pay:
What we want to do is tell people to do 2 things:
- select Shipping Method
- confirm Shipping Information (sometimes PayPal’s address isn’t where you want the package sent)
- place order
Custom Option Is Not Displaying At Admin Orders
I ended up rebuilding 2 reporting tables (after clearing).
I started to thing that I might want to clear my log tables:
Magento Clearable Tables:
From Post: http://www.magentocommerce.com/boards/viewreply/277838/:
'catalog_compare_item', 'dataflow_batch_export', 'dataflow_batch_import', 'log_customer', 'log_quote', 'log_summary', 'log_summary_type', 'log_url', 'log_url_info', 'log_visitor', 'log_visitor_info', 'log_visitor_online', 'report_event', 'report_compared_product_index', 'report_viewed_product_index', 'sales_flat_quote_item'
Here’s some tools:
Here’s the resources I was looking at:
Similar issues with upgrade:
This guy had the same error with core_url_rewrites:
Here are some notes, POST upgrade:
Issue with Magento admin menu freezing up. Basically, it’s when the main menu in the Magento admin doesn’t drop down and all you can click is the Dashboard button. This is caused by permissions issues with the /js directory in the /media directory. The /media directory should be checked for permissions to match the original in this case. You can get away with just making owned by apache:apache in a pinch.
I noticed something about the Magento log files being 7 hours ahead. Apparently for things like cron and log files Magento overrides the server timezone: