Wp-calypso: Sites: Site icon does not auto update or appear in Calypso after editing in wp-admin

[apeatling]

Testing #2871 and seeing the new "Edit Icon" link, I added an icon via wp-admin for a test site. I noticed that once the upload was done, the icon in Calypso for the site did not auto update. Even a refresh didn't make it appear.

The image should auto appear like changes to the site title do.

[lancewillett]

See also #1857 — opposite problem, when removing the Site Icon from a Jetpack site, it persists and isn't removed from Calypso site list.

[lancewillett]

I've made a change on the WP.com wp-admin side today (see 7742-wpcom) that should help with this. We weren't clearing the avatar image cache correctly after the upload step.

[lancewillett]

Note: original report was only for WordPress.com sites — the Jetpack sites connected to Calypso saw their icons change immediately in Calypso after changing them in the "Site Icon" area of a Jetpack site.

[rralian]

This seems to be an API issue (same as #1857). I've added a site icon to my test wpcom site and my test jetpack site, and the new icon doesn't appear for either of them. I'm guessing this is maybe a cache problem. Will look a little further.

[lamosty]

To recap:

1. When I add site icon on self-hosted Jetpack connected WP site, it is updated in Calypso immediately. When I remove it, it is not removed in Calypso and stays the same, even after full refresh.
2. When I add site icon to WP.com site, it is not updated in Calypso, even after full refresh.

Edit:
Using the API Console and querying /v1.1/me/sites:

1. The Jetpack self-hosted WP which had the site icon removed contains the old site icon;
2. The WP.com site which had the site icon assigned through wp-admin doesn't even contain the icon property

[lancewillett]

Let's keep the two issues separate and focus on fixing WP.com sites only with this issue here (ignoring Jetpack sites for now — they use a different library and call images via Photon and not Gravatar).

[lancewillett]

The WP.com site which had the site icon assigned through wp-admin doesn't even contain the icon property

This is working correctly in my testing, querying /v1.1/sites/lancetest24.com

"icon":
  "img": "https://secure.gravatar.com/blavatar/de7498a78b4ace2e361648bd6838a076"
  "ico": "https://secure.gravatar.com/blavatar/de7498a78b4ace2e361648bd6838a076"

Which is correctly loading the Gravatar-hosted images.

[lancewillett]

Oh — is the endpoint with /me or without?

I also see it when using that endpoint

[lancewillett]

I think what's happening is when a new blavatar (what WordPress.com calls the favicon.ico replacement, or "Site Icon") is uploaded, the Gravatar image path doesn't change — it uses the same hash, based on the domain. It doesn't take into account the image path or anything unique to the new file.

So we have two "caches" to deal with:

1) The WordPress.com CDN — to make sure the Gravatar image — even if it's the same hash in the URL, returns the new image in a request. This can be done after upload (clearing the CDN cache).
2) Browser cache — the way we "bust" this currently works by appending a timestamp string to the image paths in wp-admin. Thus as a user when you are in one browser, and upload a new image, you see the new icons right away because your browser is tricked into loading a fresh version from the CDN because of the timestamp query string.

The API call to get the icon _could_ maybe always call a "new" version by including a timestamp of its own, but that doesn't seem performant as every API call would return a new string even if the image hasn't changed.

[lancewillett]

I have WP.com/API changes ready for both 1) and 2) scenarios — awaiting review from @lamosty (reference 7742-wpcom).

[lamosty]

@lancewillett I've reviewed your patches at 7742-wpcom and they work. Please apply them so we can close this issue.

[lancewillett]

API side changes are made now.

[lamosty]

I'm reopening this issue because it's broken again. More details here: 7742-wpcom.

[lancewillett]

Let's re-open later if still needed. I have testing this and it's working as expected — delay of 20-30 seconds and sometimes you need to hard refresh the browser.