Premium Content: Paid subscribers unable to access subscriber content several days after publication

[pauljacobson]

Quick summary

One of our customers has reported that some of their subscribers are unable to access paid content despite having current, paid subscriptions on the site. Our customer pointed us to this post as an example: https://ejmagnier.com/2022/10/20/will-china-challenge-the-us-unilateralism-and-expands-beyond-its-great-wall/

Steps to reproduce

1. The affected subscriber signs into WordPress.com and browses to https://ejmagnier.com/2022/10/20/will-china-challenge-the-us-unilateralism-and-expands-beyond-its-great-wall/
2. The subscriber sees the option to Log In to view paid content, and clicks on the button to do so
3. The post reloads with a token added as a parameter on the post URL but the user doesn't see the paid content as you can see in this demo:

Capture_2022-10-25.at.16.38.32.mp4

• This particular demonstration was created using a browser with built-in ad blocking. I reproduced the issue in Chrome with no content blocking enabled too.
• I also checked the configuration of the Premium Content block, and didn't see any indication of an issue affecting subscriber content. See here for a demonstration of what I saw.

What you expected to happen

A paid subscriber should be able to view paid content when visiting a site with paid content, even if they have to click to Login to verify their access.

What actually happened

Aside from the paid content not loading, I also noticed that the page itself doesn't load the paid content. Here is an example of the HTML that loads after clicking the Login button: 2dfdf-pb/

Context

This was a customer report in 37247184-hc with a follow-up in 5657564-zen

Platform (Simple, Atomic, or both?)

No response

Theme-specific issue?

Unclear although the site has a number of subscribers, most of whom seem to be able to access the paid content.

Browser, operating system and other notes

I don't have information about the affected customers' operating systems and browsers.

I tested this on macOS 12.6 using Vivaldi 5.5.2805.38 (Stable channel) (arm64) and Chrome Version 106.0.5249.119 (Official Build) (arm64)

Reproducibility

Consistent

Severity

Some (< 50%)

Available workarounds?

No response

Workaround details

No response

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 5657564-zen
• 5635700-zen
• 5714293-zen
• 5837277-zen
• 6030390-zen
• 6558782-zen
• 7092650-zen

[cuemarie]

A site owner reported a similar problem that one of their subscribers is having here: 37667615-hc

Details they provided about their subscriber who cannot access the content:

based in Japan, using a Japanese credit card in JPY

she cannot access the content despite purchasing a membership and using the login button in the block. Out of the 16 subscribers so far, this is the only subscriber who reported this issue

I suggested to her that she log out of Wordpress, accept cookies from wordpress.com, and retry logging in from the Premium Content block's login button. She did all of that but was unable to access the content yet again.

She then cancelled her current subscription, purchased a new subscription, and was able to view the content. However, after leaving the site and returning, she encountered the same issue where she was unable to access the content.

No follow up needed here for now. I gave the site owner some recommended next troubleshooting steps (testing alternate browser, device, network) and they will report back if they need further assistance.

[cuemarie]

Similar issue is (maybe?) being looked at here: #68506

Though the details there are more specific to the first 24 hours after the monthly subscriptions renew.

[Copons]

Thanks for reporting!
I've added this to Ajax's backlog, but just to frame the expectations: at the moment we are completely swamped and cannot prioritize Payment Blocks issues. 😓
We'll try to take a look as soon as we physically can.

[pauljacobson]

It looks like we have another report here: 5635700-zen

[jamiepalatnik]

📌 SCRUBBING : RESULT

• Did not test since the issue has no steps to replicate on a test site or with a test user.

📌 FINDINGS/SCREENSHOTS/VIDEO

• The issue seems to be a report for a specific user, with no steps to replicate on a test site.
• Keeping the issue open since this comment shows it has been added to the Ajax backlog.

📌 ACTIONS

• Marked as Triaged for Quality Squad review

📌 Message to Author

• @pauljacobson If you have steps to replicate for a test site, please feel free to add them to the issue. If you are not able to replicate on a test site, consider reporting the issue through internal channels instead of GitHub. Thanks!

[pauljacobson]

Hi @jamiepalatnik

The challenge with this issue is that we haven't been able to reproduce it. At the same time we have received multiple reports from multiple users.

We have had a discussion about this internally and haven't been able to make much progress there.

[jamiepalatnik]

The user replied in 5714293-zd-woothemes to share these details:

I think I found the problem.
You may be blocking subscribers if they attempt to log in from a different location than the country they registered from.
I travel a lot and discovered that’s when you block me.

I let them know I would share these details with our team to investigate further.

[sajmes]

Another report from the same user as this comment above: #69427 (comment)

Chat: 38070585-hc
Follow up: 5837277-zd-woothemes

• Tested using Chrome and Safari
• Affects only a single subscriber (chat has username of the user in notes)
• Based in a single location
• Could see the Premium Content up until Jan 3 2023
• I cannot replicate while SU into the subscriber's account - I see the Premium content

