Why have a "ready" folder if it's supposed to be "Write once, convert to multiple platforms."

[MartinP7r]

Details

Hi,

I think this plugin is a great idea, I just have some questions about the use case.

Personally I would imagine that the notes inside the Obsidian vault would be considered the source of truth and shouldn't be changed or moved.
So instead of a "ready" and "backup" folder, wouldn't it make sense to just define a "source" and "output" folder where files from the "source" folder are synced to converted files in the "output" folder?

I hope the idea is understandable. Basically the "source" folder will always remain untouched as the "source of truth" and if there's errors during conversion, you could ever just print them to the Obsidian console or post them to the frontmatter/header of the equivalent file in the output folder.

Also, as a side note. A feature to define multiple source/output folder pairs would maybe also be nice, for people who have more than one jekyll blog.

[songkg7]

First, thank you so much for your interest and suggestion!

Why have a Ready folder?

I've been using the P.A.R.A concept in Obsidian, and recommending it to others. In this concept, documents are moved frequently to suit your situation. The name ready is a suggestion to mean that they are ready to be uploaded to your blog, and once uploaded, the intention is to organize (move) them to another directory so that you can focus on new documents.

Sync

Apart from that, your suggestion about synchronization is very interesting, but synchronization requires that we keep our directory structures as identical as possible, and as I mentioned above, the concept of PARA means that documents will be moved frequently, so synchronization may be difficult to implement in practice. Many users probably don't want to post all of their documents to their blogs, so let's start by thinking about how to implement this by requiring documents to use a front matter like publish: true inside of Obsidian so that document movement doesn't affect the grammar transformation functionality.

A feature to define multiple source/output folder pairs

Ideas for error handling and for people running multiple jekyll blogs are very positive and I'll try to incorporate them as soon as possible. However, TypeScript is not my main stack, so it may take some time. 😂 (Please Help me, every dev...!)

I hope this answers your questions, and I'm attaching some videos for your reference.

Thanks again for the great ideas!

• PARA
• How I Built a SECOND Brain 🧠 in Obsidian MD

[MartinP7r]

Thanks for the quick response @songkg7 !

I see. There's definitely many different use-cases here.
I've heard about PARA, but haven't gotten around to trying it myself.

I think a structure that's as nimble as possible would be good.

but synchronization requires that we keep our directory structures as identical as possible

not necessarily. It really depends on what your output goal is.

There's many possible user stories, and I don't think you can cater to them all, but if the basic system is very versatile, I think a lot can be accommodated.

Your suggestion of using front matter variables in stead of folders is very good.
Instead of a boolean, you could use a path where the output should be synced to.

publishTarget: some/folder/path

"synchronisation" might even be too strong a word. Because we don't need two-way, this could be a simple export (with overwrite on exist).
And in the settings of your extension, you could provide a way to map the type of markdown to the output folder path.

[songkg7]

I see some direction for development, and I'll try to get this resolved as soon as possible.

• using publish front matter instead of ready folder (BRAEKING CHANGE)
• overwrite, not sync. just settings options, including ignoring the file if it already exists. (New feature)

For users who have already written so many articles, the performance will be somewhat inefficient because they have to scan everything to extract the front matter, but let's take a look at this slowly.

[MartinP7r]

I saw you created and closed a PR about this. Were there any roadblocks you encountered? Maybe we can simplify the requirements?

[MartinP7r]

Let me summarize

• don't move or change the original file (or give option to prevent it)
• make backup, attachment folder settings optional
  • backup is not needed if the original file is not changed
  • some users may not need attachments (e.g. if they host everything externally)
  • ready folder won't be necessary if publishing is controlled by front matter
• control publishing via front matter instead of folder

[songkg7]

That offer still stands.

I did some work on it last year to implement the idea, but it involved too many code changes, so I pushed it back to the 2.0 release. There's also the fact that I'm not very familiar with Typescript 😂. I apologize for that.

The reason for closing the issue was to separate the comments into discussion and keep the issue for bug reporting only. This is not to discard your suggestion.

Here's what I planning to do, but please understand that it may take some time.

1. I will change the code style to functional programming. I'm a Java programmer, so I'm used to object-oriented.
2. change the file movement to front matter method.
3. I will be adding docusaurs in 2.0.

Thanks for the summary, also your interested my project.