No seperate archives for upgrade and full installation needed ?? Looks like...

So much for me getting an early night here. Thanks a lot, Six Apart! shakes fist

The application will detetect if it is a fresh install or if an upgrade is needed. No extra "upgrade distribution" needed.

"The application will detetect if it is a fresh install or if an upgrade is needed. No extra "upgrade distribution" needed." Just checked the ZIP - and what about the mt.cfg in the distribution??? That will kill all settings for the server/mysql ???

That is right. You don't want to overwrite your existing mt.cfg with the default mt.cfg if you are upgrading a live installation.

So if you upgrade, copy everything but the mt.cfg.

Again, be advised: this is beta software.

Reminder: MT3.2 is for testing purposes only. Make sure you feel comfortable using beta software. Make sure you back up all your data. Use MT3.2 beta with a copy of your database. Don't update your one and only weblog if you have no backups.

Wouldn't you also want to leave the mt-db-pass.cgi if you are using MySQL.

I don't suppose it'd take much work to recreate it, but some people might not realise.

Callum, yes, you should not overwrite your password file if you are updating and if you are using the MySQL configuration.

All precautions of updating an installation still apply.

in upgrade, i have an error: "SQL/DB Error -- [Table 'myusernamemt.mtconfig' doesn't exist] The requested page could not be found."

what i that? pls?

So like an idiot, I did not upgrade correctly and overwrote things I shouldn't have such as mt-db-pass.cgi and mt.cfg. How does one recover from this without losing the database contents and gettings thing running again? I did however manage to backup changes to my index template. Don't ask me why I skipped everything else. Yes, I'm an idiot. Can anyone assist?

When upgrading I was careful not to overwrite mt.cfg, but I received a database connection error and realized I'd forgotten about mt-db-pass.cgi.

After I fixed that I was happy to find this to be the smoothest MT upgrade yet.

For those who have accidently overwritten their mt-db-pass.cgi file and are having database problems, check this section of the manual. The quick explanation though is that mt-db-pass.cgi only has one line in it, the password for your database (in clear, plain text) and is what MT looks to when it logs into the database to get data.

The FlickrPhotoset plugin returns "not a HASH reference in ::file:: on line 123" (or something very close to that) when rebuilding. I thought it might be the refresh attribute and removed it, but it does the same thing.

I can't even run mt-check.cgi - 500 error. I've checked it was uploaded in ASCII, I've recreated mt-db-pass with the correct password. sigh This is insane. I should just leave well enough alone. And when I just try to load mt.cgi I get:

Got an error: Can't locate MT/App/CMS.pm in @INC (@INC contains: /Library/WebServer/Documents/mt/extlib /Library/WebServer/Documents/mt/lib /System/Library/Perl/5.8.6/darwin-thread-multi-2level /System/Library/Perl/5.8.6 /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 /Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level /Network/Library/Perl/5.8.6 /Network/Library/Perl /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 .) at /Library/WebServer/Documents/mt/mt.cgi line 21.

Any thoughts?

Outch .... I tried the upgrade on my 3.17 and get

Upgrading table for MT::Author Executing SQL: alter table mtauthor modify authorpassword varchar(60) not null; Executing SQL: alter table mtauthor modify authorid integer not null primary key auto_increment; Error during upgrade: Error during upgrade: Multiple primary key defined at C:\Inetpub\Scripts\MT31\lib/MT/App/Upgrader.pm line 145. Error during upgrade: Error during upgrade: Multiple primary key defined

Any idea how to fix??

Ok. I reinstalled 3.17. Everything ran fine. I tried reinstalling the beta, this time not overwriting mt.cfg and mt-db-pass. Same error as above. So I re-chmodded all the .cgi to 755. No go. On a hunch, I chmodded my entire webserver's docs directory (where everything is located) to 777 and sure enough, everything worked fine. Obviously this isn't all that safe so I'd love to find out why it's happening.

If you find an error in MT3.2 please file a bug report as described on this beta blog. That will make things easier for our team to track and fix the various issues. Thanks.

Will there be an upgrade version zip released as well as the full version currently available, or will that not happen until the beta versions are done with? ..even a list of what files not to upload if you're doing an upgrade as opposed to a full install would be helpful.

uploaded everything except mt-dbpass.cgi & mt.cfg.. got the page saying my database needed upgrading, clicked 'proceed' and got a 500 error on the next page, which was mt-upgrade.cgi.

I CHMOD'ed mt-upgrade.cgi to 777 and tried again and got the login page (as expected), which then took me through to the same URL with a 'begin upgrade' button on it. It took a while going through all the comments I have and then said complete, with a button to return to MT.

I next got the logon screen and was able to logon ok. It seems MT Blacklist has been killed though - I can't get into it at all.. I guess I'll contact Jay about that.

