Easiest. Upgrade. EVAR...
This is an archived entry from the Movable Type 3.2 beta test.
Entries from the current beta release (v3.3) can be found here.
If you haven't see it, you really need to: Movable Type 3.2's - Easiest upgrade ever.
A one minute video in which the actual upgrade didn't start until 45 seconds in... Wham!
Posted on July 15, 2005 6:42 PM in Features


Comments
I can't seem to find the Upgrade only DL like with most releases. Only the full download.
Posted by: Michael Paul
|
July 15, 2005 10:14 PM
Ok, I ftp'ed the files to my server. I even went in and made the necessary changes to my mt.cfg file so that I could get into my interface, log into MySQL, etc, etc, etc. But guess what? Nothing happens. It seems that it does not notice any need for upgrade. I am still at 3.16.
What's up? Should I not have set for background? I am going to go turn it off and let you know if that was it. Is there something else that I missed?
Posted by: Rook
|
July 15, 2005 10:36 PM
Ok, never mind. I found out that the files did not completely upload the first time. I have since re-ftp'ed all the beta files and have now upgraded to 3.2b1......
If I may let my effeminate side out for just a bit-interface needs a bit of a nip and tuck with the graphics. Seems just a bit unruly and hard to follow. It just don't flow.
Oh, and just because it really is very scary, I actually spelled effeminate right. Seriously. Doesn't that scare you?
Posted by: Rook
|
July 15, 2005 11:29 PM
"I can't seem to find the Upgrade only DL like with most releases. Only the full download."
The only difference these days between the "upgrade" distribution and the "full" distribution would be two files: mt.cfg and mt-db-pass.cgi. Because of that, we will only be distributing the full package.
In Beta-1, we distributed the mt.cfg and mt-db-pass.cgi without altering their names which cause some people to overwrite them. We'll be fixing that in the next release and all of the nightlies.
By the way, you'll notice that the upgrade with beta-1 is not as smooth as the one in the video. That quickness comes in beta-2, which is what you'll just catch a glimpse that we're using in the demo. Beta-1 is pretty close, but there is a logout issue that adds about 2 seconds...
Posted by: Jay Allen
|
July 16, 2005 1:34 AM
Yeah great job on that guys. I'm loving it. Leaving mt-load.cgi on the server was such a security hazard and now I don't have to worry about it.
Posted by: Mike Steinbaugh
|
July 16, 2005 9:45 AM
Thanks Jay! I'll upgrade sometime today.
Posted by: Michael Paul
|
July 16, 2005 10:26 AM
I'm hoping the login issue with b1 refers to the inability to login from two different browsers from my own machine at the same time? Also, if this is indeed a security 'feature', perhaps we should be given the option to disable this. I manage blogs from several of my clients, which means I need to periodically login and make tweaks to their entries. With beta1, when I login, they'd get logged out, which is truly a pain.
Other nice-to-haves would be:
Posted by: Shashank Tripathi
|
July 16, 2005 2:13 PM
Continuing on the wishlist from previous comment:
Posted by: Shashank Tripathi
|
July 16, 2005 2:25 PM
"I'm hoping the login issue with b1 refers to the inability to login from two different browsers from my own machine at the same time?"
It does not and we feel your pain. Believe me, as not only bloggers but developers of MT, we're looking at the same interface in multiple browsers far more often than anyone. We're working on a solution for that and we hope to have it included in the final release if not before.
"1. Disallow posting of totally blank entries!"
This sounds like a great idea for a plugin. We couldn't do that in the core because not everyone blogs in the same way. Some people may only use the entry body sometimes (think of an event calendar). As developers of a really powerful piece of software, it's impossible for us to predict how our customers use it and people may cry foul over that sort of change.
I'll consider some sort of configuration value, but I'm not sure whether most people have problems with accidentally posting blank entries. Again, though, a plugin would do wonders with this.
"2. Make a category default when one forgets to specify a category."
That's a great feature request. I'll put in in our tracking system and you can look for it in a future release.
"3. The ability to store interface settings more permanantly (e.g., a database) instead of only localized cookies that vary from browser to browser."
I'll discuss this with the team. I understand why you want it and we talked about this, but there was a reason (which escapes me at the moment) why the engineers wanted it this way.
Thanks for your feedback, Shashank!
Posted by: Jay Allen
|
July 16, 2005 6:59 PM
Oh, hey, did this become a features-request thread? ;)
Well, ok, I have one, but I bet there's some way for a plugin developer to figure this out rather than it being a core team issue: I'd like the ability to fling read comments from one post to another, as part of addressing readers who like to post off-topic but still possibly interesting comments.
I see it this way (modelled after the way the forums worked on the old MindVox BBS system): Someone posts an off-topic comment. I go into the MT CMS or an interface to (say) MT-Fling, and tell it I want the comment (say Comment ID 50) "flung" to a different entry of my choosing (say Entry ID 400, which I posted as an "open thread" entry).
In my best of all worlds scenario, the following would happen: The content and metadata for Comment ID 50 would be placed in an entirely new comment over on Entry ID 400 (say, Comment ID 53, the next available Comment ID), with an auto-added note saying it had been "flung" from its original entry. Meanwhile, the original content of Comment ID 50 would be wiped, but remain attached to the original entry but replaced with a "this comment flung to Entry ID 400" message
Posted by: The One True b!X
|
July 16, 2005 7:41 PM
"Oh, hey, did this become a features-request thread? ;)"
Ummm, no. But I made one just so that every entry doesn't become one from now on.
Posted by: Jay Allen
|
July 16, 2005 8:03 PM
"I'd like the ability to fling read comments from one post to another, as part of addressing readers who like to post off-topic but still possibly interesting comments."
Heh, yeah. I'd like that ability right NOW. :-)
Seriously though, we've got great things in store. This, and related functionality, has been a need since v1.1
Posted by: Jay Allen
|
July 16, 2005 8:06 PM
Ok, I sent an email to report this, but I found that all my comments were not published when I upgraded from 3.16 to 3.2b1, with the exception of those posted by people using KeyType registration.
In 3.16 I was allowing anonymous commenting. I am also doing so now.
Posted by: Rook
|
July 16, 2005 8:11 PM
I did a fresh install on a newly created DB and it went smooth as silk. I'm loving the feel of 3.2 - it's a thing of beauty Jay! Frigg'n awesome. applaud
Posted by: demonsurfer
|
July 16, 2005 10:11 PM
I've just attempted an upgrade on a Windows XP machine, using MySQL as the database. It outputs the following results:
Current schema looks like 3.1; upgrading to 3.2... Upgrading table for MT::Comment Executing SQL: alter table mtcomment add commentlastmovedon datetime not null default '2000-01-01 00:00:00'; Executing SQL: create index mtcommentlastmovedon on mtcomment (commentlastmovedon); Error during upgrade: Error during upgrade: Access denied for user 'mt_user'@'%' to database 'mt' at c:\inetpub\wwwroot\mt\lib/MT/App/Upgrader.pm line 145.
The DBUser field in mt.cgi is definitely mt_user, and the MySQL database is 'mt' - this was all configured and running smoothly with MT 3.17. I did not replace the mt.cgi or mt-db-pass.cgi files when uploading the new version.
Am I missing something?
Posted by: Steve
|
July 16, 2005 11:26 PM
"I did not replace the mt.cgi or mt-db-pass.cgi files when uploading the new version" oops.. it's the mt.CFG one that you didn't want to replace, not mt.cgi.. unless that's just a typo here..
Posted by: demonsurfer
|
July 16, 2005 11:33 PM
Steve: it looks like some of the SQL statements are running okay, but that last one (the create index command) failed. Does mt_user have full privileges to the mt database?
Posted by: Brad Choate
|
July 17, 2005 12:04 AM
I'm getting the Time to Upgrade! A new version of Movable Type has been installed and you will now need to upgrade your database. but when I click that "Proceed to UPgrade" button I"m taken to my login page. It says my session has ended. When I try to login from there I get a 404 error.
I've tried uploading the files twice and the only ones I've left out are the cfg and the db-pass.
Anyone know what I may be doing wrong?
Posted by: Michael Paul
|
July 17, 2005 12:12 AM
Oh and the Permissions are set to 755 for the cgi files.
Posted by: Michael Paul
|
July 17, 2005 12:31 AM
Thanks Brad - you were right. I needed to give the mt_user full access to the database. Thanks for your help!
Posted by: Steve
|
July 17, 2005 2:21 AM
What about an easy way to convert 3.2 to another host including all settings and options?
Posted by: Dennis Slagers
|
July 17, 2005 4:33 AM
Jay... re: "By the way, you'll notice that the upgrade with beta-1 is not as smooth as the one in the video. That quickness comes in beta-2, which is what you'll just catch a glimpse that we're using in the demo. Beta-1 is pretty close, but there is a logout issue that adds about 2 seconds..."
Now you tell us! Going on what I saw in the video, I upgraded. There was no warning in the video about not overwriting the cfg file. I assumed it was as easy as all other MT upgrades have been. Consequently, my site is screwed. I can't log in. MT Support won't help me. And I'm having to pay for a second install :-(
The MT web site and associated blogs are too subtle and assume too much knowledge on the part of ALL users. Please do a better job of warning.
My fault entirely. But I think my blunder was caused at least in part by the "every one should try this" and "easiest upgrade ever" rhetoric that's alot easier to find than the important warnings.
I'm not a happy MT camper right now.
Posted by: acline
|
July 17, 2005 9:57 AM
acline, I'm sorry to hear that you had this problem.
"There was no warning in the video about not overwriting the cfg file. I assumed it was as easy as all other MT upgrades have been. Consequently, my site is screwed. I can't log in. MT Support won't help me. And I'm having to pay for a second install :-("
If all you did was overwrite the mt.cfg, all you have to do now is fill in the three our four values to make your site run again.
There's no need to pay for someone to upgrade you. Setting up mt.cfg is easy.
Posted by: Jay Allen
|
July 17, 2005 12:42 PM
Michael,
I ran into the same problem as you did and I've given up upgrading for now. :(
Posted by: Dan Li
|
July 17, 2005 2:09 PM
Dan and Michael, I hope that you filed a bug with full details about the problem you are having. It is only in that way that we may fix any problem that is occuring.
Make sure to say what URL gave you a 404 and what your CGIPath is.
Posted by: Jay Allen
|
July 17, 2005 2:26 PM
Jay...
Maybe I'll try it. Are your instructions to restore 3.17 or to continue with 3.2? I've never seen/used this db directory before. I created it. I also tried to reinstall 3.17. No dice.
What's that second thing: DataSource or ObjectDriver/Database/DBUser ???
Posted by: acline
|
July 17, 2005 4:49 PM
this may help: configuration
Posted by: demonsurfer
|
July 17, 2005 5:35 PM
"Are your instructions to restore 3.17 or to continue with 3.2?"
It would probably be safer for you, at this point, to roll back to 3.17 and stay there until we have the instructions for 3.2 out and maybe even wait until the production release of 3.2.
To fill in the necessary values in mt.cfg, please see the configuration directives explanations.
Posted by: Jay Allen
|
July 17, 2005 8:19 PM
I'm getting "Error during upgrade: Error during upgrade: Access denied for user" during the upgrade (although it's slightly different from Steve's errors above -- it gives the full username@localhost, and occurs at a different line in the perl script). The password, host, dbname are all correct -- indeed I get a different error if I change them from what they should be.
Everything works fine under 3.17. Does the upgrade require more wide-ranging permissions? If so, is there any way to set them without being root?
Is this message going to be seen at all???
Posted by: ahj
|
August 25, 2005 5:19 PM
ahj: That sort of error is coming from your database server. It's saying that the "DBUser" configured to access the database doesn't have the permissions necessary to upgrade the database properly. You will need to grant additional permissions in order for it to upgrade properly.
Posted by: Brad Choate
|
August 25, 2005 5:47 PM
Brad- Thanks for the quick reply! Can you give a bit more detail, though? I know almost nothing about mysql. What permissions do I need to give the username? What is the mysql incantation to do so (for a linux command-line version)? Most importantly, do I need to be root to do it? (And, on the purely informational side, why is all this necessary? -- there were never any upgrade problems like this before!
Posted by: ahj
|
August 26, 2005 12:27 AM