Do you have a dbase backup and files backup of when you were running 0.9.2? In other words can you make your blog come back to life on the old version?

The upgrade process works, but if something goes wrong it has no way to figure out exactly what went wrong and pick up the pieces. That's what you're trying to do: pick up the pieces and help it along. So can you get your blog back to a functional status at the 0.9.2 level?

As far as I know there is no way to install new then tell it "pull in this database that is not configured correctly (for the new version) and make it be like the new version needs".

Yes EdB, After trying to upgrade my 0.9.2 without success I decided to copy 1.9.1 to a new directory and make new sqlDB. I thought that would be easier afterward since all I have to change is rename the new directory and change the path in the code.

My old blog is still online working. and I only made new DB and backed my my old DB, renamed it and restored it to the new DB.

Also EdB I don't see why there is nor for the script to to check if it had upgraded part of sqlDB and keep track if the changes. Shouldn't that be part of what computer suppose to do? One idea is to create a temporary table to keep track of all the successful update and drop it after the upgrade is complete.

I can't explain why they do it the way they do - all I know is it generally works and if it doesn't you're stuck in a loop where it says "I gotta do this but it's already done!!!". As you've noticed :( Part of "why" might be because the upgrade process is supposed to be able to go from any lower version up to whatever version you're upgrading to. It uses a param in the settings table (I think) then says "if it's this I gotta do step 4 and 5 and 6 and 7 but if it's something else I gotta do steps 6 and 7". Even if the dev team changes the upgrade process in the future it won't help you now, so let's get your upgrade working if we can.

So you created a new DB and restored your real backup to the new DB. Was the new DB completely empty when you did this? For example if you did a sample installation of 1.9.1 and did not empty the tables before restoring your real backup then your test table will have all the fields and features of the new and the old, so having an empty DB before restoring an old backup is critical.

I'm guessing you have a new installation in a folder somewhere that connects to the new DB using the 1.9.1 files. For example yourdomain.com calls your real database with the 0.9.2 files, and yourdomain.com/upgradetest calls the new DB using the new files. Correct?

I'll ask just to verify that your upgradetest/conf/_basic_config.php file has the connection info for the new DB? Also the new baseurl path (of course).

Please excuse if you think I'm talking down to you or asking stupid questions, but when the upgrader gets stuck it's best to move very slowly and make no assumptions about anything. Oh and it's a good thing you tried upgrading out of the publicly available blog. Imagine how bad it would be if you had no backup and tried the upgrade...

So EdB I think I've got what you main but let me just make sure. You mean if I install ver. 1.9.1 as fresh installation and restore the backup file from my old version which I renamed to the new will only transfer the data and not change the structure if the DB.

If that is the case it would be very easy.

Thanks

Well, I'm not entirely sure because it depends on what your backup says. For example if it has "drop table if exists" or something like that then you'll end up with 0.9.2 exactly in the tables that existed in that version, but you'll also have the tables that did not exist then but do exist now. Plus, if your backup over-writes existing table structures you could end up with a field that used to be valid but has been renamed or had details of it's composition changed.

I would say the surest way to get it done is to make sure your new table matches exactly the old table. The way I do that is to use phpmyadmin to DROP all the tables in the database, then use cpanel's restore feature to restore a different database into it. I have to change the name of the backup when I do that though. Meaning my backup is usually something like bvlt1.gz (because I use fantastico). I then tell fantastico to make me a new installation, but it makes whatever version it likes. I use phpmyadmin to drop all the tables, rename my backup to bvlt4.gz, then use restore to upload that renamed file. I then have 2 databases that match each other exactly.

Final step for me is to save the conf/_basic_config.php file that fantastico made for the new installation, copy the important bits over to the version I want to play with, then delete all the new files from the server, then upload all my new files in their place. I run the installer and tell it I'm upgrading.

It's a bit cumbersome, but I've not had a problem doing it this way.

Edb,

Could you elaborate on the final step. It is not very clear when you said "bits over to the version I want to play with, then delete all the new files from the server, then upload all my new files in their place."

So let's say I want to run 092 but fantastico installs 186 for me - something I want to do to work with some old skins again.

When fantastico does it's thing it makes the database, the password, and the username. So I have to download conf/_basic_config.php file to learn what they are. That file also hase my baseurl path (as $baseurl) and my admin email ID, and a variable called $config_is_done. Once I have that I delete all the files on the server it made except for the folder it put the installation in. I also DROP all the tables using phpmyadmin. Not just empty - actually drop. In your situation you will want to restore your backup of the other database.

So I download 092 from sourceforge and unzip it on my PC. I then open conf/_config.php from 092 and conf/_basic_config.php from the 186 that fantastico made so I can copy the connection and path info from the 186 file to the 092 file.

