New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete old Markdown file when editing the EXPORT_FILE_NAME #34

Open
kaushalmodi opened this Issue Jul 13, 2017 · 10 comments

Comments

Projects
None yet
4 participants
@kaushalmodi
Copy link
Owner

kaushalmodi commented Jul 13, 2017

If the EXPORT_FILE_NAME was "a" and then we changed that to "b", we will end up with both a.md and b.md.

Need to figure out how to delete the old file when new file is created.

@punchagan

This comment has been minimized.

Copy link
Contributor

punchagan commented Jul 24, 2017

One idea could be to maintain a "database" of the posts that have been exported from ox-hugo. Posts could be given a custom ID on export, and map that to some post metadata in the DB, including EXPORT_FILE_NAME.

If we go with this idea, we could also store a hash of the subtree/post contents, to detect changes to any of the posts, and let "export all subtrees" identify and export only the changed ones.

@kaushalmodi

This comment has been minimized.

Copy link
Owner Author

kaushalmodi commented Jul 24, 2017

Would you like to implement this? Also I don't know what the performance impact would be for big blogs if the hash has to be calculated for dozens/hundreds of posts with, let's say, 2000 words each, for each export. Poor man solution would be to rely on git diff to see which posts changed, and export just those :) Git diff also helps catch any unintended text change in older posts.

About the implementation specific to deleting old Markdown files, here's my thought: Each time a post is exported, this one property should be saved to the subtree: EXPORTED_FILE_NAME.

So..

Before first export

* My Post
:PROPERTIES:
:EXPORT_HUGO_SECTION: posts
:EXPORT_FILE_NAME: my-post
:END:

After first export

* My Post
:PROPERTIES:
:EXPORT_HUGO_SECTION: posts
:EXPORT_FILE_NAME: my-post
:EXPORTED_FILE_NAME: posts/my-post
:END:

(assuming the extension to be always .md)


After EXPORT_FILE_NAME rename (and even section change!) -- Before export

* My Article
:PROPERTIES:
:EXPORT_HUGO_SECTION: articles
:EXPORT_FILE_NAME: my-article
:EXPORTED_FILE_NAME: posts/my-post
:END:

Here as (concat <EXPORT_HUGO_SECTION> "/" <EXPORT_FILE_NAME>) does not match with <EXPORTED_FILE_NAME>, the renaming/file moving will happen.

After EXPORT_FILE_NAME rename (and even section change!) -- After export

* My Article
:PROPERTIES:
:EXPORT_HUGO_SECTION: articles
:EXPORT_FILE_NAME: my-article
:EXPORTED_FILE_NAME: articles/my-article
:END:

.. and after the export, the <EXPORTED_FILE_NAME> will be once again updated.

@punchagan

This comment has been minimized.

Copy link
Contributor

punchagan commented Jul 24, 2017

Would you like to implement this? Also I don't know what the performance impact would be for big blogs if the hash has to be calculated for dozens/hundreds of posts with, let's say, 2000 words each, for each export. Poor man solution would be to rely on git diff to see which posts changed, and export just those :) Git diff also helps catch any unintended text change in older posts.

I would like to try using the after save hook that you have provided with ox-hugo for a while, and see how it feels, before trying to implement this. Piggybacking on git diff is a nice idea!

Each time a post is exported, this one property should be saved to the subtree: EXPORTED_FILE_NAME.

This seems like a reasonable way to go about it. 👍

@takaxp

This comment has been minimized.

Copy link
Contributor

takaxp commented Aug 30, 2018

Any updates?

Piggybacking on git diff is a nice idea!

I'd support this approach.

@kaushalmodi

This comment has been minimized.

Copy link
Owner Author

kaushalmodi commented Aug 30, 2018

@takaxp

Any updates?

No, I haven't been working on this, and so have tagged as a wishlist item. Would you like to work on this?

But "this", I mean, creating a hash of all the subtrees and detecting which subtree content changed vs not.

It would be a great feature to implement, but I can use some help. This feature can also live as a separate package; either in ox-hugo repo or as a separate repo altogether . May be not as a separate repo because the subtree detection logic (that a subtree should have an EXPORT_FILE_NAME property) is specific to ox-hugo.

@takaxp

This comment has been minimized.

Copy link
Contributor

takaxp commented Aug 30, 2018

I'd like to work on this issue but currently I focus on auto-set-lastmod issue that I haven't reported yet.

Hmm... I feel now the problem is that an unexpected post could be exposed to a hugo website.

For example,

  1. Create a subtree with a title as "a-title-with-typo"
  2. Export the post by "C-c C-e H H", then "a-title-with-typo.md" will be created.
  3. After that, a user realize the typo and fix the typo as "a-correct-title"
  4. Export the same post by "C-c C-e H H" again, then "a-correct-title" will be created but "a-title-with-typo.md" still exists.
  5. Execute "hugo" and transfer the public directory to a website
  6. Then, "a-title-with-typo/index.html" will be published unexpectedly.

If a user configures (setq org-hugo-auto-export-on-save t) option, the above issue will be happen more frequently and it's critical.

But the point is when we should check the unexpected files are placed in content and public directories.

Should we have to check them all at the time exporting even a single post by introducing potential heavy calculations based on hash database?

@kaushalmodi

This comment has been minimized.

Copy link
Owner Author

kaushalmodi commented Aug 30, 2018

Export the same post by "C-c C-e H H" again, then "a-correct-title" will be created but "a-title-with-typo.md" still exists.

Yes, I understand the issue. The way I avoid is by carefully looking at the git diffs when committing. This of course doesn't help if one is not using the git flow for site deployment, and is instead directly copying the files from content, public, etc. via rsync, etc.

@takaxp

This comment has been minimized.

Copy link
Contributor

takaxp commented Aug 30, 2018

The way I avoid is by carefully looking at the git diffs when committing.

True. In my flow, I directly copy the public directory via rsync, so I can check the differences by dry-run.

@kaushalmodi

This comment has been minimized.

Copy link
Owner Author

kaushalmodi commented Sep 5, 2018

Note to self: Incorporate the hash calculation has done by @itf in itf/org-export-head@32fc582.

@itf

This comment has been minimized.

Copy link

itf commented Sep 5, 2018

Thanks! I got the hash idea from this answer: https://emacs.stackexchange.com/a/39376/20156

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment