{attach} and {filename} don't work in metadata fields

[torfsen]

I'm not sure whether this is a bug or intentional, but {attach} and {filename} don't work in the metadata fields of an article. For example, the following article is working fine, except that image.png is not copied to the articles output directory:

A Test
######

:date: 2018-06-22
:thumbnail: {attach}./image.png

Some text

Note that the image is copied to the output directory, but like a "normal" static file: its path is preserved instead of the image being put in the article's directory.

In addition, the thumbnail property of the article's article object in the template equals {attach}./image.png.

Using {attach} in the body of the article works as documented.

I would have expected that

1. the image is copied to the same directory as the article's HTML file
2. article.thumbnail equals the image file's output filename

{filename} is also affected, i.e. when using {filename} instead of {attach} in the example above the article.thumbnail property is equal to {filename}./image.png. Again I would have expected it to be equal to the image's output filename.

$ pelican --version
3.7.1

[peterdesmet]

+1 I want to use it for cover images.

I found that link expansion of metadata fields can be done by using expand_link function in @mosra's htmlsanity plugin, but I think it would make a lot of sense to add this as core Pelican functionality.

[molysgaard]

I am using the Medius theme, where article cover photo and thumbnails are specified in the post metadata. Because {attach} and {filename} are not handled for the post metadata it is not easy to have a static image file for the post without hard coding paths.

What I would ideally like is that if an article has images, I will make a self contained folder for the article, which contains the .rst as well as the images. Then all links in the .rst will be relative to this folder. This would make a more self contained article editing experience instead of having to carefully manipulate paths in the .rst and copy images to a global static folder to stitch everything together.

Is there a deliberate choice that makes it unfeasible to have expansion happen in metadata or would a pull request be accepted?

[avaris]

Only reason it's not available is that it's not easy to implement. If you can come up with a solution that'll work in all supported cases, then please go ahead.

There are a few of things to consider: This is most definitely need to be resolved at access time (i.e. from template). And location of that can vary significantly with RELATIVE_URLS. index.html and the article itself can live in different parts of the tree and both need to resolve the path to correct position (even with RELATIVE_URLS).

[torfsen]

@avaris thanks for you insights in how this might be implemented. Could you also point out how implementing {attach} and {filename} for metadata fields would differ from the existing handling of these commands in the body? My first guess would have been that one would be able to simply extend the existing mechanism to also cover the metadata fields, but your comment suggests that this might be more complex.

[avaris]

The body (aka content) is a property that can recalculate the appropriate links each time it is accessed.

On the contrary, metadata fields are simple attributes and you don't get to intercept access and provide appropriate values depending on the context.

One "simple" (but possibly horrible) solution is to wrap all metadata fields in property getters so that you can do this.
Another might be a custom function made available in templates, which would do this (i.e. {{ article.cover|expand_link }}. But that also needs to access context, which could be challenging.

[molysgaard]

@avaris Thanks for the info. Could you elaborate why a property getter function would possibly be a horrible solution?

[avaris]

I'm just guessing what the possible code would look like :).

There are standard non-string metadata fields ('tags', 'authors', 'category', etc.) that needs to be special cased. It's also possible that some plugins may add other fields to the above list.

[mosra]

Thought I would comment here to avoid inventing the same thing again from scratch :)

I was solving a similar problem some time ago. First (later discarded) attempt was in #2164 (see the discussion there for details), but then I realized that it can all be done from a plugin that adds a custom Jinja2 filter without modifying Pelican internals -- basically, if one needs link expansion in custom fields, these custom fields need to be referenced from a theme. And the theme can simply apply a filter to the variable to get the link expansion working. Simple and straighforward, in my opinion.

I have this functionality as part of the m.htmlsanity plugin in m.css, if you want to have a look.

[peterdesmet]

@mosra, would you still prefer that the internal Pelican function _link_expander would be public, so one does not have to repeat that functionality in plugins like m.htmlsanity?

https://github.com/mosra/m.css/blob/2d7d3b5e1ae7f62e35203d2848e96a7836676d6f/pelican-plugins/m/htmlsanity.py#L812-L816

[mosra]

@peterdesmet it already is :) the PR was partially merged in 1f30306.

The code in the plugin is only for backwards compatibility with version 3.7.1, for people who can't use latest master.

[justinmayer]

@peterdesmet: If @mosra's plugin doesn't do the trick, please let me know and we can consider re-opening this issue. Cheers!

[whnr]

@mosra does this expansion only work for rst-files? I tried it with an article converted from asciidoc and get nothing.