New page – my WordPress themes

I’ve set up a new page for my free WordPress themes at
My themes are totally free (licensed under the GNU GPL 2 or later) and open source. You are free to download, modify, and redistribute them (under the same license).
These themes are designed to be configurable and easy to use, but they are intended for a broad audience. If you want me to develop a custom theme for your web site or blog, just send me an email at consulting -at-

Egret free WordPress theme, version 0.0.4

From the Egret theme blog:

A new version of the Egret theme is available-it has only one minor fix which I realized would be useful when creating Egret child themes.  The goal for this version is that the stylesheet should now be able to easily modify all the divs:

-some div tags had a mal-formed id; now have fixed id declaration

-also: removed link tag

Egret 0.0.4 is a free WordPress theme released under the GNU GPL, version 2 or later.

Download Egret theme version 0.0.4 here

(previous [already outdated] version: Egret 0.0.3 is a […])

Egret free WordPress theme, version 0.0.2

I have a new free theme for WordPress available. It’s called the Egret theme and it is very primitive right now but is a start in the direction of making HTML5 themes. Following through on what I said, I did not place a link to the site in the footer of the theme. Here is the announcement from the theme’s blog:

An early version of Egret, 0.0.2, is now ready for release. Egret is free software; it is a theme for WordPress, licensed under the GNU GPL, version 2 or later.
Here is a list of features:
1. uses WordPress 3+ background image features: the blogger can set background color, or upload their own background image
2. makes use of Gravatars with comments
3. centered on page
4. HTML5
5. minimalism
It’s actually a very simple theme, I hope to improve it but if you want to try it now here is the link

Update: A new version of Egret is available.

WordPress is getting overzealous about their trademark; better to not use it at all

Jeff Chandler at writes:

“In WordPress 3.0, folks can no longer incorrectly misspell WordPress with a lower case p (WordPress). This use is detected by the following patch (14996) that Matt Mullenweg wrote and was then committed by Andrew Nacin. The code simply adds a filter that looks for WordPress used with a lower case p within the content, the post title, and comment text. If detected, the word is replace by the correct spelling. It’s a very simple patch but its simplicity has met strong resistance from those in the developer circle.

One of the arguments against this patch deals with performance which is discussed earlier on in the comments within ticket 13971.

Then there is the principle of the matter. Should WordPress force the use of a word without consent or recourse?”

If the people developing WordPress core are going to act with such contempt for end users, I think the best solution is to stop promoting the WordPress brand on our own sites. I’m planning to simply not put a link to in the next theme I develop.

Maybe this processor-expensive, anti-user auto-correct “feature” simply arises out of the desire to control end users on the part of the core devs–an unfortunate possibility. But it might have to do with people higher up the food chain. After all, Mr. Mullenweg is probably in this for the money and the money is on the side of doing whatever True Ventures, their lawyers and Giga Om tell him to do. And lawyers love aggressive stances on trademarks just as much as they love WordPerfect.

I think that Automattic is becoming another sleazy brand in the tech space like Microsoft (their new friend). Since is still effectively their captive, one solution comes down to end users not promoting that brand–nothing makes you put that WP link in your blog except your desire to support the project–and my desire to support is down to aroud zero. Mr. Mullenweg is certainly all about letting people “vote with your feet” and stop using WordPress. But WordPress code is licensed under GPL2, which means that my feet don’t have to be any one place in order to use the code freely. I’ll think instead about voting with my links.

Also, I’m wondering if we (the oppressed end users) could get the Free Software Foundation involved in this?

Keet version 0.1 (free theme for WordPress 3+ w/custom menu and custom header)

The Keet theme (version 0.1) for WordPress is now available for download:

download (ZIP archive)

or download the same file archived as a gzipped tarball

Keet is a sharp, flexible, free new theme framework that requires WordPress 3 or later.
While designed to have a similar layout to the new default theme (Twenty-ten) for WordPress, Keet offers some tweaks on the formula while still supporting the new features in WordPress.

Keet is free software; it is licensed under the GNU GPL, version 2 or later.

Here is a list of some of Keet’s features:
–Implements the new WordPress custom menus feature*, so the list of links below the header graphic can be user-defined.
–Eight free header graphics* to choose from, or (because of new WordPress features) submit a user-generated header graphic that you created yourself [just as in the Twenty-ten theme, except I’ve built the eight header graphics in Keet from myself and my wife’s own photographs and art].
–two-column layout–one large main column for content plus a widegetized right sidebar; in addition a narrow left side widgetized sidebar is available; when widget columns are unused they just disappear.
–Uses one of the new Google Web Fonts called Crimson Text by Sebastian Kosch for typography.
–Avoids excessive in-page navigation links and does not have a link on the author name to go to author archives.
–markup is in XHTML Transitional 1.0.
–Includes supports for Gravatars, pingbacks, and post attachments.
*–requires WordPress version 3 or later.

Myna theme version 0.5

Myna, a free theme for WordPress, now has version 0.5 available for download.

This version offers these changes from 0.4:
-CSS used to style text input field for comments
-extraneous comments removed from code
-CSS used to standardize size and weight of h1 and h2 tags
-readme.txt added (in the included folder) which notes that the theme is released under the GNU GPL (version 2 or later); also notes that the PHP code in the theme was informed by the tutorial at
-fixed favicon tag in header.php to work better and not repeat
-improved archive.php page that allows full post content to be shown
-added Jquery reference in header.php

Download Myna theme version 0.5 here

Or you can click here for the same code in tarball form

Myna theme version 0.4

Looking for a free, minimal theme for a WordPress blog that uses tags, not categories, offers widgets on left and right, and creates simple, minimal pages that let the content speak for itself?

Myna theme version 0.4 is now available.

This version offers these changes:
–added WordPress footer code (allows compatibility with numerous plugins)
–changed a few br tags to XHTML-appropriate br / tags
–style sheet changes for styling of a [anchor] tags to make links bold/slightly-lighter-blue when unclicked and unbold/darker-blue if already clicked on
–added category pages; based on Myna’s tag pages
–added archive pages
–added links at bottom (+ top) of index and archive and tag and category pages for navigation (older posts/newer posts)

As you probably know, the Myna theme is free software–it is released under the GNU GPL, version 2 or later.

You can download the 0.4 version of the Myna theme here

Update: A new version of Myna (0.5) is available.

Myna theme version 0.2

A new version of my Myna theme for WordPress is now available:

This version, 0.2, adds a few new features and refinements. Here are some of them:
–tag pages (which put the tag info within the h1 tag to distinguish them from other archive pages)
–updated titles for single posts to include blog name after post name
–refined favicon call to make it more likely to work on single post pages
–ultra-simple 404 page which includes link to blog home page

Myna is free software; it is released under the GNU GPL, version 2 or later.

You can download the 0.2 version of the Myna theme here

Update: A new version of Myna (0.5) is available.

A new theme on this blog

Seeking to bend, if only slightly, to the web design trends of the last three years, I have put new themes on the three flagship blogs here on the–this front page blog, the podcast, and the photo-blog.
I am (at this moment–though these things change over time) using the Kirby theme from Ian Stewart, the WordPress theme designer behind Thematic. If you use WordPress and don’t know about Thematic, you should visit its web site. In my opinion, Ian Stewart is not only one of the best theme designers, but he also is one of the most influential as he makes clear, usable and GPL-compatible frameworks that anyone can use or modify. The Kirby theme is very flexible, and emphasizes readability and accessibility. And it makes it easy to add your own header graphic–I’ve used photos by Jessica and me for the artwork at the top of the blogs.
I want to make the site readable for users with smartphones, and I am somewhat skeptical of the idea of constantly maintaining a parallel web site for mobile users, and would rather make a site that is hopefully usable for a vast majority of users and devices. [I find this site pretty good with my iPod Touch 2nd generation, although I do use the pinch-to-zoom a bit.]
Anyway my view on the new look is that the theme works very well for the podcast blog, and overall pretty well for this front page blog. It might be my choice of themes for a while on those sites.
But the way it works with the posts on the photo-blog leaves too many spaces between photo and description [one of the things that I updated the theme to Kirby for was the ability to read photo captions, but hence all the posts up to this date have used the body of the post after the embedded photo and a space so it leaves too much room].
Anyway I am interested to know what readers think about the new looks (for now) for the blogs.

Don't bother submitting tickets to WordPress

I submitted a ticket to the WordPress Trac about a problem with perma-link previewing and it was ignored for a while. Then someone submitted a bug report very similiar to mine–and Denis de Bernardy said that mine was redundant to that subsequent one that had been submitted, and also to another previous one (#6619) that actually isn’t the same issue and is only tangentially related, but that he had reported. Here is ticket #6619 as submitted by de Bernardy:

“if you create a sub-page, the permalink field should display the proper permalink.

currently, if you have:

and when you create:

the permalink shows:

until it gets saved

the expected behavior would be for it to show the correct permalink.

the same remark applies when you then change the permalink. if the parent is no longer page, but rather page-2, then the permalink should update accordingly.”

Here is my report, #7183:

“When writing a post: If you fill out the title field, then start editing the body of the post, the perma-link preview will match your title (in slug form). So far, so good.

But let’s say you decide to change the title before publishing–in that instance, the perma-link preview will stay the same as the original title, but when the post is actually published the perma-link (slug) will turn out to reflect the later, edited title. The same issue applies when leaving the title field blank at first–but in this case the slug is auto-assigned as the post number, and not updated when the user goes back to change the title–but the slug turns out reflecting the title anyway when the post is published.

(I know that this differs when one actually edits the perma-link and hits save.)

Judging by the behavior I’ve described, at first I actually thought that there might be a feature that allowed the user to create the slug first and then go back and change the post title to something different, but then I realized that such a feature was illusory and what we really have here is a bug, however minor, that can be confusing and cause link breakage.

Fixing this (by having the slug updated each time the post is auto-saved, perhaps?) would improve consistency and predictability and create a more intuitive interface.”

And here is the one (#7733) that is still in effect (though unfixed of course) even though it was submitted after mine:

“When writing a new post, the permalink is shown based on the title of the first autosave (instead of first save). The permalink is correctly set upon first save, but this behavior can be confusing as the permalink appears to change on the first save.

I believe this first appeared with autosave in version 2.6. It still exists in version 2.6.2 (not available in the version drop down).

To reproduce this: 1. Create a new post 2. Enter some body text 3. Wait for the autosave 4. Note that the permalink is shown to be the post number 5. Enter a title 6. Note the permalink does not change 7. Save the post 8. Note that the permalink has been updated to reflect the title.”

So why was the third one noticed and mine (the second one quoted above) ignored? Mine was moved out from version 2.5 which I reported it for to version 2.9 almost immediately by Ryan Boren, and after the second ticket was submitted by azaozz for version 2.6 it was picked up on fairly quickly and then my ticket was dismissed by Bernardy.
So what is the lesson? Basically, if you have a bug report to submit to WordPress, don’t bother unless you are a core committer or at least high-profile on the WP Trac. Otherwise your ticket will probably be ignored until one of the above submits a similar report anyway.