enigmacurry / blogofile Goto Github PK

There may be more blog related hard coded assumptions that can be pulled out of the blogofile code and put into the template space. The more we pull out of the code to be put in templates makes blogofile more flexible.

I doubt though that we can pull it out entirely, as templates are really only good at generating single pages, not driving the output of multiple pages that a blog requires.

John Feminella's comments:

There's a good chunk of code embedded into Blogofile that does the template processing. But theoretically, there's no reason to treat these as special, right? What if you just put as much of the template-specific processing into the templates themselves?

Then Blogofile could simply provide an environmental context for each template to run in, so that templates can electively reach in and ask Blogofile about the data they need. Then templates effectively just assemble the pieces they need, and you don't need to treat any of them differently within Blogofile. This would slice out a big chunk of the complexity and move it into templates. Win-win!

HierarchicalCache objects are designed to create sub-Caches as needed on the fly. For instance:

bf.config.one.two.three = "something"

one, two and three don't need to exist beforehand, they are created on the fly. This makes configuration less verbose and more expressive.

But when the "one" module is non-existant, the traceback is unhelpful in debugging:

>>> bf.config.controllers.one.two.three.some_method()

File "XXX", line XX, in some_method
  bf.config.controllers.one.two.three.some_method()
TypeError: 'HierarchicalCache' object is not callable

The proper traceback should emit an AttributeError on the non-existance of the "one" module. Instead, "one","two", "three" and "some_method" are created as brand new HierarchicalCache objects. Consider the effect on a developer's psyche if he misspelled the "two" module and got the above traceback? Not very helpful.

Ideally, HierarchicalCache objects would only automatically create the sub-Cache objects when the user is doing an assignment operation, rather than when calling a method or performing a slice etc.

Possible solutions:

• Only enable the auto-creation of sub-Cache objects in the _config.py. This seems cludgy, I'd like it to work everywhere.

I tested using my own site and the blogofile.com source. I ran blogofile build, and pygments.css is missing from the css directory in both cases.

If unicode string is used in blog_name and blog_description in _config.py, the following error occurs.

SyntaxError: Non-ASCII character '\xec' in file ./_config.py on line 40, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

Upon running 'blogofile build' the first time, I get the following error:

ImportError: No module named pyquery

When I did the 'python setup.py install' for blogofile, it installed a lot of dependencies. However, not pyquery. So this should be part of the default dependencies.

(On Ubuntu, you will need the following packages: cython libxslt1-dev libxml2-dev
These are prereqs to install lxml from source, which is a prereq of pyquery.)

Hi,

I suggest this feature :

• append reStructuredText support to write post and some page

I'll to write a patch.

Regards,
Stephane

You see the yaml in the actual post, and the post title gets the default title.

It seems that since 2668def there hasn't been any syntax highlighting support in Blogofile. I can't find a filter that actually does syntax highlighting, the default seems like a no-op.

It would be useful if Blogofile reported more on success instead of silently completing, as well as showing progress while building for larger blogs. For example, it might be helpful to see simple metrics after completion like:

$ blogofile -b
processing 68 files (using 12 templates)... done
moving static files to _site... done
total processing time: 13 seconds

post.date.strftime("%B %-d, %Y at %-I:%M %p") is translated into 'August -d, 2009 at -I:52 PM' in python 2.5

I am running github current blogofile, and am trying to run 'blogofile build' for the first time on a blogfile.com init. But I get the following error:

$ blogofile build
Traceback (most recent call last):
File "/home/joseph/utils/bin/blogofile", line 9, in
load_entry_point('Blogofile==0.7.0', 'console_scripts', 'blogofile')()
File "/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/main.py", line 124, in main
args.func(args)
File "/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/main.py", line 182, in do_build
writer.write_site()
File "/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/writer.py", line 55, in write_site
self.run_controllers()
File "/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/writer.py", line 131, in __run_controllers
controller.run_all()
File "/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/controller.py", line 198, in run_all
controller.run()
File "_controllers/blog/__init.py", line 19, in run
blog.posts = bf.post.parse_posts("_posts")
TypeError: 'HierarchicalCache' object is not callable

Hi,

