- MT’s native Debug mode
- Set DebugMode 4 in mt-config.cgi to see the SQL each page is generating.
- Useful system commands
- indicates processes stealing all the cpu
- shows available memory on the machine
Your rebuild is likely timing out.
- 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
- (full doc is here: http://www.movabletype.org/documentation/mt42/performance-logging.html)
- The PerformanceLoggingThreshold is in seconds, so the above example will print to the daily file generated in /var/log/mt any templates that take longer than 1.0 seconds to rebuild.
- tail -f /var/log/mt/<todaysfile>.log and rebuild your entry.
- 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.
- 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.
You’ll need MT access and database access. This is the strategy:
- 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).
- Go to Manage -> Assets and find an offset of assets that isolate the bad one(s).
- 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.
- 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.
- 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.
- Confirm your template archive mappings are set, make sense, and aren’t being overwritten by any other templates or blogs.
- 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.
- 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?
- 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”
- 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)
- If the file’s extension is php, is PHP allowed on that server? Do any other files use php?
- 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: http://www.mysite.com/mt/mt-static) 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.
- 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.
- Do you have ImageMagick or NetPBM installed?
- 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.
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/DBI.pm <…/cgi-bin/mt/extlib/Data/ObjectDriver/Driver/DBI.pm> 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 movabletype.mt_author warning : 1 client is using or hasn't closed the table properly status : OK movabletype.mt_blog warning : 1 client is using or hasn't closed the table properly status : OK movabletype.mt_category OK movabletype.mt_comment warning : 2 clients are using or haven't closed the table properly status : OK movabletype.mt_config OK movabletype.mt_entry 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 movabletype.mt_fileinfo 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 <snip>
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.