I spent a couple hours trying to diagnose why I couldn’t log into one of my blogs that used the Tarski theme. Every time I tried to login Wordpress would just hang forever. At first I thought it might be due to the Wordpress 2.5.1 update so I reinstalled. Then I thought it might be a database corruption so I created a new database and imported all my entries. Then I thought maybe it’s the plugins so I removed all plugins. Nothing seemed to work. But then I noticed that there were “edit” links on my blog entries - indicating that I was successfully logged in. So I clicked on the “edit” link and discovered I was able to edit entries. I just couldn’t get to the Dashboard or Tarski Options. So I tried going to the Tarski theme website looking for a possible solution - only to find that their website was not responding. That gave me a clue to start looking through the Tarski theme files for callbacks to the Tarski theme website.
VOILA!
It’s the stupid Tarski theme version checking function that’s hanging because it’s not able to retrieve the atom feed from their website. So I just commented out the code and now my blog is back to normal. The problem lies in wp-content/themes/tarksi/library/classes/version.php. I chose to disable version checking completely by commenting the body of the tarski_update_notifier() function on line 196:
function tarski_update_notifier($location = 'dashboard') {/*
$tarski_version = new Version;
$tarski_version->current_version_number();
$current = $tarski_version->current;
$svn_link = 'http://tarskitheme.com/help/updates/svn/';
// Update checking only performed when remote files can be accessed
if(can_get_remote()) {
// Only performs the update check when notification is enabled
if(get_tarski_option('update_notification')) {
$tarski_version->latest_version_number();
$tarski_version->latest_version_link();
$tarski_version->version_status();
}
$latest = $tarski_version->latest;
$latest_link = $tarski_version->latest_link;
$status = $tarski_version->status;
if($location == 'options_page') {
include(TARSKIDISPLAY . '/admin/version_options.php');
} elseif(!detectWPMU() || detectWPMUadmin()) {
include(TARSKIDISPLAY . '/admin/version_dashboard.php');
}
}*/
}
But the problem really lies with the version_feed_data() function on line 66. They need to set the timeout option for CURL and use ini_set(’default_socket_timeout’, $seconds); before calling file_get_contents(’http://tarskitheme.com/version.atom’);
TO THE CREATORS OF TARSKI: FIND A BETTER HOST AND FIX YOUR CODE!!!
TO THEME CREATORS: LEARN FROM THIS LESSON!!!!!
I was having caching problems with the search functionality across two of my MovableType blogs. At first I thought it was a problem with the FastSearch plugin I was using. But my other blog was having similar problems and was not using the FastSearch plugin. It turns out that I had the page caching option enabled in mtview.php:
$mt->caching = true;
Once I commented out this line the search worked fine.
I also noticed that in migrating over my blogs from MovableType 3 to MovableType 4, MT4 created a different naming convention - leaving all the old MT3 files in the archive directories. So I decided to delete all the archive files and just rebuild/republish the site. I needed a Linux command that would recursively go through all the directories and delete all php files. After consulting google I found my answer:
find . -name \*.php -exec rm {} \;
I recently noticed that I wasn’t receiving any comment email notifications from Movable Type so I decided to dive into the system to figure out what was going wrong. Running mt-check.cgi reported back that sendmail was installed so I thought it might be a permissions issue between the the apache user process and sendmail. I typed in ’sendmail’ at the prompt and received back a message talking about “Exim“. Well, I’m not a Linux guru, but I do know that Sendmail!=Exim. So I turned to google to tell me what the heck Exim is and how do I figure out what’s going wrong. Google pointed me to the exim log file on the system which I watched as I sent test emails from Movable Type. The exim.log showed that it could not resolve the email addresses and was failing. A second thing I noticed was the ton of spam it was successfully blocking. So I went back to google to find out more info. I tried searching on keywords “exim movabletype”, “exim configuration” and couldn’t find anything useful. Then after staring at the exim.conf file for 10min, the lines “domainlist local_domains=” hit me. Google had told me that Exim was used for transferring and relaying local mail. My mail is being hosted at google through google apps. So I did a new google search for “exim google apps“. That search gave up a clue that got me one step further: If you are using a linux server, don’t forget to edit the /etc/remotedomains file to delete your domain. Well after poking around the file system I knew that I didn’t have a “remotedomains” file, but it did sound very similar to my “/etc/virtual/domains” file mentioned in my exim.conf. So I googled “/etc/virtual/domains“. And saw my final clue titled: Disable SMTP to certain local domains? That article did not have the exact answer but gave me enough information for me to solve the problem. To disable SMTP/mail service for specific domains just copy “/etc/virtual/domains” to some other file such as “/etc/virtual/domains_with_smtp”, edit the file and delete all the domains which use google mail, then point exim.conf “domainlist local_domains=” and “domainlist relay_domains=” to use this new file.
Voila! Email notifications now work!
This morning I discovered that my websites were down again. That’s 3 times in the past two weeks that I’ve experienced service interruptions. I immediately emailed Dreamhost support about my “bad_httpd_conf” error. Ten hours later I received a phone call telling me that my service interruption was due to the fact that my plan had been switched to a more reliable server and the new DNS entries had not yet propagated. I didn’t buy it. Well an hour later I received an email stating that they discovered a configuration error on this new machine. Not good. Their only saving grace at this point is that they are friendly and respond pretty quickly to support requests. I came so close to switching to MediaTemple and their (dv) dedicated-virtual plan. But I know that MediaTemple has been having a lot of problems with their infrastructure as well. So I’m sticking with DreamHost for now. Hopefully this Dream will get better from this point on.