can you create a version 0.6.1 with this patch ?

http://github.com/EnigmaCurry/blogofile/commit/c3a5739f289faf92a16f897ca7072eab5c168ba6

my blog isn't compatible with blogofile 0.7 but I need to fix this issue.

Regards,
Stephane

I installed the github latest code. I ran 'blogofile init blogofile.com', but got the following error:

IOError: [Errno 2] No such file or directory: '/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/site_init/blogofile_com.zip'

Here is what is present in that directoy:
$ ls /home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/site_init
bare.zip blog_features.zip blogofile_com.py blogofile_com.pyc blog_unit_test.zip _config.py _config.pyc init.py init.pyc simple_blog.zip

How do I get the blogofile.com zip?

If the user is using both automatic permalink and automatic GUID generation, then a GUID is not generated properly because it attempts to do so before the permalink is generated. GUIDs generated in this fashion default to None.

Given a post, it should be possible to compute the URL that will be generated in some standardized way and use it accordingly. The justification for this is that it's often useful to be able to make links in lists of posts.

For example, let's say you want to construct a page that's an index of categories used on your site. Under each category header, you want to list the posts belonging to that category. Let's also say this is in a template categories-index.mako. It's possible to examine the posts and determine which posts should go into which category. But it's not obvious to me how you'd retrieve the permalink for a particular post for insertion.

Furthermore, what is the best/recommended practice for doing this in a generic way for Blogofile objects? Using the previous example, say you wanted to take it a step further, by generating a separate index page for each category. categories-index.mako might invoke a category.mako template for each category, for instance, and generate one big page that was a combined index of all the categories.

But now how should categories-index.mako refer to a specific category's URI to link to it?

I get the following error when I run 'python setup.py install' on the latest blogofile git pull.

byte-compiling build/bdist.linux-x86_64/egg/blogofile/util.py to util.pyc
  File "build/bdist.linux-x86_64/egg/blogofile/util.py", line 60
    p = path_join(*p, sep="/")
                        ^
SyntaxError: invalid syntax

This works:

blogofile -v build

This does not work:

blogofile build -v

Can we make global options work if following a subcommand?

jaemok-jeongyi-macbook-pro:blogofile.com jmjeong$ !bl
blogofile build
Traceback (most recent call last):
File "/usr/bin/blogofile", line 8, in
load_entry_point('Blogofile==0.4', 'console_scripts', 'blogofile')()
File "build/bdist.macosx-10.5-i386/egg/blogofile/main.py", line 108, in main
File "build/bdist.macosx-10.5-i386/egg/blogofile/main.py", line 158, in do_build
File "build/bdist.macosx-10.5-i386/egg/blogofile/writer.py", line 53, in write_blog
File "build/bdist.macosx-10.5-i386/egg/blogofile/writer.py", line 220, in __write_blog_first_page
IOError: [Errno 2] No such file or directory: '_site/blog/index.html'
jaemok-jeongyi-macbook-pro:blogofile.com jmjeong$

It would be useful to have a blogofile init command which sets up a minimal blogofile site structure with an example configuration file and templates (the one from blogofile.com would do nicely, I think).

The distribution tarballs are missing the zip files in site_init. Building them with sdist doesn't work either. The end result is that "blogofile init" doesn't work when it is installed this way.

$ tar ztvf blogofile-0.6.tar.gz | grep site_init
drwxr-xr-x  0 ryan   ryan        0 Mar 31  2010 blogofile-0.6/blogofile/site_init/
-rw-r--r--  0 ryan   ryan     1727 Mar 31  2010 blogofile-0.6/blogofile/site_init/__init__.py
-rw-r--r--  0 ryan   ryan      572 Mar 31  2010 blogofile-0.6/blogofile/site_init/bare.py
-rw-r--r--  0 ryan   ryan    18727 Mar 31  2010 blogofile-0.6/blogofile/site_init/blog_features.py
-rw-r--r--  0 ryan   ryan     8609 Mar 31  2010 blogofile-0.6/blogofile/site_init/blog_unit_test.py
-rw-r--r--  0 ryan   ryan     6911 Mar 31  2010 blogofile-0.6/blogofile/site_init/simple_blog.py
-rw-r--r--  0 ryan   ryan      553 Mar 31  2010 blogofile-0.6/blogofile/site_init/blogofile_com.py

