There are plenty of way to have “automated” newsletters sent out based on your WordPress blog’s RSS feed. Feedburner and MailChimp, among other do this, and there’s nothing wrong with those services.

However, if you’d want to write content specifically for your weekly e-mail, RSS is not ideal. High quality e-mailings usually don’t simply copy blog posts, they’re carefullt crafted by copywriters to get as much response as possible. That’s why the idea of a newsletter-theme has been floating around in my head. Here’s what I’m thinking might work…

Using WordPress to author e-mail newsletters

1. Set up a WordPress install on something like mycompany.com/newsletter.
2. Write posts like you normally would.
3. The theme renders the newsletter as e-mail-friendly HTML.
4. Take the theme’s output and send it out using a bulk e-mail service of your choice.
5. The WordPress install functions as a “read this online” fallback and image host.
6. Ideally, the theme would have a custom taxonomy to group posts into newsletter issues.

I once spent a couple of weeks editing HTML mailings for use in a very high-end e-mail newsletter system that did not have a nice visual editor, and this idea is primarily aimed at the users of such systems. But even compared to more user-friendly systems, there’s a case to be made for using WordPress. Authoring in an environment you control makes it easier to switch mailing services, and WordPress adds near unlimited flexibility.

Potential drawbacks

No plan, certainly not one as immature as this one, is perfect. Gathering statistics is critical with newsletters, and there’s tons of standard WordPress stuff that the theme would have to omit to keep the result e-mail client friendly. But I think a customizable newsletter theme for WordPress has potential. I’d love to hear what you think.

For a project I’m working on, I needed to create a split menu, where the top level navigation was in a horizontal menu in the header, with all underlying content listed elsewhere on the page. This turned out to be a little harder than I had anticipated, but I managed to get it working. Here’s how I did it. Feel free to add suggestions in the comments if you see room for improvement.

The horizontal menu

For the main menu (shown in red in the image above), I wanted to use WordPress 3.0′s new ‘Menus’ feature. By doing so, my client has full control over the menu’s content. Setting it up is very easy to do, so I won’t bother explaining it here.

WordPress automatically adds CSS classes to the menu for selected items, so highlighting the current selection is very easy.

#mainmenu li.current-menu-item,
#mainmenu li.current-page-ancestor,
#mainmenu li.current-post-ancestor,
#mainmenu li.current-category-ancestor { background-color: #00f; }

The sub menu

The main issue with the secondary menu (light blue in the image) was figuring out what to display. It’s easy enough in WordPress to feed the current page’s ID number to the wp_list_pages function and get its children, but in this case, that’s not what I wanted. I needed to display the menu from the selected main menu item on down, even if the current page was nested four levels deep. So instead of using the current page’s ID, I needed to figure out the selected top level page, and use that page’s ID.

function rt_getTopPageID( $page_ID ){
	$ancestors = get_post_ancestors($page_ID);
	if( !empty($ancestors) ){
		foreach( $ancestors as $ancestor ){
			$anc = get_post_ancestors($ancestor);
			if( empty($anc) ){ return $ancestor; }
		}
	}
	return $page_ID;
}

I added this function to my theme’s functions.php file. What it does is move up the page hierarchy step my step until it reaches the top page. It returns that page’s ID for use with wp_list_pages. I’m aware that this may be slow, but it’s the most efficient way I could find to get the top page.

On the sidebar, I used something like this to display the sub menu:

global $wp_query;
$page_ID = $wp_query->post->ID;
$toppage = rt_getTopPageID( $page_ID );
wp_list_pages( 'title_li=&child_of='.$toppage );

What this does is get the current page’s ID from the page query, and feed it to my rt_getTopPageID function. The returned ID is then used to call the correct menu.

Categories

I then needed to do the same for categories. I ended up creating a sidebar widget that, depending on the context, displayed the right menu. The widget is very specific to my project, but here’s the function it uses to get the top category.

function rt_getTopCategoryID( $cat_ID ){
	$pathStr = get_category_parents( $cat_ID, false, '[#]', false );
	$pathArr = explode( '[#]', $pathStr );
	$cat = get_term_by( 'name', $pathArr[0], 'category' );
	return $cat->term_id;
}

This function uses a shortcut to get to the top level category. The get_category_parents function returns a string with the full hierarchy, which we can then split. The first item in the resulting array is the top category’s name. Using get_term_by, we can then get that category’s ID. I’m assuming that this is lighter and quicker than trying to move up the hierarchy like I did with the pages.

The widget then uses this function to get the category structure. On category overview pages, I use this code.

$cat_ID = get_query_var('cat');
$topCat = rt_getTopCategoryID( $cat_ID );
wp_list_categories( 'title_li=&child_of='.$topCat );

On single post pages, This is what I currently use, but I’ll be the first to admit this needs work. Posts can be in many categories, which can result in all sorts of weirdness. Some editorial restraint will be in order for my client, but the principle works.

global $post;
$categories = get_the_category($post->ID);
$topCat = rt_getTopCategoryID( $categories[0]->term_id );
wp_list_categories( 'title_li=&child_of='.$topCat );

That’s it. My widget now shows the correct menu on single page, post and category pages. There’s probably some room left for improvement, so don’t be shy and comment away.

The templating system in WordPress is very flexible, and there’s rarely something you can’t do or that doesn’t work as you’d expect. A notable exception however is the_date. Its purpose is simple enough. It displays the current post’s date of creation. But on pages with more than one post (such as on many blog home pages), something weird happens. If a number of posts on any given page were created on the same date, the_date will only show that date for the first of those posts.

In the early days of blogging, posts were usually listed by date, much like a regular, paper diary. In the old default theme that comes with WordPress a big date title is used to separate posts into days. That’s what the_date was created to do, and so it makes sense it only displays the same date once. In most modern themes however, people like the date to be among the meta data for each article, so the_date falls short.

