Struggling with Upgrade from 2.0.RC5 to 2.0.4

[akc42]

I am running the update.php script to move my site from 2.0.rc5 to 2.0.4.  I am doing this as a trial run on my development server.  My mind is hazy about how update.php used to work, but certainly this time it appears to be making ajax requests to perform the database upgrade.

From the update.php main page I have reached step 4 database update, and from that page it just tells me that the script is taking too long to execute.  However, when I look at Firebug, I can see ajax responses saying "Duplicate column name 'redirect'"

Looking at at the update-2.0_mysql.sql script there is an alter table for the boards table which attempts to add the column redirect.  However, I can see that this script is convoluted mixture of php and sql, so I can't figure out how it works.

Can someone point me on the way of solving this little riddle.  How does the update script work?  Why am I getting this ajax response?

[kat]

The fact that you're mentioning update.php, rather than UPGRADE.php makes me think you're simply using the wrong archive/package.

You need to BACKUP FIRST!!!

Then, you want this file:

http://download.simplemachines.org/index.php?thanks;filename=smf_2-0-4_upgrade.zip

and you want to do this, with it:

http://wiki.simplemachines.org/smf/Upgrading

[akc42]

Sorry - my bad.

I am running upgrade.php - the file I am concerned about was upgrade_2.0_mysql.sql. 

they all came from

smf_2-0-4_upgrade.tar.bz2.

I am using a trash database - this is just a trial run to see it all works.  And it didn't.  Until I fix this, I won't even attempt to try it on the live site.

[akc42]

I have been making some progress with this - after some struggling to get Eclipse and a XDebug to allow me to debug the code.

Firstly.  I am not 100% sure it is intentional we are running the upgrade_2-0_mysql.sql script.  The upgrade.php script is set to be run for every version less than SMF v3.0, despite my database probably already being at the correct value.  The only reason I can see is that it ends up writing 2.0.4 in the variable settings in the database as being the current SMF version.

Secondly, the software seems to be written to catch errors in queries run from the script by setting an SQL error handler function.  The SQL in question is ALTER TABLE smf_boards ADD column redirect varchar(255).  This table and column is already in my database so an error is generated.  The error handler is not called (or at least the breakpoint I put in the error handler is not called)

I think, even if it had, it returns without doing anything.  I am not sure what that means yet.

However what happens is that  the script dies outputting the simple error "Duplicate column name 'redirect'"

Because this is an ajax call, the ajax call terminates, but because its not valid xml, there is no apparent return and the script appears to just hang.  The top level version of the script then reports that the step timed out.

I am stuck now - what is supposed to happen in this case?

[kat]

I'll be honest, here... I have no idea where all this "Ajax" stuff is coming from.

[akc42]

I'll be honest, here... I have no idea where all this "Ajax" stuff is coming from.

As far as I can work out, the Logon part of the form attempts to send a post via ajax with a js_works value set to 1.  If the script picks this up, it marks itself as javascript capable and from then on, uses ajax to request the next step in the upgrade process. So instead of self submitting the form to the script, its works its way through the process with ajax calls.

[kat]

Humour me, here, would you?

What happens, if you go to 2.0.0, first? Does that go through?

[akc42]

Humour me, here, would you?

What happens, if you go to 2.0.0, first? Does that go through?

I'll give that a try shortly, although in my environment its a little tricky to set up.  In the meantime I am puzzling over why $context is never set up by the upgrade script.

$smcFunc['db_error'] dies on an error if it is not set.

[akc42]

Nor for that matter is $txt['database_error'] set up. 

This is what causes smf_db_error to die on line 569 of Subs-Db-mysql.php

Code Select Expand


// Nothing's defined yet... just die with it.
if (empty($context) || empty($txt))
die($query_error);

// Show an error message, if possible.
$context['error_title'] = $txt['database_error'];


[akc42]

I got my upgrade working with some code modifications.  I have posted this, reporting it as a bug in the bug reports forum.  I'll wait for a response (or not) there before going any further.

[kat]

Good plan.