Automatically provide simple RSS export for all Piwik widgets

[matt]

All data is already available though RSS feed. Example: http://piwik.org/demo/?module=API&method=Referers.getKeywords&idSite=1&period=day&date=last10&format=rss The problem is that these feeds provide the "plain data" and don't have CSS, nice colors, etc.

We can export the HTML from widgets output for each day or website requested, and put this html in the rss feed.

The reports could be made available through a RSS link below each widget. The feature could also be made visible in the "Widgets" page, just like users can now export widgets in iframe.

Note: some widgets would disable the automatic RSS conversion as it is not applicable, eg. the Live! widget that shows the latest visits on the website.

During the RSS conversion, all Javascript includes would be removed to only leave the html. To what extent can styles apply? I wonder if the RSS reader keep no style at all, or maybe the inline css?

[matt]

Note: this could/should now use the Metadata API which will return the data ready to be displayed. This would be rather simple to build now! See example how PDF is created.

 http://dev.piwik.org/trac/browser/trunk/plugins/PDFReports/API.php#L181

The interesting API is the metadata API, eg.  http://demo.piwik.org/index.php?module=API&method=API.getProcessedReport&idSite=1&date=yesterday&period=day&apiModule=UserCountry&apiAction=getCountry&format=xml

[matt]

Once we have HTML of all Widgets, we can easily have an option that "Email Reports" can contain HTML as well as PDF (a nice side effet of building this feature)

[JulienM]

I'm going to implement  /trac/ticket/2318 before working on this ticket.

[JulienM]

Before starting development on this ticket I'd like to clarify a few points.

The new RSS functionality departs from the old one by using the Metadata API. Because some widgets may not publish metadata reports, the new RSS functionality can not be applied broadly to all Widget footers.

• Do we agree on dropping RSS as an API response format? If yes, we would do a rss redirect  something like this when an API is called with format=rss.

• RSS icons in widget footers will now be conditionally displayed. Should we query API.getReportMetadata and compare with the plugin name and controller action ? There may be some renaming if they don't match the module and action names in the metadata report. Or is it ok to use (with reversed logic, ie. false by default)

$this->viewProperties['show_export_as_rss_feed'] = true;

• The new RSS functionality will be implemented as a new plugin and will only publish APIs (no new widgets, no new pages).

[matt]

Good analysis.

I don't think we need a new plugin for this functionnality. Let's integrate it in core directly, or CoreHome, or elsehwere..?

OK to drop RSS as a datatable format. Don't bother about RSS redirect, we can simply state the API change in changelog.

Regarding the flag, $this->viewProperties['show_export_as_rss_feed'] sounds good. However, it must be set automatically, based on API.getReportMetadata indeed.

I think that controller.action and API.action all match, but it is well possible that some of them don't. Renaming should be OK (maybe it will remove the widgets from the dashboard, and/or from the PDF/HTML reports already setup, but maybe not). As long as things that 'had' the report before renaming, are not broken by the renaming, it is fine to rename -hope it makes sense hehe ;)

[matt]

Also, see #1664 which has suggestion around proper RSS pubdates

[JulienM]

Should I use the Zend framework RSS builder ? Or are we trying to lessen dependencies to this framework ?

[vipsoft]

If you can use the Zend_Feed module (already in trunk), please do. It's underutilized at the moment (e.g., ExampleFeedBurner).

[JulienM]

I am currently building the API method which will generate the RSS stream.

For normal RSS usages, correct behavior/value for the $date parameter is 'previousX', ie. 1 RSS entry equals 1 complete period.

Should the API allow a less restrictive approach and let the API caller set values for $date ?

In this case, what is the expected behavior if $date equals '05/01/2011' ? Should the RSS stream contain only one (probably partial) report ?

What about date ranges? Should it behave like previousX ? Or should it output only one entry?

My opinion is not to allow $date parameter to be overridden and to fix it to previousX. X being hard coded or configured in global configs.

[matt]

I would agree with your proposal: simple is better. RSS will be used to get updates in the feed reader, so no need to handle past dates (users can use other formats such as XML for past dates).

By default, maybe X can be quite high (50 entries?).

[JulienM]

(In [4879]) fixes #2414 refs #2350 refs #151 - metadata support for previousN/lastN

[JulienM]

(In [4900]) refs #2414 #2350 #151 - fix for bug introduced on json arrays and objects + adding first layer of unit tests

[matt]

There have been good improvements made in #2714 and now, Column names are translated. Still not as pretty as Piwik report, but quite good for RSS as it is.