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

[WIP] Optionally read rss guid from the post #2675

Closed
wants to merge 1 commit into from

Conversation

@anderbubble
Copy link
Contributor

@anderbubble anderbubble commented Feb 19, 2017

I'm working on enhancing Nikola to support publishing a podcast RSS feed. Most of this work is going into a "postcast" plugin I'm working on, and will submit or publish eventually; but some of what I'm trying to do requires support in Nikola itself.

This PR aims to support optional explicit (and, thus, static) GUIDs from posts, so that if I move where the podcast posts are they don't flood podcast apps with old episodes.

Assign the GUID to an episode only once and never change it. Assigning new GUIDs to existing episodes can cause issues with your podcast’s listing and chart placement in the iTunes Store.

Other related PRs I'm working on:

  • #2676 (copyright tag in rss feeds)
  • #2674 (iTunes rss tags)

I'd also be interested in direction for where and how to publish a plugin, when that's ready.

@Kwpolska
Copy link
Member

@Kwpolska Kwpolska commented Feb 19, 2017

Sorry, but this has been rejected before in #2378.

@Kwpolska Kwpolska closed this Feb 19, 2017
@anderbubble
Copy link
Contributor Author

@anderbubble anderbubble commented Feb 19, 2017

First, thank you for reviewing this pull request.

But I strongly disagree with the reasons given in #2381.

  1. I have "flooded the planets" before. It was embarrassing and, as a result, I started applying uuid4 guids to all my posts (in the ikiwiki iteration of this site). It hasn't been an issue since.

  2. As such, I have seen readers use GUID to track read status; and iTunes (which is the consumer I'm currently targeting) explicitly states that GUID must not change.

  3. I'm not trying to support moving domains; but, as-is, I can't move posts at all without making them re-appear in a reader. That's incorrect and embarrassing.

  4. I don't see how an optional parameter complicates Nikola's user interface over practicality. As-is, this cannot be done in a plugin without duplicating the RSS renderer. Show me how to do it in a plugin, and I'll move the code there.

I'm totally ok with leaving the derived permalink as the default; but since it's not actually a permalink (it changes if the post moves) it should be possible to specify something actually permanent if I want.

@Kwpolska Kwpolska reopened this Feb 19, 2017
@Kwpolska
Copy link
Member

@Kwpolska Kwpolska commented Feb 19, 2017

@da2x, @ralsina: opinions welcome.

@anderbubble
Copy link
Contributor Author

@anderbubble anderbubble commented Feb 19, 2017

@felixfontein
Copy link
Contributor

@felixfontein felixfontein commented Feb 19, 2017

How about instead having the possibility to customize RSS/Atom feed generation? Like having a signal which passes the XML object, so that signal handler plugins can hook up to the signal and add stuff? That would allow to add such specific things without modifying Nikola core.

@anderbubble
Copy link
Contributor Author

@anderbubble anderbubble commented Feb 19, 2017

@felixfontein
Copy link
Contributor

@felixfontein felixfontein commented Feb 19, 2017

Depends a bit what the signal call passes as its arguments. Passing the XML object and the post list would be a good idea. (You can of course find the posts based on the generated XML, like by using the guid, but that's kind of hacky.)

(There's also a different solution which doesn't require any support in Nikola core: you could monkey-patch the Nikola object by replacing its generic_rss_renderer method by your own function, which does whatever you want. I wouldn't recommend doing that, though.)

@anderbubble
Copy link
Contributor Author

@anderbubble anderbubble commented Feb 19, 2017

@felixfontein
Copy link
Contributor

@felixfontein felixfontein commented Feb 19, 2017

I fully agree. I think it makes sense to provide the signal handler with a list of pairs (post, extended_item) next to the rss_obj (and next to site). That should allow to make modifications very simple.

Regarding iTunes tags: that would only partially work, since you don't know in the signal handler whether this is a feed where itunes == True is passed or not. Also, you'd have to monkey-patch ExtendedItem to actually generate the needed XML.

@felixfontein
Copy link
Contributor

@felixfontein felixfontein commented Feb 19, 2017

(Signal handlers are well suited for changes which affect ALL feeds, not for specific ones.)

@ralsina
Copy link
Member

@ralsina ralsina commented Feb 19, 2017

Sigh. It's a valid issue. I suppose if the post has a guid metadata it could be used, defaulting to what is used now. If it breaks something else when used, you get to keep both pieces :-P

The RSS/Atom generation is unwieldly, and it could be improved, but backwards compatibility is a must. If we change things the wrong way we'll make everyone flood the planets.

@anderbubble
Copy link
Contributor Author

@anderbubble anderbubble commented Feb 20, 2017

While the discussion is happening, can I get the "duplicate" and "wontfix" labels removed from the PR? I'm happy to continue discussing the best way to do this, and learning about signal handlers is probably good; but those labels are vexing me. :)

fwiw, I liked the idea of a signal handler that would receive (post, extended_item) pairs. Can extended_items be edited in-place? I've only used them to append.

@felixfontein
Copy link
Contributor

@felixfontein felixfontein commented Feb 20, 2017

I removed the labels. For your other question: I guess so, but I don't really know. I've never worked with the RSS feed code.

@anderbubble anderbubble changed the title Optionally read rss guid from the post [WIP] Optionally read rss guid from the post Feb 25, 2017
@anderbubble
Copy link
Contributor Author

@anderbubble anderbubble commented Feb 26, 2017

So what's the current thinking? Does this need to become "enhance RSS feed generation to support signal handlers" or is the existing implementation path acceptable?

@felixfontein
Copy link
Contributor

@felixfontein felixfontein commented Feb 26, 2017

The last time someone suggested this feature, it was opposed by the argument that most feed readers ignore the GUID anyway. Since we now have one very specific example where the ability to specify a GUID is crucial (iTunes podcasts), and this fix is very simple and doesn't add much complexity, I suggest the original concerns do not apply anymore. @ralsina, @da2x, @tritium21 (you three opposed the previous PR): do you agree to that? Or do you still have concerns against this?

@Kwpolska
Copy link
Member

@Kwpolska Kwpolska commented Feb 26, 2017

I’m for merging this as-is.

@tritium21
Copy link
Contributor

@tritium21 tritium21 commented Feb 26, 2017

Already merged, but because of the implementation of this version of the feature doesn't break history like the old one did, I have no objection to it.

@felixfontein
Copy link
Contributor

@felixfontein felixfontein commented Feb 26, 2017

(I think the old implementation of this feature also didn't break anything. It added a function to Post to retrieve the GUID and also inserted it into Atom feeds, but its default fallback when the GUID wasn't explicitly specified was also to use the absolute permalink as before.)

@tritium21
Copy link
Contributor

@tritium21 tritium21 commented Feb 26, 2017

I looked at the old implementation....at least the version of it I saw simply swapped the guid from the permalink to a metadata field. That broke stuff. I didn't check, just now, if that was changed in later versions, and I don't remember offhand.

With a use case, and a non-breaking simple change, I cant see a problem

@felixfontein
Copy link
Contributor

@felixfontein felixfontein commented Feb 26, 2017

I just looked in the commit referenced in the old PR: julianbrost@40ba642 That one only uses the GUID from metadata if it is specified there, and otherwise uses post.permalink(lang, absolute=True).

@anderbubble
Copy link
Contributor Author

@anderbubble anderbubble commented Feb 27, 2017

Fwiw, the implementation in #2378 looks better than mine / this PR to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants