SQL errors while upgrading to 1.2.5

[rossdavidh]

Hello,

While upgrading from 1.1 to 1.2.5, I got the message, "Unfortunately there were 19 SQL errors". This was, obviously, at the point in the install were it has recognized that I'm doing an upgrade instead of an install, and after the directory permissions had been set according to its instructions.

It gave me the entire SQL command (which I copied and saved, thanks for that), but not what the error messages were. Are these hidden inside the (quite lengthy) SQL command that it gave? Were they on that web page somewhere and I just couldn't see them?

Also, any advice on what the easiest way to reproduce the error messages so that I could see them is appreciated. I'm guessing I will take the SQL command and use it with the mysql command line, with error logging turned on? I don't have phpmyadmin or anything similar installed, but I can execute an sql file in mysql fine.

I don't know, however, if this is all that I need to do to do the upgrade? In other words, if I put all the code in and do this sql command (after somehow finding out what the errors were and addressing that), would the upgrade me completed? It seems like php and mysql is all that would be required but if there's something else going on that would be good to know.

All help is appreciated.

[rocky]

When the upgrade was performed, that entire SQL state was executed on your database. If there are errors that occurred, you need to go through the SQL and find error messages. The parts of the SQL query that worked will not have error messages and so you can ignore them. If you write just the error message lines here, we can try to help you fix them.

[rossdavidh]

Well, you're right, the errors are in there. I was searching for the word "error" or somesuch, and found nothing. Putting it into jEdit with an "sql" suffix (so that I got syntax color highlighting), allowed me to see the error messages as being such.

Most (16) of them are along the lines of 'Table [some name] already exists'. I think this is probably because I tried to upgrade to 1.2.4, then backed it out, but didn't back out the database changes (mistake). A few problems caused me to realize a day or more later that we had to delete some of the new tables, but I didn't delete all of them (just the ones that seemed to cause problems). So I guess I can delete any table that I get the "...already exists" message for, and then it will recreate it as part of the upgrade.

That leaves 3 more:

INSERT INTO `ps_group_lang` (`id_lang`, `id_group`, `name`) ( SELECT `id_lang`, (SELECT `id_group` FROM `ps_group` LIMIT 1), 'Default' FROM `ps_lang`)
(1062) Duplicate entry '1-1' for key 1

INSERT INTO `ps_customer_group` (`id_customer`, `id_group`) (SELECT `id_customer`, (SELECT `id_group` FROM `ps_group` LIMIT 1) FROM `ps_customer`)
(1062) Duplicate entry '2-1' for key 1

/* TIMEZONES */ INSERT INTO `ps_timezone` (`id_timezone`, `name`) VALUES (1, 'Africa/Abidjan'), (2, 'Africa/Accra'), (3, 'Africa/Addis_Ababa')...(snip very long list of worldwide time zones)
(1062) Duplicate entry '1' for key 1

I'm guessing this might be something similar? I am not as sure how to handle it, though. I don't think I want to delete the entire ps_group_lang, ps_customer_group, and ps_timezone tables, as I am guessing they already existed in version 1.1. However, I suppose I could be wrong on that. Is there a way I can (at the mysql command line, for example) fix the existing database so that these INSERT statements won't cause a problem? Is it ok to dump all of the rows of these tables and let the upgrade process just do the INSERT? Or do I have to go through and dump only the ones in these INSERT statements?

For that matter, should these errors even be a problem? If the tables and values already exist, can I ignore the errors and move on? I suppose something could have changed between 1.2.4 and 1.2.5 that would make that not work.

All advice is appreciated.

thanks,
ross

[rocky]

Actually, I think the customer groups and timezone tables weren't in v1.1. They are new to v1.2. Unless you've added customer groups, it should be safe to delete these tables and let the installer recreate them.

[rossdavidh]

You're right, all the errors are to do with new tables.