the_time

In comes the_time. This template tag, as the name suggests, shows the time at which a post was created. However, it accepts a PHP time format string as an argument, and can be made to display the date. You could simply put a date formatting string in there and be done with it, but I like to keep things flexible, so i wanted to use the date format string set in WordPress’ settings. That way the user controls the output, and it can be adjusted to international preferences.

When I first ran into this I posted my issue on the WordPress forums, and Otto42 came up with a prefect solution. I’ve been using it ever since and thought I’d share it here.

the_time(get_option('date_format'));

What this does is get the user-set date format from WordPress and feed it to the_time. Since that function doesn’t have a ‘once a day’ limitation, you can use this as often as you like in your theme.

If you want to include an email link in a WordPress template, or any other web page for that matter, its advisable to ‘obfuscate’ the address. Unfortunately, spammers scour the web to harvest email addresses, so if you simply place your address online, you’re very likely to get a some extra unwanted email. That’s where obfuscation comes in.

If the address is fixed (the page is custom-made for one site) you can use a service like this to obfuscate that one address. In WordPress, it makes more sense to get the user or admin’s email from the system instead, and handle the obfuscation in the theme’s PHP file. I’ve been using a solution originally devised by Aaron Toponce, but with a few modifications.

<?php
     $link = 'mailto:' . get_bloginfo("admin_email");
     $obfuscatedLink = "";
     for ($i=0; $i<strlen($link); $i++){
         $obfuscatedLink .= "&#" . ord($link[$i]) . ";";
     }
?>
<a href="<?php echo $obfuscatedLink; ?>">email</a>


What this example does is take the WordPress admin email address, create a mailto link and then loop though the characters, replacing each with its ASCII equivalent. Your users won’t notice a thing, but when you look at the code you’ll see that the link is made up of ASCII codes. That’s you first line of defense against spammers.

I’ve been meaning to redesign this blog for a while now. Most of all I wanted a better sidebar setup which would accommodate more links and wider ads widgets. In fact, the old Papertrail theme I was using has only a very rudimentary widget support, and with the recent success of this blog I needed more flexibility.

Although still a work in progress, I quite like the results so far. It’s cleaner, it uses less Flash(*) and it loads extremely fast. The design still needs work and I definitely need a better tagline (wanna help me out with that one?).

* = I’ve come to believe that using Flash to create fancy titles simply isn’t worth the trouble. For one thing, most mobile phone browsers don’t support Flash, and the old theme looked terrible on those as a result. Flash is great for lots of things, but having 10+ movies on one page just to have specific font is like shooting a mosquito with a cannon (as we say here in the Netherlands).

I love it when business and pleasure coincide. I had to look into styling widgets today for an upcoming project, and decided to use my Paper Trail theme as test material. Turns out the markup of widgets gives you surprisingly (frustratingly) little to work with in terms of CSS. Still I managed to get the widgets to look like I wanted them to, thus completing the theme.

Paper Trail is a two column layout with fancy Flash post and blog titles.

• It requires Flash and Javascript (although it doesn’t break completely if these are missing). If your blog targets mobile users (for instance), this is not the theme for you.
• This is my first theme where I’ve paid any real attention to widget styling. Third party widgets may not look as intended. Chances are they will.
• Thanks to Geoff Stearns, the use of flash will not affect search engine ranking.
• The Flash titles contain complex algorithms that change things like line breaks and font size in order to best accommodate your post’s titles. Let me know if they act up. Using very long words in titles might render them unreadable.
• I’ll not be releasing the source code for the Flash movies. Mostly because I’m afraid you’ll laugh at me for my poor coding skills, but also because I fear you’ll ask me to explain how they work.
• Paper Trail was built for WordPress version 2.3, and will spend most if it’s time looking for missing things like tags on older versions (and not actually work).
• Because of limitations in the way Flash handles dynamic text the theme supports basic Latin characters only. Sorry about that.

If you want to give it a try, you can download it here.

As of now, ‘m testing a new WordPress theme on this site. I haven’t decided on a title yet, and there’s tons of little stuff missing, but I’m pretty sure I’ll be releasing this one sometime this or next month. The most important thing to sort out is decent widget support. This was sorely lacking from some of my earlier themes, and instead of updating them I decided to dedicate the time to designing a new one altogether.

I wanted to use a white background to increase readability, and I’m using Flash movies to do some typography tricks that plain HTML doesn’t know yet. Other than that it’s a relatively simple theme that will be easy to modify by anyone who isn’t completely allergic to style sheets or HTML.

So, what do you think?

I’ve been getting a lot of email asking me whether I’m going to be updating my themes to work with the new WordPress version that was released a couple of weeks ago. The short answer is ‘yes’, but there’s a ‘but’. I’m writing this from a spyware-ridden PC in an internet cafe in Bali, Crete, where I’m on vacation with my family. I’ll be back home next week and I hope to find the time to work on a new version for my themes. I’ll post the new versions here of course. Please hang in there a little longer…

One of the things I like about releasing WordPress themes is seeing what people do with them. Some just take out the credit link, other change so much I barely recognize my original work. And that’s a good thing. I try and make my themes easy to modify and do not attach any kind of license (which I know to be stupid, but I haven’t had the time to read up on things like Creative Commons).

Anyway, I liked Nikko City’s version (image above) of my Positive Feeling theme so much I thought I’d share it. They didn’t even change all that much, but seeing my layout used to sell Japanese cooking equipment made my day.

Matt of bestwpthemes.com contacted me a couple of days ago to let me know he added my Tranquility themes to his list of best WP themes. It’s always nice when someone adds your work to any kind of shortlist. Thanks Matt.