-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Fix metadata intrasite links #2288
Merged
justinmayer
merged 4 commits into
getpelican:master
from
charlesfleche:fix-metadata-intrasite-links-squashed
Feb 9, 2018
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
65daa9e
Extract refresh_metadata_intersite_links methods
charlesfleche 06fd9be
Get Content._summary from metadata
charlesfleche 31dc936
Initialize metadata with refresh_metadata_intersite_links
charlesfleche 3de422b
Add test for parsed metadata
charlesfleche File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
@charlesfleche @justinmayer As I commented in #2162 (comment), this line causes link replacement to be dependent on the order in which files are processed -- because it's done during parsing of a single article/page and not later when everything is ready (so e.g. links to pages in metadata fields that were not yet processed are reported as
Unable to find
).I investigated further and realized
refresh_metadata_intersite_links()
is called again later below, after all articles/pages are processed -- and in that second step the links that were previouslyUnable to find
are then replaced correctly. I don't know the code very well, but in my case when I commented the above two lines out, the warnings were gone (and links in metadata fields still correctly replaced). I imagine removing the above might cause some plugin to cease working (since e.g. thesummary
metadata field won't be present yet), so not really sure how to fix that. On the other hand, I don't think callingrefresh_metadata_intersite_links()
twice on everything is a good idea (at least from a perf PoV, but I could imagine some potential issues with{attach}
as well).Any ideas how to fix this?
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.
Agreed, this is not ideal.
Removing these won't make
summary
vanish, but it'll be unprocessed if one accesses before everything is processed. And that is actually fine, since accessing.summary
in a plugin earlier thanall_generators_finalized
is a "bug" in itself for this same reason (it'll spewUnable to find
warnings).Another issue is that, this removed
_summary
. Even though it's "internal", some plugins used that.From what I can see, this modification is all for preventingsummary
being processed twice.Edit: Everything is processed twice anyway. I don't know what this is for.
I'd say, reverting this bit and
get_summary
should be enough.And maybe excluding
summary
fromrefresh_metadata_intersite_links
, if one is worried enough about the double processing.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.
Finally got back to this (sorry for the delay), the proposed change is in #2406.
Not sure what you mean, reverting the above bit is (as far as I can see) enough to stop the double processing.
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.
I meant, if you revert the above part and
get_summary
thensummary
will be processed twice.refresh_metadata_intersite_links
is calledcontent.summary
is accessed (or any other way.get_summary
is called).Furthermore, reverting only this part is pointless, since you end up with a
._summary
attribute that's not used anywhere.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.
Um, I'm afraid I lost all the context over the time we're discussing this 🙈
I did that only to fix this:
So, what I ended up doing in #2406 is:
_summary
, because some plugins used that, as you saidrefresh_metadata_intersite_links
too soonI could also just delete this part altogether (and thus
_summary
would be no longer). Can we move the discussion to #2406?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.
Sure, but
_summary
is not used inget_summary
anymore. This PR also changes that. I mean those should be reverted together.Plugins modifying
_summary
do so in order to change.summary
, since you can't directly access.summary
too early. Now they will access and change something irrelevant. Modifying_summary
will leave.summary
unchanged.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.
Oh! Now I get you. I thought
_summary
was accessed only for read, never for write. Now it all makes sense, sorry for my denseness.#2406 is updated (the CI is failing for an unrelated reason, same on master), but instead of just reverting the second part I realized the changes to
_summary
won't be picked up byrefresh_metadata_intersite_links()
and the_summary
handling would need to creep there as well. So now I introduced a_summary
property getter/setter that's basically just a "view" ontometadata["summary"]
. Also, "because some plugins used that" I assume it's not a workflow worth preserving so the getter/setter now prints a deprecation warning when the property is used.I hope this is finally getting closer to how it should be :) And sorry for the delays, I'm extremely busy.