Plans view doesn't reflect my current plan

[MichaelArestad]

When I added the pro plan, the view didn't update to reflect it even upon refresh:

Steps to reproduce the issue

• Upgrade site to pro
• go to Plans view in wp-admin

[samhotchkiss]

I had this happen to me as well, but I haven't been able to reproduce-- it's a caching issue somewhere.

Moving it out of existing milestones until we can come up with steps to reliably reproduce

[beaulebens]

@MichaelArestad did this ever update/refresh for you? I haven't been able to reproduce this on any of my test sites. If you're not seeing it any more, let's close, and we can always open a new one if we get a reproducible case.

[MichaelArestad]

Let's close for now.

[jeherve]

Reopening since this is still happening in multiple places.

This happened to me when testing #5603, for example.

[jeherve]

Another report from @lschuyler:

This testing site was moved to SiteGround in the last week. They install a SG Cache plugin. I’ve disabled it.
Decided to cycle the connection. I disconnected Jetpack, and when I try to reconnect I’m getting a “Are you sure you want to do this? Please try again” message.
Tried twice, same message. Then exited out of the dashboard, re-logged in, then reconnected Jetpack, and I see that I’m on the Professional Plan in Calypso, but when I go back to the dashboard, still Upgrade buttons.
clicked the “Reset Options” link. No change.
switched from Chrome to Safari – works!!

So it was the browser cache all along? Hard refreshes weren’t solving it. Dumped cache and cookies for this site, still no change in Chrome.

[samhotchkiss]

This happened to me today while testing the latest beta. No good.

@ebinnion @gravityrail -- can you take a look?

[samhotchkiss]

When I ran into this on jtpk.us, it wasn't fixed by refreshing, and wasn't even fixed by triggering a full sync, however, when I left and came back a couple hours later, it was working properly

[ebinnion]

For posterity, we chatted more about this in Slack, and it doesn't sound like a sync issue. My bet is that it's some sort of object caching issue.

[gravityrail]

For caching plugins which interfere with Jetpack, most plugins offer a way to bypass the cache, and we should implement the necessary hooks for that to happen.

[rickybanister]

Any further news here? Where are we with accurate detecting of the current plan?

[zinigor]

I have been able to reproduce the problem on a test host on SiteGround. The REST API response seemingly gets cached, this is what I get the first time:

HTTP/2.0 200 OK
Server: nginx
Date: Tue, 04 Apr 2017 14:19:17 GMT
Content-Type: application/json; charset=UTF-8
x-robots-tag: noindex
Link: <https://remember-this-name.com/wp-json/>; rel="https://api.w.org/"
X-Content-Type-Options: nosniff
access-control-expose-headers: X-WP-Total, X-WP-TotalPages
Access-Control-Allow-Headers: Authorization, Content-Type
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
x-wp-nonce: --snip--
Allow: GET
Access-Control-Allow-Origin: https://remember-this-name.com
Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Credentials: true
Vary: Origin
Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT
Host-Header: --snip--
X-Proxy-Cache: BYPASS
X-Firefox-Spdy: h2
{ ... "plan":{
	"product_id":2002,
	"product_slug":"jetpack_free",
	"product_name_short":"Free",
	"free_trial":false,
	"expired":false,
	"user_is_owner":false}}"
 ... }

When I update the plan to a paid version and do a soft refresh, the next request comes back like this (only changed fields shown):

HTTP/2.0 304 Not Modified
Date: Tue, 04 Apr 2017 14:20:50 GMT
{ ... "plan":{
	"product_id":2002,
	"product_slug":"jetpack_free",
	"product_name_short":"Free",
	"free_trial":false,
	"expired":false,
	"user_is_owner":false}}"
 ... }

When I do a hard refresh (Ctrl+F5 for me), the request comes back as this instead (changed fields only);

HTTP/2.0 200 OK
Date: Tue, 04 Apr 2017 14:21:44 GMT
{ ... "plan":{
	"product_id":1003,
	"product_slug":"value_bundle",
	"product_name_short":"Premium",
	"free_trial":false,
	"expired":false,
	"user_is_owner":true}}"
 ... }

Since Cache-control headers state that the browser should verify each time, I'm guessing it's Apache cache, which goes behind the reverse-HTTP proxy.

[zinigor]

What's even more interesting is that all API requests seem to be getting cached, because all of them are returned with a 304 Not Modified.

[samhotchkiss]

Sounds like you're on the trail! Thanks for the updates

[zinigor]

If someone experiences that problem on a site powered by an Apache server, it can be caused by an erroneous Last-Modified header. One solution that helps in this case is to add this to your .htaccess file:

<IfModule mod_headers.c>
  Header unset Last-Modified
</IfModule>

This disables the Last-Modified header for all responses. I couldn't yet find a way to limit that directive to API requests only, so if anyone has a better idea, please let me know.

[zinigor]

Possible fix for this is making Core remove the Last-Modified header for REST API requests, there's a trac ticket for that.