Cowboy Programming Game Development and General Hacking by the Old West

I had a problem with the “Links” widget not showing up in the sidebar in WordPress, and categories not showing up in admin. I originally thought it was a problem with upgrading to 2.3.2, but eventually tracked it down to what seems like a problem with MySQL (I’m using 4.1.22).

The solution for me was to delete the file /tmp/#sql_5de0_0.MYD (or a file with a similar looking name, and probably zero size)

Note though that vanishing categories and links seems to be a symptom of several problems – including no deactivating (or upgrading) plugins while/after upgrading to 2.3.X. Check this threads for additional details:
http://wordpress.org/support/topic/135564?replies=95

I think my problem was something to do with character sets, given that I have a few blogs (some I just host for other people), and the blogs that worked were in utf8 and the blogs that did not were in latin1, so another solution might be to convert your blog to utf8. This is a much more complex procedure than deleting a spurious temporary file.

To track this down, I first enabled debugging in wp-config.php, by adding the line:

define(‘WP_DEBUG’, true);

Then when you view your blog (turn off caching first), instead of just blankness where the links should be, you will now see an error, and also the query that cause that error. In my case it looked like this:

SELECT t. * , tt. *
FROM wp_terms AS t
INNER JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id
WHERE tt.taxonomy
IN (
'link_category'
)
AND tt.count >0
ORDER BY t.term_id ASC
LIMIT 0 , 30
MySQL said:
#1 - Can't create/write to file '/tmp/#sql_5de0_0.MYD' (Errcode: 17)

I verified that it’s not a problem with WordPress by trying the same query in phpMyAdmin. With my working blogs the query succeeded, and with the non-working blogs it failed, with the same error.

So, I looked in /tmp/ and the file #sql_5de0_0.MYD was there, and of zero length. So, I just deleted it, and everything immediately started working perfectly again.

I suspect that the file was simply left over from when my server crashed under a particularly heavy load a few weeks ago.

This may be related to this problem:

 http://bugs.mysql.com/bug.php?id=11824

This error can also happen on windows installations due to an anti-virus program such as McAfee. You should add the folder where you find the file to MacAfee’s exclusion list.

I’ve been using the WordPress plugin SyntaxHighlighter to show code in posts. This worked fine, but after I was Redditted yesterday I was looking at optimizing my pages and I noticed that SH was serving up at least three files, even if it was not used on a page (which it was not, on the page that had been linked from Reddit).

So I did a little digging, and made my first plugin mod.
https://cowboyprogramming.com/2007/10/24/optional-code-in-wordpress-header/
View this Post
SyntaxHighlighter works by hooking in three actions:

add_action( 'wp_head', 'syntaxHeader' );
add_action( 'the_content', 'syntaxPost' );
add_action( 'wp_footer', 'syntaxFooter' );

The middle one does most of the work, handing a post to a syntax highlighter with the appropriate options. It’s called once per post on the page.

The other two functions respectively insert a CSS link into the page header, and a JavaScript link for each supported language into the page footer. The problem was they did this regardless of if they were actually going to be used, so every single page had these additional links, slowing down my finely tuned blog.

To fix this, I simply added this function:

// Return true if any post on this page contains the text '[source:'
function hasSyntaxPost()
{
$is_syntaxPost = false;
global $posts;
for($i=0;$i<=(count($posts)-1);$i++)
{
if( strpos( $posts[$i]->post_content, '[source:' ) !== false )
{
$is_syntaxPost = true;
}
}
return $is_syntaxPost;
}

and used it to wrap the header and footer code, like:

// Add CSS to header
function syntaxHeader() {
if (hasSyntaxPost())
{
$syntaxPath = syntaxPath();
echo "\n\t<link type=\"text/css\" rel=\"stylesheet\" href=\"{$syntaxPath}Styles/SyntaxHighlighter.css\" />\n";
}
}

That’s it. Since I know almost nothing about PHP or WordPress, I coded this with cut-and-paste coding, stealing a few lines of code from:

http://trevorcreech.com/geekery/wordpress/per-post-css/

Result: works perfectly – only pages that contain posts that need highlighting actually have the extra code added.

I then modified it to only include the languages that are used, so the user does not have to worry about setting them in the options page, and it gives an extra performance boost, as most posts will only include one language (like here I just have PHP, and on other pages I have C++).

You can see all the changed in the modified syntax.php here:

Note: When testing things like this, disable the cache until you get it working.