Upon update, blank page on checkout_shipping

Hi, I'm fairly new to zencart, but have searched all of the forums here as well as update guides and can't seem to figure out what's happening or how to fix it. I'm throwing a lot of information up here because I really have little idea as to where my hangup is coming from.

I'm updating a site from 1.3.8a to 1.5.1
I'm currently trying to test it with xampp, but originally tried with a live server.
I start out with the full unaltered version of 1.5.1, install it.
Then import the full original database into the freshly created one.
Then I use zc_install to update the database. This is where I appear to start getting errors. I've done incremental updates to see where the possible problems might be starting.

These errors appear to be the only ones I get and they happen in the upgrade from 1.3.9 to 1.5.0:

Cannot drop index page_accessed on table admin_activity_log because it does not exist.
ALTER TABLE admin_activity_log DROP INDEX page_accessed;
2.
Cannot drop index access_date on table admin_activity_log because it does not exist.
ALTER TABLE admin_activity_log DROP INDEX access_date;
3.
Cannot add index idx_page_accessed_zen to table admin_activity_log because it already exists.
ALTER TABLE admin_activity_log ADD INDEX idx_page_accessed_zen (page_accessed);
4.
Cannot add index idx_access_date_zen to table admin_activity_log because it already exists.
ALTER TABLE admin_activity_log ADD INDEX idx_access_date_zen (access_date);

From what I've searched, these can be common errors and perhaps can be ignored. It appears to be an error thrown from within the Your_admin/includes/configure.php file having to do with DB_ settings. I can't get a clear answer as to whether the settings need to be the same exact DB settings as the original live site in order to avoid this error, and whether this has anything to do with my checkout_shipping blank page error. It does seem to me that the page_accessed and access_date columns should have their names changed to get everything inline with where 1.5.0 is kosher, but just going in and manually changing the names only messes things up more. Furthermore, on the fresh install of 1.5.1 they are named as that and not idx_page_accessed_zen and idx_access_date_zen, so I'm not really sure if this is something that requires my attention.

Since I'm working with a fresh version of 1.5.1 (and have not yet added any modifications, not even template changes) and problems only show up when I try to load the old database, my conclusion is that there's something within the database that is probably causing my problem. From what I can assess, there should only be a couple of modifications reflected in the database. What ever changes might have been made with an older version of Super Orders (which was installed long before I came into the project) and a referral customization that I made on the shipping page that required two columns, order_refer and order_refer_detail in the orders table. As I said I have none of either one of those customizations reflected within the actual php code, so I don't know how they would affect anything, but thought it might be worth mentioning.

Also, I've checked the error_log file, and this is what I get:

[26-Mar-2010 00:21:43] PHP Warning: Module 'PDO' already loaded in Unknown on line 0
[26-Mar-2010 00:21:43] PHP Warning: Module 'PDO' already loaded in Unknown on line 0
[26-Mar-2010 00:21:43] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/pdo_pgsql.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/pdo_pgsql.so: cannot open shared object file: No such file or directory in Unknown on line 0

I've searched these errors, and can't seem to anything recent regarding zencart. Besides that I can't figure out what Module 'PDO' is.

Any help here would be greatly appreciated. I've been stuck on this for days and have combed the forums and tutorials on here with little success.

Upon further investigation, it appears that the Super Orders Module is what's causing so much strife. I've found many instances of super_order references within the configuration and the admin_activity_log tables.

I've not been able to find an unistall file for the Super Orders version that the site has as it dates all the way back to 2005. The oldest available version on here does not include an unistall file.

Could I dump admin_activity_log entries without losing vital information?

Also, if I dump every entry in the configuration table that refers to super_orders files, might this correct my problem?

Or is there a tool that could clean all of this up for me?

UEntity:

These errors appear to be the only ones I get and they happen in the upgrade from 1.3.9 to 1.5.0:

