Better logging if writing a tag/category/author page fails

[minchinweb]

Add a short logging message if for some reason an invalid tag is provided, and Pelican instead tries to overwrite the index page.

Before:

           CRITICAL RuntimeError: File D:/Code/obsidian-vault/zz_output/tags/index.html is to be         __init__.py:666
                    overwritten

After:

[21:56:21] ERROR    Trying to write tag page for "**".                                                 generators.py:580
           CRITICAL RuntimeError: File D:/Code/obsidian-vault/zz_output/tags/index.html is to be         __init__.py:666
                    overwritten

(For some reason, the tag ** is mapped onto the index page. Perhaps that is another issue that should be fixed...)

Fix is applied when writing Tag, Category, and Author pages. Let me know if it should be added other places.

Pull Request Checklist

• Ensured tests pass and (if applicable) updated functional test output
• Conformed to code style guidelines by running appropriate linting tools
• Added tests for changed code
• [-] Updated documentation for changed code

[avaris]

For some reason, the tag ** is mapped onto the index page.

Because, slug is empty and depending on TAG_URL/TAG_SAVE_AS you'll get "weird" results:

>>> from pelican.urlwrappers import Tag
>>> from pelican.settings import DEFAULT_CONFIG
>>> t = Tag('**', DEFAULT_CONFIG)
>>> t.slug
''

And that's because slugify will strip/replace "questionable" characters. Since this will become part of the filename in the output, and filesystems can be picky. Similar for URLs.

Off the top of my head, I cannot think of any reason for wanting an empty slug intentionally. So if no objections, we could error for empty slug.

[minchinweb]

I've updated it as per your comments! This is the current message:

[20:13:46] WARNING  Tag "**" has an invalid slug; skipping writing tag page...                                 log.py:89

I have it throw a warning (rather than a critical error) if the slug is invalid, but throws the "regular" critical error if it's run into some other problem.

I've "un- pre- formatted" the log messages, and dropped the as e.

Overall, it makes sense that slugify would strip out questionable character; I was just annoyed that Pelican would break but not really tell me what was wrong or how to fix it; I hope this explains how to fix the issue to the next user.

[minchinweb]

I've added a warning when trying to generate a slug from a name that won't give a valid slug, and downgraded the former warning to an INFO message. So the displayed messages (when run with --verbose) now look like:

           WARNING  Unable to generate valid slug for Tag "#**".                                               log.py:89
[...]
           INFO     Tag "#**" has an invalid slug; skipping writing tag page...                        generators.py:579

[avaris]

With empty slugs already generating warnings, is this special case necessary anymore? Why not just do the else block?

[minchinweb]

I think it's helpful to still keep this, because it makes it very explicity what Pelican is (or isn't doing), and it's not entirely obvious that an invalid slug would keep the page from being generated.

Also, it mirrors the logging for all the pages that are written.

[minchinweb]

Hi @avaris !

This seems to have been lost in the shuffle.

Do you want me to remove the logging (of the non-generated pages), or is it good to merge as is?

Thanks!

[minchinweb]

Hey @avaris ! Let me know if anything more is needed to merge this! Thanks!

[avaris]

Apologies, offline life get in the way of things. I'll try to get back to this ASAP.

[minchinweb]

Apologies, offline life get in the way of things. I'll try to get back to this ASAP.

No worries at all. My offline life has kept me from anything Pelican-related for the last couple months too...

[minchinweb]

Hey @avaris , just wanted to check in on this. I'm maintaining a local fork with this on my side, but would love to just see it merged in.... Thanks for your help.

[minchinweb]

Just wanted to bump this, hoping to get it merged! It's one of the patches I'm maintaining locally, and I was going to get up a new pull request till I remembered this is still here waiting...

Let me know if changes are needed; I'm happy to make them.

[justinmayer]

I believe except RuntimeError will catch any RuntimeError — not just the file-overwrite error. Perhaps it might be better to catch a more specific exception. Maybe introduce a custom FileOverwriteError subclass of RuntimeError in writers.py? What do you think?