Generated URLs have a leading slash "/" for posts. e.g.

• /page
• /%Y/%m

This limits blogofile to only publishing weblogs to root-directory deployments, e.g.

• http://www.blogofile.com/
• http://blog.example.com/

Users cannot currently use blogofile to deploy to www subdirectories, e.g.

• http://example.com/blog/
• http://www.example.org/~someuser/

While http://blogofile.com does demonstrate how to have a "blog" section of a site, blogofile does not support building / packaging weblogs for relative directories.

The permalink paragraph filter, makes redundant ids for paragraphs. Eg:

for the first paragraph of every post. Disabled that.

The anchor name for the blog post's title was " " separated. Edited that bit to make them "-" separated.

After that the other changes I had to make we ones where issue was mine, but knowing to use:

[script tag]
<script>
 
</script>
[/script tag]

To hide sections that trip up w3m from itself is a nice trick I found.

The parameter blog.post_encoding for the blog controller is not set in _config.py and yet it works.
If you clone the blog controller, blogofile does require the post_encoding option to be set explicitly for the clone though, so I guess that there's still some code left in the core, not the controller, that does set this option only for the blog component.

This error indicates that it isn't set in any clone of the original blog controller (in my case the clone was named 'projects'):
src = open(projectpage_path,"r").read().decode(bf.config.controllers.projects.post_encoding)
TypeError: decode() argument 1 must be string, not HierarchicalCache

I easy_install'ed blogofile, to get version 0.6 on my system.
I blogofile init'ed blogofile.com.
Then, when I try to blogofile build, I get the following error:

$ blogofile build
Traceback (most recent call last):
File "/home/joseph/utils/bin/blogofile", line 9, in
load_entry_point('Blogofile==0.6.0', 'console_scripts', 'blogofile')()
File "/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.6.0-py2.6.egg/blogofile/main.py", line 121, in main
args.func(args)
File "/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.6.0-py2.6.egg/blogofile/main.py", line 163, in do_build
config.init("_config.py")
File "/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.6.0-py2.6.egg/blogofile/config.py", line 221, in init
__load_config(config_file_path)
File "/home/joseph/utils/lib/python2.6/site-packages/Blogofile-0.6.0-py2.6.egg/blogofile/config.py", line 205, in __load_config
execfile(path)
File "_config.py", line 31, in
site.url = "http://www.blogofile.com"
NameError: name 'site' is not defined

Since this commit :
http://github.com/EnigmaCurry/blogofile/commit/de4e805749d15af5f67f579770f9ebad4bbce8d6

This code in my template didn't work :

% for post in bf.posts[:6]:

I've this error :

  File "/home/harobed/projets/harobed.org/harobed.blogofile/env1/lib/python2.6/site-packages/mako/runtime.py", line 278, in <lambda>
    return lambda *args, **kwargs:callable_(self.context, *args, **kwargs)
  File "memory:0x94b286c", line 9, in render_body
    % for post in bf.posts[:6]:
  File "/home/harobed/projets/harobed.org/harobed.blogofile/blogofile/blogofile/cache.py", line 65, in __getitem__
    dotted_parts = item.split(".")
AttributeError: 'slice' object has no attribute 'split'

Regards,
Stephane

http://groups.google.com/group/blogofile-discuss/browse_thread/thread/dc8c5681833b59b6

For the files in _posts or _drafts directory, textitle and markdown format can be used.
In another files not in _posts directory, textile and markdown format can't be used.

It would be great to use that format in normal documents.

When typing blogofile init, the message is:

For example, create a simple site, with a blog, and no theme:
blogofile init -t simple_blog

The -t is an invalid flag.

I have already patched this in my fork. How do I get you to accept it?

Results from this discussion: http://groups.google.com/group/blogofile-discuss/browse_thread/thread/170d2afd8e11ee62

• Remove blog_url
• Add a site_url which corresponds the _site directory
• Add a blog_path which is relative to _site
• make blog_auto_permalink relative to blog_path
• make a config option site_css_path relative to _site

