I think that the statistics reporting should become its own module, leaving Google Analytics API a pure API + authentication to be required by various modules ala Token, Date API etc. The statistics module could be its own project on Drupal.org.

Please discuss what should go where...

CommentFileSizeAuthor
#5 ga_api_gui.patch548 bytesjurgenhaas

Comments

jkitching’s picture

jkitching commented
Status: Active » Closed (fixed)

Hi,

I have split the API and the GUI into separate modules.

I'm not sure I agree that they should be separate projects on Drupal.org, at least at this point in the project's maturity. If a ton of people start using the API for a myriad of different functions then I could see creating a new project, but for now the vast majority would probably only be using it for the built-in GUI functionality.

rickvug’s picture

rickvug commented
Status: Closed (fixed) » Active

Thank you for separating the functionality. I like how the API module no longer has any dependencies. This seems much more logical to me.

I notice that the "access Google Analytics data" permission is part of the API module rather than the implementing stats module. Is this by design? Having the module be a pure API that also handles authentication would be best. Let the implementing modules worry about user facing permissions. A permission should be available for setting who can make changes to authentication settings. Alternately, you could piggyback on system module's general "administer site configuration" permission.

As a separate issue that may be related, I get the following new error when visiting /statistics:

Fatal error: Call to undefined function google_analytics_path_report() in /home/vughosting/public_html/drupal6-cluster1/public/sites/rickvug.com/modules/google_analytics_api-HEAD/gui/google_analytics_api_gui.module on line 428

This is on a clean checkout of CVS head from 15 minutes ago. If this is not a side effect of the transition let me know as another issue should be filed to track.

Finally, I understand where you coming from about the module still being in the early stages in life. In the longer term, I could see numerous modules depending on the API module but not requiring the stats. Separate projects would be best IMO. There are cases like date where an API module ships with implementation but this just seems different to me (not as closely coupled conceptually perhaps). Maybe it would be best to see if anyone else voices an opinion here.

For the short term, I'm wondering if we can come up with a better name than "Google Analytics API GUI" as this is really a Google Analytics statistics reporting module that requires Google Analytics API, rather than a GUI for the API itself. Maybe "Google Analytics Statistics"?

jkitching’s picture

jkitching commented

Hey Rick,

Thanks for pointing out the syntax error. It should be fixed now.

We can discuss the rest of the things in your bug later on.

Joel

rickvug’s picture

rickvug commented

I can confirm that the statistics functionality is working again. We can discuss the rest of the longer term slit issues at a later date when you are back in town.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented
StatusFileSize
new ga_api_gui.patch548 bytes

Looks like the hook_perm is missing in the outsourced GUI module. See attached patch to fix it.

jkitching’s picture

jkitching commented
Status: Active » Closed (fixed)

Hey jurgenhaas,

Thanks for the patch and the heads-up. I actually just caught this bug and fixed it when I did some restructuring yesterday. I renamed the "Google Analytics API GUI" module to "Google Analytics Reports", and added the lines

/**
 * Implementation of hook_perm().
 */
function google_analytics_reports_api_perm() {
  return array('access Google Analytics reports');
}

and renamed the permission of the core API module to 'administer Google Analytics API settings'. I think this provides a bit looser coupling between the two.