Per-page analytics aren't visible in Wagtail 2.0

[alexgleason]

Looks like this:

isn't showing up.

Glancing at the code, is that part being generated by JavaScript? If so I think it's a bit fragile since updating the front-end would cause it to break. It may be worth adding an extra hook into Wagtail, maybe to override settings_panels

[tomdyson]

Yes, it's definitely fragile. A new hook would be perfect.

[alexgleason]

Hi Tom, I started on this. My progress is here: https://github.com/tomdyson/wagalytics/compare/master...candlewaster:hook?expand=1

Instead of allowing arbitrary HTML to be added to the end of the settings panel, I'm envisioning that people would use a hook to insert FieldPanel/EditHandler instances wherever they want in the panel, then return that. I'm trying to rely as little as possible on the CSS and HTML staying the same between Wagtail versions.

So, I've added an AnalyticsPanel to the code. Without the aforementioned hook, I'm testing this out by adding it manually to one of my pages, like so:

settings_panels = Page.settings_panels + [
    AnalyticsPanel()
]

Any chance you could help with the Python GA API? The JS code that gets the 24 hour views would be in Python now, but I'm really bewildered about how GA actually works. The code would go here.

More about the hook: My code assumes there is a new hook called transform_settings_panel which takes in a settings_panel and a page as parameters, and returns a transformed settings_panel for that page. The hook would take affect in Page.get_edit_handler() if implemented in Wagtail. I think this is the right approach because, like I mentioned, it doesn't need to rely on the HTML or CSS staying a certain way between Wagtail versions.

[tomdyson]

Hi @alexgleason. I agree, it's bewildering! All my code uses JavaScript, with a Python view for the initial authentication step. It looks like the Python API has changed since I wrote this. There are now some good examples at:

https://developers.google.com/analytics/devguides/reporting/core/v4/quickstart/service-py

The plain REST reference is also useful - you may prefer to use this (e.g. with the Requests library):

https://developers.google.com/analytics/devguides/reporting/core/v4/basics

Annoyingly, it seems you now need to provide the 'View ID' for all reporting queries. We could document this step - probably after "4. Find the ID for your Google Analytics property" - or look it up using the Management API...

https://developers.google.com/analytics/devguides/config/mgmt/v3/mgmtReference/management/accountSummaries/list

Re your hook: how about transform_panel, with the first argument as the name of the panel, e.g. 'settings_panel', so we could use this hook to transform any panel? Perhaps this could even create a new panel, if you provide a name for one that doesn't exist yet (e.g. 'analytics')?

[Squarehost]

For a quick fix for Wagtail 2.0 the wagtail_hooks file needs line 65 changing from $('#settings ul[class="objects"]').append(html_results); -> $('#tab-settings ul[class="objects"]').append(html_results);