Not a developer? Go to




  • Useful system commands
    • top
      • indicates processes stealing all the cpu

    • free

      • shows available memory on the machine


WSOD (white screen of death)

… when I republish an entry

Your rebuild is likely timing out.

Step One: Identifying The Expensive Template

  • If the WSOD happens before the entry shows “Republishing <entry title>….”, Check to see if there are any multiblog triggers that affect this blog. You’ll need to focus on that blog in your template debugging if the current blog rebuilds the multiblog-based blog.
mysql> select * from mt_plugindata where plugindata_plugin='Multiblog';
  • You have a few options after that.
    • Identify which index templates are being republished on entry save. It may help to turn each on to publish either manually or static as you’re debugging just so you can rule out which templates rebuild in a timely manner.
    • Use the BuildTracer plugin to find out how long each template is building. The downfall of this tool is that it is also susceptible to WSODs. Once the template is installed, go to Manage -> FileInfo. Indexes are shown by default; entries are in the right sidebar.
    • Turn on Performance Logging.
      • Create a directory on the server where the daily log files will be created. Make sure MT can write new files to the dir. (we’ll use /var/log/mt/ as the example here.)
      • In the mt-config, add the following:

    DebugMode 8
    PerformanceLogging 1
    PerformanceLoggingPath /var/log/mt/
    PerformanceLoggingThreshold 1.0

Step Two: Caching the Expensive Template

  • Do your best to identify the “expensive”, or time-costly, code in your template. BuildTracer is your best start, but you may be able to tell just by looking. Costly tags include:
    • Recommend counts
    • mt:entries loops with categories
    • anything across all blogs
    • several more

  • Whether or not you can find it, cache the template’s contents for now.

    • Turn on Template Module caching. Settings -> Publishing.
    • If the template wasn’t already a module, create one and copy the original contents into the new module, named “costly_template” or something. Then be sure to <mt:include module=”costly_template”> in the original template.
    • Cache the template module by expanding the options at the bottom. The window of time is your choice, as is the reason for expiration, but make it higher than 10 minutes for the sake of debugging. You can always decrease it later.
    • Go back to the original condition that caused the WSOD (likely saving an entry) and try again. Repeat Steps One and Two until all costly code has been identified and cached.