Now I can upload mt 092 files and run the installer. In my case I'll be telling it to make a new installation, but you will want to tell it you're upgrading. For your situation the installer (which is also the upgrader of course) will look at the database connection info and connect. It will then see that the schema you have (a field in your settings table) is for v0.9.2 so it will do the stuff it needs to do to upgrade to 1.6 then 1.8.2 then 1.8.6 then 1.9.1 - though it's possible there are no new database configurations for 1.8.6.

Anyway you get the idea I trust: upgrading looks at the database then does incremental adjustments to make the database layout match the needs for the current set of files you have. That's why it's important that your database layout match exactly what it was supposed to be for the version that your settings table says you have. If it thinks you have 092 and tries to add (pretend) a new field to the posts table but finds the field already exists it breaks: it can't deal with the fact that it's already there because it simply shouldn't be there.

Sorry EdB, I'm still not clear on this. Here is what I have and the steps I've taken I understand them:

I have:

1 - My old 0.92 which online with database bvlt1

2- I have a backup copy of the above (0.92) database named bvlt1.

Here are the steps as you suggested:

Step 1: Upload 1.9.1 on a new directory and run installer as new installation. It makes database with the name bvlt2.

Step 2: I rename bvlt1.gz to bvlt3.gz.

Step 3: I save config/_basic_config.php in my desktop.

I'm not clear on what come next.

kskhater wrote:

Sorry EdB, I'm still not clear on this. Here is what I have and the steps I've taken I understand them:

I have:

1 - My old 0.92 which online with database bvlt1

2- I have a backup copy of the above (0.92) database named bvlt1.

Here are the steps as you suggested:

Step 1: Upload 1.9.1 on a new directory and run installer as new installation. It makes database with the name bvlt2.

Step 2: I rename bvlt1.gz to bvlt3.gz.

Step 3: I save config/_basic_config.php in my desktop.

I'm not clear on what come next.

Nope. You have a backup file called bvlt1.gz, which is your real database backup. You have a new installation with a database called bvlt2, so you want to rename your existing backup bvlt2.gz because you're going to restore that to the new database.

Okay so you used b2evolution to make the database. I didn't know you could do that, but that's fine because that means the files on your server know how to talk to bvlt2 - which is what you want.

Use phpmyadmin - a tool normally made available by your webhost - and select the bvlt2 database. Use the link to "select all" the checkboxes, then use the dropdown box to DROP all the tables. The new table - the one that gets used by 1.9.1 - is now completely empty. It still exists, but it has nothing in it.

Now use restore (cpanel utility) to upload bvlt2.gz - the file that used to be called bvlt1.gz - and the restore utility will automatically fill the contents of that file into the second database.

Now go to your installer for the 1.9.1 installation in the separate directory and run it again. This time tell it you're upgrading. If all goes well your database will update and you'll have a second copy of your blog running. You will have the original running 092 and the new one running 191.

Don't forget to delete the install folder when you're done.

Hey I got an idea. If you're okay with it how about PMing me with a link to where I can download a copy of your 0.9.2 database backup (in .gz format) so I can try to upgrade it to either 1.8.6 or 1.9.1? Assuming success I'll do a backup and PM you with a link to where you can get it back from.

Here is the link to bvlt1.gz

http://www.alkhater.net/blog/dloadfiles/bvlt1.gz

I did what you suggested in your previous message but I'm back to squire one. I get the following error:

Table 'evo_sessions' already exists(Errno=1050)

Your query:

CREATE TABLE evo_sessions (
sess_ID INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
sess_key CHAR(32) NULL,
sess_lastseen DATETIME NOT NULL,
sess_ipaddress VARCHAR(15) NOT NULL DEFAULT '',
sess_user_ID INT(10) DEFAULT NULL,
sess_agnt_ID INT UNSIGNED NULL,
sess_data TEXT DEFAULT NULL,
PRIMARY KEY( sess_ID )
)

I hope you can succed in upgrading my old database. That will really make my day.

Best of luck.

That's not a backup from a 0.9.2 installation. It has tables that did not exist then (like plugin tables), so that must be a backup from after you tried to upgrade. This means that it won't upgrade because, well, because the table is not in a known configuration. Sorry, but I'll be up against the same thing you are: every step of the way it will try to do something that's already done. So you'll have to manually handle it all.

