Comments for Upgrade to 4.2 Problems

Upgrade to 4.2 Problems

2008-08-14T19:29:15Z

I upgraded from 4.12 to 4.2. The upgrade from 3.5 to 4.12 went flawlessly. So, this should be a simple thing, right? All the templates for my blog are gone. I did exactly that same thing I did when I upgraded from 3.5 to 4.12. Copied the files to the MT4 directory on my server. Went to http://www.server.com/cgi-bin/mt4/mt.cgi. Got redirected to the upgrade cgi which appeared to proceed without incident. Once it was done, there was a button to go to Movable Type control panel. Off I went. Hum, looks OK. Let's rebuild and see what happens.

Uh oh. Error. Oooh look, edit template button, how cool is that!! Hey, that's not a template I've ever used. Better go look at the templates and see what's changed. Uh, whadda ya mean No Templates found?? That's not good.

So, that's where I'm at. I was planning to go looking for the templates. I have no idea where they are stored. My guess is the MySQL database which is where I was planning to look next. I should also point out that I cannot Create New Template from the MT Control Panel either. Which probably implies deeper problems.

I always installed from downloads on the download page at Six Apart. I had 3.52, I think, for a long time. I avoided upgrading because of this very reason. A couple of weeks ago, I downloaded 4.12 from the Six Apart download page and upgraded my install. That upgrade went off without a hitch. Hence my confidence in upgrading from 4.12 to 4.2.

All in all, a lousy upgrade experience.

Smittie

Comment from Byrne Reese on 2008-08-13

2008-08-14T03:37:39Z

@Smittie - do you mean that simply by upgrading to 4.2, and doing *nothing else*, Movable Type physically deleted all of your templates? That's it? That's just wrong, but it is also very hard to believe as there is no code that I am aware of that deletes templates upon upgrading. Perhaps there is a bug, but I would like to work with you to get to the bottom of it. Can you explain exactly what you did, perhaps in our forums, so that I can assist?

Comment from Smittie on 2008-08-13

2008-08-14T03:51:22Z

Insofar as I know, yes. I did exactly that same thing I did when I upgraded from 3.5 to 4.12. Copied the files to the MT4 directory on my server. Went to http://www.server.com/cgi-bin/mt4/mt.cgi. Got redirected to the upgrade cgi which appeared to proceed without incident. Once it was done, there was a button to go to Movable Type control panel. Off I went. Hum, looks OK. Let's rebuild and see what happens.

All in all, a lousy upgrade experience.

Smittie

Comment from MikeT on 2008-08-14

2008-08-14T12:00:16Z

Smittie, your best bet is to export your blog and reimport it into a clean installation of Movable Type. An upgrade from 3.5, to 4.12, to 4.2 may have some issues with old, dead code in the core and plugins getting left behind.

Comment from Smittie on 2008-08-14

2008-08-14T18:20:36Z

@MikeT I fail to see how that will resurrect the templates and style sheet that I had built and which is now missing.

The style sheet got blown away when MT 4.2 tried to rebuild the site. It overwrote the existing style sheet.

To be perfectly honest, if I have to rebuild – which it appears I do – I'm going to look at the other content management systems out there. This is completely unacceptable. A simple update should not permit data loss.

Smittie

Comment from Byrne Reese on 2008-08-14

2008-08-14T18:26:13Z

@Smittie - You seem to have run into a legitimate bug. Another user in our forums reported a similar problem. The good news is that they have been very forthcoming with information and data, and in their case, their templates were NOT deleted. Something happened that resulting in MT losing the association of their templates with their blog. Obviously, far from ideal (duh), but at least data was not lost.

I want to clarify one thing however - you said you upgraded from MT 3.5. Were you using the project codenamed "Wheeljack?" There was a version of MT released through subversion called 3.5 or Wheeljack, but it was never released nor officially supported. In fact, I can say for certain that there would be forwards compatibility issues between 3.5 and 4.x. Can you confirm what version of MT you had installed?

Comment from Smittie on 2008-08-14

2008-08-14T18:51:16Z

Smittie

Comment from Byrne Reese on 2008-08-14

2008-08-15T02:29:04Z

Smittie - engineers have investigated the data you have given us and it looks like your system was not properly or completely upgraded. There are tables that are completely missing that would be there if the system upgraded properly, and your database registers a MT schema version that does not correspond to the schema version of 4.2.

