Apparently, WordPress 2.1+ doesn’t display pages with any post_status other than ‘publish’ to anonymous users. The pages Tarski creates are created with the post_status ’static’. This needs to be changed from ’static’ to ‘publish’ before anonymous users can see your Archives and Tags pages. However, those pages won’t even appear in the Manage section of the administrative interface.

To change the post_status on those pages, you have to change the database directly, using phpMyAdmin or some other database editing tool. Open the wp_posts table, and find the entries that Tarski created. The easy way to do this is to search for all the entries whose post_status is “static”. Those are the ones you want to fix. Simply edit those entries and change post_status to “publish”.

Now those pages will appear in the Manage interface, and anonymous users will be able to see them.

The first thing I noticed happening was that Gmail Notifier couldn’t connect. It kept failing to connect to the server, returning error 12029, “Can not log in to mailbox”. Firefox could open Google Mail without a problem, but Internet Explorer could not. I looked in the new firewall log to see if some new rule was messing things up, and sure enough, access was being blocked due to the rule “Block access to secure sites”. That turned out to be a spectacularly unhelpful rule.

What really happened is that the Windows SSL service was somehow disabled by the SCS install. Instead of being set to automatically run, it was set to manually run, and was stopped by default. Changing this service back to “automatic” and rebooting restored access to secure (https) sites.

Symptoms (after switching to a new Wordpress theme):

• The screenshot for the theme doesnt show up in the theme selector
• The pages on the blog are unstyled
• Theme images don’t load correctly
• Trying to manually open the URL’s for the stylesheets, images, etc, gives you a 404 page

The problem was that permissions were not set correctly on the unzipped theme folder. I had to make sure there was read and execute access granted on the folder and all the theme files (chmod 755 for you command-line junkies). You could probably do this through your FTP client, if it’s a decent one (I recommend Smart FTP).

Not a problem, says I…

I’ll just deactivate the WP-Cache plugin until I’m finished developing. As it turns out, that doesn’t work. Once you activate (on the plugins page) and enable (on the WP-Cache settings page) the WP-Cache plugin, to turn it off, you have to disable it (on the WP-Cache settings page). Deactivating the plugin does not disable caching.

I mostly work with Java and Eclipse, but do enough web stuff to beat my head against a wall every once in a while. This site will have tips, tutorials, bug workarounds, and anything else I can think of that people might find worthwhile.

I suppose I could start with the simplest and most embarrassing debugging problem I ever hit…

In Eclipse (and most interactive debuggers), you can set up expressions that are evaluated whenever the debugged process halts. Because these expressions are evaluated in the current thread context, they have full access to read (or write to) local variables. I happened to put a typo in one of these expressions, and did the ol’ “assign instead of compare” trick, evaluating “str = null” instead of “str == null”.

I didn’t really notice the bug, and didn’t end up needing to see whether str was null or not, so I went back to another view, hiding the debug expressions I had set (out of sight, out of mind, right?). It was about that time I started noticing a bizarre new bug… whenever I would hit a breakpoint, str would be null, even if the code I was stepping through didn’t do a thing with str! Fancy that!

Lesson 1: If there is weird behavior when debugging, check to see if expressions are being evaluated without you knowing.

Lesson 2: Use “null == str” instead of “str == null” to avoid assignment vs. compare bugs. (this actually doesn’t work in all languages… wait for a future post)