Make thorough unit tests to ensure nothing breaks ;)

When running blogofile -b on a new site that has no configuration file, Blogofile gives a message that doesn't really address the source of the issue:

[...]> blogofile -b
Traceback (most recent call last):
  File "/usr/local/bin/blogofile", line 8, in <module>
    load_entry_point('Blogofile==0.4', 'console_scripts', 'blogofile')()
  File "build/bdist.linux-x86_64/egg/blogofile/main.py", line 77, in main
  File "/usr/lib/python2.6/ConfigParser.py", line 531, in get
    raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'syntax-highlighting'

It would be more helpful if it simply aborted with something akin to "configuration file not found".

Introduce a step in blog post parsing that md5/sha hashes the post and loads a preparsed Post object if the hash is unchanged.

Can this speed up rendering of large sites?

Each blog entry has date and updated field.
Sometime it is useful to sort article by 'updated' field.

How about adding blog_sort_date whcih specifies how to sort the blog entry?
blog_sort_date may have two options : "sort_by_post_date", "sort_by_modified_date"

The blogofile command-line interface could be more intuitive by implementing subcommands (instead of exclusively using switches/flags). For example,

• blogofile init (see #5)
• blogofile build
• blogofile build -c config.cfg -d

Think git subcommand and apt-get subcommand -- which are fairly intuitive interfaces. The idea is to put the action into the subcommand and keep command-line switches for avoiding defaults.

(I'm willing to contribute this change.)

For parsing, you might find the following package more useful than optparse.
http://code.google.com/p/argparse/

Looks like more windows path problems: http://groups.google.com/group/blogofile-discuss/browse_frm/thread/beed6fbcc60b1f2f

When rendering a category page, the posts object is limited to just that categories posts and prevents looking at all the posts. This messes up any "Recent Posts" listing for eg. in sidebars.

Probably the solution is to remove the filtering of posts from the blogofile side and move it into the template.

Modeled after the maven -fn (fail never) option, Blogofile should have the option to attempt to continue building when non fatal exceptions occur. Instead it should verbosely log the errors and continue building the site.

This should be a command line option as well as an option settable in _config.py, with the command line option trumping the one in _config.py.

I'm getting this error when trying to run blogofile build on a site where blog_path is set to "" -- in other words, where the blog_path is the document root:

OSError: [Errno 13] Permission denied: '//archive'

The Traceback is pretty confusing, but it appears that util.mkdir is the culprit.

I first discovered this when trying to convert my personal site -- which is built from the 0.5 pypi release -- to the current master branch (that is, post-merge with templates-externalized). But this can also be duplicated with a copy of the blogofile site. So steps to reproduce are:

1. blogofile init blogofile.com
2. change blog_path in _config.py to ""
3. blogofile build

Another thing that I'm sure is connected: if you leave the blog_path as "/blog", the site is built in _site as expected, but empty directories are also deposited in the project itself.

Again, I think util.mkdir is the problem, but I can't seem to suss out the offending code.

Blogofile seems to assume the presence of certain Mako templates in _templates, although this isn't clear from the docs. Although other static files appear to be generated and _site gets populated, there is an issue. In Blogofile 0.4, I get the following exception.

$ blogofile -b
Traceback (most recent call last):
  File "/usr/local/bin/blogofile", line 8, in <module>
    load_entry_point('Blogofile==0.4', 'console_scripts', 'blogofile')()
  File "build/bdist.linux-x86_64/egg/blogofile/main.py", line 87, in main
  File "build/bdist.linux-x86_64/egg/blogofile/writer.py", line 50, in write_blog
  File "build/bdist.linux-x86_64/egg/blogofile/writer.py", line 188, in __write_blog_chron
  File "/usr/local/lib/python2.6/dist-packages/Mako-0.2.4-py2.6.egg/mako/lookup.py", line 87, in get_template
    raise exceptions.TopLevelLookupException("Cant locate template for uri '%s'" % uri)
mako.exceptions.TopLevelLookupException: Cant locate template for uri 'chronological.mako'

Running touch _templates/chronological.mako solves this issue, but raises a new exception a few lines lower in writer.py@write_blog:51, saying the template for permapage.mako can't be found either.

Repeatedly performing touch on permapage.mako, rss.mako, and atom.mako to generate these files and appease Blogofile will work and remove the exceptions.

It's not necessarily clear to me that these are required from the documentation. I would suggest that, as a future improvement, there be a configuration option to specify which templates in _templates are actually looked at for generation. Then it would be sensible to complain about templates which are requested but not found. Additionally, this would allow users to generate only the templates they care about -- some blogs, for example, may not have a need for a chronological listing of posts or an Atom feed.

This bug is fixed here :

http://github.com/harobed/blogofile/commit/c3a5739f289faf92a16f897ca7072eab5c168ba6

Regards,
Stephane

if blog_path is "" in _config.py the generated link is wrong.

Next page' link is 'http://page/2'

Converting a Wordpress blog that is using a database encoded in latin1 on a system with the default character set as UTF-8 can cause certain characters to be embedded as incorrect files. An example problem character is the € sign which gets encoded as <80>, which is listed on Unicode charts as a control character. When you attempt to use blogofile build on the exported posts, it throws exceptions, such as the example here:

ERROR:blogofile.post:Error reading post: _posts/016 - building-a-pc.html  
Traceback (most recent call last):
File "_controllers/blog/post.py", line 333, in parse_posts
  bf.config.controllers.blog.post_encoding)
File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
  return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xb1 in position 822: invalid start byte
Traceback (most recent call last):
File "/usr/bin/blogofile", line 9, in <module>
  load_entry_point('Blogofile==0.7.0', 'console_scripts', 'blogofile')()
File "/usr/lib/python2.7/site-packages/Blogofile-0.7.0-py2.7.egg/blogofile/main.py", line 127, in main
  args.func(args)
File "/usr/lib/python2.7/site-packages/Blogofile-0.7.0-py2.7.egg/blogofile/main.py", line 192, in do_build
  writer.write_site()
File "/usr/lib/python2.7/site-packages/Blogofile-0.7.0-py2.7.egg/blogofile/writer.py", line 57, in write_site
  self.__run_controllers()
File "/usr/lib/python2.7/site-packages/Blogofile-0.7.0-py2.7.egg/blogofile/writer.py", line 134, in __run_controllers
  controller.run_all()
File "/usr/lib/python2.7/site-packages/Blogofile-0.7.0-py2.7.egg/blogofile/controller.py", line 204, in run_all
  controller.run()
File "_controllers/blog/__init__.py", line 25, in run
  blog.posts = post.parse_posts("_posts")
File "_controllers/blog/post.py", line 333, in parse_posts
  bf.config.controllers.blog.post_encoding)
