If you’re using Pyzor to help you block spam (a lot of people use it alongside SpamAssassin), then you’ve probably run into these nasty “pyzor: check failed: internal error” messages in your maillog since July 21st.
     After digging into on my own a bit, I found two things.  The first was the “InternalError” was being caused by a corrupt “servers” file that contained nothing but “File Not Found” information.  The second was that the “discover” command line was returning:

downloading servers from http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x
Traceback (most recent call last):
  File “/usr/bin/pyzor”, line 4, in ?
    pyzor.client.run()
  File “/usr/lib/python2.4/site-packages/pyzor/client.py”, line 991, in run
    ExecCall().run()
  File “/usr/lib/python2.4/site-packages/pyzor/client.py”, line 185, in run
    self.servers  = self.get_servers(servers_fn)
  File “/usr/lib/python2.4/site-packages/pyzor/client.py”, line 410, in get_servers
    servers.read(open(servers_fn))
  File “/usr/lib/python2.4/site-packages/pyzor/client.py”, line 119, in read
    self.append(pyzor.Address.from_str(line))
  File “/usr/lib/python2.4/site-packages/pyzor/__init__.py”, line 458, in from_str
    fields[1] = int(fields[1])
IndexError: list index out of range 

     Obviously, linking to non-existent files, especially in the /cgi-bin/ directory, is a bad thing.

     As a temporary measure, simply disable your “pyzor discover” cron job, and manually add “82.94.255.100:24441” into your “servers” file (wherever it may be with your configuration).

     Ya know, I saw a random bug report in the WordPress forums about the Search Everything plugin with no actual description about what the bug was.  It just had a code snippet and said “108.”  No explanation, no fix… Just a complaint that says “108.”

     In SE-Admin.php, change Line 108 from:

<p><input type=”checkbox” id=”search_drafts” name=”search_drafts” value=”true”  <?php if($options[‘SE4_use_draft_search’] == ‘true’) { echo ‘checked=”true”‘; } ?>

     To:

<p><input type=”checkbox” id=”search_drafts” name=”search_drafts” value=”true”  <?php if($options[‘SE4_use_draft_search’] == ‘true’) { echo ‘checked=”true”‘; } ?> />

     Of course, while you’re at it, you can fix Line 102 from:

<p>     <input type=”checkbox” class=”SE_text_input” id=”appvd_comments” name=”appvd_comments” value=”true”  <?php if($options[‘SE4_approved_comments_only’] == ‘true’) { echo ‘checked=”true”‘; } ?>

to

<p>     <input type=”checkbox” class=”SE_text_input” id=”appvd_comments” name=”appvd_comments” value=”true”  <?php if($options[‘SE4_approved_comments_only’] == ‘true’) { echo ‘checked=”true”‘; } ?> />

     After doing that, some of the check boxes will actually show and work on the Settings page…

     There’s a stopper-style bug in the the latest Akismet plugin for WordPress.  If you have multiple pages of Spam Comments, it keeps returning the first fifty — not good if you get as much Spam as we do, as we have to periodically check for false positives.
     The fix is easy…

     In Akismet 2.1.4, change wp-content/plugins/akismet/akismet.php, line 483 from:

        $comments = akismet_spam_comments( $current_type );

     to

        $comments = akismet_spam_comments( $current_type, $page );

     And Enjoy.  😉

     Arne Brachnold’s Google Sitemap Generator for WordPress is a pretty neat piece of software that’ll build a Google-style XML-Sitemap, and ping Google with it every time you update your blog.
     Good stuff for SEO, good stuff for making sure Google has your site indexed. 

     After setting up a few blogs with the latest, I found a caveat that just annoyed me to death: you’re in the Admin, but when you manually update the sitemap, it comes back with a blank page. Sure, I know how to work around it, but they guys I’m setting this stuff up for get all huffy about it.
     Pretty quick bug to figure out.  There’s even a nice ticket on Trac (Ticket 604) that I’m unable to post this solution to…
     Line 2463 of sitemap.php is:

<script type=”text/javascript” src=”list-manipulation.js” mce_src=”list-manipulation.js”></script>

     Of course, that doesn’t exist, but if we change it to:

<script type=”text/javascript” src=”../wp-includes/js/list-manipulation-js.php” mce_src=”../wp-includes/js/list-manipulation-js.php”></script>

     …then all is right and good with the world.

     Hopefully, Arne’ll drop this in his next release — and be able to close Ticket 604 on Trac.  😉

[Ed. Note: The text of this article refers to “the latest” WordPress (2.1.x) and version of the plugin for it (3.0xxx).]

     Yesterday, I was called to fix this bug, which caused a SQL error when users would go to the Stats / Leaders page:

Error:

mySQL query error: SELECT m.id, m.name, m.email, m.hide_email, m.location, m.aim_name, m.icq_number,
  f.id as forum_id, f.read_perms, f.name as forum_name, c.state
  FROM ibf_members m, ibf_categories c
  LEFT JOIN ibf_moderators mod ON((m.id=mod.member_id or (mod.is_group=1 and mod.group_id=m.mgroup)))
  LEFT JOIN ibf_forums f ON(f.id=mod.forum_id)
  WHERE c.id=f.category AND c.state != 0

mySQL error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘mod ON((m.id=mod.member_id or (mod.is_group=1 and mod.group_id=m.mgroup)))’ at line 4

     Not too difficult to spot that first LEFT JOIN is broke … Editing the query in ~/sources/misc/stats.php, line 255, and surrounding `mod` with backticks did the job.

     Although, it’d be nice if customers would keep their software versions up-to-date…