Add use case of pelican as general static site generator

[diimpp]

It can be done by moving pages to / and articels to /blog

Here is a example configuration.

ARTICLE_DIR = 'blog'
ARTICLE_URL = 'blog/{slug}.html'
ARTICLE_SAVE_AS = 'blog/{slug}.html'
PAGE_DIR = 'pages'
PAGE_URL = '{slug}.html'
PAGE_SAVE_AS = '{slug}.html'
AUTHOR_SAVE_AS = False
CATEGORY_SAVE_AS = 'blog/category/{slug}.html'
CATEGORY_URL = 'blog/category/{slug}.html'
TAG_SAVE_AS = 'blog/tag/{slug}.html'
TAG_URL = 'blog/tag/{slug}.html'
DIRECT_TEMPLATES = (('index', 'blog/tags', 'blog/categories', 'blog/archives', 'blog/index'))
PAGINATED_DIRECT_TEMPLATES = (('index', 'blog/index', ))

Details can be found in first comment to this post http://stackful-dev.com/static-site-jinja-pelican-shared-templates.html

[talha131]

I think, merged patch bfa8c74 addresses this issue partly.

[justinmayer]

See also: https://github.com/cocodelabs/cocode.org/issues/6

[foresto]

Pelican really is shaping up into a decent general-purpose site generator. I suspect more people would choose it if features useful for creating/migrating non-blog sites were more obvious to newcomers. For example:

• Pages can be generated in a site's root directory, and articles can live in a subdirectory instead of the root (or be left out entirely).
• The generated directory structure need not be flat or simple; it can be as complex as any existing website, either by replicating the source directory structure or through per-page path overrides.
• Page sources and static files can either share the same source directories or be divided into separate ones. Pelican can work with whichever approach works best for the author and his existing tools.
• Individual pages can have their file names and URLs overridden to be different from the the pattern used by other pages. This is especially useful for special pages like directory indexes.
• Generated file names can be pretty much anything. They don't have to be based on a slug, or contain dashes, or end in .html. Their suffixes can be whatever an existing site uses, including .php, .asp, or nothing at all.

Most of this stuff can be discovered if someone is willing to invest a bunch of time carefully reading the docs and experimenting, but someone who just wants a convenient website generator is more likely to see Pelican as a blogger's tool and move on to something else. That's a pity, because Pelican is definitely capable of more if configured with the right combination of settings.

Perhaps a sensible start toward addressing the issue would be to give the Tutorials page some sample configurations specifically tailored to non-blog sites, and highlight them in the documentation. Once the most common/popular use cases are identified and refined, one or two of them could be added to pelican-quickstart. I think this would go a long way toward turning such sites into first-class citizens. (Or from another perspective, turning Pelican into a first-class tool for such sites.)

[iKevinY]

Great points, @foresto. Adding onto your point about expanding the documentation, perhaps the Quickstart should describe the process for quickstarting a simple static site as well as quickstarting a blog? Also, it might be beneficial for the Pelican homepage to explicitly state the fact that it is usable as a general-purpose static site generator as well as a blogging tool, in order to clear up the potential misconception that Pelican is only good for blogging sooner rather than later.

[asmaier]

I completely agree with @foresto . In addition to documentation I would suggest to add another pelican-quickstart script creating a base project using the defaults as shown by @diimpp . This would help a lot of people for which a blog is just of secondary interest for their website. It would also prevent people from being forced to create their own website generators for this purpose (see e.g. http://www.jandecaluwe.com/blog/i-dont-like-blogs.html) and simply use pelican instead.

[naturallymitchell]

[leotrs]

What's the state of this? I was recommended pelican by friends and they outright told me it not only works for blogs. It's worked brilliantly up to now, but I agree a bit more documentation could be in order. I think adding diimpp's defaults to the faq would be enough.

[leotrs]

@justinmayer Maybe we can add this to the next milestone. It's no longer an issue, we just need docs.

[justinmayer]

@leotrs: I'm open to including this in the next release, but I'd prefer to add it once someone has submitted a pull request that implements it. (^_^)

[leotrs]

I was under the impression this can already be achieved and we are only in need of documentation. I use pelican for non-blog static site with perfect results.

[pjz]

FYI http://stackful-dev.com/static-site-jinja-pelican-shared-templates.html is a dead site - is there another/better/different HOWTO ?

[cjer]

Is there any documented progress here or some examples? I have a running blog using pelican, but would like to use pelican for another non-blog static site.

[cjer]

and @pjz you can always turn to the Internet Archive for rescue: https://web.archive.org/web/20160126144309/http://stackful-dev.com/static-site-jinja-pelican-shared-templates.html

[mosra]

@cjer I'm using pelican to generate primarily static sites, with a blog being just an optional part. Frankly I didn't have any problems or wasn't missing documentation on how to achieve that, it's just about adapting the SAVE_AS / URL settings and overriding index.html with a dedicated page. If that helps you in any way, this is one such site and this is the corresponding configuration and setup.

[wumpus]

I'm here because I looked through all of the pelican-templates and 100% of them were blogs. So I suppose I'm here to vote for making non-blog usage prominent in the existing docs. For example the FAQ has one question about it, with an answer much less interesting than the discussion here.