Remove the page for RSS settings

[jenlampton]

Once the front page and the taxonomy/term/% pages have been replaced with views, we'll need to remember to remove the page for RSS settings, since these won't be used anymore.

Also related:
#668 RSS Settings don't save
#151 Replace listings with views

---

PR by @BWPanda: backdrop/backdrop#3057

[docwilmot]

Why will that not be used anymore?

[quicksketch]

The three options on that page:

• Feed description
• Number of items in each feed
• Feed content

All three of those are options within Views. Although we could potentially keep them and use them as default values, having settings that conflict with the View configuration would probably cause more confusion than it would be helpful.

[docwilmot]

Hmm. To my mind settings like those should have a form. Fiddling with the view feels like hacking core, if you know what i mean.
A form with a link that says "to change the advanced settings edit the view directly"
But I'm probably nitpicking here.

[jenlampton]

How often have you actually changed these settings on a site? It's way more common that people just adjust the view(s) they need changed. Having two UIs for the same thing could be very confusing.

[klonos]

I'm with Jen and Nate on this one.

What @docwilmot is talking about here is some sort of separation of the views settings UI to simple/advanced. This could eventually happen in a future version of Backdrop/views, but this will take a lot of time/resources/effort and we'll need to put a lot of thought into it. I don't think we should complicate this right now when we need to focus on getting the rest of the major features in.

[MrHaroldA]

Is removing the settings page enough, or should all traces of RSS/Syndication be removed from Backdrop core, as that is Views' task now?

• rss.xml page callback
• RSS node links
• Syndication block
• Comment RSS support
• RSS/Syndication tests
• format_rss_channel()
• format_rss_item()
• Etc

[quicksketch]

Hi @MrHaroldA! I think what we're trying to accomplish here is replacing all the built-in RSS feeds with views, making this settings page unnecessary. So if the page/function is no longer necessary because it's been replaced by a View, then yes we may remove it. Note I think we'd keep the Syndicate block, as it is only an icon linking to rss.xml (which will eventually be a View).

[MrHaroldA]

Note I think we'd keep the Syndicate block, as it is only an icon linking to rss.xml (which will eventually be a View).

But that should be dependent on whether the RSS view/display/attachment is enabled; so I guess the hardcoded Syndicate block must go to in favor of a block display in Views?

[quicksketch]

But that should be dependent on whether the RSS view/display/attachment is enabled; so I guess the hardcoded Syndicate block must go to in favor of a block display in Views?

The syndicate block could load the view check if the RSS view is enabled and only show up if this is the case. Or perhaps better it could simply check if any module made a menu entry at rss.xml and toggle on that. I don't think making the block itself a View would be necessary.

[ghost]

Here's a PR: backdrop/backdrop#3057

[klonos]

LGTM 👍 ...when we remove paths/menus, don't we usually put a redirect in place? Should we be redirecting to /admin/structure/views/view/promoted/configure/feed or something (if that view is enabled)?

[ghost]

Tests are failing. Not sure what to do exactly, as it seems to disable the Views module to run these RSS tests (in Node module). Does that mean it's using the non-Views RSS feed?

[kbahey]

Please see #1583 for a fix that makes the RSS settings work with a default installation, without views for the front page ...