Migrate from Chart module to Charts

This module is totally out of date if not updated to use Googe Interactive Charts.
When the old Chart API will be shutdown by Google, this module will stop working.

following

yes that is true. i am interested in this too.

Marked #2366737: Port to Google Chart Tools as duplicate of this issue.

Which module we should use for charts?

1. Charts - 7000+ installs. Under active development. Support charts: Google Charts, Highcharts.
2. Google Chart Tools - 2000 installs. Under active development. Support charts: Google Charts.
3. Charts and Graphs - 2500 installs. Under active development. Support charts: Flot, D3.
4. Visualization API - 2500 installs. Maintenance fixes only.

Would it be possible to give the users the option to choose which library?

I looked into Charts and even though it may have more installs I found Google Chart Tools much better, as it exposes the Google Chart options and matches the documentation that google provide. Charts only supports a subset of the API (I assume as result of supporting two charting libraries) and I wasn't able to convert the existing charts to match.

The patch I attached also requires small patch to Google Chart Tools to support the AJAX loaded blocks.

Fixed up missing trailing comma on setting arrays.

To whom it may concern: I recently became a new co-maintainer of the chart module. Refer to the related link I just added to this issue for more details about what I'm trying to achieve.

Moving from chart to charts is the migrate approach mentioned in that issue, one of the available options that I seem to recognise in some of the comments in this issue here. What isn't clear to me yet due to insufficient experience with chart and charts (sorry!), is what the "impact" of such migrate approach is. Therefor I'd appreciate if anybody could, at least briefly, answer these questions about that:

1. Assuming the patch(es) in this issue is committed, is it correct to say that existing google analytics reports sites wouldn't really see any impact of it, since basically everything is handled under the cover for them? Obviously, they'd have to swap from chart to charts as module dependency. But are there any scenarios/usages of this module where people might have to do more work themselves also?
2. Would the upgrade approach mentioned in that issue make sense as an option to consider in the context of Google Analytics Reporting? If so, any suggestions about what to yes or no consider as requirements for such upgraded chart module? I've recognised some of the comments in this issue that confirm some of "my" goals detailed in #2368793: Chart 2.0, which is why I ask. In case those goals don't apply in the context of Google Analytics Reporting, but rather for whatever other charting needs, please add your feedback about it, preferably in that issue then.

Last but not least, checkout the Comparison of contributed modules that I created recently, which contains details about other modules available for creating charts. Such as the Forena module, of which I'm a co-maintainer also and which apart from reporting also facilitates charting, using the SVG Graphs library for now (not related to google-whatever).

This module use chart module to display one chart on reporting page and in block. These features are hardcoded so users can't change it without changing code in module. I'm planning to rewrite module and build reports based on Views because we have great Google Analytics Views module (part of Google Analtyics Reports), see #2368151: Build reports in Reports module on Views.

So, the main feature for the chart(s) modules is support Views. Charts module support it. Will Chart module support Views?

@Plazik what's the latest on the charts module support? The chart module was recently marked as unsupported and I'm just starting to look at possible migration paths. Also, charts support is pending support for oauth2 as per #1678306: Add Support for OAuth2 Authentication - correct?

@fenstrat hello, sorry for delay. I haven't time to update this module recently. I've finished about 50% in this issue and I'm planning to finish it as soon as I can.

Anyway you can build your own views reports with Google Analytics Reports Views and Charts modules.

Re #12: that 'was' indeed the case about 20 hours ago, however that is no longer the case. Refer to #2376179-8: Chart 7.x-3.x Release for more details. Which also includes links to other issues with details about how we plan to move forward.

@Plazik No worries, thanks for the update. And yes, migrating to charts does seem like the logical path here. If I get a moment I will try building that view.

@Pierre.Vriens Sorry, I'm not sure what you mean by it 'was' the case. I'd already read 2376179. #2376179-7: Chart 7.x-3.x Release makes it clear that all chart module releases have been marked as unsupported (a decision I'd agree with). https://www.drupal.org/project/chart also demonstrates that - it shows no releases.

The Google Chart Tools: Image Charts module is now officially "unsupported" (see attached).

Needs review for first part of patch (converted Google Analytics Summary page and block into view).

Re #15: please visit the new comments in #2376179-11: Chart 7.x-3.x Release and Refer to #2376179-13: Chart 7.x-3.x Release. Clear enough that chart is NOT unsupported, and that there is again a release for both D6 and D7?

Re #16: that info is outdated again, because of what I wrote in #2376179-11: Chart 7.x-3.x Release.

