GIFs are gone

Hi Jan,

I'm raising this with Verint. We've still got the image, it hasn't gone anywhere. I don't really want to go into the depths of how our images get handled and stored, but what's happened here is that the URL for the image has changed from one that will automatically generate a key to gain access to the image store, to one that goes direct without a key. The question I don't know the answer to is why that has happened, or how common that problem is.

I've looked into similar problems to this before, and it was you that reported it then!

As I say, I want to raise this with Verint but first I need a better understanding on how this might be happening.

I have a few questions.

1. Have you (or anyone else) seen this in content that you didn't create? (I'm trying to ascertain if this is something specific to they way you're working or if this is more global)

2. When did you edit this last? (I'm trying to ascertain what changed - it worked before, it doesn't work now, what changed?)

There are some real nasty gotchas here that make this very difficult to get to the bottom of. Browser and CDN caching will hide things that are broken so things can be broken immediately after publish but because the image gets cached, it doesn't show as broken until the cache resets. There is also the fact that after publish, the URL for images will generally change to one containing uploadfilemanager until the job server comes along and shuffles everything around into the place where it should live.

I don't want to over-generalize, and I also don't want to go into the depths of how these things are stored, but as a very VERY loose generalization, the url for something you generate should go via community.element14.com and it should contain cfs-file or resized-image. You'll probably quickly find exceptions to that rule, but in the case of these gifs, something is causing the image URL to go directly to community-storage.element14.com and that's our issue.

I think we're looking at an Verint bug here, specific to gifs, and specific to us using an azure environment. I'm trying to the bottom of what that bug actually is so I can report it to them

Dudley

P.S. I was in Belgium last weekend, I so love your country!

Hi Jan Cumps , hope all is well with you.

We've been talking at length with our vendor about what happened here. As I say, there are two images on this post, both broken, which have entirely separate causes.  I'll include a picture so it's clear what I'm talking about. The picture comes from the web archive.

The first one is the post image as specified in the options tab when you post it. It's an unusual set of circumstances that cause it to disappear, but it's reproducable and we have reproduced it and they are going to get that fixed. It is a bug on their part that affects the latest version of the software. I like it when we complain about something and it results in a change, that feels like we're getting somewhere.

But I wanted to run past the scenario they've highlighted with the second one and make sure it fits with what your memory of this might be. Appreciate this was a long time ago, so I appreciate you may well not remember.

What they say happened is that the post was uploaded, and embedded into the post as normal. When embedded, it embeds the image with a ~ at the start of the file path, so it'll be ~/cfs-file/__key/communityserver-components-multipleuploadfilemanager/something-something-something instead of /cfs-file/__key/communityserver-components-multipleuploadfilemanager/something-something-something

The ~ acts as a "the system needs to do something with this".

What they are saying is that the user (i.e. you) removed the ~ from that file path using the html editor before it got posted. Is that something you might have done? It might not be something you did manually, but if (for example) you are copying the html out and working on it in a separate editor, that might remove the ~ from the path - although if that were the case, I would expect this to happen quite regularly.

I ask if this is something you've done because I'm not convinced - I'm very wary when a software company blames the user on why their software doesn't work.

They are raising a bug - the multipleuploadfilemanager in the path also acts as a "the system needs to do something with this" and they are going to fix that so it will work.

And just to explain why this then goes on to cause a problem - multipleuploadfilemanager acts as a temporary file store while users upload files to include in content. It's considered unsafe by the system as it hasn't been checked. Once you post, a process comes along and checks those files to make sure there isn't an issue (for example, virused or banned file types) and if all is good, it moves it into a trusted area. In the case of that image, that process never happened, allegedly due to a missing ~ in the path.

However, because we aggressively cache images, should this happen, it'll appear to you like there is no problem at all because the image will be in the cache from where you posted it. The fact that it doesn't appear on our servers makes no difference, the image request never reaches our server because it comes from cache. This makes it a very tricky one to catch when it happens. You'll be able to see others it has affected, but you probably won't be able to see your own posts fail unless you check on a different device on a different ISP. 

I hope this helps with some answers, and I'm happy you told me all about this because we've managed to raise two changes out of one complaint! Every time this happens it makes the software a little bit better! 

Hi Jan Cumps , hope all is well with you.

We've been talking at length with our vendor about what happened here. As I say, there are two images on this post, both broken, which have entirely separate causes.  I'll include a picture so it's clear what I'm talking about. The picture comes from the web archive.

The first one is the post image as specified in the options tab when you post it. It's an unusual set of circumstances that cause it to disappear, but it's reproducable and we have reproduced it and they are going to get that fixed. It is a bug on their part that affects the latest version of the software. I like it when we complain about something and it results in a change, that feels like we're getting somewhere.

But I wanted to run past the scenario they've highlighted with the second one and make sure it fits with what your memory of this might be. Appreciate this was a long time ago, so I appreciate you may well not remember.

What they say happened is that the post was uploaded, and embedded into the post as normal. When embedded, it embeds the image with a ~ at the start of the file path, so it'll be ~/cfs-file/__key/communityserver-components-multipleuploadfilemanager/something-something-something instead of /cfs-file/__key/communityserver-components-multipleuploadfilemanager/something-something-something

The ~ acts as a "the system needs to do something with this".

What they are saying is that the user (i.e. you) removed the ~ from that file path using the html editor before it got posted. Is that something you might have done? It might not be something you did manually, but if (for example) you are copying the html out and working on it in a separate editor, that might remove the ~ from the path - although if that were the case, I would expect this to happen quite regularly.

I ask if this is something you've done because I'm not convinced - I'm very wary when a software company blames the user on why their software doesn't work.

They are raising a bug - the multipleuploadfilemanager in the path also acts as a "the system needs to do something with this" and they are going to fix that so it will work.

And just to explain why this then goes on to cause a problem - multipleuploadfilemanager acts as a temporary file store while users upload files to include in content. It's considered unsafe by the system as it hasn't been checked. Once you post, a process comes along and checks those files to make sure there isn't an issue (for example, virused or banned file types) and if all is good, it moves it into a trusted area. In the case of that image, that process never happened, allegedly due to a missing ~ in the path.

However, because we aggressively cache images, should this happen, it'll appear to you like there is no problem at all because the image will be in the cache from where you posted it. The fact that it doesn't appear on our servers makes no difference, the image request never reaches our server because it comes from cache. This makes it a very tricky one to catch when it happens. You'll be able to see others it has affected, but you probably won't be able to see your own posts fail unless you check on a different device on a different ISP. 

I hope this helps with some answers, and I'm happy you told me all about this because we've managed to raise two changes out of one complaint! Every time this happens it makes the software a little bit better!