@mattab opened this Issue on March 18th 2008 Owner

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?

@mattab commented on July 29th 2010 Owner

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.

https://github.com/piwik/piwik/blob/master/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

@mattab commented on January 17th 2011 Owner

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)

@julienmoumne commented on April 16th 2011 Member

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

@julienmoumne commented on April 25th 2011 Member

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).
@mattab commented on April 25th 2011 Owner

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 ;)

@mattab commented on April 28th 2011 Owner

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

@julienmoumne commented on May 1st 2011 Member

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

@robocoder commented on May 1st 2011 Contributor

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

@julienmoumne commented on May 1st 2011 Member

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.

@mattab commented on May 1st 2011 Owner

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?).

@julienmoumne commented on June 6th 2011 Member

(In [4879]) fixes #2414 refs piwik/piwik-mobile-2#2350 refs #5571 - metadata support for previousN/lastN

@julienmoumne commented on June 10th 2011 Member

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

@mattab commented on November 23rd 2011 Owner

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.

@mattab commented on March 11th 2012 Owner

The implementation could reuse the HTML reports templates.

Also, the &format=html could use this "pretty table" view. Then, the RSS export would use the HTML renderer. This would add 2 new features at the same time (pretty RSS reports, and lightweight HTML embed reports).

Depends on #3031

This Issue was closed on February 19th 2015
Powered by GitHub Issue Mirror