…when I view Manage -> Assets

  • This can happen when:
    • an image you’ve uploaded is corrupt
    • an image you’ve uploaded is a different type than its extension (ex: uploading a PhotoShop file that ends in .jpg)
    • a file you’ve uploaded can’t be handled by your image library (ex: your ImageMagick installation can’t handle .png-formatted files but you uploaded one anyway

  • It’s happening because the underlying image library (like ImageMagick or NetPBM or something) is trying to create thumbnails on files that MT classifies as ‘images’ (based on file extension ONLY as of MT 4.23). The library dies at the system level and doesn’t give any indication to MT as to why it died; just a WSOD.

How to pinpoint your Bad Asset

You’ll need MT access and database access. This is the strategy:

  1. Find the bad asset(s).
    • Go to Manage -> Assets and find an offset of assets that isolate the bad one(s).
      • You should see a WSOD here.
      • Add ‘&offset=25’ in the url. This will ignore the 25 most recent assets uploaded to this blog.
        • If you still see a WSOD, you either have more than one corrupt asset or or a bad Image Magick installation. Can you view the assets for any other blogs (not system level)? This is likely not the result of one singular file and won’t be straightforward to track down.
      • If you don’t see a WSOD with the older assets (offset=25), then you know that some asset in the most recent 25 is our target. Decrease the offset value in the URL until you have a decent-sized sampling set (say 5 for arguments sake).
  2. Look up the asset’s information in the database and find which individual ones make WSODs (given your blog_id=m, offset=n)
    • select asset_id, asset_class, asset_url from mt_asset where asset_blog_id=m order by asset_created_on desc limit n;
    • View each MT::Asset object through the Edit Asset screen in MT. The parameters will be like this: mt.cgi?__mode=view&_type=asset&blog_id=10&id=8099 , so change the id parameter every time. The Edit Assets that do NOT lead to WSODs are safe. Pinpoint the id’s that lead to WSODs.
  3. Either (1) remove the mt_asset rows that are bad, or upload another file of the same name (to overwrite the bad one) that is not corrupt/of the wrong type.
    • If you remove the mt_asset row, you won’t be removing the physical file from the server, but it will take the offending object out of the Manage Assets listing. Uploading the same file to overwrite the offending one is the best approach, since the problem lies with the physical file itself. But be sure that you know why this image is broken before you upload another in its place. If its type is actually a Photoshop file but you named it with a .jpg, use some other program to actually convert the file to be in the jpg format. If your Image Magick doesn’t allow pngs, don’t upload them—-even when they end in .jpg, ImageMagick can still tell how the file is formatted despite its extension. Firefox is pretty good at determining file type (in the top Title bar) based on a url, although curl is the superior tool.

My Entry Doesn’t Publish

… and I don’t see any errors on save+rebuild

  1. Check to see if any files in this blog are using the publish queue. Design -> Templates should show immediately which templates are using which method of publishing.
    If any of your individual entry templates are using the publish queue, make them publish Statically. This will prevent the masking of potential template syntax errors.
  2. Confirm your template archive mappings are set, make sense, and aren’t being overwritten by any other templates or blogs.
  3. Look at the blog’s Preferences -> Publishing settings to see where the files are building on the server.
    Check each of the following
    Blog Site URL
    Is this url configured via apache to be accesible on this server?
    Blog Site Path
    Does this path exist on the system? Can MT write to it?
    Blog Archive URL + Path
    If these values are not set, just refer to the top two. Otherwise, use the same check for the url and path as above.
  4. Do you have any rewrites on the server that would affect how your page is served? Like translating - to _ accidentally and that’s why your page is breaking?
  5. Publish an index file in the same directory that your entry is supposed to go into by simply making the index’s outfile be something like 2008/01/great_new_entry.html with the body as simple as barebones html with “THIS IS A GREAT NEW ENTRY”
  6. If you’re using the Publish Queue…
    are you using a cron job to run run-periodic-tasks? Check that.
    Use the PublishQueueManager to see what’s in your Pub Q (System Overview -> Manage -> Publish Queue)
  7. If the file’s extension is php, is PHP allowed on that server? Do any other files use php?

None of my users have Avatars (and they’re supposed to)

…and I just upgraded from MT 4 to a later version of MT 4.

  • If you were using the core Profile Avatar feature, first confirm that users have avatars assigned:
mysql> select author_id, author_name, author_userpic_asset_id from mt_author where author_userpic_asset_id > 0 limit 20;
  • Then, pick one of those author_userpic_asset_ids (say id=n) and find out its original URL:
mysql> select asset_id, asset_url from mt_asset where asset_id=n;
  • Replace the %s in the asset_url value with the url to the mt-static directory (ex: and confirm that your file is there. If the originally uploaded avatar isn’t on the server in the current mt-static directory, thumbnailed avatars will NOT be created in support/assets_c/userpics .
  • This is a silent error upon upgrade: COPY ALL OF YOUR mt-static/support FILES TO YOUR LIVE INSTANCE just after upgrade.

…and I just upgraded from a CommunityPack-like installation to the lastest version of MT4.

  • Your commenters might be authors of type ‘2’. Use these queries to find out if your authors have the wrong type:
mysql> select count(*) from mt_author;
mysql> select count(distinct author_name) from mt_author;
  • If these two counts are different, then you likely have the MT3-CommunityPack-style of having authors of type 2 for comment and 1 for authors:
mysql> select count(*) from mt_author where author_type=1;
  • You’ll need a script to merge the two or just translate all authors of type2 to become type1. Don’t forget to translate over the comment data, since comments will be authored by the author_id whose type=2.

…for some other reason

  1. Do you have ImageMagick or NetPBM installed?

I can’t see my entry or template text in MT’s editors

See below.

I can’t edit my entry or template text in MT’s editors

  • You’re probably using the wrong URL to access Movable Type. Common mistakes include leaving off the www before the domain, or using another subdomain instead of the one that mt-config defines as the MT installation. This happens because the entry and template editor area is actually an iframe, and if it’s accessed from a different subdomain than the page itself, the browser recognizes it as a cross-site scripting security problem. Safari doesn’t show the text, Firefox shows it as read-only.

Recovering from a Database Failure

In the event that a database shuts down prematurely or unexpectedly, tables may become corrupt or out of sync. In such an event it is possible that Movable Type may remain functional until the application attempts to access one of those corrupt tables at which time you may encounter an application error like the following.

Statement has no result columns to bind (perhaps you need to successfully call execute first) at …/cgi-bin/mt/extlib/Data/ObjectDriver/Driver/ <…/cgi-bin/mt/extlib/Data/ObjectDriver/Driver/> line 119.

In most cases this error is easily recovered from by running an integrity check on the database. If you are running MySQL you can do this by running the mysqlcheck command. We recommend first scanning the database for errors before repairing them. First execute:

mysqlcheck -u <user> -p <movabletype_db>

If errors are found, you may see output like this:

movabletype.mt_asset                               OK
movabletype.mt_association                         OK
warning  : 1 client is using or hasn't closed the table properly
status   : OK
warning  : 1 client is using or hasn't closed the table properly
status   : OK
movabletype.mt_category                            OK
warning  : 2 clients are using or haven't closed the table properly
status   : OK
movabletype.mt_config                              OK
warning  : 3 clients are using or haven't closed the table properly
status   : OK
movabletype.mt_ext_bl_group                        OK
movabletype.mt_ext_bl_groupmap                     OK
movabletype.mt_ext_bl_item                         OK
movabletype.mt_ext_bl_log                          OK
movabletype.mt_ext_bl_permission                   OK
movabletype.mt_ext_bl_source                       OK
movabletype.mt_ext_bl_update                       OK
warning  : Table is marked as crashed
warning  : 1 client is using or hasn't closed the table properly
error    : Size of datafile is: 4722688         Should be: 4722692
error    : Corrupt
movabletype.mt_ipbanlist                           OK
movabletype.mt_log                                 OK
movabletype.mt_notification                        OK
movabletype.mt_notifier_data                       OK
movabletype.mt_notifier_queue                      OK

If it appears your database may have corrupt tables, repair your database using the proper command. In MySQL, you would run:

mysqlcheck -r -u <user> -p <movabletype_db>

This command should then indicate if it was able to repair your corrupted tables. For example:

info     : Found link that points at 4722672 (outside data file) at 1870256
status   : OK

Once that is complete, try accessing Movable Type again to see if your problem is resolved.


1 Comment

Mike Pepper

Mike Pepper on December 6, 2009, 3:40 p.m. Reply

Thanks so much for this! Not a MySQL pro and scared to death of screwing it up.

Can you tell me, please; will this also fix errors where there are multiple indexes? That’s the error that we see.

Thanks again.