+1 on this

Maybe fold in drnic's work?

http://github.com/drnic/jekyll_generator/

I thought this would be cool too. My patch probably isn't very efficient or anything, but it's a proof-of-concept that demonstrates generating somebody can build upon/the like: http://github.com/h0rs3r4dish/jekyll

I like it. This definitely needs some tests and features built in if you want it included.

I'll gladly write the tests. Can you elaborate on what you mean by "features built in" so I can move forward on getting this integrated?

Sorry about the dup msg...

No problem. I meant a Cucumber feature/integration test for this, just to ensure that it works as expected.

Another issue with this: some sort of secure: false flag should be necessary to enable this feature. Since Jekyll is in charge of generating the GitHub pages, we can't let just anyone to execute whatever they'd like on the server. For most users generating posts though, this behavior is extremely useful.

That shouldn't be hard to implement. I'll add it in my fork.

I added support for a _liquid_tags directory along with a config param "liquid_tags" that defaults to false. Also added two tests to test_site. It may be worth breaking the "should load external tags" test into its own context since it uses its own site with a different config. Let me know what you think.

http://github.com/n8agrin/jekyll/commit/dfd5ef02b4c0edf59476aa15b472a0a5ab9980ee

I see this is on hold. Anything else I can do to help it get through?

There's been no work done towards an insecure/secure mode yet. I'd like to see that in the lib first. The same conditions apply as my earlier comment.

Ah ok, I didn't interpret your earlier request as you literally wanted a "secure: false" flag implemented. I took that to mean you wanted the option to turn importing custom tags on and off, hence the liquid_tags config param. My mistake, shouldn't be hard to get a secure flag working.

What's holding this back? It seems like it has a command line flag to turn it on or off. why isn't that enough?

While I realize people are working on this (sorry to be impatient!), I have come up with a temporary solution for those that are interested:

http://benjaminthomas.org/2009/10/21/custom-liquid-tags-in-jekyll.html

Cool. I just bumped this here: http://github.com/n8agrin/jekyll/commit/4b82e06f8b0ee153149edc803abd297d50539b41 Hopefully that's should cover everything.

Summary of changes:
1) Changed liquid_tags flag to "secure", secure is set to true by default
2) Added if block that checks the secure flag, if it's false, liquid tags (and presumably other insecure code) can be loaded.
3) Added tests for the liquid tags.

I'm not terribly happy with the line that reads "load file unless require file", I may change that to just "load file".

Please review and let me know if there are issues which need to be resolved before this can be merged.

Your CLI syntax looks great, much better than the methods outlined on the wiki. It's been 3 months since you've opened this for suggestion, I'd say your syntax is the way to go. Also, why are there no instructions on migrating from WordPress? Thanks, I'm excited about migrating to Jekyll!

@appden: Yeah, I definitely need to hack this up. The main issue is that you only have to do the import once, so it's never really been a painful issue when using jekyll over time. This is definitely an important feature to get to though.

@qrush: Awesome. I know its low priority, but it does seem to be a small barrier to entry. Same with the missing Wordpress instructions. When these barriers are lifted, Jekyll will likely gain many more users. Thanks for the quick reply!

looks good to me -- just getting started with a transition this second and would love to be done already so I could tell my friends how cool i am.

We'll definitely accept a patch for this if you're willing to hack it up. That being said, I wonder if the templating system within Jekyll could be refactored in a way to make this kind of extension easier.

oh, well, if I was able to do this, I will definitely send you a patch :)
asciidoc is written in python, and I don't have any idea of how integrate this in jekyll.

But thank you for your quick answer :)

I just tried out this on my own blog and I didn't see any repeated info. I also don't see any on your site. Could you clarify this a bit or provide a smaller example?

Under Archives in the sidebar it has April and 2009 above each posts when it should only be above them once since they are from the same month and year. I'll try create a smaller example tonight.

I still can't recreate it on my local version, but here's a comparison of the difference I'm talking about.

Tristan,

Is this still happening? GitHub Pages is now on Jekyll 0.5.1.

Yes, but still no clue why.