File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
  return codecs.utf_8_decode(input, errors, True)

the command line option --config-file serves a wider purpose than it originally did in that it also specifies the directory for the source of the site.

Refactor --config-file to be called --source-dir (-s ?) and automatically assume there is going to be a _config.py in that same directory. I don't see a reason to make a separate config file location.

Rather than chaining filters to have markdown and code highlighting - it may be better in most cases to use markdowns extensions. This can be done easily by changing the markdown_template - to do something like this;

return markdown.markdown(content, ['codehilite','footnotes'])

It's easy to do, but only when you know where too look. I was hitting my head off the wall for a few mins.

In the 0.5 pypi release, writer.__get_archive_links() and writer.__get_all_categories() were responsible for creating the category and archive links. It appears that the responsibility has been passed to the project-level controller functions archives.write_monthly_archives and categories.write_categories.

There are at least a couple of problems I'm seeing:

1. Archive links aren't picking up the page dir number that they used to, so the user is taken to /archive/2009/11, but there's no index in that directory - it's been written to /archive/2009/11/1. Blogofile is writing that page, but the link isn't pointing to it correctly. For an example, see the blogofile.com archive list in the sidebar of the main blog page. (Note also, though, that the path on those links is relative to the current page. This is because of a problem with util.blog_path_helper. Check the fix in my 0.5 fork: http://github.com/mattd/blogofile/commit/9432c727bdb3fde1fb3a9629f9acb6582c87f59c#diff-0)
2. Category display pages are receiving a version of all_categories that only contains the currently viewed category. Notice the category list in the sidebar of this category detail page: http://blogofile.com/blog/category/development/. The way I figure, this must be because the cached all_categories is getting clobbered - but I can't find where.

In Blogofile's config.py, the user's configuration is included by means of an execfile() invocation. However, that won't put user modules in the load path. That means that if your _config.py imports some module which is on your sys.path but not Blogofile's, an ImportError will result.

To reproduce, try this:

blogofile init bare
mkdir -p _cfg
touch _cfg/__init__.py
echo "from _cfg import *" >> _config.py
echo "blog_enabled = False" >> _config.py
echo "print 'hello!'" >> _config.py
blogofile build

On blogofile 0.7.0, I am seeing sporadic build failures when I put Japanese text in the title of a post. All my files are UTF-8 encoded.

I only get errors for some posts, so I am hoping that this is supposed to work, as my blog has lots of Japanese titles.

The error is "UnicodeEncodeError: 'ascii' codec can't encode characters" and I pasted a transcript below wherein I reproduce the bug from start to finish in a bash shell.

Thanks.

Last login: Thu Jan 27 15:13:10 on ttys005


                              _____________________
                        ____||                     |
                       []   ||   NAKAHARA          |  ____
                       |    ||       INFORMATICS   | ___
                       |____||_____________________|
                        (o)   (o)            (o)(o)

 _________________________________________________________________


[mason@IT-PC-MACPRO-1 ~]$ mkdir /tmp/fuckery
[mason@IT-PC-MACPRO-1 ~]$ cd /tmp/fuckery/
[mason@IT-PC-MACPRO-1 fuckery]$ blogofile init simple_blog
Initializing the simple_blog site template...
[mason@IT-PC-MACPRO-1 fuckery]$ cat "_posts/003 - post 3.markdown" 

---
categories: Unicode
date: 2009/08/22 15:22:00
title: Post 3 - Unicode Test

---
Anglo-Saxon Rune Poem:

ᚠᛇᚻ᛫ᛒᛦᚦ᛫ᚠᚱᚩᚠᚢᚱ᛫ᚠᛁᚱᚪ᛫ᚷᛖᚻᚹᛦᛚᚳᚢᛗ
ᛋᚳᛖᚪᛚ᛫ᚦᛖᚪᚻ᛫ᛗᚪᚾᚾᚪ᛫ᚷᛖᚻᚹᛦᛚᚳ᛫ᛗᛁᚳᛚᚢᚾ᛫ᚻᛦᛏ᛫ᛞᚫᛚᚪᚾ
ᚷᛁᚠ᛫ᚻᛖ᛫ᚹᛁᛚᛖ᛫ᚠᚩᚱ᛫ᛞᚱᛁᚻᛏᚾᛖ᛫ᛞᚩᛗᛖᛋ᛫ᚻᛚᛇᛏᚪᚾ᛬

Tamil poetry:

யாமறிந்த மொழிகளிலே தமிழ்மொழி போல் இனிதாவது எங்கும் காணோம்,
பாமரராய் விலங்குகளாய், உலகனைத்தும் இகழ்ச்சிசொலப் பான்மை கெட்டு,
நாமமது தமிழரெனக் கொண்டு இங்கு வாழ்ந்திடுதல் நன்றோ? சொல்லீர்!
தேமதுரத் தமிழோசை உலகமெலாம் பரவும்வகை செய்தல் வேண்டும்.


I can eat glass:
私はガラスを食べられます。それは私を傷つけません。
Կրնամ ապակի ուտել և ինծի անհանգիստ չըներ։
I kå Glas frässa, ond des macht mr nix!
᚛᚛ᚉᚑᚅᚔᚉᚉᚔᚋ ᚔᚈᚔ ᚍᚂᚐᚅᚑ ᚅᚔᚋᚌᚓᚅᚐ᚜
אני יכול לאכול זכוכית וזה לא מזיק לי
काचं शक्नोम्यत्तुम् । नोपहिनस्ति माम् ॥ 

[mason@IT-PC-MACPRO-1 fuckery]$ COMMENT="
> 
> OK, cool, looks like blogofile supports
> Unicode. That's what I need. Let's just
> make sure it builds.
> "
[mason@IT-PC-MACPRO-1 fuckery]$ blogofile build
[mason@IT-PC-MACPRO-1 fuckery]$ COMMENT="
> 
> Great, it built no problem.
> "
[mason@IT-PC-MACPRO-1 fuckery]$ bbedit "_posts/003 - post 3.markdown" 
[mason@IT-PC-MACPRO-1 fuckery]$ cat "_posts/003 - post 3.markdown" 

---
categories: Unicode
date: 2009/08/22 15:22:00
title: Post 3 - Unicode Test　日本語テスト

---
Anglo-Saxon Rune Poem:

ᚠᛇᚻ᛫ᛒᛦᚦ᛫ᚠᚱᚩᚠᚢᚱ᛫ᚠᛁᚱᚪ᛫ᚷᛖᚻᚹᛦᛚᚳᚢᛗ
ᛋᚳᛖᚪᛚ᛫ᚦᛖᚪᚻ᛫ᛗᚪᚾᚾᚪ᛫ᚷᛖᚻᚹᛦᛚᚳ᛫ᛗᛁᚳᛚᚢᚾ᛫ᚻᛦᛏ᛫ᛞᚫᛚᚪᚾ
ᚷᛁᚠ᛫ᚻᛖ᛫ᚹᛁᛚᛖ᛫ᚠᚩᚱ᛫ᛞᚱᛁᚻᛏᚾᛖ᛫ᛞᚩᛗᛖᛋ᛫ᚻᛚᛇᛏᚪᚾ᛬

Tamil poetry:

யாமறிந்த மொழிகளிலே தமிழ்மொழி போல் இனிதாவது எங்கும் காணோம்,
பாமரராய் விலங்குகளாய், உலகனைத்தும் இகழ்ச்சிசொலப் பான்மை கெட்டு,
நாமமது தமிழரெனக் கொண்டு இங்கு வாழ்ந்திடுதல் நன்றோ? சொல்லீர்!
தேமதுரத் தமிழோசை உலகமெலாம் பரவும்வகை செய்தல் வேண்டும்.


I can eat glass:
私はガラスを食べられます。それは私を傷つけません。
Կրնամ ապակի ուտել և ինծի անհանգիստ չըներ։
I kå Glas frässa, ond des macht mr nix!
᚛᚛ᚉᚑᚅᚔᚉᚉᚔᚋ ᚔᚈᚔ ᚍᚂᚐᚅᚑ ᚅᚔᚋᚌᚓᚅᚐ᚜
אני יכול לאכול זכוכית וזה לא מזיק לי
काचं शक्नोम्यत्तुम् । नोपहिनस्ति माम् ॥ 

[mason@IT-PC-MACPRO-1 fuckery]$ COMMENT="
> 
> As you can see, I added a couple Japanese words
> to the post title. Let's make sure that works.
> "
[mason@IT-PC-MACPRO-1 fuckery]$ blogofile build                       
Traceback (most recent call last):
  File "/usr/local/bin/blogofile", line 8, in <module>
    load_entry_point('Blogofile==0.7.0', 'console_scripts', 'blogofile')()
  File "/Library/Python/2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/main.py", line 135, in main
    args.func(args)
  File "/Library/Python/2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/main.py", line 200, in do_build
    writer.write_site()
  File "/Library/Python/2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/writer.py", line 52, in write_site
    self.__run_controllers()
  File "/Library/Python/2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/writer.py", line 134, in __run_controllers
    controller.run_all()
  File "/Library/Python/2.6/site-packages/Blogofile-0.7.0-py2.6.egg/blogofile/controller.py", line 203, in run_all
    controller.run()
  File "_controllers/blog/__init__.py", line 25, in run
    blog.posts = post.parse_posts("_posts")
  File "_controllers/blog/post.py", line 334, in parse_posts
    p = Post(src, filename=post_fn)
  File "_controllers/blog/post.py", line 97, in __init__
    self.__post_process()
  File "_controllers/blog/post.py", line 202, in __post_process
    logger.debug("Permalink: {0}".format(self.permalink))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 61-67: ordinal not in range(128)
[mason@IT-PC-MACPRO-1 fuckery]$ 
[mason@IT-PC-MACPRO-1 fuckery]$ COMMENT="
> 
> Doh! That broke everything!
> The file is UTF8-encoded... does that mean
> I cannot use UTF-8 in post titles? That would
> kind of be a dealbreaker.
> "
[mason@IT-PC-MACPRO-1 fuckery]$ rm "_posts/003 - post 3.markdown" 
[mason@IT-PC-MACPRO-1 fuckery]$ blogofile build
[mason@IT-PC-MACPRO-1 fuckery]$ COMMENT="
> 
> OK, deleted the post with a Japanese title and it builds again.
> But wait, there's more! Here's a different file with UTF-8 in the
> post title, that *does* work!
> "
[mason@IT-PC-MACPRO-1 fuckery]$ cp "/Users/mason/Dropbox/Code/masonmark.com/_posts/0083. dreamweaver-f00kin-%c2%ae00lz-%e2%88%8200%e2%88%82.html" ./_posts/
[mason@IT-PC-MACPRO-1 fuckery]$ 
[mason@IT-PC-MACPRO-1 fuckery]$ cat "_posts/0083. dreamweaver-f00kin-%c2%ae00lz-%e2%88%8200%e2%88%82.html" 

---
categories: code
date: 2009/05/18 02:54:09
guid: http://www.yoursite.com/?p=83
permalink: http://www.yoursite.com/2009/05/dreamweaver-f00kin-%c2%ae00lz-%e2%88%8200%e2%88%82/
tags: ''
title: Dreamweaver f00kin ®00lz, ∂00∂　日本語テスト

---
A few years ago, friend of mine worked on a large specialty retail web site, which had been built-up over the years by people using <b>Dreamweaver</b>. This week, as I was helping to retrofit a legacy (as in EUC, SJIS, Dreamweaver, Flash) web site here in Tokyo and bring it into the modern (as in Unicode, revision control, machine validation, and not-Flash) world, I was inspired to dig up a snippet of <b>truly amazing Dreamweaver-generated code</b>.

This code was live on the retailer's production e-commerce server circa 2005. It's a great demonstration of why you should <strong>ALWAYS</strong> use Dreamweaver for <strong>ANY</strong> web authoring that you do.

[CODE DELETED FOR BREVITY]
[mason@IT-PC-MACPRO-1 fuckery]$ 
[mason@IT-PC-MACPRO-1 fuckery]$ 
[mason@IT-PC-MACPRO-1 fuckery]$ COMMENT="
> 
> As you can see, this post has the same Japanese words in the title.
> 
> Will it build?
> "
[mason@IT-PC-MACPRO-1 fuckery]$ 
[mason@IT-PC-MACPRO-1 fuckery]$ blogofile build
[mason@IT-PC-MACPRO-1 fuckery]$ 
[mason@IT-PC-MACPRO-1 fuckery]$ COMMENT="
> 
> Yes it builds! So... hopefully the failure is just a bug,
> and not a feature?
> 
> Anyway, to summarize the steps to reproduce:
> 
> 1. init a new simple blog with 'blogofile init simple_blog'
> 2. Add the words '日本語テスト' to the title of a post
> 3. Try 'blogofile build' and watch it crash and burn
> 
> Thanks for listening.
> "
[mason@IT-PC-MACPRO-1 fuckery]$ 

I'm new to Blogofile, so apologies if I misunderstand something.

I want my blog to be in my site's root, so as per comments in _config.py, I set blog.path = "". Only, this doesn't seem to work.

None of my posts appear to end up in _site. I'd expect to find _site/2009, _site/2010, etc. but don't. Instead, I have a blog/ directory in the directory above _site, alongside _config.py and such. This directory does have the expected structure.

In mac darwin and linux debian/ubuntu with python 2.5, zipimport.ZipImportError occurs.

With small source changes, python setup.py install fails with the error described in title.
The next successive command will success.

Create a configuration parameter for _config.cfg that specifies a default permalink style for posts.

For example: /:year/:month/:day/:title

This would only be used for posts that the user did not put a permalink explicitly in the per-post YAML

Some sort of recursive rendering problem on windows when building even the simple blog template