After declaring compatibility with WordPress 3.0 for Cornerstone a couple days ago, I of course found a few bugs.  I spent some time squashing those bugs and ended up finding a couple more.

Cornerstone

So far, I’ve only found one new compatibility-related bug in Cornerstone (I did say I still had testing to do), but it was one that had me digging through a lot more code than I would have liked to get to the root of the issue.  As I was running through my tests, I noticed that all page permalinks were coming up as “page not found”.  I initially thought that this was due to some overzealous permalink rewriting, but the issue was still there after disabling all rewrite rule modifications.

After disabling about half of Cornerstone’s functionality to determine the cause of the issue, I narrowed it down to a conditional statement in the recent update I made to the Content Types module.  The conditional was supposed to determine the different situations where the additional post types should be added to the query so that all posts (regardless of their post type) were retrieved and displayed.  While most of the bases were covered, I forgot to exclude the situation were only one content item (i.e. a post, a page, an attachment, etc.) was requested.  I added an additional statement to the excluded situations,

is_singular()

and pages were loading up as good as new!  I then just re-enabled all of the modules that I disabled while I was troubleshooting the issue and we were back in business.

Archetyped

I recently decided to change the name of the Dump section since the content I’ve been adding to has been more resource-based as opposed to just brain dumps that I initially imagined I would be using that section for (turns out that’s what the Blog section is good for).  While WordPress makes this a fairly painless process, as it provides the UI to change the section’s title and slug (used in the URI) as well as handling redirects for links to posts in the old section, I still had a bit of manual work to do.  Specifically, I had to change the icon used to specify the section content belongs to.

Old Dump Section Icon

Since I was changing the icon text, I also decided to rectify something that started bugging me about these icons.  With text this small, Photoshop’s antialiasing causes the icon text to appear blurry and dull.  I don’t feel that they are clear enough, so I decided to remove the antialiasing all together since small text will generally be sharper and easier to read without any antialiasing applied.  However, it obviously would not do to have sharp text  just for one section, so I decided to change all of the icons.  It’s not really that bad, since there aren’t that many sections.

I think the new icons are much clearer and more readable so it was worth the time to rebuild all of the section icons.  All I really had to do to add them to the theme was overwrite the old image files with the newly generated ones.  Easy.

However, as I was testing the new icons, I noticed that the section descriptions were no longer showing up.

Section title and description

I initially wasn’t sure why this was, but it seemed to be related to differences in WordPress 3.0 and earlier versions of WordPress as my test server (using 3.0) was having this issue, while another test server (that uses an earlier version of WordPress) does not.  By inspecting the query variables for the page, I was able to see that the global $pages variable was not being populated with the current page’s content, which caused an issue because the get_the_content() function used in the theme uses this variable to retrieve a post’s content.  To resolve this issue, I simply wrapped the page’s output in the following conditional statement to pre-populate all of the necessary variables with the page’s data.

if ( have_posts() ) : the_post(); //Setup page data
/* Page Output */
endif; //End page output

Finally, it appears that my featured posts are no longer being properly retrieved.  As it stands, I’m not sure why this is, but it will have to wait until tomorrow as I’ve run out of time today.

Finding bugs is not always fun, but it is always good because it means that I’m able to fix an issue that I previously didn’t know about.  As much as I’d like my code to be perfect right out of the gate, I know there will always be room for improvement and optimization, so I’m thankful I at least came across these bugs before deploying my updates to my production server.