The Markdown form [{{< figure .. >}}](some link) results in wrapping
the <figure> in <a> in the final HTML, which is invalid.
- [X] Non-inlined hyperlinked images -- Use link in figure
https://github.com/kaushalmodi/ox-hugo/issues/125
One minor behavior change: Now <a> tag attributes like "target" and
"rel" cannot be applied *only to* the links that images hyperlink
to. The reason is to make the exported Markdown generate valid HTML,
and with how the "figure" shortcode is designed in HTML, those
parameters are not passed onto the <a> element in the generated
<figure> element.
Now if the attachments are in the same dir as the content Org file,
the full directory hierarchy for those attachments is preserved when
copied to the bundle dir in content/, even if the path does not
contain "static/".
Example:
Original path:
<ORG_FILE_DIR>/foo/bar/baz.png
Copied-to path:
<HUGO_BASE_DIR>/content/<SECTION>/<BUNDLE>/foo/bar/baz.png
Fixes https://github.com/kaushalmodi/ox-hugo/issues/124
Remove the logic clutter that tried to preserve "file:" before
links.. "file:" does not make sense for web pages (may be need to
revisit this in future, but for now all existing tests pass).
- Add tests for images linked to images when the linked image needs to
be copied to static.
- Another test similar to above but when the page is a bundle and the
linked image needs to be copied to the bundle dir.
- Also update test site theme
The --recursive switch is now needed when cloning as the test site
theme hugo-bare-min-theme is now a git submodule.
Remove repeated mentions about `--navigateToChanged` switch being
introduced in Hugo v0.25.. hopefully folks using `ox-hugo` are already
on a much newer version :)
It's used in the Hugo-internal template "opengraph":
2fa70c9344/tpl/tplimpl/template_embedded.go (L205)
Added new keywords HUGO_WITH_LOCALE (defaults to nil) and HUGO_LOCALE.
With HUGO_WITH_LOCALE non-nil, and HUGO_LOCALE nil, the locale is
auto-detected from the system env vars LANGUAGE, LC_ALL or LANG.
User can also choose to manually specify the locale instead using
HUGO_LOCALE using a "language_TERRITORY" type string.
Note that the auto-detected/manually specified locale will be exported
to the "locale" front-matter only if HUGO_WITH_LOCALE is set to a
non-nil value (like t).
https://github.com/kaushalmodi/ox-hugo/issues/122
Org keywords: #+HUGO_TAGS, #+HUGO_CATEGORIES, #+KEYWORDS
or
Org properties: :EXPORT_HUGO_TAGS:, :EXPORT_HUGO_CATEGORIES:, :EXPORT_KEYWORDS:
!! This is a breaking change !!
Earlier, strings with spaces in those keywords had to be written as
abc__def. Now strings with spaces need to be written as "abc def"
instead, which is more intuitive.
This *does not* change the abc__def style required in Org
tags (e.g. :abc__def:), because Org tags cannot contain spaces. Note
that the same applies to the #+FILETAGS keyword too! In the
abc__def.
For many keywords like #+HUGO_TAGS, it is useful to merge multiple
values when this is done:
#+HUGO_TAGS: value1
#+HUGO_TAGS: value2
This merging did not happen as expected for these keywords; this
commit fixes that.
#+AUTHOR:
#+HUGO_CUSTOM_FRONT_MATTER:
#+HUGO_BLACKFRIDAY:
#+HUGO_MENU:
#+HUGO_MENU_OVERRIDE:
#+HUGO_OUTPUTS:
#+HUGO_RESOURCES:
Add test case for the same.
(Note that this fix was needed only for Org keyword values merging, not
subtree property merging.)
By default, ox-hugo interprets Org tags without "@" prefix as "tags"
and those with the "@" prefix as "categories".
But if you prefer to do the opposite i.e. have "tags" with the "@"
prefix, simply add:
#+HUGO_FRONT_MATTER_KEY_REPLACE: tags>categories categories>tags
That's it! :)
The org-hugo--replace-keys-maybe function is optimized, gotten rid of
redundant code, and made more robust.
Now it won't puke if user make an error in the "oldkey>newkey"
replacement syntax (like spaces around ">" and stuff like that). It
will now silently prevent doing replacements if the replacement syntax
is invalid.
New Org keyword/property:
#+HUGO_FRONT_MATTER_KEY_REPLACE
:EXPORT_HUGO_FRONT_MATTER_KEY_REPLACE:
This commit obsoletes the 2 new keywords/properties pairs introduced
in an earlier commit today:
e5e6e87e71
Earlier approach was hard-coded to replace only tags and categories
keys in the front-matter.
This new approach used in this commit can replace *any* front-matter
key with the string the user wants.
The syntax is:
#+HUGO_FRONT_MATTER_KEY_REPLACE: oldkey>newkey
You can also do multiple key replacements:
#+HUGO_FRONT_MATTER_KEY_REPLACE: oldkey1>newkey1 oldkey2>newkey2
Note that:
1. There are no spaces around the special character ">".
2. Spaces are used to only separate multiple replacements are shown in
the second example above.
3. The replacements are literal.. there are no regular expressions
involved.
- Optimize org-hugo--get-yaml-toml-list-string
- Re-write org-hugo--transform-org-tags-2 as
org-hugo--delim-str-to-list, with better documentation.
- Keywords front-matter parsing is now on par with the parsing of tags
and categories (multiple keywords, keywords with spaces, hyphens,
underscores).
- Add test cases for keywords parsing.
New keywords/properties:
#+HUGO_FRONT_MATTER_KEY_ORG_TAGS
:EXPORT_HUGO_FRONT_MATTER_KEY_ORG_TAGS:
#+HUGO_FRONT_MATTER_KEY_ORG_CATEGORIES
:EXPORT_HUGO_FRONT_MATTER_KEY_ORG_CATEGORIES:
Add test cases / examples for this new feature.
Now you can "C-c . RET" to set values for HUGO_PUBLISHDATE and
HUGO_EXPIRYDATE properties too (just like you can already do that for
DATE and HUGO_LASTMOD properties).
Added test cases for "lastmod", "publishdate" and "expirydate"
front-matter variables.
Consolidate the date formatting logic into a separate new function
`org-hugo--format-date', and use it to derive all the Hugo date
front-matter variable values: "date", "lastmod", "publishdate", and
"expirydate".
Kaushal Modi