I asked user to have their subscriber try incognito mode to rule out extensions and other browser issues.

[filipanoscampos]

Just adding that the user from the comment previous to mine is concerned this is taking so long to address given this is related to paid subscriptions.
Do we have any developments we can share with this user, @Copons?
Thanks in advance.

[ClassicRKR27]

Update on 5837277-zd-woothemes

They said that the user went back to their original location/network and was still not able to access the content, so they don't believe that location is an issue here.

They also said that the user was only able to see the content after cancelling their subscription and re-subscribing, and they're reporting that some other accounts are showing as duplicates in the dashboard (they did not provide details of which ones).

[Copons]

FYI, we are talking about this internally at paYJgx-2OB-p2, trying to find a good team to own this.

[dsas]

Update on 5837277-zd-woothemes, FAO @ClassicRKR27, @filipanoscampos, @pauljacobson, @sajmes

On at least two pages using premium-content on that site, the premium-content block is using a button block to link to the login page, rather than the special login button block which is inserted when adding a premium-content block.

I don't know how this happened, I can't reproduce it happening myself. My guess is that this is a change the user has made either deliberately or accidentally.

Using the proper login block (by reinserting the premium-content block and cutting and pasting content into it) should fix the issue where people don't have access to the premium-content if they have cleared all cookies or are logging in on a different device. It won't fix any other issue.

See also p1673547301964119/1673521153.034619-slack-C02FMH4G8

[dsas]

Using the proper login block (by reinserting the premium-content block and cutting and pasting content into it)

An easier way to do this is to remove the children of the Premium Content buttons block which will make the original buttons reappear

MdGwio.mp4

[Copons]

An easier way to do this is to remove the children of the Premium Content buttons block which will make the original buttons reappear

I haven't tested this, but note that the "respawned" Payment Button block might not be associated with the same product/subscription as before (IIRC newly created Payment Button block automatically get the most recent product).

At the same time, the Premium Content block does plenty of magic with subscriptions (i.e. I can't remember if the subscription is associated with the Premium Content and inherited by the Payment Button, or the other way around), so I might be incorrect.

To be on the safe side, when suggesting this workaround, we should ask the user to note down the original subscription used by their Premium Content block and, if needed, reselect it on the new blocks.

[dsas]

I have tested it and it worked for me, no harm in caution though.

The premium content has the planId and passes it down to the payment button but it's stored in both as an attribute.

[jamiepalatnik]

A similar issue in this ticket: 6030390-zd-woothemes

Suggested that the site owner could ask the subscriber to cancel and resubscribe as a potential workaround, based on this comment. Also suggested they could try replacing the Premium Content block as a test.

[dsas]

Looking at the page mentioned in that ticket, it looks correct right now.

I can repro that on that page 😢 by following these steps:

1. In Firefox click the login button
2. This redirects you back to the page with the log-in button now removed
3. In Chrome do the same and then hit subscribe (at least I think I logged in first)
4. Go through the subscribe process in Chrome
5. Chrome now shows the subscriber only content
6. Refresh in Firefox, I still get the 'Subscribe' button
7. Check in cookies and both have jp-premium-content-session cookie set to the same value

[dsas]

Though if I then clear my jetpack.wordpress.com, public-api.wordpress.com and the sites cookies, and then refresh and press login, it does work 🤔

[csabarakasz]

same issue: 6558782-zd-woothemes

I am suggesting to remove the block and re-add the content.

[dolgelukkig]

Here is another one -7146430

[poeticabdul]

Reported here 7092650-zen

[lsl]

#68506 and this issue might be related.

@dsas would you like to look at trying to reproduce this issue again? Wondering about site timezone settings and whether they effect subscription start/end times and the jp premium cookies we set. https://github.com/Automattic/jetpack/blob/065013cb4f2d01c174ac430acf7a7b43b788d487/projects/plugins/jetpack/extensions/blocks/premium-content/_inc/subscription-service/class-abstract-token-subscription-service.php#L558 (The strtotime sticks out as something that should be gmdate but I don't know if that would be an issue here or not)

Caching might also be something to check.

[dsas]

I'll take a look again now that I'm not in UTC. I don't think that changing that line to gmdate will fix the problem though, for two reasons.

• Given our servers work in utc, then strtotime ought to be operating in utc already, but I don't know off-hand how the site tz setting affects this
• If "several days" is accurate then it seems odd that a matter of hours is the problem

[dsas]

I'm struggling to repro this, I can't even repro on my test site using the steps I used before which assumed a user subbed in one UA and then tried to access in another UA.

T-Rex worked on the block editing interface and admin experience. I am only familiar with how any of the payment stuff works for users through spending hours trying to debug this issue - which I've clearly not been very successful at :)

@Automattic/gold it looks like you've been active on similar issues recently, any chance you've resolved this issue already since it was last reported in 2023?

[millerf]

Closed with https://github.com/Automattic/gold/issues/36