Null tag {slug} is being generated in addition to the other tags

[guru-das-s]

Hello everyone, I have been trying to debug this weird issue locally for a couple of days without any success.

I have been happily deploying my custom theme on my blog with great success and adding features to it. One thing that was missing was tags, so I thought to hack together a feature addition to the blog enabling the generation of tag pages and an overall tags page.

Issue

When I add tags to my Markdown blog posts, they all appear in output/tag/{slug}/index.html as expected. But weirdly, in addition to those tags, a literal output/tag/{slag}/index.html directory is also being generated. And upon inspection of that HTML file, it is clear that a null value for {tag} is being generated from the Jinja substitution phase.

And this null tag lists all the articles on my blog.

To illustrate:

$ ls output/tag
git  go  kernel  linux  meta  nand2tetris  opensource  rust  {slug}  terminal  tmux  vim

Problematic code

First things first.

1. Link to my currently deployed source code - does not contain the tag enablement code.
   • Sharing this so that you can see the various templates and architecture of my blog.
2. Buggy patch enabling tags: https://pastebin.com/TKiwtetD

Weirder behaviour (hopefully useful)

When I set

TAG_URL = 'tag/{abc}/'                                                                                                                                                                       
TAG_SAVE_AS = 'tag/{abc}/index.html'    

I see no errors or warnings from make devserver (that's my workflow for local testing) and I see output/tag/{abc}/index.html.

What I tried

I tried reading the source code, searching for how TAG_URL etc. is used in reader.py but couldn't really figure it out.

I tried removing all tags from my posts - in this case, a lone single tag, {slug} is still generated!

Questions

1. Why is tag.html being called when there are no tags to process?
2. How come changing TAG_URL to tag/{abc} doesn't trigger any errors or warnings for unknown metadata attribute?
3. Why is a literal {slug} or {abc} being generated in output?

Please help - I have stayed up late a couple of nights going slightly crazy over this. Thanks a lot for reading.

[justinmayer]

Hi Guru. I can't replicate the problem you described. The relevant settings for my Justin Mayer site are:

TAG_URL = "tag/{slug}/"
TAG_SAVE_AS = "tag/{slug}/index.html"
TAGS_SAVE_AS = "tags/index.html"

… which seem to be the same as the settings I am seeing in the paste-bin link you provided.

My suggestion is to (1) delete your output folder, (2) use pelican-quickstart to generate a fresh site with default pelicanconf.py, and (3) adjust configuration settings one line at a time — generating the site after each change — to see if/where the problem gets introduced. Make sense?

[guru-das-s]

Thanks for the quick reply, Justin. That is a good idea, let me try that out.

Based on my searching of similar issues on the main Pelican Issues page, I want to rule out any problems with my custom tag and tags template as well.

[guru-das-s]

Thanks a lot @justinmayer for the idea. I was able to fix the issue!

The "fix" was this:

-DIRECT_TEMPLATES = ['index', 'blog', 'til', 'tags', 'tag']
+DIRECT_TEMPLATES = ['index', 'blog', 'til', 'tags']

I don't know why this fixes the problem but it does. Specifying 'tag' as direct template creates a spurious null tag. Skipping it (while providing tag.html custom Jinja-based template) produces the expected result of there being no spurious null tags in output or sitemap.

How I figured this out is by first rebasing and relocating my commits that add tag support to an older point in the git history (resolving merge conflicts) and then checking output. I found that the erroneous behaviour persisted even when tag support was added way back in the git history, which convinced me that the problem was definitely related to my commits and not something that happened prior to them. And then by sheer dumb luck I discovered this "fix".

Thanks again!

[justinmayer]

I don't why you had tag and tags in DIRECT_TEMPLATES, because tags is the intended canonical location for the tag collection index. But in any case, I am glad you were able to locate and resolve the source of the problem. 😊