What version were you trying to upgrade to before you grabbed this backup of the database? It looks like a 1.8.6 database because it doesn't have evo_item, but I can't tell by looking if it has everything a 1.8.6 installation would have. I'm thinking you could TRY to tell the database it's a 1.8.6 database by changing the value for 'db_version' in the evo_settings table to 9200, then try to use your files to upgrade to 1.9.1, but there are no promises this will work. Bummer about not having a pre-upgrade backup :(

I checked my bvtl1 in PhpMyAdmin and it does not have a table called plugin although in the backoffice it shows that I have plugins.

Also never mind the tables that do not have evo_ becuase I added these later for other use like mailing list etc.

I also check my online b2evo which uses bvtl1 and it is 092.

also here is the link to enbvlt.gz

http://www.alkhater.net/blog/dloadfiles/enbvlt.gz

After I tried to upgrade

The backup has them, and that's what is causing the installer to not be able to upgrade. Having an unused table (plugins in v092) won't stop it from running. Having something exist that the upgrade process is required to build will.

Those backups simply won't upgrade BECAUSE they already have tables (and fields in tables) that the upgrader wants to create. That's what all the errors you're seeing are all about, as you've already noticed.

You don't have a backup from BEFORE attempting to upgrade to 1.8.6?

A regular installation of 0.9.2 has 12 tables. Ignoring the evo_ prefix they are:

• antispam

• blogs

• blogusers

• categories

• comments

• groups

• hitlog

• locales

• postcats

• posts

• settings

• users[/list:u]

EVERYTHING that your backups have that are not something you specifically added are the problem. Your choices are to alter the evo_settings table db_value field to 9200 and hope that all the tables and fields required have already been created, OR, to delete all tables that are not part of the 0.9.2 package (other than the tables you personally added). There is no certainty this will work because sometimes upgrading will change or add fields within an existing table. Either way, without a backup from before you tried upgrading it's going to be a manual process that you will have to work through each step of the way.

I never upgraded my bvtl1 to 1.8.6 I got this when I upgraded from b2evo v 0.9.0.12.

Is there a way to downgrade from 092 to b2evo v 0.9.0.12. and start again?

I have changed the db_version to 9340 in evo_settings and it seems I've passed the db upgrade but I get the following errors:

Notice: Undefined property: blog_urlname in /home/alkha4/public_html/en_blog/inc/MODEL/collections/_blog.class.php on line 162

Notice: Undefined property: blog_allowcomments in /home/alkha4/public_html/en_blog/inc/MODEL/collections/_blog.class.php on line 166

Notice: Undefined property: blog_allowblogcss in /home/alkha4/public_html/en_blog/inc/MODEL/collections/_blog.class.php on line 168

Notice: Undefined property: blog_allowusercss in /home/alkha4/public_html/en_blog/inc/MODEL/collections/_blog.class.php on line 169

Notice: Undefined property: blog_media_location in /home/alkha4/public_html/en_blog/inc/MODEL/collections/_blog.class.php on line 174

Notice: Undefined property: blog_media_subdir in /home/alkha4/public_html/en_blog/inc/MODEL/collections/_blog.class.php on line 175

Notice: Undefined property: blog_media_fullpath in /home/alkha4/public_html/en_blog/inc/MODEL/collections/_blog.class.php on line 176

Notice: Undefined property: blog_media_url in /home/alkha4/public_html/en_blog/inc/MODEL/collections/_blog.class.php on line 177
An unexpected error has occured!

If this error persits, please report it to the administrator.

Go back to home page
Additional information about this error:
Unhandled LIMITING mode in ItemList (paged mode is obsolete)

Thanks for your patience.

You're getting those errors because the upgrade was not complete. I told you there was no promise it would work right?

So now you can try to figure out exactly what field in which table needs to be modified to make the program run again, OR, to restore your blog to v0.9.2 (which is what you were running when the evo_settings table db_version field got set to 8600), deleting all the tables that are not on the list of tables I provided you, and HOPING that method will work.

Without a backup from before you tried upgrading there is no easy method to get you to a functional and updated blog again. I'm sorry, but there is nothing else to do but figure it out the hard way.

Finally I've done by deleteing all the files except the one you listed. But I lost my categories (I did not drop the table).

The other problem I've now is with the skin. I have change my old kubrick2evo main as recommended but I get an error when I try to exit the backoffice in the line I commented with error:

<?php
// -------------------------- CALENDAR INCLUDED HERE -----------------------------
// Call the Calendar plugin:
$Plugins->call_by_code( 'evo_Calr', array( // Params follow:
'block_start'=>,
'block_end'=>, // error
'title'=>, // No title.
) );
// -------------------------------- END OF CALENDAR

----------------------------------

The other problem is the image of the skin is not showing in the list of available skins but only the name.

?>

Thanks EdB,

I finally was able to upgrade by keeping the tables you suggested and deleting the rest.

But now I get the following 2 errors when I display the page:
1)

Notice: Undefined property: allowpingbacks in /home/alkha4/public_html/en_blog/inc/MODEL/dataobjects/_dataobject.class.php on line 461

20

Original design by Michael Heilemann, modified for b2evolution by EdB
Valid XHTML :: CSS
Notice: Undefined variable: sponsored_links in /home/alkha4/public_html/en_blog/skins/kubrick2evo/_main.php on line 341

Can you help with that. Thanks again