With Bill Tozier, I’m working on re-basing XProgramming.com from WordPress to Ruby/Sinatra etc. We tweeted a bit about an issue we ran into today. It goes like this:

The image we had of the new site is that each article would be stored in a folder named to match the WordPress “slug” for the article such as “…/articles/xprognew-todays-problem/”. We’re planning to keep the article, its metadata, and any other assets, such as images, right in the article.

Writing will be in Markdown. So I’d expect to write an article that looks like this:

# Some Title

Here’s a paragraph of text. Assume it runs on and on …

![](picture7.png)

Markdown assumes that the construct above specifies a picture in the same folder as the article. It will generate, roughly, <img src=’picture7.png/>.

This would clearly be the easiest way to specify the picture, and it seems to us to make sense to keep the pictures and metadata with the article. And the folder name matching the slug makes converting the existing site much easier. (Existing images will not have that kind of link, but are all in a WordPress images folder together somewhere. We’ve not looked yet at what to do about that. We’re trying to make new articles easier and if the conversion is tricky so be it.)

We are using Sinatra and kramdown. The Markdown above does generate the image statement shown. However, somewhere inside or above Sinatra, there is a built-in assumption that assets like images will be in a folder named “public”, and the article is rendered as if it, itself, were in public, so that the image call looks into public.

We tried navigating out of public with things like “../articles/myslug/” but this just doesn’t work. I’m told by Z Spencer that Rackup or whatever its name is, keeps you in public as a security measure. Good for it.

The result, though, is that we see few options:

  • **Put all images in public.** This will work, and is not unlike WordPress, but we don't like it.
  • **Put images in a subfolder of public, and type the folder name into the image call.** This ties the article contents to the name of its slug and we don't like that.
  • **Put images in a subfolder of public, and do an on-the-fly substitution of the file name as we render the file.** This requires a search and replace on the article and we don't like that either.

There are probably other options but we see none that we like. And we see, today, no way to override where public points, except somewhere else under public.

Anyway, that’s the problem I’ve been tweeting about.