I’m only marginally literate in web production, and yeah, I’m using Dreamweaver CS5. (Minimal sneers, please.) A few years ago I created a (rather nice) 21-page web site for a local non-profit organization that has been working well and bringing in money and kudos.
Today I saw that a rollover was not working on the index page, so I fixed it and uploaded just that one page to the remote server. When I did so, the page was “broken.” By that I mean the divs and blocks were displaced. Here’s a piece of the page:
Basically, the page previews perfectly in Firefox and IE in Dreamweaver, but when I upload it and look at it live on the web, the page is still broken… BUT, as I’ve been tinkering with it, the breaks have appeared in different places. At first, the top of the page was broken. Now it’s the middle of the page.
I’ve gone back to earlier versions of the page (as I save earlier versions of most everything for just such times as these) and uploaded those… and the page is still broken, but in different places from the first snafu.
I KNOW this is hard to diagnose without more visual/textual detail, but this is my main question: **what would cause a page to preview perfectly but to break down when uploaded?
**
If I have to, I can re-upload the whole site (when I get to work tomorrow where the connection is about 10X faster than at home), but it’s only the index page that’s broken. When I go to the site live, all the other pages/links/etc. look good and work perfectly.
It’s impossible to know for sure when we can’t see the source code – can we see the actual published site?
If I had to guess, you probably have an issue with the image URLs. Maybe absolute/relative links or maybe they’re pointing to the image on your hard drive.
Almost certainly this. It’s easy to have code on several levels and unless DW is carefully set up, it will throw the code up with file paths that don’t match what’s on the live server. We have a site with a test sub-site and are forever having to correct bad image links on it.
Unix is case sensitive. It’s also unforgiving with spaces in file and directory names. On the other hand Microsoft products are the sluts of the computer world. MS tools will do whatever it takes to suck you in. So if you use MS standard (bad) practices when creating web pages and attempt to upload to Unix servers, your links will fail.
Also, check your Dreamweaver configuration for the site. If it’s a Unix server, you may need to tweak Dreamweaver’s base settings.
Thanks for these comments. I just found out that I’m going to need to make some other edits due to staff changes, a new program, calendar updates. This should be an interesting day.
Worse still, some HTTP servers overcompensate for this with functions that attempt to find the file they think you meant - on the (linux) hosting for my own site, the web server ignores small differences in the actual file name - so you ask for ExampleImage11.jpg - if it doesn’t exist, but there’s one called ExampleImage1.JPG or Example_image_11.png, or ExammpleImage11.jpg, it will serve that up instead.
I hate this, as it means typos have gone unnoticed until years later, when I try to port the site somewhere else.
If you’re not up to the task of transforming what sounds like a static website to a dynamic, data driven one, I would suggest wrangling up one of the freely available content managers out there so that they can make these types of updates themselves.
I just went to my backup (I backup every day) and got the web site folder from day before yesterday with all the files that were working fine yesterday morning (before I tried to fix the rollover), and made that folder the new root folder. I didn’t change anything in it. I uploaded that folder–the whole ball o’ wax–to the server.
I went live to the web and the first page is broken in the way it was the first time I checked it (after correcting the rollover). WTF?
This is a site that has worked fine for a couple of years. It’s starting to make me think that my correcting the rollover was just a coincidence and that something was getting ready to go wrong anyway.
I don’t want to post the site link here, but if anyone is interested in looking at it, I’ll PM the link to you.
When I managed a university system eons ago I received a call from a professor complaining the university web site had porn all over it. Huh? Not that I could see from my computer so I took a long walk across campus to see for myself on the professor’s computer.
Sure enough, he was correct. There was porn all over the university’s public web site, on his computer. I did a deep browser refresh to clear his browser cache, and waited. No more porn showing up the university web site, on his computer. He thanked me profusely and that was that. I didn’t have the heart to tell him the problem was caused by him actually visiting porn sites on his university computer. Seems his browser cache was corrupted and many of the porn image names in his cache were identical to a number of university image names on the university web site. You do the math.
I still kick myself years later for not doing some after hours due diligence to find out the top porn sites at the time. It would have been fun to rename a number of main web images on the university public web site to be identical to those found on several porn site images.
Well, that sounds like a very badly designed browser cache system, if it’ll use an image from the cache instead of an image on a completely different website because it has the same filename.
I guess it’s a set of rules, so it’ll return the first rule match or the last one, depending on whether it stops processing on success.
I think it was the Apache Spelling mod, or something similar. It’s just a terrible idea - HTTP requests should work if properly formed, and fail otherwise - this sort of dumbing down only creates fresh problems.
