Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better logging if writing a tag/catetory/author page fails #3266

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

MinchinWeb
Copy link
Contributor

@MinchinWeb MinchinWeb commented Dec 12, 2023

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

pelican/generators.py Outdated Show resolved Hide resolved
@avaris
Copy link
Member

avaris commented Dec 12, 2023

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
Copy link
Contributor Author

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.

pelican/generators.py Outdated Show resolved Hide resolved
@MinchinWeb
Copy link
Contributor Author

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

Comment on lines +578 to +584
if not tag.slug:
logger.info(
'Tag "%s" has an invalid slug; skipping writing tag page...',
tag,
extra={"limit_msg": "Further tags with invalid slugs."},
)
continue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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!

@justinmayer justinmayer requested a review from avaris April 19, 2024 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants