404 error page that comes with MT
If, when you try to load mt.cgi into your browser--or mt-load.cgi or mt-check.cgi during the installation process--then the problem is that your webserver does not have CGI scripting enabled in its configuration.
If you run your web site on a hosted provider, you will need to email the support for this provider and ask them to turn on CGI scripting for your account (or for the webserver on a whole); this is not something that you can configure yourself.
If you run your own webserver, or if you have access to the webserver configuration files--and the privileges to restart the webserver, after modifying the configuration--you can use these steps to enable CGI scripts on your webserver. The following instructions assume that you are running Apache.
Directory or Location block that configures the webroot for
the server.
Inside of that block, add this line:
Options +ExecCGI
Directory or Location block, add the line
AddHandler cgi-script .cgi
CGI scripts should now execute, instead of merely displaying their source.
500 Internal Server Error is the general webserver error that occurs when
something goes wrong--in particular, when something goes wrong when trying to
execute a CGI script.
Here is a list of diagnostics for trying to fix this error:
-w at the end of the first
line in each file; this setting turns on warnings in Perl, and it is important
that it be left on.
To determine the location of Perl on your webserver, take a look at the support pages for your hosting service. Alternatively, if you have a shell (command line) account, and are familiar using it, you can log in to that account that type:
$ whereis perl
This will give you the location(s) of Perl on your system.
When running mt-load.cgi, if you get an error that says
Tie '/path/to/db' failed: No such file or directory or
Tie '/path/to/db' failed: Permission denied, this indicates that the
DataSource path that you have set in mt.cfg is incorrect, or that the
permissions on your db directory are incorrect.
The DataSource setting should contain the full filesystem path to your db directory. You can obtain this path in several ways:
$ cd my/db/
where my/db/ is the path to your db directory from your home directory. Then use the pwd directory to display the full path to that directory:
$ pwd
This will print out the full path, which you can then copy and paste into your mt.cfg file as the DataSource value.
To use this method, run mt-check.cgi by pointing your browser at the URL for mt-check.cgi on your site. For example, if your site is http://www.your-site.com/, and you uploaded the Movable Type files into the /mt directory, you'd type http://www.your-site.com/mt/mt-check.cgi.
In the output of mt-check.cgi, look for a line like this:
Current working directory: /path/to/your/mt/directory
This is the full path to the directory where you installed Movable Type. From that path, you should be able to determine the full path to your db directory.
If you are getting a Permission denied error, this may indicate that the
permissions on your db directory are incorrect. The installation
instructions describe how to set permissions to 777.
When first trying to view the Movable Type application using the mt.cgi
program, if you receive a long error that starts Can't load error
template, got error 'Loading template 'error.tmpl' failed and continues from
there, this indicates that Movable Type can't find the files in your tmpl
directory.
If this happens, try the following:
In addition, make sure that the case on the directories is correct; they are case sensitive, so if your FTP program changes the name of the directory to Cms, for example, this will not work.
To fix this, open your mt.cfg file in a text editor, and add the following line:
TemplatePath /full/path/to/tmpl/
where /full/path/to/tmpl/ is the full path to your tmpl directory.
Save mt.cfg, then try to run mt.cgi again.
If, when running any of the Movable Type CGI scripts, you receive an error
that says Can't locate Some/File.pm in @INC, where Some/File.pm is the
name of a file, you should try the following to fix this:
Note that the file names are case sensitive, so a directory called Lib, for example, will not work. Likewise some/file.pm is not the same thing as Some/File.pm; the latter will work, but the former will not.
If, when you first view Movable Type, the images and styles do not show up properly in your browser, you will need to move the images, documentation, and stylesheet to a different location. The reason for this is that you installed Movable Type into your cgi-bin directory, because--presumably--it was necessary to do so on your server. But hosting non-CGI files out of the cgi-bin directory causes problems, because the webserver sometimes tries to execute the images, as if they were programs.
To fix this, you will need to re-upload the images directory (images), the documentation directory (docs), and the stylesheet (styles.css) to a different directory, outside of your cgi-bin directory. Then, edit the mt.cfg file, and add this line:
StaticWebPath /path/to/dir/
where /path/to/dir/ is the URL to the directory containing images and styles.css. For example, if images is located at /movable-static/images/, you would use
StaticWebPath /movable-static/
This should fix the problem.
The problem: you log in to the system and get the Main Menu; but every
link you click on that screen brings you back to the login screen.
The reason for this is likely that you have cookies disabled in your browser. Movable Type uses a cookie to store your authentication credentials; in this cookie, your password is one-way encrypted, so this is not a security risk. If you do not allow this cookie, however, Movable Type has no way of knowing that you have already successfully logged in, so it will present you with a login prompt when you try to do anything.
To fix this problem, you will need to enable cookies in your browser.
The problem: you are logged in to Movable Type; then you logout, and try to login as another user (for example). But you are still logged in as yourself.
This is probably due to your browser having several versions of the Movable
Type login cookie. The reason this might happen is that the cookie is dependent
on the domain name; so if you have two different domain names that access the
same Movable Type installation, and you use both to get there, you will get
two versions of the Movable Type cookie. If one domain name is a substring of
the other domain name--for example, if one domain is www.foo.com, and the
other is foo.com--then you will need to log out of both sessions in order
to truly logout. To do this, load Movable Type on both domains, and log out
of both sessions.
Because of this, if possible it makes sense to always access Movable Type through one single domain name.
If you are generating PHP files through Movable Type, some webservers will
require that the generated files have the execute bit set (in other words,
that the permissions are at least 755). By default all files created by
the system will have their permissions set to 666, and you will receive
errors about your files not being executable.
To fix this, add this line to your mt.cfg file:
HTMLPerms 0777
This will set the default permissions for all files created by the
system to 777; note that if you are using the HTMLUmask setting in
mt.cfg, the setting for HTMLPerms will be adjusted by the umask setting.
For example, if you have set HTMLPerms to 0777, and you set HTMLUmask
to 0022, all files created by the system will have permissions of 0755.
NOTE: another symptom of this problem is that notification messages sent
through the Edit an entry screen never reach the members of your
notification list.
If you know that users are posting comments on your site, and you are not
receiving them, you should first check your weblog configuration to ensure that
Email new comments? is checked.
If it is, then this is most likely a problem with the path to the sendmail program on your webserver; this is the program used to send email. Movable Type looks in three locations for sendmail: /usr/lib/sendmail, /usr/sbin/sendmail, and /usr/ucblib/sendmail. These are the three most common locations for sendmail on Unix machines. If your version of sendmail is at a different location, here are instructions for telling Movable Type what that location is:
SendMailPath /path/to/sendmail
where /path/to/sendmail is the path to sendmail that you determined in
Step 1.
That's it; if the location to sendmail is correct, you should now be able to receive email notifications of new comments.
If you have tried the above steps to get sendmail working, or if you know that your webserver doesn't have sendmail--for example, Win32 machines do not have sendmail--Movable Type allows you to send email messages through SMTP. To do this, you will need to install the Mail::Sendmail Perl module; if you are on Win32 machines, you can do this using Activestate's ppm tool. Launch ppm, then at the prompt, type
install Mail::Sendmail
and ppm will do all of the work to install the module. If you are on a non-Win32 machine, and you need (or prefer) to use SMTP, you can download the distribution from here:
http://www.movabletype.org/cpan/cpan-Mail-Sendmail.tar.gz
Unpack the archive using an extraction program, then connect via FTP to your
webserver. Open the directory where you installed Movable Type, then open the
extlib directory; then create a new directory called Mail. Then open
the Mail directory, and upload the file Sendmail.pm from the archive
into the Mail directory.
After you have installed Mail::Sendmail, you will need to configure Movable Type to send mail using SMTP. To do so, edit your mt.cfg file, and add the line
MailTransfer smtp
By default, Movable Type will try to use the SMTP server on the webserver (on
localhost); if you need to change this, add another line
SMTPServer address.of.smtp.server
Save (and re-upload, if necessary) your mt.cfg file, and you're done. Movable Type should now send email through the SMTP server.
Some hosts do not have the Image::Magick Perl module, which Movable Type uses to create thumbnails of uploaded images. As of version 2.3 of Movable Type, the system now supports an alternate method of creating thumbnails, using the NetPBM suite of tools. If your system has NetPBM but not Image::Magick, you'll need to do the following:
http://www.movabletype.org/cpan/cpan-IPC-Run.tar.gz
On your FTP server, create a new folder called IPC within your extlib folder. Then upload the Run.pm file and the Run folder from the IPC-Run distribution into the IPC folder on your server.
ImageDriver NetPBM
By default, Movable Type will look for the NetPBM tools in one of the following locations: /usr/local/netpbm/bin, /usr/local/bin, or /usr/bin. If you need to set a different path, add another line to mt.cfg:
NetPBMPath /path/to/netpbm
Save (and re-upload, if necessary) your mt.cfg file, and you're done.
If your host does not have NetPBM, or if you run your own server, you can download and install the NetPBM suite of tools from http://netpbm.sourceforge.net/. If you'd prefer (or need) the precompiled binaries, the Gallery developers provide a set of binaries which can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=7130.
When rebuilding a page, Movable Type first writes the page data to a temp file, then renames the temp file to the actual file name. The temp file is named with an extension of .new; for example, if the file index.html is being rebuilt, the temp file would be named index.html.new. Movable Type does this to prevent corruption of your public files; if, for some reason, the rebuild process is killed in the middle of writing data to a file, that file will not be complete, and will appear corrupted to a web browser.
The process of writing to temp files requires that permissions on the
Local Site Path directory be set to 777; some users can not--or would
rather not--set the permissions this liberally, and will then receive errors
when Movable Type is unable to write to the .new temp files. If this is
the case for you, you can turn off the use of temp files. To do so, edit
your mt.cfg file, and add the line
NoTempFiles 1
This will tell Movable Type not to write data to temp files, and you should no longer receive errors when rebuilding.
When encoding characters into HTML entities--either for editing, or when
you use the encode_html global tag attribute--Movable Type uses the
HTML::Entities Perl module, if your server has it; otherwise, it uses a
simple encoding that encodes <, >, &, and
into the proper entities.
In some cases, however, HTML::Entities will not work properly for your characters--this may happen, for example, if your characters are encoded in a different character set (if you are writing in Polish, Russian, etc). In this case, edit your mt.cfg file, and add the line
NoHTMLEntities 1
This will tell Movable Type to use its simple encoding, which will not mess with the special characters you are using.
404 error page that comes with MTThe Movable Type distribution includes a file index.html in the main Movable Type directory; when you upload this file to your webserver, it prevents users from viewing the contents of the directory listing. This is not meant to provide bulletproof security, but it keeps away curious viewers.
The version that ships with Movable Type is rather plain, so if you'd like to improve it on your server, just edit the file index.html; it's just a standard HTML file.
If you are using Apache as your webserver, you can use a different technique to prevent users from viewing your directory listings:
Options -Indexes to that file.
If you use this technique, you can remove the index.html file from the directory; the webserver will then prevent viewers from listing the contents of the directory.
When you change hosting providers (or just move to a different server at the same provider), it is possible that the two servers have different versions of the Berkeley DB library; this is the library that Movable Type uses to store your data. When you copy the DB files from one host to another, if the two hosts have different versions of Berkeley DB, the new host will not be able to read the files from the old host.
This can be fixed by converting the DB files over to the format used by the new library version; this is accomplished in several different ways, depending on the Berkeley DB versions involved. The files that need to be converted are all of the files in your db directory whose filenames end in either .db or .idx (the .lock files do not need to be converted).
The following steps require that you have shell access to your server, and imply that you are somewhat familiar with running Unix commands; if this is not the case, you should ask your hosting provider to help you.
$ cd <db_dir> $ db_upgrade *.db *.idx
If your server has db_upgrade, this will convert all of your DB files over to the new format. If this works, you're done, and you can skip the following steps; Movable Type should now work.
command not found--then you will need to use the following
method to convert your data. This method dumps out all of the data from your
DB files, then loads it into new versions of those DB files.
The program used to dump the contents of your DB files is called either one of two things: db_dump, or db_dump185. To determine which program you need to use, first try running the following command in your shell account:
$ cd <db_dir> $ db_dump author.db
If this command is successful, you will see a screenful of data dumped out. If it is unsuccessful, you will get an error message; in this case, try using the following command:
$ db_dump185 author.db
Again, if the command is successful, you will see a screenful of data. If this also fails, then you will need to contact your hosting provider.
$ db_dump -f author.db.data author.db $ mv author.db author.db.old $ db_load -f author.db.data author.db $ chmod 666 author.db
You will need to run these four commands for each file in your db directory whose name ends in .db or .idx. After you have done so, you're done, and Movable Type should now work.