i am currently hosting my site on justhost (just as a test server), when i save my work on my local computer through aptana the files are automatically uploaded to the hosting server, and they appear fine. However this only works for my actual files like .php and .html
They do not work for my .css files, so if i save them and upload them the changes do not take effect, until like the next day, or if i turn my computer on and off and leave it a couple of hours, i am not sure why they are not taking effect immediately like the rest of the fiels.
I have tried deleting my cache and adding ?ver=1.0 to the end of the file name, but still no luck.
Also, i checked the hosting directly and the css file has updated to the correct version, but just does not show in browser.
Any ideas on what could be wrong, it would make life much easier if i could get them updating like the other files.
Thanks
I can't be sure what is causing this, but if I'm correct - the files do upload, its not a case of not uploading. It's one of these things
The Cache is holding it (already cleared it though?)
The file is doing some odd cross server transfer, depends what sort of hosting your on, but it may be the file is getting held up somewhere
Try clearing the DNS Cache
Start > type CMD > in the dialog type:
ipconfig /flushdns
That may force the computer to reload the file.
As for an ongoing solution to prevent it in the future I'm out...
I know it has been a while, but as others may find this question the way I did, the solution for me was to enable Cloudflare Developer Mode. Cloudflare was keeping the css files in cache and it drove me crazy to find the solution in another forum. I hope your case may be the same as mine as thus you can solve it as well.
Related
I'm new to ssh and vps management. In fact I had someone do the initial configuration and setting up my WordPress site, but I feel there is something wrong (Multiple things), because the site goes offline a lot and there is one thing I managed to notice via using "ncdu /" and that there is a big file called "on" inside /usr/share/nginx/ directory. It's almost 15GB in size now but it's increasing everyday, I think this is not normal right? What is this file and how to stop it? could it be the reason for the site down time?
It's been a while now that i'm using Wordpress; and I know it quite well.
But this time, I've got a problem I've never seen :
My website freezes as soon as I try to go to the backend.
The frontend works, but when I go to /wp-admin, it stops working and eventually fires a "ERR_CONNECTION_TIMED_OUT" error.
Then the whole website (and FTP) is then down for about 5 minutes, then it comes back.
I don't know what as been changed since last time it worked.
Here's what I did try so far :
override my Wordpress folder with a fresh install
disable plugins (renamed wp-content/plugins to wp-content/pluginsOLD)
disable current theme (renamed wp-content/themes/my-theme to wp-content/themes/my-themeOLD)
edited wp-config.php file to enable debugging with WP_DEBUG, WP_DEBUG_LOG and SAVEQUERIES set to true; no debug.log is generated.
I also considered a server issue and waited for about 24hours. But my other websites (which are hosted on the same place) just work fine.
Any ideas about this ? I'm getting mad :)
My host had blacklisted my IP, that's why I wasn't able to access it.
I guess each time I was trying to access the backend, they did freeze my website to avoid an attack or something.
Well, this may be interesting for others. If I had knew it, I would have change my IP... :/
i've got an issue with website made in asp.net. A site is published and online, i've made some modifications, republished site on my computer and just uploaded a .aspx file into the server via ftp.
First time it seems to have worked after a while. But i've made a small error and want to edit it again, i did the same, but it wont change. Could it be that i need to wait some time before changes are seen? Or could it be that there needs to be a server restart or something?
If you've edited something in the aspx.cs page you will need to upload the bin directory to the remote site, or better still republish the whole site.
If it is a change to the .aspx, css or javasctipt file, the original will most likely be cached in your browser. Try a differrent browser brand or refreshing the page, ctrl-f5 does a complete refresh.
If this error was by any chance a CSS mistake, that can be easily fixed by adding a "?" at the end of the address since CSS files are normally stored in the cache of the browser and the ? tells the browser to update them. Same thing is true about JavaScripts which are kept in individual files
I'd recommend you to use the Visual Studio Publish Website under the Build instead of manually uploading the site over FTP. That built in publisher provides you many advantages of which one of them is the same issue you have faced. When you make a small change, fixing the error in host would be very faster by republishing the site that way rather than manually upping it over FTP.
I have change a bit of code in my CSS from Magento for my header logo but Magento doesn't load my new CSS update and still shows the old one.
I have already refresh the cache in Magento
Flush Magento Cache
Flush Cache storage
Flush Javascript/CSS Cache
At System - Cache Management
I have a folder var/cache and in here folders like mage--0, mage--1
i have tried to back-up them so i can restore it when i delete them and something won't wrong but i cant back-up it.
Hello first of all you can always safely delete the contents of var/cache you do not need to back it up. I konw it might sound silly but did you clear browser cache? Also make shure you changed the correct css file, use Firebug to see if your changes are not overwritten by other rules. A link to the project and more information will be helpful.
It may be that the browser is caching your files, not the server. To check, try either merging your files or unmerging your files and refresh the page. If you see the changes, then it is indeed your browser that is caching the files.
In that case, we've developed a handy little extension that automatically refreshes the merged JS + CSS static files. http://extensions.activo.com/css-and-javascript-versioning.html
you may be using different theme. check in system config design section what package and theme you are using and then check for that folder in skin and change. delete the var cache and changes will show. you do not need to back up var cache
Its also important to check System -> Design, where design overrides are located. Recently we've had a problem with this, someone (we are not sure who, hacker?) added override without dates, and whole shop become broken (we have pretty sophisticated package with lots of modifications). It took us about 30 minutes to figure out what was going on.
I just redeployed one of my sites today and suddenly some (but not all) of my .aspx files are redirecting to my 404 handler.
I've scrutinized the security settings on the offending files, comparing them line-by-line with other .aspx files that are serving correctly, with no luck.
The files 404'ing files were indeed ones I had been working on, and were replaced during the deploy. But then again, some of the other files I was working on are coming up fine. Naturally, the changes were not the sort of thing that would cause the errors I'm seeing, and the site runs perfectly in my dev environment.
Any idea what could be causing this?
ANSWER: User Error (as always)
Looks like my deploy script was skipping .ascx files. (One of the minor changes between last deploy and this one was adding a couple usercontrols.) The page would start loading, look for its UserControls, not find them, and throw a 404.
Thanks all for the sympathy. Sorry to waste your time. Hopefully this will at least help the next guy who fat-fingers a deploy script and gets a non-helpful error message.
Maybe you've already done this, but as you stated you had been recently working on those files, I would start by verifying that the links to the offending pages are correct in the source - check that their declared path is (works out to be) indeed valid. I try and make all links relative with Server.MapPath or something similar, but occasionally one slips my mind.