Cannot drop index page_accessed on table admin_activity_log because it does not exist.
ALTER TABLE admin_activity_log DROP INDEX page_accessed;
2.
Cannot drop index access_date on table admin_activity_log because it does not exist.
ALTER TABLE admin_activity_log DROP INDEX access_date;
3.
Cannot add index idx_page_accessed_zen to table admin_activity_log because it already exists.
ALTER TABLE admin_activity_log ADD INDEX idx_page_accessed_zen (page_accessed);
4.
Cannot add index idx_access_date_zen to table admin_activity_log because it already exists.
ALTER TABLE admin_activity_log ADD INDEX idx_access_date_zen (access_date);

From what I've searched, these can be common errors and perhaps can be ignored.Yes, they can be ignored. They're not even errors, merely messages that certain steps weren't needed because they were already taken care of. Some of those steps have to be attempted in order to take care of legacy structures from much older versions.
They are nothing to worry about.
UEntity:

It appears to be an error thrown from within the Your_admin/includes/configure.php file having to do with DB_ settings. I can't get a clear answer as to whether the settings need to be the same exact DB settings as the original live site in order to avoid this error, and whether this has anything to do with my checkout_shipping blank page error.No, it has nothing to do with checkout_shipping.
UEntity:

It does seem to me that the page_accessed and access_date columns should have their names changed to get everything inline with where 1.5.0 is kosher, but just going in and manually changing the names only messes things up more. Furthermore, on the fresh install of 1.5.1 they are named as that and not idx_page_accessed_zen and idx_access_date_zen, so I'm not really sure if this is something that requires my attention.No, you're misreading the messages. Ignore them.

UEntity:

Since I'm working with a fresh version of 1.5.1 (and have not yet added any modifications, not even template changes) and problems only show up when I try to load the old database, my conclusion is that there's something within the database that is probably causing my problem.Probably a fair conclusion.> UEntity:

From what I can assess, there should only be a couple of modifications reflected in the database. What ever changes might have been made with an older version of Super Orders (which was installed long before I came into the project) and a referral customization that I made on the shipping page that required two columns, order_refer and order_refer_detail in the orders table. As I said I have none of either one of those customizations reflected within the actual php code, so I don't know how they would affect anything, but thought it might be worth mentioning.The system generally won't be bothered by the presence of those additional fields.

UEntity:

Also, I've checked the error_log file, and this is what I get:

[26-Mar-2010 00:21:43] PHP Warning: Module 'PDO' already loaded in Unknown on line 0
[26-Mar-2010 00:21:43] PHP Warning: Module 'PDO' already loaded in Unknown on line 0
[26-Mar-2010 00:21:43] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/pdo_pgsql.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/pdo_pgsql.so: cannot open shared object file: No such file or directory in Unknown on line 0Those are issues your hosting company needs to deal with, because they're problems with the webserver's PHP configuration. They're not from Zen Cart.
UEntity:

Besides that I can't figure out what Module 'PDO' is.PDO is a database-engine access client program. Again, you don't need to know anything about that. Simply report those warnings to your hosting company and get them to fix that.
It's unlikely that they're related to your checkout_shipping issue either, unless you've added something to your site that needs something specific via PDO ... which would be pretty rare but without knowing what shipping modules/plugins you've added to your site it's tough to give a definitive statement on that.

More likely is that your actual problem will be explained in the myDebug-xxxxxx.log files, as explained here: http://www.zen-cart.com/content.php?124-blank-page

UEntity:

Could I dump admin_activity_log entries without losing vital information?Those are merely activity logs, and have nothing to do with checkout. Those records are the history of all admin logins and activities, and are used for security audits, etc.

UEntity:

Also, if I dump every entry in the configuration table that refers to super_orders files, might this correct my problem?
Well, that would probably create more of a problem than it would fix. If your problem is really super_orders, then you need to remove the super_orders code changes that were made to all your PHP files first. For both admin and non-admin.

After that you can remove any database entries that were made when you installed super_orders.

As for the configuration table, be mindful that many plugins make MORE changes than merely configuration-table entries. But if it's those entries you want to remove, first find the super-orders entry in the configuration_groups table, see what number is assigned to it, and then delete all entries from the configuration table whose config group id is the same as the id in the configuration_groups table, and then delete that entry from the configuration_groups table too.
But that's not always a complete removal. Look at the installation instructions/scripts that you used when you first installed it, since that'll show you what was done to the database.
And probably has nothing to do with checkout.

