site-kit-wp: AMP plugin compatibility: Analytics error when AMP Analytics is configured

Bug Description

When using the Analytics section of the AMP plugin:

AMP plugin Analytics

Attempting to connect Analytics via Site Kit causes the following error:

Site Kit Analytics error with AMP Analytics

Occurs when using all modes of the plugin: Standard, Transitional, Reader

Steps to reproduce

  1. In the AMP plugin, configure the AMP > Analytics section
  2. Attempt to connect Analytics in Site Kit
  3. Go to the Site Kit > Analytics page
  4. See the Site Kit error

Screenshots

Additional Context

  • PHP Version: 7.3.16
  • OS: MacOS
  • Browser: Chrome
  • Plugin Version: 1.9.0
  • Device: MacBook Air
  • AMP plugin version: 1.5.3

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

  • There should be no errors during the Analytics setup (except the potentially expected user-facing error that they don’t have access to the existing tag) when the existing tag extracted from a URL snippet is not a valid property ID.
  • In such a case, the existing tag should be ignored, since Site Kit cannot assume anything here.

Implementation Brief

  • Return null in hasExistingTag() if an existing tag for Analytics has an invalid PropertyID.
  • Merge #1760

QA Brief

Changelog entry

  • Fix bug where placing an invalid Analytics tag through another plugin could cause the Site Kit Analytics setup UI to break.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 15 (6 by maintainers)

Most upvoted comments

My thinking is that saying that we found a tag but that it isn’t valid is a more flexible approach, but that’s a good point. I’ll adjust it so that any invalid tag is simply treated as not returning a truthy value from hasExistingTag.

I original thought about your proposed idea but wanted to see if I could provide a warning without too much effort. But I like the idea of it just saying an invalid tag is the same as no tag, so I’ll adjust the IB. 👍

The error is actually that we consider an invalid tag an existing tag on the site. I suppose this is fair, but it’s a bit odd that an invalid ID (that presumably won’t cause Analytics events to fire) is flagged as an existing tag. Weirder is that we weren’t verifying if the tag was valid before setting it, so we’d end up with 404s for a tag with invalid characters and invariant errors trying to set the invalid tag—because we do validate the tag on set, but not on receive.

The fix here should be to check that the existing tag is valid before limiting user interaction to the existing tag and showing an error when it’s invalid.

Also, we’ll want to have checks on disabling the account/profile select for only a valid, existing tag or we’ll wind up with this situation:

Screenshot 2020-07-10 at 18 39 51

Hmm, sadly I tried to replicate the issue with the steps and code provided here but I couldn’t get an error. I used that JSON and got no error.

@ernee Could you record a screencast of exactly what you did to get the error so I can follow the steps and see where it is? I feel like I’m missing something here because I’m not able to reproduce.

Hi @tofumatt ! So I was able to replicate the error with the tester plugin’s develop branch. Here’s the JSON I entered (note the trailing > character after the first Tracking ID):

{
    "vars": {
        "gtag_id": "UA-XXXXXXXXX-1>",
        "config": {
            "UA-XXXXXXXXX-1": {
                "groups": "default"
            }
        }
    }
}

@ernee I was able to reproduce this using the JSON in the example, however from what I’ve read in the AMP analytics documentation. I think that the issue may be that the gtag_id in the example contains a typo and is including a trailing > character.

When I remove that character, I no longer get the Site Kit error but rather am correctly seeing the user-facing error that the ID is not associated with my account.

Can you confirm that the JSON is correct, please?