Relative paths in the content folder don't seem to be preserved.

[scpedicini]

Relatively new to Pelican so I'm probably missing something but I can't understand why my folder structure in the output area isn't identical to my content heirarchy.

Content structure

After running pelican content - Output folder:

This also means that the URL is: http://127.0.0.1:8000/first-blog-post.html rather than http://127.0.0.1:8000/blog/first-blog-post.html.

[justinmayer]

Hi Shaun. This has been covered before in #686 & #2673, but I'd like to find a solution that works for you so I can document it more thoroughly.

Would you please try the following settings and let me know whether they provide the behavior you seek?

USE_FOLDER_AS_CATEGORY = False
PATH_METADATA = "(?P<path_no_ext>.*)\..*"
ARTICLE_URL = ARTICLE_SAVE_AS = PAGE_URL = PAGE_SAVE_AS = "{path_no_ext}.html"

[dltj]

This is brilliant, and I'm already starting to enjoy Pelican's Python-ness. I'm migrating from Jekyll with article links that look like /article/{slug}/index.html. I already had a FILENAME_METADATA line to handle getting the date and the slug from the filename, so adding the second line here based on @justinmayer's suggestion did the trick:

FILENAME_METADATA = r"(?P<date>\d{4}-\d{2}-\d{2})-(?P<slug>.*)"
ARTICLE_URL = ARTICLE_SAVE_AS = PAGE_URL = PAGE_SAVE_AS = "article/{slug}/index.html"

[scpedicini]

Thanks @justinmayer - that seems to do the trick.

Alternatively I've noticed that doing this also gets around my issue:

Title: First Blog Post
Date: 2024-07-08 13:30
Tags: obsidian, pelican, technical
Category: blog
Slug: blog/first-blog-post

Category seems like more of a single-level classification used by many pelican themes as almost like "top level menus".

Not sure if I should be using a folder structure in the "slug" component but this does seem to create the expected folder structure.

[justinmayer]

Yes, the category is meant for folks who want to separate posts into high-level categories like "Rants", "Reviews", etc. — one category per post, with optional top-level menu items depending on the theme. Multiple tags, on the other hand, can be applied to posts. Folks who want more categories per post can use the More Categories plugin.

If you want your blog content to available at /blog/, with other static pages present at top-level /[…].html, you might want to have a look here: cocodelabs/cocode.org#6

We probably should have started the discussion by being clear about the desired outcome, instead of talking about the mechanics of mirroring source & output folder structure. What exactly are you trying to achieve?

[scpedicini]

I think I assumed that any folder structure placed in the content folder would be automatically "mirrored" in the output - even related assets embedded within the markdown files themselves (e.g. !()[some_media.png] links):

content/blog/first-post.md
content/blog/first-post-assets/pic-1.png
content/blog/first-post-assets/pic-2.png

output/blog/first-post.html
output/blog/first-post-assets/pic-1.png
output/blog/first-post-assets/pic-2.png

I noticed that Pelican makes a distinction between Pages vs Articles (based on if the MD file is placed in a pages subfolder) though I would have expected this classification to have been a property that lived on the frontmatter itself. Reading through the documentation it's a bit unclear to me whether "articles"/"pages" have any different logic other than how they are possibly transformed through theme templates.

Maybe my confusion stems from my workflow - I don't do any actual work in the pelican path at all. By that I mean I have a custom preprocessor for the original markdown notes which lives in a totally different place on my laptop. If Pelican prefers me to use the "slug" value to specify a folder structure (a/b/c/my-doc) - it is relatively simple for me to change the preprocessor to prepend this as frontmatter to the MD file before it copies everything over to the pelican/content folder. Totally fine with that.

So my workflow currently looks like this:

1. Use typora to create a new document in ~users/scpedicini/notes and add rich media to it / etc
2. Run preprocessor which modifies frontmatter / etc (such as adding a slug section derived from the MD file's path)
3. Preprocessor copies the note(s) to the pelican/content folder
4. Run pelican content
5. rsync pelican/output directory to VPS

I suppose technically my preference is that I can just drop my folder structure into content and expect a 1:1 mirror in the output of every single file including media assets such as webm, png, etc). I would like to "sans" the HTML part so a user doesn't have to specify the .html though I can always just use a simple nginx rewrite rule.

So far I'm really enjoying using Pelican - I've been migrating away from a much heavier wordpress site so this is my first time using a static site generator. (never tried any others like Hugo, Jekyll, 11ty, etc).

[justinmayer]

Thanks for taking the time to elaborate. As you probably guessed, Pelican wasn't created with the 1:1 content-to-output mirroring use case in mind. If someone were to submit a pull request to better support that use case out-of-the-box, I think it would be a welcome addition to the project.

You should be able to output HTML files without .html extensions, provided Nginx understands what to do with them.

What pages are output to /[…]/? i.e., outside of /blog/)

[scpedicini]

Thanks @justinmayer -

My structure is more along the lines of:

/blog/*
/reviews/*
/papers/*

maybe I'll take a look at the code base and see what kind of effort would be involved with setting up a MIRROR_CONTENT_FOLDER flag!