hmm.. anyone else lost ability to comment?

An error occurred: Rebuild failed: Building date-based archive 'Monthly20050701000000' failed: Build error in template 'Date-Based Archive (monthly)': Error in tag: You used an 'MTEntryDate' tag outside of the context of an entry; perhaps you mistakenly placed it outside of an 'MTEntries' container?

I checked the template, MTEntryDate is not outside MTEntries tags (same template worked fine before btw). Bah. Well, this entry did say unsupported beta.

Hey Demonsurfer, you definitely shouldn't have to set that script set to 777. 755 should be perfectly sufficient. For those using suexec or cgiwrap, even less will suffice.

And about Blacklist, see here. Bad plugin. No biscuit.

nods, I set it back to 755 after I ran it :) Not sure why it spat.. I'm having other issues though and have tried to revert back to 3.17.. but whatever the changes were made to the DB by 3.2 have caused probs reverting back.. waiting to see if host will help revert the DB (I have a backup).

Fast, easy install, and no problems yet. :o)

I've got a strange one, it may be something I did, though I don't know what. After I have MT 3.2 installed, I hit /mt/mt.cgi and push the upgrade button, it then goes to mt/mt-upgrade.cgi and asks me to log in. I give it credentials, then it bounces me to /mt-upgrade cgi (outside the mt directory) and kicks a 404 error, because of course the mt-upgrade.cgi isn't located there.

Anyone have any idea what's wrong here? Is there a manual way to run the upgrade script?

Even stranger, if I try it on my Mac, it bounces me to http://mt-upgrade.cgi...

Check that your CGIPath in the mt.cfg is set correctly. It should be a fully qualified URL (i.e. starting with http://)

..and check it ends with a / as well

That shouldn't be necessary anymore. MT was made to recognize URLs and put slashes on them when needed (also true for the Siet URL). If it is necessary, though, that's a bug.

nice :) Jay do you know if SimpleComments is playing nicely with 3.2?

Just like Seth mentioned above, I am having the same problem with completing the beta upgrade. Perhaps a manual method to upgrade would be good? Or just the upgraded verison of the beta?

Kristina (and Seth):

"Check that your CGIPath in the mt.cfg is set correctly. It should be a fully qualified URL (i.e. starting with http:// )"

Actually Jay, I tried that suggestion. Changed the URL and everything. Nothing has change.

I do have exactly the same probs Kristina had. What a mess, upgrade in 45 sec, LOL

Have any of you filed a bug about this problem that you're having because we would definitely fix it if we had a bug with full details to work with.

@Jay I send this bug report via email. Hope this works. Cuz to describe a problem as entry in this comments seems not enough. Arrgh.

Yes, I also had already checked my mt.cfg and the path was correct, it made no difference. If it makes any difference, my hosting company is 1and1.com, in case that applies to the others with the problem...

Part of the generic code after building mt-upgrade.cgi is

ScriptURI = 'http:/mt-upgrade.cgi';

It seems the is wrong ... But unable to find the place this variable is definded...

Here's a much less strenuous question. Recently a fix was released to address an issue wherein dirify was suddenly not striping out hyphens, when that stripping out had been the previous MT behavior.

Thing is, I liked it better with the hyphens and have settled in what that change on my site. So where would I go in the MT 3.2 code to make sure that the "dirify leaves hyphens alone" behavior that I like doesn't revert to the "correct" behavior of dirify stripping out the hyphens?

I'm having the same problem as Kristina. After logging in, it forwarded me to the 404 error page because, as stated, it's looking for mt-upgrade.cgi outside of the MT dir.

After installing/upgrading, is it necessary to delete mt-upgrade.cgi or any other files?

There is no need to delete anything after installation or upgrade. mt-upgrade can only be run by an MT user with System Administrator access (previously known as Can Create Weblogs).

Am I missing something? There is no mt-dbpass.cgi in my MT3.2b distribution. Are we supposed to create one?

Jay, I'm trying to do a fresh install of MT3.2b and I really don't understand what we are supposed to do regarding the database password if we are using MySQL. The MT-config.cgi-original has a line for the DB password, but this file is completely viewable to the public. I'm assuming that one is supposed to remove "-orginal" from the title of the config file? Or are we still supposed to have a separate mt-dbpass.cgi. If instructions regarding install other than what you've posted here, and other than what is existing for MT3.1x, please let me know where those are. This is quite confusing.

elise--

You should put your password in the same file as the other configuration data—namely, the newly renamed mt-config.cgi.

The password goes under the name DBPassword:

   DBPassword y0ullneverguess

For new installs, you should move mt-config.cgi-original to mt-config.cgi. When upgrading, then, the mt-config.cgi-original file will not overwrite your configuration.

