Adding support for multiple files created the same day

[Jay L. Colbert]

With the current file naming configuration, only one file could be created per day in each folder. Is there a way to add title slugs after the date in the file name, and have it parse?

[Thomasorus]

Currently there’s no way of doing this. Adding title slugs would not solve another problem, which is ordering posts with the same day. We would probably need to add the hour inside the file name.

I’ll look how to fix this.

[Jay L. Colbert]

Thanks for looking into it! I've been looking for a static site generator for my own semi-professional/personal website & digital garden, and I love how small/simple it is plus your anticapitalist principles.

[Thomasorus]

@jlcolbert I took a bit of time to think about this. The limit you encountered is that Chisai uses dates as filenames, and you can only create one for each day. Since you need wikilinks (cf #6 ), I suspect you use a zettelkasten system of sorts, and see Chisai as a good way to generate a web version of your notes.

So my conclusion is that dates does not matter in your use case, and slugs are more important because your content is not expected to be organized by dates.

Am I correct?

If I am, here are the changes I suggest we do.

• Chisai should support files using something else than a date. Example: if you have a notes folder, and put a notes-on-book-1.md inside, it should produce a file with this url: /notes/notes-on-book-1.html.
• Timeless notes should be listed by last edit instead of dates
• Chisai should have a flatten urls option that removes containing folders from URLs during build. Example: if you have a notes folder, and put a notes-on-book-1.md inside, if the flatten option is set to true, it should produce a file with this url: /notes-on-book-1.html.

Does that makes sense to you?

[Jay L. Colbert]

Yes, that makes sense! And yeah, I'm wanting to do a "digital garden," primarily as a way to work through research ideas.

[Thomasorus]

I'll start working on this soon. Keep in mind that I probably need to refactor some things to make it works so it could take some time before it's done.

[Jay L. Colbert]

No problem at all! Thanks again for looking into it.

[Thomasorus]

Ok I actually had time tonight and it was less complicated that I thought.

URL options

You now have 3 options to name your files:

1. Keep using just a date with the format 01-01-2021.md. Ideal for blog entries, the date you entered is the "published date" used to order posts in a reverse chronological order in index pages. Nothing changes from before, your url will be /01-01-2021.html
2. Use a date format followed by a slug entry: 01-01-2021-my-file-name.md. Ideal if you want a custom "published date" but don't want to use dates as the slug. Your url will be /my-file-name.html.
3. Use no date at all: my-file-name.md. For wiki or notes pages that are not calendar oriented. A date will still be shown under the title in the listings, but it will be the last time you saved the file. The url will be Your url will be /my-file-name.html.

I strongly discourage mixing the custom date approaches with the no date approach in the same folder! It's probably better to use the date or date + slug in your blog folder, and the no date format in your notes pages.

Flat build option

In the config.py file, you'll find a flat_build option.

• If set to False, nothing changes from previous Chisai. If you have a notes folder, your url will be /notes/ for the index.md file and each page will be under this folder, ex: /notes/note-1.html.
• If set to True, the folder disappear from the built website. If you have a notes folder, your url will be /notes.html for the index.md file and each page will just be the slug, ex: /note-1.html.

Wikilink option

I updated the wikilink syntax to take the flat build option into account.

When NOT using the flat build:

• Still with our notes folder and note-1.md file, if you use a simple wikilink syntax like [[note-2]], you will link to /notes/note-2.html. The simple syntax takes your current folder as an url basis.
• If you want to link another folder, you need to use the complete syntax [[A page in the art section|art/art-1]].
• You can't use the simple syntax to link directly to another folder, ex: [[art/art-1]] will not work.

When USING the flat build:

• Since there are no folders anymore, the simple syntax will always link to the right file. Ex: [[note-1]] or [[art-1]] can be written from anywhere.
• The complete syntax then should be used to just change the text of the link.

In your case since you are working towards a digital garden approach, I suggest you se the flat build option to True. This way you'll be able to use wikilinks way more easily without thinking about the folder you're in.

Let me know how it goes or if you find any bugs.

[Jay L. Colbert]

Works like a charm! Thanks so much.

[Jay L. Colbert]

Oh, just realized something. When I push commits, the build of the site seems to reset all the dates to the date of the commit. I can open up a new issue if needed! I do have it set to flat build but still use folders in my actual editor. The build removes the folders just fine, but I didn't know if that might have something to do with the dates.

[Thomasorus]

Hum that's not normal. I'll look it to it asap.

[Thomasorus]

Ok, after a lot of trials and errors that made me delete the entire commit history, squash dozens of commits for in the end delete everything and be back to square one, I can at least explain what's happening.

The reason you have all the dates and I did not have them is because of github-actions, the set of scripts that is building the website each time you make a change. Instead of taking the existing files, the whole repository seems to be cloned, which creates new "last modified" dates for all the files and of course, when the build happends, they're all the same. This problem would not happen in a configuration where the deployment is done on a classic server, after a simple git pull.

It doesn't seem there is a way to change this for github actions as everything runs on docker image files or equivalent. I'm going to explore two solutions:

1. Try to find if the builder can somehow explore the file modification history and if yes, try to take the previous save instead of previous creation.
2. If not possible, add an option in the config file to hide dates.

Thanks for your patience.

[Thomasorus]

To keep you updated:

• The builder is now using the git commit history to find the last change you made to a file, it's working great!
• Except it doesn't work on github because of the automated build process that crushes the git commit history for whatever reason and replaces it by the build date.

TLDR: it works until it doesn't, still investigating. Meanwhile you can still use Chisai and dates should be the right ones when I find a solution.

[Jay L. Colbert]

Awesome, thanks! In the meantime, should I refrain from using GitHub actions and run the build script manually? I noticed running build.py in my local repo built it just fine, it was just the gh actions generating that specific branch that got screwy.

[Thomasorus]

For Chisai I assume people don't have the know-how of git and launching scripts, so I always try to make things work without the user having to manually build the site.

Since you have the knowledge yes, you can build it locally if you want. It should be even better than the previous version since now it takes git commit dates instead of modification dates, which means if you ever cloned the repo to another computer, the dates should still be ok.

I'll keep searching how to fix this!

[Jay L. Colbert]

Sweet! I'll let you know how the manual build goes. I might not be too knowledgeable, but I always try to know just enough to be dangerous, ha.

[Jay L. Colbert]

Got it to work!

Here's what I did:

1. Change build_folder in config.py to docs/
2. In partials/main.html, remove "build_url" from in front of anything with "assets", and make sure there isn't a "/" in front. For example, "assets/main.css" instead of "/assets/main.css" or "build_urlassets/main.css"
3. Manually run build.py
4. For GitHub Pages, set the branch to "master" and folder to "docs/"
5. I had to do some HTML links in the index pages, but otherwise, the wikilinks work great!

[Thomasorus]

If it's working for you then good, the goal is that everyone can self-appropriate it. I'll keep working on my side. :)