So, after backing up, I tried the install again. For some reason I don't know, I always have to repeat the copy
of settings.inc.php to the new folder to allow it to do an upgrade. I don't know the contents of this file, but either it keeps changing or the prestashop code is looking at the timestamp and comparing it to the other files, because it is always the case that it won't give me the option to upgrade until I again copy this file over from the old folder.

The other odd thing I notice is that the /img directory never turns green. I have set the permissions to 777, and confirmed this at the command line, but it never believes me. This was true in my initial install as well, if I recall correctly.

So, I complete the install without errors! Then I delete the install folder and rename the admin folder. Now, I can look at the back office without a problem. However, the front office (i.e. customer-facing web page) is completely blank. I refresh and look in a different browser, same story.

Sadly, I back out the new code (and the database, this time, won't make that mistake again I hope). The good news is the site works again, and has no issues. The bad news is I'm still not upgraded, and now I don't know what to check, really, because I have no errors.

The only odd thing I can think of with my shop is that prestashop is on a lower level, the top-level is wordpress. But I don't think this is that unusual of a setup.

Any ideas? All help is greatly appreciated.

[rocky]

It is normal that you must have the settings.inc.php file there for the upgrade option to appear. That is how Prestashop knows what version to upgrade from and what database details to use for the upgrade.

Blank pages are usually caused by PHP errors. You should check your for an error_log in Prestashop's root directory on your remote server. It will contain information on any errors that are occurring. If there isn't, you can try changing config/config.inc.php and changing 'display_errors' to 'on', then refreshing the Front Office to see the error message.

[rossdavidh]

Ok, I decided to start from scratch in case it mattered:

apt-get install unzip
psftp zipped copy of prestashop_1_2_5
have to chmod 777 secret-oktober.com
unzip prestashop_1_2_5
chmod 755 secret-oktober.com (just had to have this for unzip above to work)
rm prestashop_1_2_5.zip
cp -a prestashop/img/[asterisk] prestashop_1_2_5/img/[asterisk]
made a googlebase directory in prestashop_1_2_5/modules
cp -a googlebase/[asterisk] /home/secret-oktober.com/prestashop_1_2_5/modules/googlebase
cp -a htaccess /home/secret-oktober.com/prestashop_1_2_5/ just in case it matters
cp -a secret-oktober /home/secret-oktober.com/prestashop_1_2_5/themes/secret-oktober
turn prestashop off in back office, which won't last long because I'm about to
 change directories but at least it gives anyone still hanging around a little notice
disable googlebase
select default theme (this and the one above it shouldn't matter because I'm about to
 stop using the old prestashop directory anyway but at this point I'm paranoid)
cd to a directory where I can backup the database
mysqldump -u root -p [prestashop database name] > sopsbackupfile.sq
edit /home/secret-oktober.com/prestashop/config/config.inc.php to have debugging on
cp -a /home/secret-oktober.com/prestashop/config/config.inc.php /home/secret-oktober.com/prestashop_1_2_5/config
mv prestashop prestashop_old
mv prestashop_1_2_5 prestashop
browse to www.secret-oktober.com/prestashop/install

Then, I got "permission denied" in the browser (403 error). I guessed maybe my blank htaccess was causing a problem,
so I renamed that to remove it from consideration

mv htaccess htaccess.txt

I also noticed the owner on the old prestashop wasn't root, whereas on the new prestashop it was, so I
decided to change ownership of the new prestashop files in case that mattered

chown -R [same owner name as old prestashop folder] /home/secret-oktober.com/prestashop

Now I get this:

Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0

Fatal error: Unknown: Failed opening required '/home/secret-oktober.com/prestashop/install/index.php'
(include_path='.:/usr/share/php:/usr/share/pear') in Unknown on line 0

This is a different result from last time, when I just got a blank screen, so thanks to rocky for
showing me how to turn on error logging. I am wondering if my version of php is the problem, so I
did:

dpkg -l|grep -i php

...and saw:

ii  libapache2-mod-php5                    5.2.4-2ubuntu5.4            server-side, HTML-embedded scripting languag
ii  php5                                   5.2.4-2ubuntu5.4            server-side, HTML-embedded scripting languag
ii  php5-cli                               5.2.4-2ubuntu5.4            command-line interpreter for the php5 script
ii  php5-common                            5.2.4-2ubuntu5.4            Common files for packages built from the php
ii  php5-curl                              5.2.4-2ubuntu5.4            CURL module for php5
ii  php5-gd                                5.2.4-2ubuntu5.4            GD module for php5
ii  php5-mcrypt                            5.2.3-0ubuntu1              MCrypt module for php5
ii  php5-mysql                             5.2.4-2ubuntu5.4            MySQL module for php5

I would have thought 5.2.4 would be enough, but maybe I'm missing something? I can't seem to find the
system requirements anymore on prestashop's page. Does anyone know if the above php is missing
something required for prestashop 1.2.5?

All help is appreciated.

[rocky]

You need to click the "Validate and download Prestashop for FREE" button to see the PHP requirements now. You don't need to enter anything first before clicking the button. Anyway, here are the requirements:

* Some PHP 5 versions are bugged and prevent PrestaShop from working correctly:
- PHP 5.2.1 (authentication is impossible)
- PHP 5.2.6 (authentication is impossible under 64bits servers)
- PHP 5.2.9 (image management/upload broken)
- PHP < 5.2 (invalid date timezone)

It doesn't mention 5.2.4, so I think it should work.

[rossdavidh]

Hmmmm...I noticed a reference to pear in the error message, so I did the following:

apt-get install php-pear

(lots of messages, indicating success in installing pear)
Then, tried it again:

mv prestashop prestashop_old
mv prestashop_1_2_5 prestashop

browsed to the install page and:

Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0

Fatal error: Unknown: Failed opening required '/home/secret-oktober.com/prestashop/install/index.php' 
(include_path='.:/usr/share/php:/usr/share/pear') in Unknown on line 0

Looking in install/index.php, the only includes seem to be:

if(file_exists(INSTALL_PATH.'/../config/settings.inc.php')){
   include(INSTALL_PATH.'/../config/settings.inc.php');

...and...

include(INSTALL_PATH.'/classes/LanguagesManager.php');

Both of these seem to exist...[smacks forehead with palm]but no one but root has access to the files in the
new prestashop install, not even for read! Argh. Will try again.

[rossdavidh]

One thing about this upgrade, it's getting me up in the morning early on a regular basis, trying to complete it before there's much traffic on the website.

So, I have these errors when I browse to /install/ :

Warning: include_once(../classes/Validate.php) [function.include-once]: failed to open stream: No such file or directory in /home/secret-oktober.com/prestashop/install/classes/LanguagesManager.php on line 3

Warning: include_once() [function.include]: Failed opening '../classes/Validate.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /home/secret-oktober.com/prestashop/install/classes/LanguagesManager.php on line 3

So, I look in /install/classes/LanguagesManager.php on line 3, and I see this:

include_once("../classes/Validate.php");

The thing is, there is no Validate.php at /install/classes/ . There is a Validate.php at the /classes/ directory on the same level as /install/, so I changed the code to be

include_once("../../classes/Validate.php");

Same result, probably because that directory has different permissions on it.

So at this point, I have what looks, to me, like a software bug. Is there supposed to be a Validate.php in the /install/classes directory? Or is /install/classes/LanguageManager.php supposed to be including a file that isn't there?

I looked in the svn to make sure I hadn't missed a file:
http://svn.prestashop.com/tags/1.2.5/install/classes/

Is this a bug? Why would I be the only one seeing it? Any help is appreciated.

thanks,
ross

[rossdavidh]

Ok, I reported this as a bug, we'll see what comes of it. It seems odd that it could have a bug of this kind, because everyone should be having the problem, but I've looked at it for a while now and can't see how this should work, so perhaps a Bug report will at least resolve it one way or the other.