I've removed the "-original" from mt-config.cgi. Now the error I get when I try to run mt.cgi is this: oo many redirects occurred trying to open “http://(my web site domain)/mt/mt.cgi/mt-upgrade.cgi?__mode=install�. This might occur if you open a page that is redirected to open another page which then is redirected to open the original page."

Trying to run mt.cgi appears to redirect to mt-upgrade.cgi. Even though this is not an upgrade.

Keeping the "-original" in there gives me an error message about my database not being set up. My database is set up. The config has all of the right settings.

Elise and I have solved her problem offline.

In case anyone else has the problem Elise describes, please make sure that your CGIPath directive in the mt-config.cgi does NOT end in "mt.cgi". It should be the path to, but not the URL of, mt.cgi.

Also, answering another of Elise's concerns: The mt-config.cgi file is not readable from the web by virtue of its .cgi extension.

After upgrading to 3.2beta, I get this when rebuilding:

"Building date-based archive 'Monthly20050601000000' failed: Build error in template 'Date-Based Archive': Error in tag: You used an 'MTEntryDate' tag outside of the context of an entry; perhaps you mistakenly placed it outside of an 'MTEntries' container?"

This template worked fine in 3.17.

In the Archive File Path on your Weblog publishing settings page, what do you have listed for your Monthly archives?

If you have something like "archive/<MTEntryDate format="%Y%m">.php" you need to change that to "archive/<MTArchiveDate format="%Y%m">.php"

Also Daniel, if you have a bug or need support in the future, this isn't the best place for that:

How to file bugs

Support for the beta

Thanks for understanding.

No matter what I try I get this error when running mt.cgi

Got an error: Unknown encoding 'utf-8\' at /home/users/web/b2945/userpr/cgi-bin/mt/lib/MT.pm line 796

everything upped as ASCII, all *.cgi to 755

completely stumped... curiously though I get a similar error when trying to upgrade to 3.17... I'm still running 3.01D

Unix box.. mt-check.cgi says everything is ducky! (clearly.. 3.01D works flawlessly).. running a MySQL database!

any insights?

Search in your mt.cfg/mt-config.cgi for a line like this one:

PublishCharset utf-8

Make sure that it doesn't have a backslash ('\')on the end of it.

Also, line numbers in error messages do no good unless we know exactly what version you are using so we can find the source of the error.

Just finished the installation. It works without any problem!

Upgrading MT 3.15 to 3.2b4.

I got caught by a change involving the mt-static directory. As instructed, I looked for the docs/images/etc. directories and files to move to a non-CGI directory, didn't see them, so I presumed that the upgrade didn't have those. It wasn't until I spent a lot of time trying to figure out why things didn't work that I noticed that those directories were now nested under the mt-static directory, unlike previous versions. Overall that's a good choice but I think a mention of it would have been nice. Or am I the only one who didn't figure that out right off?

Today I upgraded from 3.15 to 3.2b5.

I was having a little problem getting mt happy with the recommended install path of: www.mysite.con/cgi-bin/mt/ vs the old recommendation of www.mysite.com/mt/

I got the thing about locaitng the static files and the change from mt-cfg.

I like to use Textwrangler to manage my templates and have a folder, my_tmpl, that all the files are linked to.

It would be nice to be able to set a default path for linked files.

I was having trouble logging onto MT. It turned out I was using the wrong login/password (the problem with setting the login name different from the displayed user name).

Trying to track this down I deleted my old mt directory thinking there was some cross linking confusion. Next I moved my old blog directory out of the public_html directory. This allowed me to create a new blog.

Doing this nuked my entries from mySQL.

I have a backup of mySQL and I have the data from the original blog. If I do a restore of the mySQL data, how do I get MT to recognize those entries?

Thanks

We've actually mentioned it several times including in an entry on this blog and several times in the documentation.

www.mysite.con/cgi-bin/mt/
vs the old recommendation of
www.mysite.com/mt/

Either of these are totally fine. What we DON'T recommend (recommend against, actually) is installing MT directly into your web root, as in mysite.com/mt.cgi. That's bad.

Anyway, about your problem, I'm a bit confused what with all of the directory wrangling and deleting. Can you restore your backup and just follow the instructions in the user manual? Don't worry about the cgi-bin/mt vs /mt thing. As I said, either are fine.

Also, if you wouldn't mind, can you please post any future problems to this thread? Thanks.

I just did an upgrade as instructed, uploaded all the files, and tried to log into my mt.cgi for the upgrade, what it does now it just pop up a window asking me to download "mt-upgrade.cgi", I downloaded it, and I opened it and here I got this message

A file permissions error has occurred. Please check the permissions on the script and the directory it is in and try again.

now I cant even log into my mt.cgi anymore. HELP please.