Movable Type Beta Weblog - The first nightly

« Beta tester sound-off | Main | User-to-user beta test support »

The first nightly

by Jay Allen

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.

I've posted the first nightly build over on the left sidebar in the Downloads section. If you are inclined to download it and test it, it is very important that you read the rest of this entry first.

First and foremost, if you are not blocked by a major bug and beta-1 is working well for you minus an annoying bug or two, you are better off NOT trying out the nightly unless you have a full backup. Nightly releases are only run through automated tests and are not tested by our QA team. They may contain larger bugs than were addressed since the last beta release. Be warned!

Secondly, if you do try it, there has been a fairly significant change to the config file structure first mentioned in a previous entry: the new mt-config.cgi file.

The new config file for Movable Type is named mt-config.cgi although it is distributed as mt-config.cgi-original to prevent overwriting when upgrading the software. It combines mt.cfg and mt-db-pass.cgi into one file that is impossible for a third party to read from the browser.

A few important points:

Your old mt.cfg and mt-db-pass.cgi should continue to work just as it always has, but you are highly encouraged to migrate to the new mt-config.cgi as soon as possible, because we are deprecating the old config files and plugins may start to specify the new ones in their startup routines.
To use the new config file, you must rename mt-config.cgi-original to mt-config.cgi and set it up just like your old mt.cfg.
If you are using MySQL or postgreSQL, your database password from mt-db-pass.cgi goes into mt-config.cgi with the directive DBPassword.
Once you have everything set up, move your mt.cfg and mt-db-pass.cgi out of your MT directory.

After following these instructions, and executing Movable Type, you will be prompted to upgrade with this nightly build and everything should continue to work just as it always has.

When you upgrade in the future, you will not have to fear overwriting your mt-config.cgi from the one in the distribution because of the different file name.

Again, don't use the nightly unless you have full backups!

Posted on July 19, 2005 8:27 AM in Announcements

TrackBack

Listed below are links to weblogs that reference The first nightly:

» Movable Type Beta from Arsenic.net
Six Apart, makers of Movable Type, have released a beta version of their new blogging software, MT Version 3.2. I installed the beta version on another blog, and here are some thoughts. So far, I like it. Managing blogs, entries... [Read More]

Comments

The 20050718 nightly fixed the issue I had with the index page showing the oldest X entries of the weblog rather than the most recent X entries. :)

I have a query regarding archive mapping. I thought (wrongly) that the codes used in the archive file path would have mirrored the template tag date codes, but they don't, and I can't seem to find anywhere stating how they are structured, although I think it would make sense to mirror the existing template tag date codes.

For example, right now to set up an archive path containing the year, %y will give a 4-digit representation of the year, however in template tags (as linked above), %y would give a 2-digit representation, and %Y would give the 4-digit representation. For including the month in the archive file path, currently %m will give a 2-digit month, which is the same for template tags, however if I want the month displayed in the URL to show as a 3-character abbreviation (ie: Jan, Feb, Mar, Apr...), the template tag would be %b, but the archive file path does not recognise %b at all.

Is there a list of the tags to use for the archive file path? I haven't been able to locate them.. and as a suggestion, wouldn't it make more sense just to use the same tags as are used for the template date tags?

cheers.

Posted by: demonsurfer | July 19, 2005 2:08 PM

I dunno if I should email that tag issue as a bug.. unsure if you'd consider it a bug or a ..err ..feature? ;)

Posted by: demonsurfer | July 19, 2005 2:14 PM

Note that the file template archive formatting codes (%y, etc.) may appear similar to the date format codes, but they are different. There are some format codes that have no mapping at all to the date formatting codes ("%c" for the category/subcategory path for the entry), and some that differ entirely from the date formatting codes ("%x" which provides the file extension).

"%y" in this context produces a full 4 digit year. The common, "expected" result was chosen for the lowercase letters.

Posted by: Brad Choate | July 19, 2005 2:27 PM

Thanks for the response. Is a list of the codes publically available anywhere yet, or not until the new doc files come out? (unless they're already in the docs and I just didn't find them)

Posted by: demonsurfer | July 19, 2005 3:01 PM

This will be documented. It's coming.

Posted by: Jay Allen | July 19, 2005 3:40 PM

awesome, thanks.

Posted by: demonsurfer | July 19, 2005 3:57 PM

FYI Just noticed this in my activity log:

Unnamed plugin died with: Can't locate object method "load" via package "MT::TemplateMap" at lib/MT/App/CMS.pm line 2725.

Fresh install (fresh MySql DB as well) on Version 3.2-20050718 with no additional plugins at all.. just what comes in the download.

Posted by: demonsurfer | July 19, 2005 7:19 PM

demonsurfer: I gave up trying to figure out what the codes meant and just left what I had before: put in the MTArchiveDate tag and use it to specify the date correctly.

Posted by: The Plaid Cow | July 20, 2005 7:24 AM

Don't be afraid to use the email bug submission address even for the nightlies. (Translation: Please don't file them in the comments -- especially if they're not something that you're unsure is a bug. Because it's a fresh install, it's most likely a bug.)

Posted by: Jay Allen | July 20, 2005 8:59 AM

Any idea when the 3.2 will be mySQL5 compatible?

Posted by: Lutz-R. Frank | July 20, 2005 9:19 AM

We're actually working on it. Can't say it will happen with this release, but we're sure trying...

Posted by: Jay Allen | July 20, 2005 9:30 AM

Jay, good news - I'm running a Gallery which has the tables created with mySQL 5 - and is not backward compatible. Btw. MT3.2 is running fine with mySQL5 - only the upgrade module makes the problem (I assume as soon as touching the DB structure).

Posted by: Lutz-R. Frank | July 21, 2005 12:49 AM

That's good to know. As far as the upgrade incompatibility, we fixed that yesterday. Last night's nightly build and beta-2 (when released) have the fix

Posted by: Jay Allen | July 21, 2005 6:24 AM

I made Korean language translation file, ko.pm and MT interface templates for MT 3.17. (http://www.flickr.com/photos/33376553@N00/24870171/)

In several days ago, I found 3.2 beta, so I'm converting these into MT 3.2. During converting, I found some un-$app->trans()ed new vocabulary in MT/App/CMS.pm. I know it's not BUG.

sub initcoreitemset_actions {... label => 'Publish Entries'... ----->>> label => $app->trans('Publish Entries')

Because "Publish/Unpublish Entries" etc. are hard coded in English, I(not supported languguage user) can't insert these into extlib/MT/L10N/ko.pm language file.

Please code every possible English vocabulary with $app->trans() or $app->err_trans or

Posted by: Lee, Joon | July 21, 2005 9:10 AM

Actually, that sounds very much like a bug. Please file it so that out engineers can fix it.

"Please code every possible English vocabulary with $app->trans() or $app->err_trans or"

We try to, so if you find anymore, please file bugs against them.

Thanks.

Posted by: Jay Allen | July 21, 2005 9:24 AM