ode - a simple personal publishing platform for the web

I just wrote about how the new ShyPosts addin can be used to preview unpublished posts. As the title of this post suggests, you can do the same thing with themes.

If you're making changes to a theme or working on a brand new theme, no one will be able to see it unless they specifically request it, as long as it is not the current version of the default theme. That gives you 2 options.

1 - You can give your new theme a name other than the default (even if it will eventually be the default theme for your site).

'new_unfinished' would work fine. You could preview your new theme by specifically requesting it, like:

http://example.net/cgi-bin/ode.cgi/index.new_unfinished

All of your visitors would see your current default. Creating a new theme is as simple as copying an existing them and changing it's name.

When you're finished with the new version, give it the same name as the default theme and you're done.

Read the rest of this post

The credit for this helpful how-to goes to an Ode user named Daniel.

I don't know how much other info he wants me to share, so I'll leave it at that for now. (Daniel let me know if you'd like me to include a link to your website or any other biographical info.)

Thanks for your time and efforts Daniel! It's much appreciated.

What follows is an almost direct copy of the document he sent to me. I've made a few slight formatting changes and maybe a grammatical issue here or there, but that's about it.

Install Ode with lighttpd in Debian Squeeze

Both lighttpd and Ode are quite light weight. Lighttpd is a web server like Apache while Ode is blog software like Wordpress. Together they're a great solution for maintaining a simple personal blog especially installed on your laptop.

Read the rest of this post

Note: I refer to the 'next release' throughout this post. The current release at the time I'm writing this post is 1.2.3. So the next release will be anything greater than 1.2.3.

I say a nearly complete all for several reasons:

1. First, it's possible that I may have missed something. (Hopefully that's not the case, but it is possible.)

2. As the project continues to evolve there will be new theme variables. It probably makes sense to maintain an up to date listing of all variables. (This post may not be the right place to keep that list going forward.)

3. Ode uses a lot of variables only some of which are appropriate to use in themes. Some are clearly useful in themes. Others are clearly not useful. And there are some that aren't obviously one or the other. I am making some judgement calls.

4. It's important to note that this list only includes variables defined in the script itself (ode.cgi) and in ode's configuration file.

Additional variables may be defined by addins. In fact, that's a pretty good use of an addin, and I expect it to be quite common. You'll want to read to the documentation included with any addins you install to learn about variables they might provide.

In fact, that's a pretty good use of an addin, and I expect it to be quite common. You'll want to read to the documentation included with any addins you install to learn about variables they might provide.

Read the rest of this post

At this point we've seen all of the components of an Ode theme (page, date, content_type, page_no_posts). But, we've only briefly looked at a few of the variables that are used as placeholders for dynamic content in themes. In the next post I will provide a nearly complete list of these variables. I want to use this post to provide some information that will help you put those variables to use.

As I've already hinted at, variables come from 3 sources:

1. The script itself (ode.cgi)
2. Ode's configuration file
3. Addins

Read the rest of this post

Alternative tite: Probably more than you ever wanted to know about the page_title variable.

I've been working on a list of variables that can used in themes as part of the documentation for the project. It was going pretty well and then I got to the page_title variable.

I don't know if you've ever given it much thought, but coming up with a useful page title can take some doing. Ode uses a number of different forms of page title depending on the type of request. As I started to describe the value of this variable I decided that it needed its own post.

The page title is intended to serve as the title of the current page. That being the case, you should consider adding it to the title element in the head section of your page._ theme file.

Of course, it's not a requirement that you use the page_title as your page's title, but if you do Ode will take care of generating reasonable page titles for you.

You can also put the page_title anywhere else on the page that makes sense to you. For example, you might want to display a stylized page title somewhere in the body of the page as part of the overall site design.

