Kirby3-feed: where to add a xsl file?

Hello! I’m using the plugin kirby3-feed from @bnomei.

Inspired by the About feeds project I want to create a preview for my RSS feed in order to help people who are not familiar with RSS. Here is an example of styled feed.

I need to add a xsl file but as I don’t fully understand how the plugin is working and creating the xml feed, I don’t know where to add the file.

If anyone has an idea on how to manage that it would be great!

Who is requiring a XSL file? From the plugin description, I cannot see this.

The TO wants to add an xsl file to create a styled version of the feed, similar to here for the sitemap: kirby-xml-sitemap/xml-sitemap.xsl at master · pedroborges/kirby-xml-sitemap · GitHub

The template for the RSS feed’s XML is actually a snippet: kirby3-feed/rss.php at master · bnomei/kirby3-feed · GitHub …so you should be able to override that snippet by creating a modified copy in site/snippets/feed/rss.php.

Squeeze in the XSL reference between ?> and <rss on line 3:

<?xml-stylesheet href="/assets/url/to/your/stylesheet.xsl" type="text/xsl"?>

You’d place the XSL file under the according path below your assets folder.

Only caveat: whenever the snippet changes in a future plugin update, you’d have to update your modified copy accordingly.


I’ve tried already to add this line directly in the rss.php snippet provided but it seems the stylesheet is not loading :confused:

I do see the line in the raw xml file though. I thought that maybe I was putting the file in the wrong place but maybe something is wrong with my xsl file. It’s working without problem on another website of mine though.

I’ll look further into that and report here if I find a solution.

Thank you!

Hmm. From a quick glance, your markup seems ok now; the XSL reference tag is correct, the XSL file exists at the indicated location and does not have any obvious syntax errors either… Classic case of “should work” :wink:

My hunch is a MIME type issue. Your feed is returned with the semantically correct mime header of application/rss+xml whereas the most compatible header would be application/xml (see discussions here, for example).

The feed you linked as an example in your first post uses the latter and there this markup works fine (both on Firefox* and Chromium; your feed is offered as a “download” by Firefox and simply displayed as source markup in Chromium – hence my suspicion this may be due to the MIME header).

*Firefox removed RSS support in December 2018, so I’m using the “Want my RSS” extension which applies its own style sheet and ignores XSL unless clicking on the “source” link.

1 Like

It seems that this is it.

It’s weird I did not have to add anything on my other website (Bribes de réel) to make it work (but maybe there was already something there).

I’ve updated my .htaccess to add the following header:
Content-Type: application/xml; charset=utf-8 # not application/rss+xml

It’s now partially working. The CSS does not seem to work but this I think I’ll manage to understand why!

Thank you so much for your time!

1 Like

Sorry I still have one question though.

I’ve put Header set Content-Type: application/xml; charset=utf-8 # not application/rss+xml in my htaccess file (Apache server) at the root of my website.

The preview page of the feed works well but of course it’s breaking the other normal pages of the website because I guess I’ve defined them as xml files too by doing so.

How/where should I set the MIME type only for the feed?

You can set the mimetype in the settings of the plugin or in the options to the feed page method that this plugin provides. See the documentation of the plugin.

The default is null and thus set automatically, e.g. for RSS to application/rss+xml.

Set it to application/xml should work.

If I understood correctly. You are suggesting something like this:

$options = [
    'title'       => 'Luce Carević - Notes',
    'description' => 'Dernières notes',
    'link'        => 'notes',
    'mime'        => 'application/xml'
echo page('notes')->children()->listed()->flip()->limit(10)->feed($options);

I might have made a mistake but it’s still not working.

Two things come to mind:

First of all, it seems that the mime variable that the plugin accepts has to be one of the strings defined in kirby/Mime.php at · getkirby/kirby · GitHub (aka. “extension”, so not the final mime string to be returned in the header but a file type that Kirby then assigns one of those hardcoded mime types accordingly); for reference, this happens here: kirby3-feed/Feed.php at 95975879e51b29cd8575e84f4d479a61aa0900aa · bnomei/kirby3-feed · GitHub

So, in order to force the desired application/xml header, use 'mime' => 'xml'.

Secondly, I am not sure if the approach with echo is going to work here (haven’t tried, and am not familiar enough with the inner workings of Kirby to that degree). Usually, once you call echo PHP already sends some kind of header, so it might be too late to send that modified mime type. If the above fix still doesn’t work you might want to check with devtools what is the return header of your URL and, if it’s not application/xml, maybe try the “virtual page in site/config.php” setup outlined in the plugin’s readme.

1 Like

This solves it!

I indeed had to use ‘mime’ => ‘xml’ in the options to make it work.

Thank you very much.

As @adspectus spotted and pointed out in your follow-up thread, there was a mistake in my earlier answer above:

'mime' => 'xml' indeed leads to a MIME header of text/xml, not application/xml.

However, I agree with the assessment from the other thread, that this should be ok: text/xml is a very common header for feeds (and the RSS spec only refers to the XML spec but does not command a particular MIME type itself)

For instance, serves his using that header, and he must have tens of thousands of RSS subscribers; I’d be comfortable to follow his example :wink:

The MIME header text/xml is still working perfectly so it’s not an issue ! :slight_smile:

For me it’s still the only solution to render the XSL file.