Wp-calypso: Earn: Investigate if premium content is being delivered to paying subscribers

Created on 2 Jun 2020  路  12Comments  路  Source: Automattic/wp-calypso

Let's make sure folks are seeing unlocked content in email subscriptions instead of a prompt to login.

83557077-dc508b00-a4c5-11ea-96c4-3981b9e2968d

To reproduce:

  1. Setup a recurring payment plan
  2. Add a premium content block to a page or post with some text in the subscriber view
  3. In Earn > Recurring Payment settings Toggle the checkbox to email newly published posts.
  4. As a different user, subscribe to the plan and check the box in stripe to opt-in to updates.
  5. As the first user publish a new post with a premium content block

Expected: The second user recieves an email with an except of subscriber content
Actual: The second user recieves an email with a prompt to subscribe or login.

Earn [Type] Bug

Most helpful comment

Turns out the reason its not working in production is because when the premium content block looks up the logged in users memberships subscriptions, none are returned so the user isn't given access to the premium content.

The reason no subscriptions are returned is because we are sandboxing payments (when subscribing) so the subscriptions are being stored in test tables. When the job runs in production, the test tables are not queried so it appears as though the user has no subscriptions.

All 12 comments

I tried to replicate this by manually sending the email from my sandbox (using testing instructions from https://github.com/Automattic/wp-calypso/pull/42544) and verified I can see the subscriber content.

However, when the email is sent normally in production, the content is not visible.

My guess is that the "is the user logged in" check is giving different results depending on the environment (true when sending manually the email on our sandboxes, false in production) so likely we'd need to remove that check if WPCOM_JOBS is defined. However I have no idea about how to test that.

cc @eoigal

Ok, I think I found a way of replicating the issue while sending the email from my sandbox. There is a subscription/send.php script we can use:

php bin/subscriptions/send.php <BLOG_ID> post <POST_ID> <EMAIL>

When I run that using my test site, a post containing a premium content block and the email of a subscriber to the plan selected in the premium content block, I get an email with the subscriber content not visible. Let's see if removing the logged in check fixes anything.

On a second thought, I actually think the issue is caused by the current user not being set to the subscriber when the async job sends an email (at least, couldn't find anything while looking at bsub_email_child_send_post_to_subscribers and Subscription_Mailer->send_post). That means that the offline subscription service is likely getting a user that cannot view the content.

I wonder if WPCOM_Offline_Subscription_Service should try getting the user in different way when WPCOM_JOBS is true or if the bsub_email_child_send_post_to_subscribers async job should switch to the subscriber with wp_set_current_user before calling Subscription_Mailer->send_post.

Ah man, I've _fixed_ this twice already!

I actually think the issue is caused by the current user not being set to the subscriber when the async job sends an email

I have testing instructions in this PR that _should_ have run the same code via the jobs to verify that the current user is set to the subscriber.

The current user _should_ be set when we check Blog_Subscription::user_can_view when bsub_email_child_send_post_to_subscribers is run in a job.

I have testing instructions in this PR that _should_ have run the same code via the jobs to verify that the current user is set to the subscriber.

@eoigal, I ran those steps, but it didn't work for me -- I didn't receive any email.

Update: I reran it and it worked...

The current user _should_ be set when we check Blog_Subscription::user_can_view when bsub_email_child_send_post_to_subscribers is run in a job.

Oh right, didn't notice that. Then yeah, both current blog and user should be set when the job is running. Not sure what's going on then in production, anything I try in the sandbox works as expected 馃槙

While testing, the email sent automatically via the job did not contain the premium content, however when I ran the job manually the premium content was included.

I'm not sure on what the difference could be. Either the user isn't logged in or the WPCOM_JOBS define isn't set in production, which would mean the offline subscription service is unavailable.

Would it be worthwhile to check in a piece of code to logstash the global/local vars when a specific email address is used? I can't seem to see a good way of debugging this currently.

Snap Brent! D44504-code

Turns out the reason its not working in production is because when the premium content block looks up the logged in users memberships subscriptions, none are returned so the user isn't given access to the premium content.

The reason no subscriptions are returned is because we are sandboxing payments (when subscribing) so the subscriptions are being stored in test tables. When the job runs in production, the test tables are not queried so it appears as though the user has no subscriptions.

I created a new test website that is connected to a real stripe account. Created a plan on live tables and tested receiving an email with premium content and it worked.

You can try by using a real credit card here if you wish - https://eoinlivefse.wordpress.com/2020/06/05/sign-up/

Create a new post with premium content with the same plan and you should receive the email with premium content rendered.

You beat me! I was just about to update too. 馃ぃ

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kellychoffman picture kellychoffman  路  3Comments

aduth picture aduth  路  3Comments

samouri picture samouri  路  3Comments

kellychoffman picture kellychoffman  路  3Comments

ehg picture ehg  路  3Comments