On the other hand, it probably doesn't make sense to include the page_title in the post section of the page. The value will not change from one post to the next. Instead the same title would repeat once for each post. I can't immediately think of a case where that would be a useful thing to do. (There may be one, but I can't think of it.)

So what is the page_title anyway?

Read the rest of this post

If I were asked to describe Ode concisely I might say,

Ode is an extensible personal publishing engine for the web.

Yeah, that's sounds good to me.

I'd like to discuss 2 particularly important ideas expressed in that short definition (though only one is directly relevant to this post).

• The difference between a publishing platform and a publishing engine.

• The value of an extensible project

The difference between a publishing platform and a publishing engine.

I like the term engine rather than platform because I think it better captures the spirit of/nature of/what Ode actually is/what Ode is intended to be. A platform is a foundation on which something else is built. In some sense, it's an entirely new or distinct way of doing things. That's not what Ode is. Ode is intended to be an extension of the underlying technology. The platform is the web itself, not Ode. The engine is a part of a larger whole. It's device that converts energy into motion. That sounds more like it. Ode takes static content and converts it to something that's dynamic. It's a relatively straight-forward, purely functional thing. It's an engine, definitely not a platform, for sure.

The value of an extensible project

Because it's extensible, you can make it do new things, without rewriting the script itself. That's good. It also means that you can experiment with Ode and accomplish things that would take far more time and effort to do if you had to start from the very beginning with a en empty file. (Starting to write any substantial program from scratch is an intimidating process. I know.) That's also good. Just as importantly, like the rest of the project, Ode's addin mechanism is intended to be as simple (easily understandable) as possible, without dumbing down the experience. More than anything else, this is what makes Ode an interesting project (in my opinion).

Let's say you have no programming experience at all, but you want to learn. Ode is a great place to start. What do you need to know?

Read the rest of this post

There is only one more theme component to discuss, page_no_posts.theme_name, and you already know almost everything you need to know about it. (Assuming you've read the page.theme_name post.)

page_no_posts._ follows all of the same rules as the page._ theme file. In fact page_no_posts._ is itself a page theme component. It's a special version of page._ that's used whenever there are no posts matching the current request.

I'll say that again. page_no_posts._ is an alternative page._ component.

So the script does something like this:

if(the number of posts matching the current request > 0)
{
  use page._
}
else
{
  use page_no_posts._
}

Read the rest of this post

Without a doubt the most important theme component is page.theme_name. Fortunately, it requires the least amount of explanation.

If you open that file in a text editor, you'll see what looks like any other html document. The file starts with a doctype declaration, and ends with the closing html tag.

If you're already comfortable working with HTML, you should have no trouble understanding the page._ theme file.

This one file (along with associated stylesheets, images, etc.) Dictates the look at the layout of your site, with the exception of the post date separators, which as we've already seen, are found in the date._ file.

So is that all you need to know? Not quite, there are a couple of important Ode specific things about the page._ file.

Read the rest of this post

Though not hard to understand, this one may be a little hard to explain.

A typical Ode site will have a collection of posts, listed in reverse chronological order (i.e. newest posts at the top). Whenever two posts appear on different days, a date separator inserted between them.

The date theme file is where you define this date separator.

Keep in mind that there may be 1, 2, ..., 100, or any other number of posts without a date separator between them, as long as the post dates for each do not trigger the insertion of a date separator. (Keep reading.)

The content of the file is just a snippet of HTML. For example, here is the complete content of the date component file from the default theme.

<!-- BEGIN, date._ theme -->
<div class="date_separator">
<ul>
  <li class="wkday_name">$ode::wkday_name</li>
  <li class="separator">|</li>
  <li class="month_day">$ode::month_day</li>
  <li class="month_name">$ode::month_name</li>
  <li class="year">$ode::year</li>
</ul>
</div>
<!-- END, date._ theme -->

As you can see it's just an under-ordered list - though a list that's been pretty heavily marked up with classes so that it can be styled easily. You can of course modify the content of this file, however you see fit. (You might want to remove some of those classes if you don't think they're necessary.)

Read the rest of this post

The content_type theme file gives theme designers an opportunity to set the content _type and encoding of the document in the HTTP response header.

The contents of this theme component file must be one of a small number of legitimate (i.e recognized and valid) content_type strings -- and of course the value must be appropriate for the page being returned.

More specifically, the value should be consistent with the content type and character set encoding specified in the HTML page being returned. For an Ode theme, this is set in the page._ theme file. (We'll get the page file in a moment.)

Read the rest of this post