Engineers suspect that not all of the files associated with MT 4.2 were installed properly or completely.

I can recommend two next steps:

1. re-upload MT Pro 4.2 and see if the upgrade process starts again
2. tar up your MT install and send it to me, so that I can take a closer look

Also, check your `mt-config.cgi` file and see if there is a `SchemaVersion` config directive. Is there one?

Comment from Jason Truell on 2008-08-16

2008-08-16T08:53:33Z

I tried upgrading from 4.1 to 4.2. The upgrade seemed to have gone smoothly but after I rebuilt I noticed a lot of data was missing. It seems like the upgrade lost about half of my custom fields data. I restored my database from a backup but I would appreciate it if I could get some help on this.

Thanks

Comment from Smittie on 2008-08-16

2008-08-16T16:42:23Z

I'm rebuilding the templates that were lost in my upgrade from 4.12 to 4.2. I was not able to recover them. I hope you have better luck than I did.

Comment from LeoMoon on 2008-08-16

2008-08-17T00:30:17Z

The best way to upgrade would be:
1- Backup your Database in 3 formats: MT Backup, cPanel Database Backup and PHPMyAdmin Database Backup.
2- Log in to your Movable Type control panel and Write down the plugins you are using right now.
3- Rename the your MT folder that exists inside cgi-bin to something else. For example if you MT folder is called "mt" rename it to something like "mtOld".
4- Download the new MT, unzip it and rename it to your original MT folder name. In our example, rename it to "mt".
5- Now open your old mt-config.cgi (that exists inside "mtOld" folder) with note pad and copy exactly what you have to your new mt-config.cgi-original (that exists in "mt" folder).
6- Now rename the mt-config.cgi-original to mt-config.cgi
7- Go to this address: www.yoursite.com/cgi-bin/mt/mt.cgi
8- Everything should work properly.
9- Before you do ANYTHING (anything means post or publish or anything like that) go ahead and download the latest version of the plubins you were using and install them...

Comment from smittie on 2008-08-16

2008-08-17T02:43:56Z

So, what LeoMoon is suggesting is that the best way to upgrade is to do a clean install every time. Which makes one wonder why Six Apart goes to the effort of trying to create an upgrade experience.

And for all that effort, it is my opinion that every upgrade is an excellent time to review the other CMS solutions that are available. Because the simple truth is, upgrading is about as much work as moving to another system. Migration of templates would need to be taken into consideration but that is becoming easier. Moving entries from one CMS to another is relatively painless at this point.

Comment from Su on 2008-08-17

2008-08-17T10:50:45Z

Um, Smittie? You might step back first and determine whether you think LeoMoon is actually right. (Hint: He's not. And that what he describes isn't a clean install as you refer to it.) You seem to have hit a glitch, yes. An annoying one, yes. This isn't a reason to let basic judgment get clouded.

No sane developer is going to suggest you make three backups, in three formats, much less think anyone will actually do it. Is there some functional difference between a cPanel db backup and one from phpMyAdmin? Should I also do another from my desktop SQL client? I'm surprised he didn't suggest also doing one in the old export format, just for fun.

But yes, you should back up your data before an upgrade. Every app will tell you that. I think the internal backup utility is now good enough to be sufficient for this. I usually just do an actual database dump, myself. This is the really important part.

For the actual software, if you want to add an extra bit of (questionable) protection, make a backup copy of the app files if you want; it's not really necessary in the great majority of cases. And all that manual moving around and copying of things is certainly not. Just overwrite the files and make sure to give your ftp client's log(if you go the ftp route) a quick look to make sure there were no upload errors.

Comment from smittie on 2008-08-17

2008-08-17T19:12:47Z

I did not make adequate backups before upgrading. That was my foolishness. The previous upgrade, from 3.5 to 4.12 had gone so well, I was too cavalier about this one. That I do not have a backup from which to recover is my fault.

Part of the problem with making a backup is borne out by this discussion. The internal backup utility may be good enough now. But it hasn't been and the only way to find out that it actually is not is to depend on it and have it fail. Yuck! So, what backup is good enough? The involvement of the MySQL database makes determining that, more complicated than the average blogger is interested in. At least in my opinion.