kaushalmodi / ox-hugo

A carefully crafted Org exporter back-end for Hugo

Home Page:https://ox-hugo.scripter.co

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Fix attachment rewrite

kaushalmodi opened this issue · comments

Hi @titaniumbones ,

Can you please try out this branch: https://github.com/kaushalmodi/ox-hugo/tree/copy-files-to-static-images-only-when-needed

From the commit message in there:

Earlier, the images/ directory was given too much prominence. A user
could have multiple dirs inside their static/ dir.. but the rewrite
would always happen to just static/<HUGO_STATIC_IMAGE>. That did not
look right.

Now ox-hugo tries to be smarted in figuring out where to copy the
outside-Hugo-static-dir files to.

I believe this will work for your flow too.. you will simply need to ensure that your outside Hugo dir structure includes /static/ followed by the path that you would like to see post-attachment-rewrote inside Hugo Static dir.

Here is the new behavior summary copied from example-site/content-org/all-posts.org:

If you link to files outside of the Hugo =static= directory, ensure
that the path contains =/static/= if you would like to preserve the
directory structure.

Example translations between outside =static= directory paths to the
copied location inside =static=:
|----------------------------------+-------------------------------------------+----------------------------------------------------------------------------------------------------------------------|
| Outside =static=                 | Copied-to location inside =static=        | Explanation                                                                                                          |
|----------------------------------+-------------------------------------------+----------------------------------------------------------------------------------------------------------------------|
| =~/temp/static/images/foo.png=   | =<HUGO_BASE_DIR>/static/images/foo.png=   | If the *outside* path has =/static/= in it, the directory structure after that is preserved when copied.             |
| =~/temp/static/img/foo.png=      | =<HUGO_BASE_DIR>/static/img/foo.png=      | (same as above)                                                                                                      |
| =~/temp/static/foo.png=          | =<HUGO_BASE_DIR>/static/foo.png=          | (same as above)                                                                                                      |
| =~/temp/static/articles/zoo.pdf= | =<HUGO_BASE_DIR>/static/articles/zoo.pdf= | (same as above)                                                                                                      |
| =~/temp/bar/baz/foo.png=         | =<HUGO_BASE_DIR>/static/foo.png=          | Here, as the *outside* path does not have =/static/=, the file is copied directly into the Hugo =static/= directory. |
|----------------------------------+-------------------------------------------+----------------------------------------------------------------------------------------------------------------------|

Note the updated location for this example too: https://github.com/kaushalmodi/ox-hugo/blob/copy-files-to-static-images-only-when-needed/example-site/files-to-be-copied-to-static/static/images/copy-of-unicorn-logo.png

Please let me know if this update works alright for you at the soonest. I will merge it in after that.

Haven't had a chance to try it out yet but the commit looks great. It's a far superior mechanism. Will try to play with it soon but feel free to merge before and we an fix bugs later if they emerge.

a little occupied right now trying to figure out how best to get my reveal.js lecture slides into the hugo-based website. I'll want to use this code actually!

Will try to play with it soon but feel free to merge before and we an fix bugs later if they emerge.

Thanks. I have merged it, with documentation added to https://github.com/kaushalmodi/ox-hugo/wiki/Image-Links

a little occupied right now trying to figure out how best to get my reveal.js lecture slides into the hugo-based website

I might also have to tackle that soon. Let me know what you come up with

Fixed in 1a2b8d9

a little occupied right now trying to figure out how best to get my reveal.js lecture slides into the hugo-based website

I might also have to tackle that soon. Let me know what you come up with

I'm thinking that the easiest way to do this is to reuse the org-hugo image rewriting code (maybe extract it into its own defun now that it's getting richer), then write a simple derived backend on top of ox-reveal.

Unfortunately, reveal slideshows need to be run in an iframe rather than a div. so... Idon't think my first ide will work -- which was to strip out the header & footer info from the html export, and just incorporate those into the hugo templates.

So, instead, I am thinking I will export the slideshows to static/slides/ and write a"slides" page that lists the content of that directory in a sidebar menu (using hugo's readDir) and opens the full reveal slideshow in an iframe in the main portion of the page.

It feels clunky. Do you have any better ideas?
I think one could just cut out hte preamble, nad write a hugo

Have you looked at this? https://github.com/minoritea/hugo-revealjs-generator

Just that applying that layout specific to a section like slides in a way that it blends with the rest of the site might be challenging.

I looked at hugo-revealjs-generator -- that workflow & the one-page-per-slide setup don't seem to match my habits very well.

The aphecetche site is interesting. Two thoughts from me about htis approach:

  • I haven't used the built-in markdown feature of revealjs. The README says reveal uses github-flavoured markdown, which means it won't support class attributes. For me that would likely break a lot of my existing presentations, which often break the slides up horizontally, so I use a class to keep the slides within the grid. I currently use most of the features of ox-reveal, and I personally would want to retain those features if possible.
  • in Abcecetche's setup,, clicking on a talk takes you outside of the menu system, so that you almost feel like you're not in the website anymore. That makes sense in some ways, but I think it would be disorienting for my students, and also it would make it a little hard to navigate between the lectures. So I would like to keep the talks inside an iframe (here's an example of one current site: http://wildwater.hackinghistory.ca/article/wildwater-1-syllabus/ , which has menu apparatus on the side 7 title on the top).

Still, the markdown export is appealling, and I prefer keeping an md file in my site repo to writing out the full html and saving that...

Coming back to the actual topic of this issue: at present, linked images & files that are not kept in a directory tree containing a "static" dir are dumped to the root hugo-base-dir/static directory. This is probably a bad place for them. Can we instead keep them either in static/images or a new dir, say static/ox-hugo or similar?

(we'd just have to change line 830, and possibly introduce another defcustom to name that dir).

say static/ox-hugo

How about static/misc? I'll make the change now.. and then maybe add a defcustom if needed. Adding a defcustom too.

BTW is using static/ in the source directory path impractical?

BTW is using static/ in the source directory path impractical?

I will do so going forward, but at present I have something like 100 lectures and I would guess around 1000 images, spread over a number of courses. I guess I could write a script to move all the images and change al lll the links, but it feels a little hard to do right now.

btw, I was able to implement a hugo-compatible reveal export. I put it here: https://github.com/titaniumbones/ox-huveal -- it's mostly frankencode from your repo and https://github.com/yjwen/org-reveal/. You can see the slides produced here or here. I'm using this theme, and the menu code is here.

Try out the attachment rewrite change.. If it works for you, I'll bump the revision number.

Feel free to re-open this if this doesn't work for you.