Looks like when using only GUID the results are still None.

Example from GUID (only) use in a map.mako file is None and if only GUID is used within rss.mako file, instead of the (present) option for Permalink, results are also None.

Based on my tests and my read of the code:

1. if you explicitly set the guid value in the YAML of your blog post, that value is passed to the template code unaltered.
2. if you do not set the guid value or the permalink value in the YAML of your post, the guid is set to None and passed to your template code.
3. if you set the permalink value in the YAML of your post, but do not set the guid value there, then the value you set for permalink is passed to your template as both post.guid and post.permalink.

Note: when automatically generating a permalink from the template in the config file the string :uuid (which, by default, is not part of the template string) is replaced with the hex representation of the sha1 hash of the blog title. It seems like that would not necessarily be universally unique. :)

The changes I propose:

1. if you do not set the guid value or the permalink value in your post the guid is generated as a hash of month, day and title.
2. if you set the permalink value in your post but not guid, then the guid is generated as a hash of the permalink
3. when building permalinks from a template, the value of :uuid is replaced by the post guid, which should be urlencoded if provided by the user.
4. when automatically generating a guid use the url-safe base64 representation of the hash (base64.urlsafe_b64encode) rather than the hex representation of the hash.

One issue I want to call out is that if the behavior of :uuid in the permalink template changes, it will probably change some people's existing permalinks. I think this is justified because the :uuid should really be replace with something more likely to be universally unique.

Anyway, I'll work on a patch.

I've implemented the changes I've suggested in my tree (git://github.com/szoth/blogofile.git) in commit ef1111f:

https://github.com/szoth/blogofile/commit/ef1111f85c850b8d76204b468460856152b8f17b

I suppose the base64 encoding might be too ugly for some and couldn't be used in a javascript identifier. My own feeling is that base16 is wasteful of url real estate.

Excellent. Good fix.

Merged in SHA: 7754006