Output is at http://tristandunn.com/ and the logic is at http://github.com/tristandunn/tristandunn.github.com/commit/f8f115c281f98c8fc343bcf9290f4e71c312b28e#diff-0

Upgraded to 0.5.1 locally and it rendered correctly still.

Great idea, but absolutely no tests.

Very true. It was a quick hack that I needed for a one-time import. I just put it here so it wouldn't be lost in case someone needed it.

Love the idea but it has some of your custom mods built in. If this could be sliced off based on the current HEAD and tested, I'm up for it :)

I'd love to see this. I often write the same piece of YAML boilerplate at the beginning of my posts. I was thinking of writing something similar but have not yet had time.

Adding this feature would do a tremendous amount toward sharing README.markdown, index.markdown file between the gh-pages/jekyll-rendered site, and the github 'inlined readme' feature. Appending front matter makes src files look ugly for example when navigating through the regular github views. If we had default layouts in jekyll and can write just plain markdown it would remain compatible with github's own system (and many other systems).

I've taken Henrik's commit, updated it to work under the current (0.5.4) tag, and added a few tests. It's available for review on the post_defaults branch of my fork: http://github.com/mikewest/jekyll/tree/post_defaults

You can set the destination or source where files are generated: http://wiki.github.com/mojombo/jekyll/configuration

Also, with the new Permalink system you can pretty much tell your posts to live where you want: http://wiki.github.com/mojombo/jekyll/permalinks

Keep explaining if I'm missing your point here :)

source, destination, and the new permalink spec all define the structure relative to the local filesystem. They say nothing about where these files will live on the server relative to its URL (not filesystem) root.

For example, with the site exported as http://some.server/url/root/<jekyll-starts-here>, a user would have to hard-code /url/root before CSS files and all other content in the generated _site (or, yes, wherever destination points) in every single template file.

This is doubly problematic:

• Hard-coding the root URL path directly in all the template source is needlessly inflexible (though admittedly it can be altered with a simple find/replace)
• It breaks the WEBRick preview server (--server), which is essential for easily previewing the site with links (especially to CSS) intact without having to push to the live server. One of the key reasons this exists, I believe, is to allow quick hosting where Jekyll files reside at the URL root of the server (vs. previewing on an existing site, like personal web sharing on today's desktop OSes, where it would generally have to live in a sub-path, breaking all the absolute links), and for exactly the same reasons, a site which is built (with absolute paths) to live in a sub-path of the URL root will fail during preview (no CSS, internal links break, etc.)

Though it is possible to work around this, above all, it makes it substantially less than obvious to new users exactly how they should set up Jekyll in situations like this. These situations are extremely common, for example, in university or departmental web hosting, and I expect this could be a key demographic for Jekyll use.

There are two obvious solutions that spring to mind:

• Using relative paths for everything. This could be significantly aided by the template system via a dynamic variable page.relative_path_to_root which would yield something of the form "../../../". This is more complex in the sense that this variable is dynamic per-page, and it does not work with simple existing template examples which link directly to pages and posts via url template variables—specifically, it requires many more changes to the template.
• Configurable absolute path root. This would be a single static variable site.url_root or similar, specified in _config.yml, used in the templates to configurably define absolute paths to resources (e.g. "{{site.url_root}}/css/screen.css"), and which would cause the WEBrick preview server to host files at http://localhost:4000/url/root/ instead of http://localhost:4000/.

WordPress and its ilk all generally have a core configuration variable specifying where they are exported in the external URL structure, entirely independent of where they live on the filesystem (and never assuming that they are exported at http://host/). I'd like to see essentially the same thing in Jekyll.

I'm working on a patch to add a url_root config option (which defaults to /) which is exported in the site object, prefixes post URLs in the templates, and which sets the preview WEBrick server to export the site at http://localhost:<server_port>/<url_root> (with a redirect on / to /<url_root> if url_root != '/'). I'll wrap and post it after a string of meetings, but am curious if anyone has thoughts on a better way to handle this general usage model of non-server-root Jekyll site deployments, in case I'm completely crazy.

I made a patch that can be used for this (and more): http://github.com/mojombo/jekyll/issues#issue/15

Yeah, I saw that, but thanks for the heads-up. It's a very good (and general/powerful) idea. I hope to use it in general. It does not, however, solve the problem of simplifying the templates by making URL generation smarter for posts, or allowing local preview in WEBrick before posting to the live site. I definitely want to see your post hit the mainline, but I've pulled together a more complete solution to the url_root problem which I'll share shortly.

That's cool. If you generate relative paths it will be possible to browse the generated site files directly even without WEBrick. That would be nice.

rebased against current mojombo/master instead of my own fork: http://github.com/jberkel/jekyll/commit/4cd469585a9f7662dcad2fd4b3e6387b56d4b317

Is there any example sites this could be tested against? None of the converters are tested, they definitely all need to be somehow. I'd like to reorganize how they're called as well, it seems too manual at the moment.

sorry, only tested against my site. i'm a big fan of testing, but just didn't see the point writing tests for this since it's a one-off thing (the conversion process). also don't mind having a manual process for importing, most of jekyll's users seem to be geeky enough to figure this out for themselves anyway :)

I like this, but it definitely needs tests. On hold until someone can get around to writing them.

Hi, I created a branch with tests: http://github.com/Jens-n/jekyll/tree/test_categorynames

Might I humbly suggest category_list instead of categorynames?

Done: 98a4683

Why not rework site.categories to accomplish this? So we can do like:

{% for category in site.categories %}
  <h2>{{ category.name }}</h2>
  {% for post in category.posts %}
...

Initially I just needed a small fix for my site. A one-liner seemed like a good-enough solution for the time being. I initially even set out to implement Thomas idea but was too lazy, so I stuck with the one-liner.

That said, I think that a bit of re-modeling might benefit jekyll in the future (i.e. decoupling filesystem layout and reading from content transformation, changing Topic and Category into real objects, etc.).

I was able to make the snippet in my last comment work, but in order to keep site.categories.foo working, I had to make a Categories class that acts both like a hash (mapping category names to Post arrays) and like an array of Category objects (through each).

This seems like it would become more of a problem if categories ever get more data. I'd like to be able to someday do:

<a href="{{ category.url }}">{{ category.name }}</a>

and have it link to an automatically generated _site/[category]/index.html. But if site.categories.foo is an array of posts, the extra category data won't be accessible from it.

Maybe we could change site.categories.foo to site.categories.foo.posts?

Alright, now that tags are in master I think it's time to address this issue. I like tomo's idea but I need to play around with this more. If you've got other suggestions pipe up!

If this was to be refactored, I think it would need to degrade gracefully. For instance I think at least until 0.6.0 or 0.7.0 the site object would have to work as normal. There could then be a new object, perhaps jekyll or another name that makes sense with the refactored payload.

Or maybe this could be done through a config value... payload: new and default to old, print out plenty of warnings in the meantime.

I really like tomos idea. I like to have a strong domain model at the heart of my programs and his idea goes along the same lines. My suggestion is: Follow tomo and drop site.categories.foo in favor of site.categories.foo.posts.

Btw: I created a wiki page (http://wiki.github.com/mojombo/jekyll/thoughts-about-a-new-version ) that discusses API-breaking changes. Please contribute to the page.

Could you give an example of how this works?

For example using startinline will cause PHP code to get highlighted without the need for <?php ?>.

<% highlight php linenos startinline %>
$inline = true;
echo "This is inline PHP code.";
<% endhighlight %>

will result in highlighted PHP code and line numbers.

There are several other options, most of them are boolean. So the value defaults to true if an option is set. But you can also use e.g. encoding=utf-8 or tabsize=2.

+1

Solid! I was about to start a patch that would let me set linenostart in my highlighted code, but this looks like it would do exactly what I need.

Another easier way to accomplish this is to make Post.output available to Liquid. But this still creates the "standalone" HTML files.
I would really appreciate any implementation of this feature on GitHub pages.

To work around this on GitHub pages I let Jekyll render standalone HTML files and include them via prototype's Ajax.Updater. This is far from optimal, but it works.

source

Great idea, definitely needs tests. On hold until that happens.

Added a test.

http://github.com/koraktor/jekyll/commit/7b802053fd48b9e4c228cbe37f6205a535db7c81

Partials in jekyll would be great.

Agreed, this shouldn't be too hard to implement (or test). If you or someone else wants to wrap up a patch (with tests) I'll be glad to merge it in.

jrk,

Is this still valid given the topics and tags changes that I've just pushed? Let me know, thanks!

Got this working at http://github.com/tomo/jekyll/tree/hierarchical_categories, last 2 commits.

The features and tests assumed that categories would show up in the URL in alphabetical order. I changed them to assume that categories should show up in the order specified by the directory layout or in the YAML.

For searching on one tag it seems like we could just generate tag indexes. E.g. for every tag you use, generate _site/tags/[tag]/index.html from some tag layout file.

But if you want to be able to go to /tags/linux/administration to get everything with both tags, then things could get crazy. When you have a post with 5 tags you'd have to generate 120 separate tag indexes, for that post's tags alone. For that many the space required isn't so bad, but I'm not sure how much it would slow jekyll down. If you have 7 or more tags on a post it starts to get ridiculous.

Tag index pages or a single page listing tags (like http://henrik.nyh.se/tag ) could work. If someone needs to find tag1+tag2, I'd suggest going with a single page and then using JavaScript to e.g. make /tag#tag1+tag2 do something clever.

@henrik - yeah it would work on just a single page or may be I should abandon this whole idea and just go and use wiki.

The problem with this is editing already published posts, you pretty much run into the same problem. I think using a date option in the YAML front matter would be better.

We've been discussing this in Issue #30. At the moment, the best way to do this is overriding date in YAML, as qrush suggested. Here's an example:

date: 2009-05-09 10:08:39 +02:00

This will override the date parsed from the filename.

My fork gets time from the filename (2009-05-09_10-98-my-slug) or from time in the YAML.

I considered using file modification times but after some experimentation it didn't seem like a good idea. Would need some other form of metadata to account for imported old stuff anyway.

I'm not seeing any tests for this at all. Please add some to cover the functionality you're adding/fixing and I'll merge this in. Thanks.

http://wiki.github.com/mojombo/jekyll/contribute

+1, seems like a good solution. Or for still more descriptiveness: ignore, unlisted, published.

This sounds like a great idea, but could you cut this into one patch that's cleanly based on top of the latest mojombo/master ? Not including stuff like commenting out the tags implementation (80fcd03) would be great too. Thanks!

I re-forked your repo and applied my changes, the new commit should be:

http://github.com/kyleburton/jekyll/commit/8202c848cbf5c014fd189d45397425c00798981f

it should have a unit test with it as well.

Thanks,

Kyle

running jekyll --no-auto causes the full stack-trace to bubble up, which is very helpful in debugging.

But it doesn't always work. I'm getting the following error from GitHub's build:

The page build failed with the following error:
private method `chop!' called for nil:NilClass

But running jekyll --no-auto locally (after cleaning out the _site/ directory) gives this:

Configuration from ./_config.yml
Building site: . -> ./_site
Successfully generated site: . -> ./_site

Yeah, I've run into this as well. Definitely needs to be fixed.

Looking at the Maruku source, chop! is only used in three places. One is for getting rid of trailing whitespace, one is for titles in links (a la [text](url "title")) and one is for titles in images. I think it's important that those titles are bounded by double quotes rather than single quotes.

Well, I fixed all the single quotes around titles, but that doesn't seem to be it. It must be a whitespace issue, b/c I have no images (except one done explicitly in HTML).

The underlying error seems to have been a problem in Maruku, since the page built fine once I changed the processor to RDiscount. It would still be nice to have those errors bubble up, though.

This is specifically in Pygments code, right? Fixed that in my jekyll fork and in http://github.com/henrik/albino/tree/master

Sorry, I should have been more specific. I was trying to merge in Claymore's changes for gitready that were written in Russian, and Jekyll was just failing silently on processing them. http://github.com/Claymore/gitready/tree/ru

I've looked into it and it seems that jekyll doesn't play well with BOM UTF-8 files. UTF-8 without BOM works fine.

I can see how this might be useful for developing locally, but you actually serve your site with WEBrick? I think usually most people that host their own Jekyll sites just dump the generated files in their own folder and go from there. I'm willing to hear more about how you use this or others would use it if you're interested.

I use WEBrick to preview my site when I am making changes to it. When I am satisfied with the changes, I commit them to git and push them on to my server where they are served as static files from Apache.

Since my site is served from "/arnar" by Apache, I need to references this in various places, e.g. in CSS links (relative urls don't work since the master template might be used in various subdirectories). Having WEBrick behave exactly like Apache does with my configuration simply helps make the local previewing process smooth.

I could see Jekyll being very useful to college students building web pages hosted by their university. Most universities give limited web space to students, and this usually doesn't include the ability to install database-driven content management systems. These sites are also typically deployed in non-root locations, which requires some tweaking without the baseurl option described by Anar.

The problem is that GitHub pages cannot allow people to execute arbitrary Ruby code. In other tickets I've mentioned that the best way to do this is to have a 'secure' mode for Pages and a non-secure mode that is more flexible. I haven't seen this implemented cleanly anywhere that I can merge into the core yet.

I'm sorry, but still don't understand - what have Jekyll implementation to do with GitHub pages?

imanel, Jekyll is used for GitHub pages. My version of Jekyll wasn't forked that long ago, and has been updated once or twice since, but my additions don't come with tests.

Secure/insecure could be interesting.

Sorry - didn't know:/
About secure/insecure mode - there's another way. At this time Jekyll have 167 forks - mostly adding one or two small functions, sometimes something more. What if you could add lib directory and put into your application any plugins you want? http://github.com/tomash/jekyll/tree/per-site-libfiles have something like that - in standard it's normal Jekyll, but You can provide --plugins option so everything in _lib will be executed. GitHub will run without this option, but users will be able to create Jekyll-ecosystem of plugins instead of useless(sorry) forks... How about that solution?

PS: @henrik - don't know how I did that, but I was sure that your last update was 8.04 ;) Anyway - is there any chance to update to newest version soon?

Jekyll is small and hackable enough that I think I prefer forking and modifying to a lib/plugin solution. It's definitely tricky to figure out what fork to use, or if someone has already added functionality you want, but we could perhaps use the wiki to make that easier. http://wiki.github.com/mojombo/jekyll/sites does that to some extent.

As to my fork, feel free to fork that and update to latest Jekyll ;) I might do that next time I hack on it, but that may not be for a while.

+1 for Haml and Sass.

I don't accept the security argument here. The point being here is to use Haml as markup generator, not templating engine for replacing Liquid.

So maybe the point/aim is: have/get/make a Haml parser that ignores "-" and "=" ruby code blocks (just a dumb html generator) and make it work with Liquid. That would be secure enough and at the same time let us be freed from HTML when writing our pages -- I mean, come on, it's 2009 ;)

Like, here:
http://lab.hamptoncatlin.com/play/with/haml

Try putting (for instance) {{ liquid stuff }} somewhere in the source haml and generate.

And from HAML documentation (options for rendering engine):
…or by passing an options hash to Haml::Engine.new. Available options are:

:format

Determines the output format. The default is :xhtml. Other options are :html4 and :html5, which are identical to :xhtml except there are no self-closing tags, XML prolog is ignored and correct DOCTYPEs are generated. 

:escape_html

Sets whether or not to escape HTML-sensitive characters in script. If this is true, = behaves like &=; otherwise, it behaves like !=. Note that if this is set, != should be used for yielding to subtemplates and rendering partials. Defaults to false. 

:suppress_eval

Whether or not attribute hashes and Ruby scripts designated by = or ~ should be evaluated. If this is true, said scripts are rendered as empty strings. Defaults to false. 

How many internets do I win? ;)

After my Engine related refactoring (Chrononaut@dc70e3b), adding Haml engine support was just a few lines of code away (I guess this proves that the refactoring was useful). The Haml engine implementation can be viewed here: Chrononaut@2dc41d1. The test shows that the Ruby evaled code indeed is suppressed.

I think that at least the refactor commit should be pulled in - it makes the Site class a lot cleaner.

It is already really easy to use compass with Jekyll for Sass, as described in my short blog post (http://chrononaut.net/2009/05/08/using-compass-with-jekyll.html). Simply let compass automatically compile the Sass locally, no additional support from Jekyll is required.

+1 for Chrononaut commits

Chrononaut, that looks like a nice refactoring. How does it handle access to site etc from e.g. Haml templates? From a quick look at the code, it's not handled. What I did was render in a context and use a custom class similar to OpenStruct for that context:

http://github.com/henrik/jekyll/commit/b9dea95f1ed100d5786d3cb580fcab968ab3b41f

http://github.com/henrik/jekyll/commit/8870dde625e850c2b173ed97d30de5d34e8ec61b

Actually, accessing site data isn't a problem, just use Liquid tags. I had to add one line to convertible.rb to make Jekyll support Haml layouts: Chrononaut@1baf081

I've converted my own layouts to Haml, one example can be viewed here: http://github.com/Chrononaut/chrononaut.net/blob/d919c7428b6dc1eab054a4dc79125346fd046b01/index.haml . Works just fine.

Liquid tags works for Haml posts/pages as well as layouts. By using Liquid everything should be just as safe as before since no Ruby evals are done from the Haml templates. So this shouldn't be a problem to run on GitHub pages.

Chrononaut: Ah, get it, thanks.

In my fork, I'm moving towards removing Liquid entirely and only using Haml, without suppressing eval, since I got frustrated working within the Liquid limitations. But this is for running on my own server, not as GitHub Pages.

+1 for haml/sass support in GitHub's Jekyll

svenfuchs worked on a safe mode for haml (and erb as well), maybe worth looking into: http://github.com/svenfuchs/safemode/tree/master

Bump.

Man I really want to go full stem ahead with using Jekyll too. But I'm a die hard Haml fan.

As a front-end developer I don't really want to bounce back and forth from HTML to Haml. That would just be torture. ;)

Running jekyll on this post causes some strange behavior. Everything is fine up until the {% highlight %} blocks. Pygments takes care of turning those into <pre>s just fine, but RDiscount stops processing right after the first block. If I remove the first block, RDiscount turns the next paragraph into a <p>, but stops processing after the following {% highlight %} block. I've tried removing the content from the code blocks and changing the highlight language; nothing works. I always end up with an absolute mess at the end of the post.

This is true of all posts in that site that use highlighting. I just didn't notice it with the others because I had very minimal markdown after a highlight block.

Using RedCloth seems to produce better results.

Try updating RDiscount, I believe the bug which caused it to incorrectly parse the HTML generated by Pygments has been fixed now.

I don't fully understand...so how will textile/markdown get rendered if we're not using the external libraries? I think it would be most unwise to implement an engine for either inside of Jekyll.

I'm up for any sort of work related to fixing this problem, it's definitely a huge pain point.

Maybe I didn't get my idea across properly (I'm not a native speaker) - I'll try again. :)

Sure, I think these libraries should be used to render the pages, but they aren't really requirements for using Jekyll. If I want to use markdown, and for some reason prefer rdiscount, I don't need Jekyll to install RedCloth and maruku as dependencies as I won't even use these other engines.

So instead of having these as dependencies for installing the gem, they could be run-time dependencies. RDiscount actually works the way I suggest right now. If you chose RDiscount in _config.yml without having it installed, you will simply get a LoadError telling you how to install it. That's how RedCloth and maruku should be treated as well, imo.

Ahh, I see now. +1 then :)

Definitely a cool idea. I'm not so sure about adding RBTree as a dependency though, pretty much for the reasons you said. I think this is more of a feature than a fix too. If others like it, perhaps we can merge it in, but it definitely needs some tests first.

Sounds cool! Hack it up and test it, sounds like a great idea. I haven't seen this in any fork yet.

Hi,

I don't understand why the _stylesheets directory is necessary. Why not just run LESS over any file with a .less extension, just as Textile is run over .textile files and Markdown on .md/mkdwn/markdown files?

Maybe I'm missing the point, but it seems to me we should continue to use the convention of letting the file extension dictate the filter used in the Convertible module, and skip all the _stylesheets directory logic. My same argument should hold true for SASS and HAML as well.

The stylesheets directory is a parallel to the posts directory. As far as I know, jekyll only runs textile and markdown over files in the posts directory (I haven't actually tried anywhere else). LESS will only be be run over files with a .less extension, so SASS files should be able to be placed in stylesheets without any problems.

I suppose the alternative is to allow them to be placed anywhere and then not publish the .less files.

Okay, I understand your thinking now, but actually Jekyll runs Markdown or Textile over any file with the corresponding extension, not just posts. This is done in the Convertible module that is included and called from the Page and Post modules.

An example of this would be my about.textile page on my site:
http://github.com/appden/appden.github.com/tree/master

Gotcha. That's a feature I haven't used. So, I'm not opposed to the proposed change. It'll require some reworking of the patch though.

I've implemented Less integration in my fork in a dumb way (see it here around line 200). This follows the simple rule of the extensions dictating the filter. Would this, in principle, be a suitable solution? (this is not a pull request, but an implementation suggestion)

I've started noticing this too. It didn't happen with earlier versions of jekyll.

In my opinion, we shouldn't need hard coded checks for the html extension. Instead, let Jekyll assume that any permalink that ends with a slash should create a directory and put an index.html file there.

I.e.:

Permalink "/foo/bar/" corresponds to the file "foo/bar/index.html"

Permalink "foo/baz.xml" corresponds to the file "foo/baz.xml" (edit: was /baz.xml)

Permalink "/atom.xml" corresponds to the file "atom.xml"

Checking for the trailing slash is exactly what web servers do, so this makes good sense to me.

I made a patch in http://github.com/vilcans/jekyll/tree/automatic-index

I'd also like it to work on files without specifying the permalink.

If I have a file called atom.xml, I need to put "permalink: /atom.xml" in it, or it will be generated as "_site/atom/index.html". I haven't fixed this, but the main problem is fixed as described above.

As I understand it, the 'pretty' permalink creates a directory with index.html. Previously, stating at static relative url like '/atom.xml' would just use the permalink specified verbatim. So it seems like something is just broken. I think the page processor seems to want an 'html' suffix or it creates a directory using mkdir_p.

Yeah, just read and applied the OP's patch and all is good.

I can also confirm that patch applies cleanly and fixes my atom problem.

This seems like a neat feature...i think a better way to implement this would be through a liquid tag since different markup languages can be used. Hack it up and I'll gladly merge it in. :)

http://wiki.github.com/mojombo/jekyll/contribute

I'll give it a try for sure... although I don't know Ruby, and this would be my first collaborative git project. But I can learn.

Question though, if it were a liquid tag, what do you think it would look like? I'm thinking:

{% link 2009-06-30-name-of-post-file %}

notice the lack of extension, to provide for different markup languages.

This is something I've felt has been missing since I started using Jekyll. I've created a branch on my fork with a patch to add this feature.

http://github.com/tatey/jekyll/tree/permalink_liquid_tag

With wiki documentation

http://wiki.github.com/tatey/jekyll/liquid-extensions

Please let me know if this is suitable.

This sounds like another good reason to have the secure: false config option.

Or it can be secured so it disallow writing to files outside the _site directory or reading from files outside the source directory.

The {%include%} tag has some similar logic. But I'd rather not have the requirement that the images must be in a specific directory. Does anyone know an easy and secure way to check whether a file is in any subdirectory of a specific directory?

I think limiting images to an _images folder is certainly acceptable. I pretty much have the same thing in all of my jekyll sites at the moment.

Perhaps default to an _images folder and allow a configuration option to change it...provided it doesn't go up any directories.

Could you give an example? And moving this to the mailing list would be better: http://groups.google.com/group/jekyll-rb

BTW, I am working on a patch for this, complete with tests and documentation.

A patch is at http://github.com/kr/jekyll/commit/smartypants-filter.>

I'm now working on documentation in http://wiki.github.com/kr/jekyll.>

Okay, github apparently doesn't like a URL at the end of a sentence. Let's try again.

http://github.com/kr/jekyll/commit/smartypants-filter
http://wiki.github.com/kr/jekyll

This is awesome—I’m looking forward for this to be merged into the master tree. Thanks for working on this. (:

BTW, you can fake this with:

{{ post.title | textilize | strip_html }}

(On a related note, why is there a textilize filter, but no markdownize filter?)

I have run into this problem as well. Any chance this could get merged into the main repo?

Fixed in my fork:

http://github.com/appden/jekyll/commit/0b8fc9daafbceddc5ab5e89cbd2cfd3ae81e1533

Have you tested it for this occurence:

----
-------------
---ZOMG!

I have not tested it but it seems your fix would still allow these ones. Fix should be more like a case in XHTML where every starting tag has a closing tag and the starting tag being "---"

Good effort though.

There is another way to fix it but that would require a considerable change. Have a look at nanoc(http://nanoc.stoneship.org/). It uses a seperate yaml file so instead of a yaml header one could just have a seperate yaml file. The only downside is every post would have two files, one for markup and one yaml file.

Hmm, this probably makes sense. If you could whip up a patch or a good way to test this I'd be up for it.

This is easy to fix. I had problems using includes from within includes (in the _includes directory).

I fixed this issue by changing line 38 in http://github.com/mojombo/jekyll/blob/master/lib/jekyll.rb from:

 'source'       => '.',

to:

 'source'       => Dir.pwd,

This change breaks ./test/test_configuration.rb. To fix the test change line 6 in test_configuration.rb to:

 @path = File.join(Dir.pwd, '_config.yml')

I can create a patch if required.

Thanks, works for me too!

Thanks, worked great!

I second this. My first thought of how to do it was some kind of .jekyllignore, either one in the root that would tell it what to ignore, or even just have it be that you ignore any dir that has a .jekyllignore file.

My use case is that I have a sass/ directory and a rake task that builds the files and puts it in css/. I really have no need to put sass/ in _site/

Fixed in my fork:

http://github.com/appden/jekyll/commit/7a6306a360d5fc88079e001d15cba2621fcaadc9

Another implementation, but without tests: http://github.com/henrik/jekyll/commit/1d42b39f70415fc69f80e6736649bc570ff4e2cb

This did bite me as well:
http://support.github.com/discussions/repos/1306-user-pages-containing-obsolete-files-howto-clean-upavoid-this-situation

One simple quick-fix might be to allow the owner of the user page to trigger a wipe of the jekyll generated content with a subsequent full pull of all user-page content.

Could you provide the site or any other information so this can be reproduced? Thanks.

I was able to track this down. The tags section was just empty:

---
title: How could I miss that one
tags: 
layout: post
---

While one can leave out the "tags:" this should not result in an error like this.

I am trying to create http://www.h3rald.com/ (this has been done in nanoc another Jekyll like blog creator) like static site which is not similar to a blog. My problem was that Jekyll creates the posts as per the date specified in the file name. Therefore, in order to mess about with the ordering one needs to change the dates in the file name to ensure they are in the right order after compilation. That's exactly what I did.

I am sure there is a better fix rather than hacking the file names but I would leave it like this now and revisit it later.

Forget it, I'll ask on the mailing list.

You can definitely throw XML in there, that's how we get atom feeds for our blogs. What exactly would this need that isn't in Jekyll already?

Nice work. I'm adding my support to have this patch integrated.

Correction: now I fixed it: karottenreibe/jekyll@fe3c094

The earlier version would convert

---
foo: bar ---

into { foo => 'bar ' }

fixed in my branch: robey/jekyll

+1