IIRC, the only connection to checkout that the super-orders module has is a purchase-order payment choice. But that has nothing to do with checkout_shipping.

Thanks DrByte!

I did go over the page you suggested. Part of what's got me so confused is that I'm using a fresh install of 1.5.1. It has none of the Super Orders file edits in it. I've compiled a set of files that I can use to overwrite everything as soon as I can update the current database to a 1.5.1 site. It includes an up to date Super Orders install, a Captcha module install, my modifications and the theme folders. Of course that itself might require testing as well, but I haven't even gotten to that point yet. So at this point, I don't see how there could be any php errors driving this.

From using winmerge between the current site and the out of the box version of that site (1.3.8a), the only real differences between files consists of Super Orders, my couple of customizations and the theme files, so I can't imagine that there would be anything else within the database that would be causing me trouble.

Regarding the changes that were made by Super Orders when it was added, I have little frame of reference as I had nothing to do with that installation and I can't seem to find that version of Super Orders on this site. It was written in 02/03/2006 and the oldest version was written by the same author 08/26/2006. I downloaded that version hoping it might have an uninstallation file. I do have a sql file that might help me glean something, but again, it is a different version so I don't know how much it will help me.

I will experiment with the configuration and configuration group tables to see if that can get me somewhere. At this point, nothing is live or in danger of getting lost.

Okay, I went through the SQL file that comes with Super Orders and Deleted every single database entry that's created by the Module, still get the same result.

http://www.zen-cart.com/content.php?124-blank-page

I've come by that link a couple of times. It looks as though all of the possible problems it outlines come from the php and not the database. I've uploaded this as a fresh site too many times to count using both hosting servers and my own computer (via xampp). I don't see how it's possible that a file would have partially uploaded every time. I'm using Dreamweaver as FTP. I did try to use the debugging method listed at the bottom, but it won't show on the checkout_shipping page, only a blank page.

I'm at the point where I'm inspecting the database itself for clues as to what the problem is. You keep pointing me to the php files, but as I've said this is from a completely fresh install, no modules, no modifications of any kind are in the files I'm using at this point. After further investigation, I've found three tables that are carrying over into the new database, 2 nochex tables and a customer_wishlist table (which appears to have been there for future updates, not used in this version though). This all is kind of confusing to me as I see that nochex is a module, and all of the files from nochex are in the original site, but they also all seem to be in the 1.3.8a zencart download that I used to compare changes and deviations.

In any case, I removed those tables, the only tables that I could see created by the module, according to it's SQL site anyway. But alas, this did nothing to help my situation. Did I do the correct thing in removing these tables? I still have a backup, I just don't see that these tables are relevant to a new install at this time.

Upon inspecting the configurations table I did notice that there are a good 80 entries more than what the fresh 1.5.1 install creates. I'm guessing this could give me some clues as to what's triggering the problem, but what would I be looking for that's out of the ordinary?

The nochex tables are added by the nochex module if you install it and use it.
The customers_wishlist table was never used by Zen Cart, and has been removed for fresh installs.
Hence the differences you pointed out. Nothing to worry about there.

Stop looking at the database until you have concrete proof that there is a specific error message pointing to a problem with database tables or queries.

The reason I'm pointing you to the Blank Page FAQ article is because A BLANK PAGE IS CAUSED BY A PHP FATAL ERROR WHICH HALTS EXECUTION. And since Zen Cart is set up to output those PHP errors to a myDebug-xxxxxx.log file in your /logs/ or /cache/ folder.

If you won't look at those logs, it's very very very difficult to help you.

Part of the problem here is that using xampp, I'm not getting an errorlog file for some reason, I'm assuming it's the difference of using my computer as a server vs using a host. But when I did try this process through a hosting site, the error log showed the errors that I listed above, that you attributed to the hosting company. I looked in to my cache folder as well to see if the error log was created there, but there's nothing there either.

Maybe your PHP configuration is preventing Zen Cart from being allowed to override it and put debug info into files. Or maybe the logs folder isn't writable so it can't write out the debug logs.