For the sake of understanding: the temporary "unsupported" status a few days ago happened outside my control (I was not aware of it, and had not been contacted about it by anybody; A pitty, but that's what happened).

PS to Plazik, about #17: Seems like you made a lot of progress! Curiousity: why the dependency on "charts_google" ?

Curiousity: why the dependency on "charts_google" ?

Because it works out of the box.

@Plazik thanks for your work here. Any chance the dashboard block could be kept via a callback that uses views_embed_view()? That wouldn't break the block in a potential 7.x-1.4 release.

@Pierre.Vriens thanks for reactivating the chart releases for now. I'd still agree that a move to charts for google_analytics_reports is a good idea here.

To @fenstrat (Saul), about #20, just to make sure there is no misunderstanding: of course I can understand that, I also think that's a good idea, and I don't have a problem with that, don't worry. Because in the end, "my" goal is "Chart 2.0". Which module namespace is used for that is really not important to me. @Plazik must know where I'm coming from, and it is actually he who was one of the first users to suggest to me to consider becoming co-maintainer of charts also. I doubted at first, but now, a few months later I'm happy I did. I haven't really "contributed" a lot of commits in charts so far, but at least I'm happy with these results I achieved so far:

• Community docu for charts (have you seen it lately?)
• Issue queue triage (at least there is a plan now to get to a new release of charts, right?)

Next on my list is to get that RC1-release finalized, which I had hoped to finish before already. But since in the meantime the chart-deadline has come close, and because it's a fairly lonely adventure (not a lot of help from other contributors, not for charts, not for chart), I've no other choice then to give "chart" the highest priority these days (charts is in good shape I believe, too bad for the rc1-status right now, that will get resolved soon also, after the chart deadline is gone). Recent "reported installs" for charts seem to indicate to me that many users agree with me (I'm waiting for the 10K mark to show up very soon now, would be a great Easter event if it would happen next Sunday, no?).

And then there is Yandix Metrics, who is also moving from 'chart', to 'visualization' (of which I am also a co-maintainer, though I haven't had a lot of time to work on contributing to that module). So with only these 2 "huge" chart users moving away from chart, I start to feel a little more comfortable regarding the remaining reported installs for chart. Though I'm still unsure what the D6 sites are going to end up with (check the chart usage statistics, to understand what I mean). Just so that you know: I do not want to let the D6 sites down, at least not for as long as D6 core is supported.

Also, I can't wait for the day that, because of the upcoming GAR-release, charts is going to take over from chart as it relates to "most reported installs" (because that is what I predict is going to happen ...). Unless people start to realize in the near future what chart 2.0, to me, is really all about: pick from the list charting engines that fit best your needs, either because of features, or because of licensing needs. Just don't expect chart to support Google Charts (the new ones) or Highcharts, because that is what charts is all about (maybe some day we'll consider a module dependency from chart to charts to also support those engines). Makes sense?

Hang on for more roadmap-related docu to show up soon, OK? If you can't wait: part of it I documented already in some recent comments in chart or charts issues.

@Pierre.Vriens thanks for that background info. Our chart(s) usage is very simple at the moment, i.e. just for google_analytics_reports, hence my theory on switching to charts due to the fact that is working now. Unfortunately I've not got the bandwidth to step into the whole chart/charts landscape debate, however I do wish you luck with your roadmap.

The patch in #17 works well for us, but there is an issue with converting the summary page to a view. It removes this critical check.

if (!variable_get('google_analytics_reports_api_oauth_token', FALSE)) {
-    drupal_set_message(t('You must <a href="!url">authorize</a> Drupal to use your Analytics account before you can view reports.',
-      array('!url' => url('admin/config/system/google-analytics-reports-api'))), 'warning');
-    return ' ';
-  }

Because the check is not happening, one sees a cascade of errors when trying to visit the reports summary before authentication.

@brantwynn thank you for bug report, I'll fix it in the next patch.

Here's a dump of the type of errors we see, for those following along. :)

Notice: Trying to get property of non-object in google_analytics_reports_views_plugin_query_google_analytics->execute() (line 237 of ...modules/contrib/google_analytics_reports/google_analytics_reports_views/plugins/google_analytics_reports_views_plugin_query_google_analytics.inc).
Notice: Trying to get property of non-object in google_analytics_reports_views_plugin_query_google_analytics->execute() (line 248 of ...modules/contrib/google_analytics_reports/google_analytics_reports_views/plugins/google_analytics_reports_views_plugin_query_google_analytics.inc).
Warning: Invalid argument supplied for foreach() in google_analytics_reports_views_plugin_query_google_analytics->execute() (line 249 of ...modules/contrib/google_analytics_reports/google_analytics_reports_views/plugins/google_analytics_reports_views_plugin_query_google_analytics.inc).
Notice: Trying to get property of non-object in google_analytics_reports_views_plugin_query_google_analytics->execute() (line 261 of ...modules/contrib/google_analytics_reports/google_analytics_reports_views/plugins/google_analytics_reports_views_plugin_query_google_analytics.inc).

Patch and interdiff attached with the check moved into the views plugin's execute method.

Marking as 'Needs Review' in case there are any automated tests. #20 still applies though. This only fixes #23-#25

Edit: Please ignore patches #26 and #27 - use the patch from #28

And I just realized that #27 was missing the new views file... Interdiff from #26 still applies. Please ignore the other patches for this one.

So I got this working in conjunction with the patch I created at: https://www.drupal.org/node/1678306. It seems to work well. I had to make some changes to this patch based on what was applied there. Not sure how we want to handle it. Basically when applying the other patch and then trying to apply this patch. oauth_token check's need to be "access_token" checks now. The other thing is I just manually removed the page callback that this patch was removing (It failed probably because the other patch is changing "oauth_token" to "access_token"); Other then that I would appreciate you doing the same so we can get both of these RTBC.

I have combined all the patches so it is just one. It will hopefully make it easier for applying so we can get this to dev.

Fixed in #2488754: OAuth & Charts, Integration.

Leaving another note here of my working configuration so others can ensure they are at the right versions:

Drupal Core 7.38
Google Analytics Reports 7.x-3.0-beta2+5-dev
Charts 7.x-2.0-rc1
NOTE: Charts 7.x-2.0-rc1+5-dev (development branch)- breaks the multiple fields (Pageviews, Sessions, etc) on a single chart. So, I had to "downgrade" to the older master branch 7.x-2.0-rc1. This threw me off because all the recent development on Google Analytics Reports module. I was expecting there to be required changes in the development branch on Charts. False.

I looked at both this issue and the #2488754: OAuth & Charts, Integration to catch up and figure out what could be the problem.

This configuration gives outputs like the Google Analytics Reports summary page looks on Plazik's screenshots (as seen in comment #17 above)

Thanks again everyone!

@cthshabel this issue is fixed. Please open other one with your post.