fix(content-gating): account for block visibility in GA4 params

[dkoo]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Takes visibility of important blocks into account when setting relevant GA4 params related to membership content gates. Previously, a content gate was said to "have" Donate, Registration, or Checkout Button blocks if its post content contained those blocks. Now, it will "have" those blocks only if the blocks exist in the DOM inside the content gate container, AND they're visible in the DOM (not hidden by CSS).

Closes 1200550061930446/as/1209574433088705.

How to test the changes in this Pull Request:

1. Check out this branch.
2. Set up a site with Google Analytics + RAS + Woo Memberships with a metered regwall + paywall setup (DM me for instructions on how). The important thing is that the Non-Member Content block shown to anonymous readers contains one or more of the Donate, Registration, or Checkout Button blocks, and the Member Content block shown to registered readers contains the others of those blocks.
3. As an anonymous reader, visit a post that will show the regwall part of the content gate. In Dev Tools > Network look for a collect XHR request that contains a payload that looks like this:

Note the highlighted part of the payload, and confirm that the gate_has_donation_block, gate_has_registration_block, and gate_has_checkout_button params are accurately set to yes or no based on which of those blocks are visible within the content gate.

4. Register to pass the regwall and view more posts until you see the paywall content gate. In Dev Tools > Network look for the collect XHR request and confirm that its payload is accurate based on which blocks are visible in the content gate.
5. Also check the value of window.newspack_memberships_gate.metadata in the JS console. The parameters here are calculated in the back-end, and should match the values of the front-end parameters most of the time.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1209574433088705

[leogermani]

I believe this is also used by back-end events... maybe we need to keep things here and override on the front-end... but for the back-end events we would actually need to see how that conditional blocks are rendered to find out what values to set

[dkoo]

Ah, I didn't see that the back-end events were actually using this. Maybe we can avoid recreating the Memberships blocks' logic by checking their render output.

[dkoo]

2f117da adds a check in the back-end method, too. We don't get innerBlocks if a member or non-member block won't render any content.

[dkoo]

@leogermani this could use another review

[leogermani]

@leogermani this could use another review

Tomorrow, I promise

[leogermani]

I'm afraid this didn't work for backend events and it might be trickier than we thought:

The front-end event sent from a "non members" block that had only a Newsletter Subscription block looked right. It was not considering the "Checkout button" element that was behind the "Members only" block.

But the respective back-end events were different:

[20-Mar-2025 18:11:53 UTC] [448]  [NEWSPACK-DATA-EVENTS-GA4][Newspack\Data_Events\Connectors\GA4::log]: Event payload: {"client_id":"615855095.1742494201","timestamp_micros":1742494308000000,"events":[{"name":"np_gate_interaction","params":{"logged_in":"yes","ga_session_id":"1742494201","author":"leogermani","categories":"News","is_reader":"yes","email_hash":"36d345fd6087159ecffc9e71cb2049dd","is_newsletter_subscriber":"no","is_donor":"no","is_subscriber":"no","gate_post_id":"1131","action":"form_submission_received","action_type":"registration","referrer":"","referer":"","order_id":"","product_id":"","amount":"","currency":"","gate_has_donation_block":"no","gate_has_registration_block":"no","gate_has_checkout_button":"yes"}}],"user_id":"o7MZbOGC9tEH"}

...

[20-Mar-2025 18:11:53 UTC] [448]  [NEWSPACK-DATA-EVENTS-GA4][Newspack\Data_Events\Connectors\GA4::log]: Event payload: {"client_id":"615855095.1742494201","timestamp_micros":1742494308000000,"events":[{"name":"np_gate_interaction","params":{"logged_in":"yes","ga_session_id":"1742494201","author":"leogermani","categories":"News","is_reader":"yes","email_hash":"36d345fd6087159ecffc9e71cb2049dd","is_newsletter_subscriber":"no","is_donor":"no","is_subscriber":"no","gate_post_id":"1131","action":"form_submission_success","action_type":"registration","referrer":"","referer":"","order_id":"","product_id":"","amount":"","currency":"","gate_has_donation_block":"no","gate_has_registration_block":"no","gate_has_checkout_button":"yes"}}],"user_id":"o7MZbOGC9tEH"}

What it seems to me is that by the time the backend event is fired, the user is already logged in (it logs in as part of the registration process), and then the calculation there takes this into account.

This might need a deeper conversation

1. Let's review backend events? Are we really using them? Do they have the valyue we thought they had?
2. Do we really want to change this behavior... as we pointed out, we do have the "is_logged_in"
3. I noticed that apparently the front-end events do not include some info present in the backend events that will allow for more granular filtering. For example: logged_in, is_reader, is_newsletter_subscribed, etc... I think we should try to include those