Move Google Analytics to a contrib extension

Development
#1

Hi devs,

I’d like to propose to move the Google Analytics feature into an extension. Several reasons:

  1. It’s not a core feature and thus shouldn’t be in XS by default
  2. Google says On July 1, 2023, Universal Analytics will stop processing new hits. If you still rely on Universal Analytics, we urge you to prepare for the future by completing your move to Google Analytics 4, our next-generation measurement solution., and thus our current implementation will stop working. I don’t know if any core dev will want to work to support Google Analytics 4 and thus it’s best to make it a contrib app where anyone could easily contribute to it.

From what I see the move is not too hard:

  • Move GoogleAnalyticsCode.xml out of xwiki-platform-administration-ui
  • Fix the AdministrationIT test by removing the check for the Google Analytics entry, and ideally add a functional test in the new contrib extension
  • Deprecate the following admin.analytics.* translation keys and add them in the new contrib extension:
    admin.analytics=Google Analytics\u2122
admin.analytics.description=Configure the Google Analytics\u2122 account.
admin.analytics.account.description=To enable page view tracking in Google Analytics\u2122, enter your Google Analytics\u2122 account here. You may enter more accounts (space separated) to track pages in multiple accounts.
admin.analytics.method.description=The tracking method you selected when you created the account.
admin.analytics.notrunning=Google Analytics\u2122 is not running.
admin.analytics.running=Google Analytics\u2122 is running.
admin.analytics.noscript=The application is unable to retrieve the script required to execute Google Analytics\u2122.
XWiki.GoogleAnalyticsCode_method=Tracking Method
XWiki.GoogleAnalyticsCode_method_universal=Universal Analytics
XWiki.GoogleAnalyticsCode_method_classic=Classic Analytics
XWiki.GoogleAnalyticsCode_account=Account

WDYT?

Thanks

1 Like
#2

+1, thank you!

#3

Hi Vincent,

thanks for bringing that up. We recently discussed that with @tmortagne and the outcome of the discussion was more to just get rid of the feature since as you mentioned it will stop working in 2023 and it shouldn’t indeed be bundled in XS.

So I’m +1 that we create a contrib repo if someone wants to contribute to a new extension for GA 4, but I don’t see the point of migrating our existing code there for now so I’d be -0 for that.

Now definitely +1 to remove our current implem of GA from XS. Note that I don’t recall but maybe there’s some templates files that would be impacted too to inject the GA code in XWiki pages?

#4

Note that once it’s contrib, it’s up to anyone to decide what they want to do and there’s no voting by the Core dev team anymore.

The JSX is in XWiki.GoogleAnalyticsCode but it’s onDemand so indeed there must be some place that calls it, but I can’t find it in xwiki-platform.

#5

+1 Thanks

#6

Strangely, on xwiki.org it’s set to be “on this wiki” which explains why it works… So maybe there’s actually a bug in the code :wink:

#7

Maybe that would explain:

:wink:

#8

Seems it’s like this since XWIKI-6579: Make it easier to enable and configure Google Analytics · xwiki/xwiki-platform@29df77e · GitHub ie since XWiki 3.2M3 (Loading...)

1 Like
#9

+1 to get rid of the current Google Analytics support

#10

+1

Thanks,
Marius

#11

I’ve noticed that there’s already an application-googleanalytics extension at GitHub - xwiki-contrib/application-googleanalytics: Google Analytics Embed Extension (see also XWiki Application - Google Analytics Embed Application (XWiki.org)).

It’s an extension that allows embedding GA graphs in wiki pages.

I see 3 options:

  • Option 1: Add a new feature to the application-googleanalytics extension, i.e. the collection of GA stats, and thus refactor the extension into 2 subdirectories (one for the GA collection/registration and one for the reporting part). This means 2 extensions from an XWiki POV but released together.
  • Option 2: Rename the application-googleanalytics extension into application-googleanalytics-reports (or application-googleanalytics-reporting), add a pom EM feature entry, and create a new application-googleanalytics extension for the GA colleection/registration. This means having to re-release application-googleanalytics-reports. I think there’s also the problem with EM upgrades for users who have had the application-googleanalytics extension installed.
  • Option 3: Add a new repo and don’t touch the existing application-googleanalytics one, using a suboptimal name. For example: application-googleanalytics-tracker or application-googleanalytics-collect or application-googleanalytics-registration or …

The main pro for option 1 is to have everything related to GA in one place. The main con for it is that I don’t know the status of the current code for the reports and I’ll release a new version for the code moved.

Option 2 is simpler and probably cleaner vs option 1 but I think it can cause problems with EM.

Option 3 is by far the simplest but with a suboptimal extension/repo name.

Any preference?

Thanks

#12

I think I would go for option 1: worst case scenario you release it and the reporting does not work anymore (but I guess it means it was already not working anymore on recent versions of XWiki) and we’ll need to release a bug fix for fixing it (which is good meaning we’ll fix it).

#13

The age of the extension does not give me much confidence on its working status, but it does have 4 active installs…

-1 for that, stealing the ID of an existing extension for something completely different is a very bad idea

I would suggest something like Option 2 but without reusing the old ID: just refactor GitHub - xwiki-contrib/application-googleanalytics: Google Analytics Embed Extension to have two extensions ( application-googleanalytics-reports/ with the old one as feature and application-googleanalytics-tracker/, or some other names) instead of one.

#14

I think the tracking and the chart features are really quite different features. Therefore, I’m -0 for 1 and +1 for 3 and +1 for the option suggested by Thomas.

#15

I’m also fine with Thomas suggestion, provided that you document on the extension page the extension moved.

#16

ok, that’s option 1 actually.

Now @MichaelHamann says -0 for option 1 yet he says he’s ok with the option suggested by Thomas :slight_smile: Could you confirm you’re ok with it? Of so, it seems the 3 of you are in agreement about option 1.

#17

So I guess the question is whether to use the same GitHub repo (option 1), and thus the same version (released together) or to use 2 separate repos (option 3) and thus have different versions (released separately). I’m slightly more for option 1.

Thanks,
Marius

#18

yep that’s exactly the question, thanks for phrasing it more simply :wink: Released together, yet with 2 different extensions so that users can install only the extension they need.

#19

Ah, I think I misunderstood this here, I thought the idea was to have two different repositories… I don’t see that these two extensions will have much in common but anyways, if you want to have them both in one repository, why not.

#20

I’m also +1 for two separate extensions and repositories, and +0 for a single repo for both extensions.