I am experiencing some pretty strange behavior on our site. I will navigate to a brand page and sometimes the brand images will display, sometimes they won’t. The code responsible for displaying these images is as follows:
If the image doesn’t 404, then repeat steps 2&3 UPDATE: - Refresh this post - Observe image above…
Sometimes you have to navigate into the product page of one of these products to get it to error out, but most of the time this issue occurs when we first land on a page with a brand logo on it.
The above brands are just examples, this seems to occur with all brands and their images…
There may be something weird going on with the staging servers as our main site seems to be functioning fine. I’ve noticed some strange behaviour over the last 24 hours where I’ll be working away and out of nowhere and even though I’ve not updated the file, our style sheet fails to load with a 404 error.
As mentioned, it started occurring about 24 hours ago, which may or may not have coincided with your network upgrade. Either way it’s making life a little more difficult today.
On the plus side (I could be wrong) the admin side of things appears to be a little snappier since yesterday as page changes are instant now.
I’m seeing the same with CSS files on the FTP, js files, images etc. - I made changes to a CSS file yesterday on a demo store that are not showing up through HTTP yet - I can open the file directly from any browser and not see any changes - it’s almost like the FTP and the webstore are disconnected
There are multiple servers serving your http requests on the backend, sometimes it’s possible that files can take an additional amount of time to propagate to all servers. It does seem strange thou that in this instance the files failed to propagate (it wasn’t just a delay). Was there anything special with how you uploaded those images? I’ve verified that http://ws4301-4323.staging.nitrosell.com/ is synchronized correctly now. We have been working to mitigate some performance issues over the last few days and it’s possible this may be a side effect. Can you please let me know if you experience any further issues?
@andy and @lindadusa and @stans - I really need more information - what webstores are you guys referring to? what images are not synchronizing? were the images uploaded by ftp? or nsc sync? or via the WSM?
Just went and checked and it’s still not the correct file - so I tried to upload again - all I’ve done is remove the text-align:center on line 8 (body) for store #4131
These are brand images uploaded directly to the FTP server in a custom directory via FileZilla. I uploaded many of these images on the 27th of April (so it has taken over a month to propagate), and they were behaving as I mentioned in my original post all the way up to Friday of last week.
It sounds like you might have found the issue. I will test and get back to you. I have some additional brand images to upload, so those will make good guinea pigs lol.
There was actually two issues which were affecting you. The first was a more general issue affecting all files uploaded via FTP for all customers - they simply were not propagating properly due to a hung process in our file propagation system. The process hung as a side effect of some performance issues we’ve been tackling at mitigating over the last week. As of right now for 99% of use cases everything is now working properly once again and a mitigation mechanism has been put in place to prevent that issue happening again.
The other issue relates to the Kendall brand image itself and why it never propagated at all. I actually dug in to that a little deeper last night. You uploaded the image on April 23rd and the filename then was all lowercase with an underscore rather than title case with a space. Once uploaded you renamed it and it seems this caused the issue whereby it never propagated properly. It seems that some FTP clients can send a rename in an alternative way which we haven’t anticipated and this can result in the renamed file never propagating. I’m going to run some test cases so I can verify that a fix for this rename bug is working and once it is all should be well. If you’re not renaming files then this won’t affect you but in any case I’ll send an update on this topic once I’ve confirmed the issue has been resolved.
Ah, yes. That makes sense. Windows has some strange behavior when you change the case of a character and don’t make any other modifications to the string when renaming. You have to either add or remove a character to get the filename to update properly… I didn’t realize FTP clients have the ability to send alternative rename commands. Pretty trippy. I hope you find a solution to that!
The stuff you did wouldn’t have brought back an immense amount of deleted directories would it? Our FTP root directory has a bunch of directories that should not be there… They look familiar… But they should either be deleted or in a different directory…
Doh, sorry that was probably my fault. Due to your public_html dir being out of sync, when I merged the contents of the directory from the copies across our webservers this would have inadvertently brought back some old files which as a result of the bug didn’t get removed on all servers. Please accept my apologies for that… the superfluous files are safe to delete.
In other news, I can now confirm that the ftp rename bug is also fixed. There should be no further issues now with FTP uploads of any kind. Woohoo!
Glad to hear that is resolved!