** that server probably wont show up for you, its behind a firewall.
and I looked at other posts, its odd the ‘?random_gen_number_string’ was happening here too and needed to go away and it is gone now but still there is a problem
one thing i noticed is that there is the all cap word in the link - HYPE-684
the files are not capitalized, maybe the live server is case sensitive where the local files are not?
scratching my head because even things that use to work are not working now. but its solar flares,
or gremlins, or something I cant see right away and I need help spotting it. i am up to date, all updates are in - so its a bit perplexing.
What is the sever your running? The “odd” string you mentioned is a cache buster. As browsers keep files cached with matching URLs tumult Hype adds a random string (number) as a URL parameter to have a variation in the path. This is to ensure you see updates when publishing new versions at the same location.
It is true that the default configuration of a Mac is case insensitive, and most servers are case-sensitive. However all references to the HYPE-684.thin.min.js should be that same case. However it could be that another file in your path (like colors.hyperesources) is using a different case than referenced due to a name change?
It'd be useful if could provide a live URL for the file on your server to take a glance.
The most common cause is just an incomplete upload or some CDN caching that might have happened leading to the file not showing up.
yeah i know what the string is for - it was a reference to another post where someone suggested deleting it to solve a similar problem, so i thought I would just put it out there to stop that suggestion being offered here as well.
this fails on both my test server, and my live server. i will post an updated link when things calm down at work later today so you can see the live version. live is CENTOS 6.5 and test is CENTOS 7.3
as far as links go, its pretty straight forward. dozens and dozens of times, I have done this. when it failed in a large system on the test and the live, I decided to check it by creating a small account on the test server with no other files in it (no other javascript files, no SQL or php, just the index file hype generates, and a resource folder). copied this pure index.html file that hype generated, copied the resource folder - and it still failed.
i have some files that are older, created in Hype3 - that USED to work, but I opened it, saved it as a folder, and posted it and it failed. Something has changed in the way things are being out put. other files on both my servers that run hype that are old and still working, so its definitely something that is new in the output and the process of saving a project to a folder, or it seems to be.
here is the oddity - other files on that test server in other accounts on the server are still functioning because they were created in the past and they are running just fine. i use hype like sprinkles of fun on super complex php / my sql systems, i am not a newbie. moving hype to servers is not new to me, but it suddenly failing for no reason is.
i am not opposed to deleting all the copies of version 4.0 and then re-downloading the current one (even though I did this when i bought the upgrade, because i was testing) if that could help.
This is the weirdest thing. It works on the live server now, and still failed on the test server. This particular flavor of linux is : CentOS Linux 7.6.1810
and I shell into the test server, manually change the case via a shell command
and it works on the test server like magic. so the situation is that hype is just fine, but my server is being super picky about that capitalization.
Can you send an export that fails before the change, along with a zip of your .hype document?
Basically I’d need to see a failing output and also what was intended from the export to determine where the issue lies.
I actually ran into a capitalization issue myself with our servers a few weeks ago. My best working theory that I could reproduce is that an initial export used a lower case version and a later export used an uppercase version of one of the files, and the save kept the previous name. But I wasn’t certain this was the root cause and didn’t look into it very much (assuming it was my user error) because of the v4 crunch we were in. (Perhaps it is related to Apple’s new file system?)
Thank you! i need to clarify a bit - the actual output from HYPE didn’t need to be changed, my problem is caused by my test server is forcing the case of the file names to be lower case - so they starts out all caps on my desktop, move it to the test server and the name changes case on its own. The only requirement to making the files work on my test server now is that i shell in and change the case of the name of file itself, so the problem is not with the output from Hype, or any of the code it creates - but something with my test server which is behind a firewall so you can’t see it this is a server side issue, not the problem of anyone on this forum, I have to just roll up my sleeves and find out what changed on the server. its also very new - 12 days ago this wasn’t happening.
i can show a screenshot of the file with an arrow pointing to the one I changed the case of and it started working, but it seems like overkill… what the heck!
If you add two other files to the project. Maybe some image files that start with the same words and has a - hyphen after the start word but ends differently after the hyphen.
does one of them also change.
My thinking is maybe your server is only looking at the first few characters up to the hyphen and deems they are the same name so changes the case
not always sure which level people are on.
this is a server side issue, not the problem of anyone on this forum, I have to just roll up my sleeves and find out what changed on the server. its also very new - 12 days ago this wasn’t happening. 
