Let's make sure folks are seeing unlocked content in email subscriptions instead of a prompt to login.
To reproduce:
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.
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
whenbsub_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. 馃ぃ
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.