Movable Type User Manual: TROUBLESHOOTING

« Table of Contents


TROUBLESHOOTING

I see the source of the CGI script when I run Movable Type

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.

  1. Find the configuration file httpd.conf, and open it up in an editor.

  2. Find the Directory or Location block that configures the webroot for the server.

    Inside of that block, add this line:

    Options +ExecCGI
    

  3. Outside of the Directory or Location block, add the line
    AddHandler cgi-script .cgi
    

  4. Restart the webserver.

CGI scripts should now execute, instead of merely displaying their source.

I get a 500 Internal Server Error

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:

Errors when running mt-load.cgi

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:

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.

``Can't load error template''

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:

  1. First check to ensure that the directory tmpl is in the same directory as mt.cgi; that inside tmpl there is a directory called cms; and that inside cms there are a number of files with the extension .tmpl.

    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.

  2. If all of the files are in the location they should be, the issue may be that your webserver runs CGI scripts with a different current working directory than the directory in which the CGI scripts actually live.

    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.

Perl modules cannot be loaded

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:

  1. First, you should run mt-check.cgi to ensure that all of the Perl modules required for Movable Type usage are installed on your webserver. If they are not, follow the instructions in the Installation Documentation.

  2. Check to make sure that in the directory containing your CGI files (for example, mt.cgi), there is a directory called lib; inside that the file in the error message (for example, Some/File.pm) should exist. For example, with the above error message, the file lib/Some/File.pm should exist.

    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.

Images, styles, and documentation do not show up

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 inside 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.

Some buttons produce no action

The problem: you click on a button, like ``Delete Comments'' and nothing happens.

The most common reasons for this are either: you have JavaScript disabled in your browser, or you have not moved the mt.js file into your ``static files'' directory. To enable JavaScript, see the documentation for your web browser. If JavaScript is enabled, try moving mt.js: follow the directions above in the scenario where images do not appear. mt.js should be in the same directory as your images directory.

I keep getting the Movable Type login screen

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.

If you repeatedly get the ``Invalid Login'' message even though you're confident you've entered your name and password correctly, it may be that you have installed a new version but have not run upgrade scripts to upgrade your installation. See Upgrading.

I can't logout!

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.

My PHP output files need to be executable

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.

I never receive email notifications for comments

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:

  1. Determine the location of sendmail on your webserver. You may need to ask your hosting provider or system administrator for this information.

  2. In the directory where you installed Movable Type, there is a file called mt.cfg; download that file, and open it in an editor. (If you are comfortable with the shell, you do not need to download the file, but can instead edit it in vi or another editor of your choosing.)

  3. Add this line to the file:
    SendMailPath /path/to/sendmail
    

    where /path/to/sendmail is the path to sendmail that you determined in Step 1.

  4. Save mt.cfg, and re-upload it to your server. Ensure that you upload the file in ASCII (text) format. (If you used the shell to edit the file, you can skip this step.)

That's it; if the location to sendmail is correct, you should now be able to receive email notifications of new comments.

My webserver doesn't have sendmail

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.

My host doesn't have Image::Magick

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:

  1. Install IPC::Run
    You'll need to install the IPC::Run Perl module, which Movable Type uses to talk to the NetPBM tools. Download the file at this URL:
    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.

  2. Edit mt.cfg
    Edit your mt.cfg file, and add this line
    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.

I get an error, 'Can't call method ``force'' on unblessed reference' when rebuilding

This message appears when using a plugin that's not compatible with Movable Type version 3.0 or later. Some plugin developers will need to make a change to their code in order to be compatible with the latest versions.

If you see this message, look for an upgraded version of the plugin. If one doesn't yet exist, you'll have to remove the plugin until it is updated.

I get an error about .new files when rebuilding

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.

Movable Type encodes the characters in my language incorrectly

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.

I imported a weblog from an older version of Movable Type and when I publish, accented characters come out incorrectly

If you are importing a weblog from a version of Movable Type before 3.0, your data is most likely encoded using the ISO-8859-1 character encoding, but Movable Type 3.0 is set by default to use the UTF-8 encoding.

To change the character encoding used by Movable Type, open your mt.cfg file and find the line that reads

PublishCharset utf-8

Change utf-8 to the same encoding that was given in the PublishCharset option in your old installation's configuration file.

I don't like the 404 error page that comes with MT

The 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:

  1. Create a file .htaccess in the directory where you installed Movable Type.

  2. Open that file in an editor.

  3. Add the line Options -Indexes to that file.

  4. Save the file, then exit the editor.

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.

I get a message that Perl crashed whenever I save an entry. What can I do about it?

Assuming you are using a supported version of Perl and a supported webserver, the most likely cause for this is that your environment doesn't support the ``background tasks'' feature that we've used to streamline the user experience for rebuilding.

If you are suffering crashes, try turning off MT's background tasks by adding the following line to your mt.cfg:

LaunchBackgroundTasks 0

I changed hosts, and now I can't log in to Movable Type.

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.

  1. First, and most important, back up your DB files; you need to create backup copies of all of the files in your db directory. (If you do this by downloading the directory, make sure to transfer it in binary mode.)

  2. The easiest way to convert the DB files is to use the db_upgrade program; unfortunately this is not available on every server, but it may be available on yours. To find out, log into your shell account, and type the following at your shell prompt (<db_dir> is the path to your db directory):
    $ 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.

  3. If the above db_upgrade command does not work--for example, if you get an error saying that 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.

  4. Now that you have determined which db_dump program to use (either db_dump or db_dump185), you can dump all of the data from your old DBM files and load it into new versions of those files. To do that, try the following (substitute db_dump185 instead of db_dump, if necessary):
    $ 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.

I see the source of the mtview.php script when I view my dynamic pages.

You may not have PHP installed on your server. Or it may not be associated with files that have a ``php'' extension. If you are running with Apache, you can add the association for PHP to your .htaccess file:

AddType application/x-httpd-php .php

If this does not resolve the problem, consult with your web hosting provider about how to run PHP scripts on your site.

I'm getting a database connection error when viewing dynamically published pages.

Be sure that the ``mtview.php'' script contains the proper path to your mt.cfg file. Movable Type should populate this for you, but if it doesn't, you may have to assign the location manually:

$mt = new MT(<$MTBlogID$>, '/path/to/mt.cfg');

Dynamic pages are extremely slow.

Review the suggestions provided in the ``Optimizing your Dynamic Pages''.

I'm getting errors executing certain tags with dynamic publishing enabled.

The dynamic publishing option supports the core Movable Type tags plus any PHP-written plugins you may have installed. If you have Perl-written plugins installed for Movable Type's static publishing mode, those will not be available to the dynamic process. Any such tags would have to be removed from your dynamic templates until the plugin is ported to PHP for use with dynamic publishing.

I'm making changes to my templates/posts, but the dynamic pages are not reflecting the changes.

Check to make sure there is not a static HTML file on the web server that may be taking precedent. If a physical file exists for a given URL, it will be served instead of generating the page dynamically. Once it is removed from the server, the ``mtview.php'' script can execute to serve the page dynamically.

I see messages that say ``Use of uninitialized value...'' at the bottom of some screens

These warnings sometimes indicate a deeper problem and other times they're harmless. Make a note of the message, and in particular the part of the message after ``lib/MT,'' for example: ``lib/MT/Template/Context.pm line 472.'' If you have other problems with Movable Type, include these messages in the bug report.


top