-
Notifications
You must be signed in to change notification settings - Fork 99
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
Add debug logging to assist in troubleshooting #144
base: master
Are you sure you want to change the base?
Conversation
@kriation Instead of leaving the opening comment of a Pull Request empty and opening a related issue-ticket, it is better if the PR's raison d'être is contained within the PR itself. However, if you're submitting a PR to resolve an existing issue ticket, you can include |
I don't have a sample site at hand to test this manually. Can you please post screenshots of the debug output from this change? |
|
If this is is accepted, this should be documented on the README. |
There are couple of things immediately apparent from the screenshot:
All in all, I'm not in favor of this proposal. Sorry. |
@ashmaroli IIUC this will only be output when you use |
Yes, that is correct. I was thinking maybe instead of piping into the default debug output, it'd be better if these output was triggered via an additional configuration... For example, jekyll-archives:
debug: true But that needs to be approved by other maintainers first. |
@ashmaroli - I'm happy to make the changes you mentioned. With regard to noisy verbose output, isn't verbosity verbose by design? Without this logic, resolving issues (as I did) would take considerably longer as there are no other mechanisms to debug what is being processed in this plugin. |
Unfortunately, true, to both questions.
What exactly was that issue? |
How is this different than using the debug logger?
Nuance in how I specified tags in post front matter. |
Greater control and flexibility.. For example: def read_tags
if enabled? "tags"
tags.each do |title, posts|
debug_key(posts, title, "tag")
@archives << Archive.new(@site, title, "tag", posts)
end
end
end
private
def debug_key(posts, title, key)
posts.each do |post|
debug "Processing #{post.relative_path} with #{key}: #{title}"
end
end
def debug_date(...)
...
end
def debug(msg)
return unless site.config.dig("jekyll_archives", "debug")
Jekyll.logger.debug "Archives:", msg
end Disclaimer: The above example needs to be optimized further.. |
Understood! I'll update my branch with the changes. |
I was hoping for some inputs or approval of that idea from one of the other maintainers before you made additional changes.. |
Co-Authored-By: Frank Taillandier <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The debug output should only be displayed when using the --debug
option
@DirtyF That's how it is already. |
@DirtyF What is your opinion on resolving RuboCop offenses on this branch by using the example in #144 (comment) as a guide..? |
fine by me |
@kriation Thank you for bring this PR up to date. But my requests for changes still remains.. I'll approve if you're able to refactor this to meet the following:
|
@ashmaroli Absolutely! I noticed earlier this week that the original commits were well behind the existing mainline, so this last commit was to bring it up to par. I'll take a stab at implementing your changes and will add it to the commit list for this PR. |
Recently, I was struggling to understand why archives was generating duplicate pages. Without debug logging in how archives was processing each set of pages, it was difficult to determine where the issue was.
I added the code in this PR to assist and hope to close issue #145