EW 4

Question

I downloaded both a trial version of EW4 and Microsoft Expression and SuperPreview 4.

Can anyone tell me the difference?  EW 4 wouldn't start because it said EW 4 Service Pack 2 couldn't be installed because the program to be upgraded either is missing or is the wrong version.  Huh?  I was told I could download the new version since I have EW 3 and now I'm confused.

The SuperPreview 4 installed without any problem.  Which do I need?

Thanks for any help.

Rick

Answer 1

They are different things. SuperPreview is just a way to compare how your site renders statically in different browsers. It's not as good as previewing locally in the 4 or 5 most common browsers, but it lets you compare renderings side-by-side. I rarely use it.

You need EW4 to create the site, just like EW3.

Your description is very very fuzzy. It sounds like you didn't actually install EW4 yet. Starting EW4 would never give you a message that SP2 couldn't install; those are two entirely different things. The only way to get a message like that ("EW 4 Service Pack 2 couldn't be installed because the program to be upgraded either is missing or is the wrong version") would be by trying to install SP2 on a computer that doesn't have EW4 installed yet.

---

It's not the heat, it's the stupidity.

Answer 2

From the wording of that message, it sounds as if you might have tried to install the Service Pack without having first installed the program.

Be sure to download the full trial, then install it. Then go here and download the Service Pack and install it. See if that resolves your issue.

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 3

Bill, you really ought to change that signature.

JMHO

---

ClarkNK, A.K.A. HomePage Doctor
HomePageDoctor.com -- Expression Web database tutorials
Ownertrades.com -- Created with Expression, VWDExress, SQL Express, and ASP.NET
Arvixe -- My favored web host

Answer 4

Thanks, Clark.

When I went on vacation a month ago it was still hot. Now that I'm back and catching up, not so much. It was one of many things on the back burner.

All fixed.

---

How many SEO experts does it take to change a lightbulb lightbulbs buy light bulbs neon lights sex porn.

Answer 5

Thanks for the help.  I have been in EW 3 Forum and someone gave me a link to download EW 4.  Apparently that was the wrong place/address.  I just downloaded what they said.  Oh, well.  I used your link and they worked and installed.

Another question that I have....has anyone reported any problems with the difference between Windows 7 and XP?  I have been told that some of the problems that I am having in EW 3 are probably due to my website was created on an XP machine and now I am trying to load the data onto a Windows 7 computer and the files aren't being read completely.  Do you know anything about that and is it true?

If it is true - how do I fix the problem?

Rick

Answer 6

Great reply!

Another question that I have....has anyone reported any problems with the difference between Windows 7 and XP?  I have been told that some of the problems that I am having in EW 3 are probably due to my website was created on an XP machine and now I am trying to load the data onto a Windows 7 computer and the files aren't being read completely.  Do you know anything about that and is it true?

If it is true - how do I fix the problem?

Rick

Answer 7

Website files (html, css, aspx, php...) are just plain old text files. There is no difference between XP and Win 7 on reading files.

If you publish your site down correctly to *any* machine EW is running on, it will work.

You haven't been specific about what you mean by "loading the data on the machine" and what problems you are having.

Answer 8

Website files (html, css, aspx, php...) are just plain old text files. There is no difference between XP and Win 7 on reading files.

If you publish your site down correctly to *any* machine EW is running on, it will work.

You haven't been specific about what you mean by "loading the data on the machine" and what problems you are having.

Don't forget EW also creates hidden '_vti_cnf' files etc. to 'manage' the site.

But as you say, more info is needed :)

Answer 9

Don't forget EW also creates hidden '_vti_cnf' files etc. to 'manage' the site.

Which has nothing to do with anything. Those, too, are simply text files, with no difference between different operating systems. To my knowledge, those files are only created locally, and used locally, and if they don't exist, will be created automatically when "Manage site using hidden metadata" is enabled, and ignored if it is not enabled.

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 10

Sorry for the lack of detail.  I reaching for straws.  I had a techy develop our website and they are no longer available to help with our changes anymore.  I can maintain most of the items we need to have updated, but I wasn't there when they chose to "publish" the data.

All I know is that all our web site (data) is on an external hard drive and it is backed up on the desktop of our new computer.

I can open the web site in either EW 3 or EW 4 (I am currently using the EW 4 because again I was told in made fixes that where in EW 3).  However there are images that are in the "Image" folder that I want to bring into the website and everytime I click on the image folder, I get a message back that says, "Server error.  The server extensions were unable to acces the file "G\SOL\_vti_pvt\service.lck".  Please check the file permissions.  Contact your Internet service provider or Web server administrator for more information."

I contacted my web server and they thought the best thing to do was remove the vti file because they thought it was from an old version of Frontpage, the predecessor to EW.

I removed the file and it did allow me to now view the image folder that I couldn't get into.  However, when I went to upload the file via FTP to my server, the file failed and couldn't or wouldn't load.  Therefore no changes were uploaded to my server.

Does that make it any clearer or still like mud?

Rick

Answer 11

Badgerer;

Thanks for your comments.  Please see the comments above that I wrote to Kathy.

I did see the vti_cnt file in the image folder.  After I removed the file above, I don't know how that plays into the process of uploading...or is it part of the problem with why it didn't load.

Any further comments?

Answer 12

"Does that make it any clearer or still like mud?"

Closer, but not yet.  First, are you opening the local site on your PC in EW to make changes, then publishing them to your hosted site?  What method are you using to publish?  Was this a FrontPage site and if so did it use the FrontPage Server extensions, and does it use features that rely on them?

Answer 13

Yes, I opened the bkup website data that was on the desktop using EW 4.  The changes were added and saved.  I tried to upload those changes that were saved, to the hosting server via FTP.  Just like what we have been doing for 2-3 years.  And it failed.  I'm thinking it failed becaused I removed the vti_pvt file, however I could be wrong.

When we started along time ago, Frontpage was what we used.  However it was very unstable and things were moving all over the place.  3 diff. techy worked on it and none could fix the problems.  We were looking at making a software change and that is when we were told about EW.

We developed a brand new website from scratch and I thought our server people gave us a new location???  I don't know if they used any of the FrontPage Server extensions.  He did keep mentioning or refering to FrontPage and that was making me uncomfortable.

He did say that I shouldn't need the file that he told me to deleted.

What do you recommend?

Answer 14

Hi RH1dapw,

It sounds as if I might have been on the right tracks if the problem started after removing the hidden 'vti' files!

I use Filezilla to FTP/upload my files but the vti files are required for EW4 to manage the site and removing them will cause issues.

Hopefuly @paladyn will come back to appologise to me and explain how you can repair things :)

Answer 15

Scott's reply was under the context of XP vs W7 question. Moving your project from one OS to another should have no impact on EW even considering the vti files. I know because I've done that myself a couple of times and had no problem. If you didn't move those vti files to your new computer then that is bad just like not moving your main page "index.html" is also a bad thing. I doubt you're going to be getting an apology from Scott anyway even if you caught him banging your wife. Maybe if you had a gun?

Answer 16

vti folders are recreated if they don't exist. That's part of what FP Cleaner does when you use it to fix corrupt meta data. You don't need to worry about moving them. Making sure the "use meta data" box is checked is all you need to do to get new vti folders/files created.

FWIW, there are not vti folders or files on my servers. The only ones that need them are servers where you use FPSE for publishing.

---

Free Expression Web Tutorials
For an Expression Web forum with without the posting issues try expressionwebforum.com

Answer 17

 Hi RH1dapw,

It sounds as if I might have been on the right tracks if the problem started after removing the hidden 'vti' files!

Rubbish! that is an example of the post hoc, ergo propter hoc fallacy, a common failing of weak minds unable to reason properly.

I use Filezilla to FTP/upload my files but the vti files are required for EW4 to manage the site and removing them will cause issues.

It is quite clear that you don't understand the mechanisms involved. EW uses the _vti_XXX files for metadata management locally, and as stated, will create them automatically when "Manage site using hidden metadata" is enabled, and will re-create them if you delete them, as long as you leave "Manage site using hidden metadata" enabled.

In any event, if you are using FTP, they are NOT used on the server. They may possibly be used if the OP is using the FPSE for publishing, it's been too many years now since I used FPSE for me to remember, but they are completely immaterial if using FTP for publishing. I have a site created using a custom-built DWT, which requires metadata management locally, and which has never been published using third-party FTP, and there are NO _vti_XXX folders on the server, so it appears that EW, which hides those folders in the Folder List and Site View lcally, also does not transfer them to the remote server when its own FTP is used. Third-party FTP programs are not aware of the nature of those folders, and will transfer them anyway, where they will sit, dormant, on the server, not affecting anything.

Hopefuly @paladyn will come back to appologise to me and explain how you can repair things :)

Why on earth would I ever do that, when you have once again demonstrated your egregious ignorance of how EW works and what is involved in publishing? You have shown yourself to be the clueless twit that you have been in the past, and I owe you nothing, and certainly not an apology.

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 18

Yes, I opened the bkup website data that was on the desktop using EW 4.  The changes were added and saved.  I tried to upload those changes that were saved, to the hosting server via FTP.  Just like what we have been doing for 2-3 years.  And it failed.  I'm thinking it failed becaused I removed the vti_pvt file, however I could be wrong.

When we started along time ago, Frontpage was what we used.  However it was very unstable and things were moving all over the place.  3 diff. techy worked on it and none could fix the problems.  We were looking at making a software change and that is when we were told about EW.

We developed a brand new website from scratch and I thought our server people gave us a new location???  I don't know if they used any of the FrontPage Server extensions.  He did keep mentioning or refering to FrontPage and that was making me uncomfortable.

He did say that I shouldn't need the file that he told me to deleted.

What do you recommend?

OK, we're getting (slightly ;-) closer to an understanding of what is going on here. Let's look at the situation—you're not sure if you have used FPSE (FrontPage Server Extensions) for publishing previously. Not a problem; we regularly recommend here anyway that users abandon the FPSE, before their hosting providers do so unilaterally and leave them stranded. So, let us work from the assumption that you are going to use FTP to publish going forward, which is the preferable option.

So, before doing anything else, go to http://www.95isalive.com/fixes/ew4.htm and download and run the FPCleaner utility to clear up any existing problems (don't worry about the "Open Last Web" setting).

That done, now, open EW, then use "Site|Open Site..." or "Site|Recent Sites..." to open your site. Load your "index.html" file (it might be named "default.html," or whatever your site default file is named, or it might have an "htm" extension instead of "html"). With that file active, click the Preview icon on the toolbar, or use "File|Preview in Browser," and check to see if the images and other resources you expect to see there are in fact there.

Now, while previewing, use your site's menus to move around in the site from page to page. Is everything there that you expect to be there? If so, good, we've established a baseline. We now know that your local site has all of the edits that you thought that you had made. If not, then the problem is not a publishing issue, but something that you're doing wrong locally, and we need to start investigating your workflow to discern the problem.

OK, for now, let's presume that the site looks the way you expect it to when you preview locally. All of your edits, all of your images, everything is in place. Now, let's publish it. Make sure that your connection settings are correct, and that you are using FTP (with an "ftp://yourdomain.com" address, NOT an "http://yourdomain.com" address," which would indicate that you're using the FPSE).

Now that you have checked your "Connection Settings," and previewed to ensure that your changes are all implemented locally, click on "Site|Publish All Files to ..." For this first publish, we want to make sure that everything goes up. For subsequent sessions, you can just use "Site|Publish Changed Files..." to publish only the changes made that session.

Now, the test. Use your browser to go to the online version of your site and see if the edits you saw locally appear in the site as published online. If not, or if you experience issues during this procedure, report back and we will go from there. You haven't been exactly clear describing your situation, or the steps you are taking, but by taking a logical, systematic approach, maybe we can hone in on what the problem actually is.   ;-)

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 19

Thanks for the friendly encouragement @paladyn :)
Always good to see new forum members made to feel at home.

The EW Help pages also mention the requirement for these hidden files in some circumstances (this is what I referred to as 'site management'):

"Microsoft Expression Web uses metadata to maintain the cross-page dependencies that are required for some Expression Web features such as hyperlink management features, Dynamic Web templates, and certain site reports. Certain options in the Site Settings and Properties dialog boxes are also unavailable if your site does not have metadata."

I mentioned to the OP that I use Filezilla as a standalone FTP client I didn't mean to connect the two items (FTP and vti files) - sorry about that, I could have saved you a lot of time there.

Thanks again for the friendly encouragement and your cheerful polite manner which I’m sure will ensure lots of new EW users come forward with their queries and helps make this forum a pleasure to visit :)

Answer 20

Badgerer, you came into this forum and all but begged to be rebuffed. First is your chosen handle—badger has only one meaning as a verb, "to harass or pester persistently." When you added the "er" ending, it became "one who harasses or pesters persistently."

And then you immediately appeared to be trying to live up to that handle, with your posts to the forum contributing absolutely nothing to the conversation, but freely adding "rants" about the regulars who do actually contribute their time and effort here answering questions that we can answer, and adding meaningless, and unhelpful, posts to threads chastising us for telling people, accurately, that we're not tech support and there are some questions that we cannot answer.

You have, apparently deliberately, made yourself into an irritant, a nasty little horsefly who contributes nothing, but buzzes around, stinging and moving on, a gadfly. We don't need your criticism, and if you expect anyone to love you for it and to offer you "encouragement and a cheerful, polite manner," you've got serious reality issues to deal with.

You want to actually help? Learn enough about the program, and about HTML and CSS, to offer constructive suggestions. That's constructive, tested suggestions, NOT guesses. If you offer a procedure, test it yourself first to make sure it works. If you read something, like that section you quoted from the Help file above, be sure that you understand what you have read, and that it actually applies to the question at hand (that does not, BTW). Questioners here are confused enough, and by the nature of the situation, willing to believe what they read here, so muddying the waters with inappropriate non sequiturs contributes nothing to the conversation, and does not help the OP resolve his issue, and that is our main objective here.

In short, stop acting like an irritating little twit, and you will stop being treated like one.

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 21

@paladyn - Thanks for that it's appreciated and very constructive :¬)

FYI - Re. username.
Actually I wanted Badger (a small mammal) but that was gone so I just added 'er' to get signed up. No doubt you will tell me I'm mistaken and that's not what I did at all! ;¬)

Answer 22

Cheryl;

Where are the vti files recreated?  I can see that the server still has the vti & cni files on their system (hosting folks).   All I know now is that I can't upload the data I saved using EW4 (saved back to the desktop).

When you say, "Making sure the "use meta data" box is checked" are you refering to the location, Site/Sublishing Settings/the General Tab and have the box checked that read, "Maintain the site using hidden metadata files"?

I'm sorry, I don't know what FWIW or FPSE stands for...

Rick

Answer 23

Scott;

Thanks for the help.  I downloaded the "Cleaner" program and I have ignored the "Open Last Web" button.  However, do I click the 3 remaining buttons (Hidden Temp File, Hidden Cache and Replace Mru/List)?

I'm going to take this one step at a time....sorry for the slow progress.

Rick

Answer 24

FWIW = For What it's Worth

FPSE = FrontPage Server Extensions

 

The _vti* files are recreated on your PC using

Site->Site Settings - General tab and ticking the box "Maintain the site using hidden metadata files"

 

If you publish with FPSE, the server creates the _vti* folders and files on the server as required.

Using FTP, the _vti* folders are not required on the server - if any are there may cause a warning message saying that the site should be published using the FPSE - this warning can be ignored.

 

Neither FrontPage nor Expression Web ever publishes these folders/files when using either FTP or FPSE (and FileZilla can be set to ignore them).

 

---

Ron Symonds
Microsoft MVP (Expression Web)

www.rxs-enterprises.org/fp

Answer 25

Ron;

Thanks for the help.

I don't publish with FP anymore or at least to my knowledge.  The vti folder is still on the server and they may have been created when we used FP a long time ago.  Again, I thought our hosting site provided us a new location to dump our data so that we could start with our new website.  Now I'm beginning to question that.

I'm not sure how all this plays together nor do I understand why I can't open the files in EW 4 that are on the external hard drive. 

I don't understand why the data won't upload to the server from my desktop (bkup site) after I removed the vti file that was on the desktop, which I was told to do by the server hosting folks.

Rick

Answer 26

OK, when you are using FTP to publish, the _vti_xxx files and folders are meaningless to the publishing process, either on the server or locally. They have no effect whatsoever.

If you use EW to publish with FTP, EW will ignore the local _vti_xxx files and folders. You may have already noticed that EW does not display them in its own Folder List or Site Views, although you can see them when you look in an external file management program. As far as EW is concerned, they are hidden folders used only for managing the site locally, are no  concern of the user, and if using FTP, have no effect on the publishing process. So, for purposes of this discussion, you can completely discount the local _vti_xxx files and folders, and imagine that they do not exist. Got that?

Now, if they exist on the server, that means one of two things. Either the site was at one time published using the FPSE (FrontPage Server Extensions, which I explained in my previous post), and they are simply holdovers from that time, or the site has been published at some time using an external, 3rd-party FTP client. Those clients don't know of the special, hidden nature of those folders, so unlike EW, which does not publish them, a 3rd-party client will.

In any event, they are completely immaterial. The only thing that uses them on the server is the FPSE. If they are present on the server, and you are not using FPSE, they are ignored, and have no effect on publishing. None.

So, what that means is that, going forward, as long as you are using FTP to publish, the _vti_xxx files and folders are NOT a point of discussion. They just don't matter, period, no matter what the "server hosting folks" tell you. If you are not using the FPSE, you don't need to be concerned with the _vti_xxx files and folders.

I'm not sure how all this plays together nor do I understand why I can't open the files in EW 4 that are on the external hard drive. 

That is another issue entirely, which has nothing to do with publishing, since when opening files locally you are using only the local file system. You should be able to use "Site|New Site...", which will give you this dialog

Select "Empty Site" then click the "Browse" button to browse to the folder containing the site on the external drive. That will fill in the "Location" field. If you wish, give it a name in the "Name" field, then check the box to "Add to Managed list." Now, click OK, and you should have the site open in EW, where you can open and work with any of the files in the site.

Now, try that, then report back. If you can get that far, we can work on the next stage. One step at a time...

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 27

Scott;

I followed your instructions as indicated.  However, I ran into problems.  I'll explain.

I opened EW4 and went to the tab Site\New Site\Empty Site and hit the browse button to find the file I wanted on the external hard drive.  The file name loaded in the location block and block where the box check, "Add to Managed sites is.  Then I clicked ok, and then I get a popup that reads, "G:\SOL Site already contains a site.  Please specify a different location." 

When that msg came back, the first thing I thought of was to change the site name so I changed it to SOL Site1 and repeated the steps.  I rec'd the same error message.

Then I tried copying the file from the hard drive to the desktop, changed the name and the files didn't copy.  This is becoming a nightmare.

I finally was successful in getting the name changed and the files were in place.  I was able to open the new site in EW4 and the changes that I wanted were in place.  I knew that the changes had been added to the site that is viewed by anyone on the web, so decided to close out of the EW and try uploading like I have been doing for years.

I logged into CORE FTP (which is the FTP site I use) and proceeded to upload the image file.  Each time it failed up upload, even on retry.  I opened the Image file that is on my external hard drive, while in FTP.  I notice that it has a file in it called vti_cnf.  From what has been written back to me that shouldn't appear to be a problem.

I opened the image file on the server and the vti_cnf isn't there. 

I decided to try and upload the webpage that was changed to see if it would work.  It didn't.  It gave me an option to rename it so I did.  Now I had both files sitting on the server not knowing what was going to happen.  I closed out of the FTP server, went to our website and the webpage was still the same.  I'm guess for one or both of 2 reasons.  The image file didn't upload or the 1st html site took precedence over the 2nd page because all I did was add a number "1" to the end of the name1.html.  I don't think the page would work anyway because the image file wasn't uploaded.

Reporting back as requested.  Now what?

Rick

Answer 28

I opened EW4 and went to the tab Site\New Site\Empty Site and hit the browse button to find the file I wanted on the external hard drive.  The file name loaded in the location block and block where the box check, "Add to Managed sites is.  Then I clicked ok, and then I get a popup that reads, "G:\SOL Site already contains a site.  Please specify a different location." 

OK, we're making progress. Like I said, one step at a time... ;-)

What that message means is that, at some time in the past, that folder has already been defined as a Web site in EW. That's OK; I was giving you those instructions because I presumed, from your previous statement that you were unable to open it, that it had never been defined as a site.

Now that we know it has, you should be able to use "Site|Open Site..." then browse to and open that site in EW. From your later statement, it appears that that is the case...

I was able to open the new site in EW4 and the changes that I wanted were in place.  I knew that the changes had been added to the site that is viewed by anyone on the web, so decided to close out of the EW and try uploading like I have been doing for years.

Alright. Here's where we need to vary from the practice that you have been following. I don't really understand what you mean by this...

I logged into CORE FTP (which is the FTP site I use) and proceeded to upload the image file.  Each time it failed up upload, even on retry.

I have no idea what you mean by that. Core FTP is a 3rd-party FTP client, not a site. That is, it's an application, which you run locally on your machine. Secondly, you say "upload the image file." What do you mean by that?

Never mind that for now. Let's try this—instead of using Core FTP, let's work with EW's FTP client instead. MS finally got it right with EW4, and its FTP client and site management are now spot on, fast and reliable.

In EW, with the site open, open the index.html file (or whatever your home page is called), then click "File|Preview in Browser." Now, while viewing the local site in your browser, use your site menus to move around and make sure that all of your content is there as expected. If so, report back and we'll go into setting up a Publishing Destination in EW, OK?  ;-)

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 29

Yes, the Site - Site Settings - General tab is where you check the "Maintain site using hidden meta data files" option.

FWIW = For What Its Worth

FPSE = FrontPage Server Extensions used for http publishing and required for the FrontPage forms processor to work (backwards compatibility for FrontPage legacy sites.)

If you have vti files on the server they are there because either you previously  used FPSE to publish or you used a third party FTP tool like Filezilla or WS-FTP Pro that uploads everthing in the local folder.  When you publish via FTP from within Expression Web the vti folder and the files in them should not be sent to the folder.

The vti folders and contents should only be in local site folder (along with some other meta data that is maintained in the user's app data account folder.)

In theory if you remove the FPSEs from the server the vti folders there will be removed.  Given how poorly understood the FPSE are by many hosts that doesn't always happen even when you remove the FPSEs through your control panel or their techs do it.

None of the sites I manage with the exception of one that still has FPSE installed (client manages content and it hasn't been updated in design/feature set for years so while it is still a client site in reality I've done nothing with it for years) has any vti files or folders on it.

I am aware that if you try to ftp using EW or FP to a site with FPSEs installed you will get warning telling you to use the FPSE or you risk breaking the FPSEs. I have never seen that prevent you from being able to publish though if you use a mix of FPSE required content and content you need to publish by FTP (such as a portion of a site that uses a blog application) you should mark that section of the site - "do not publish" in EW and use a third party FTP client to publish it but I digress.

When you run FP Cleaner you will want to check the Hidden Temp files and Hidden Cache. Whether or not you replace the MRU (most recently used) list or not is your choice.

---

Free Expression Web Tutorials
For an Expression Web forum with without the posting issues try expressionwebforum.com

Answer 30

Scott;

All the pages are there as expected. 

I have never used the EW 3 to move the pages to the server.  That is way it was s/u in the beginning.   Maybe the techy knew that EW 3 didn't work correctly...don't know.  That was the reason we always saved the data to the external hard drive, backed the data up to the desktop and then opened Core FTP (3rd party) and transferred the data from the external hard drive to the server.  Always worked - never had a problem.

Rick

Answer 31

I don't know exactly why your tech did things that way. I can say that I myself didn't use EW's FTP until version 4. All previous versions had seriously compromised FTP capability, but, as noted, with EW4 they got it right.

OK, so now we know that the site can be opened in EW4, and that you can edit it there and see the changes locally, so let's go the next step and try using EW to publish your changes. To set this up, with the local site open, click the "Site View" tab, then, down at the bottom, the "Publishing" tab. In the center of the pane you will see "Add a publishing destination." Click that, and you will see this...

Use the settings that your provider has given you. Note that the "Name" field can be anything you choose; it is only used by EW to identify publishing destinations (EW allows you to create more than one). Make sure that the Connection Type is set to FTP, and that the correct FTP address is shown in the "Location" field.

The "Directory" field can sometimes be a quandary. If you know for certain what goes in that field ("public_html," "wwwroot," "httpdocs," simply left blank, etc.), go ahead and put it there. If not, ask your provider's tech support what goes there. It's important—if it is wrong, the transfer may appear to go perfectly, but your changes won't appear on the live site.

Onc you get everything set up, click "Add," then open one page of your site in EW, make a change to that page that will be easy to spot, then click "Site|Publish Changed Files..." Once the transaction is complete, use your browser to visit the live, online site. Go to the page you changed and see if the change was uploaded. You may have to press Ctrl-F5 to force a refresh.

If everything's copacetic, you're in business. If not, or, well, in any case, report back and let us know what happened. Enquiring minds want to know...  ;-)

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 32

Scott;

Maybe I'm a little slow, but what goes in the Location blank?  ftp://????????

I will call my provider and get the info for the Directory.  I'm assuming this can change from time to time, because occassionally we see some things missing or whatever and we call them and they tell us it was moved to another server and we hold on for a minute or two and it's fixed.

Rick

P.S.  I called the provider and they told me nothing goes in the Directory and for the Location blank - to add the name of our "website.com".  I saved it.

Then I had the page that I wanted uploaded and clicked "Site/Publish current file...  The reason I did that instead of the "changed files" is because every folder/image came up and tried to update.  They all failed.

When I did just the one html file (I still rec'd an error msg - One or more file copy operations failed.  Please check the failed tab or the Log tab on the Publishing Status for details.  I clicked on the Fail Tab at the bottom and the window closed and I was left starring at the html data for the page that I wanted loaded to the website.

Answer 33

"ftp://????????"

Your site's FTP address.  You need to have an FTP account set up to ftp your site files up.  Any ftp program will need this.

Ask your host for the proper form (it can vary) for your site's FTP address, as well as for the FTP directory: the name of the folder your site files are all under, or, depending on your host and how things are set up, to be left blank.

If your host told you it was just "website.com", they were wrong.  If they told you it was ftp://website.com, well it could be, but if it didn't work, perhaps not.  And it all assumes you have an FTP account set up and know the user credentials and password and have filled them in, too: did you?

Answer 34

OK, let's find out if you are actually connecting to the server. With your site open, click the "Site View" tab, then the "Publishing" tab. You should see the name you assigned the connection in the dropdown labeled "Connect To:", like this...

If you see that name in the dropdown, then click on the "Connect to the current publishing destination" link. If the connection is successful, you should see a local and a remote file pane similar to what you see in your FTP client, like this...

In the address bar on the left (local) side, you should see your local site's location in the local file system. In the address bar on the right (remote) side, you should see the FTP address ("Location" field in the "Connection Settings" dialog), including the directory ("Directory" field, if any, in the "Connection Settings" dialog), as shown in the illustration above ("sandbox" is the target directory).

Give that a try. No Publish command is issued, just a connection made to see if you can do that. Connecting is the sine qua non for publishing, so you have to get past that point to move on. If you get an error when you try to connect, write down the full, exact error message and report back.

BTW, just a suggestion, but you might want to tell your provider's tech support guy to check this thread. I've posted screen grabs of the EW interface that might help him understand exactly what information you need. Information such as "Location" and "Directory" must come from your provider—we cannot provide it; we have no way to know it or guess it, so you must somehow get them on board with providing you the information you need, OK?

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 35

Scott;

Sorry for the confusion about the website.com.  All I was trying to do was show you they told me that the name of our site went there.

I followed your directions and here is what I have....well I am trying to copying in my open window file and I am having no luck.  To the left of the Names are explamation signs that are in red, under the Status is the word "Conflict".  This is in both my local side and the Host side.

I've tried to use Ducklink as my screen grabs, but had no luck putting it in this area.  How do you get your screen grabs to work or what program do you use?

Rick

Answer 36

Conflict is expected.  It just means EW hasn't published those files and doesn't know if they are the same locally and on the host.  That's not an issue.  You would have to publish your complete site with EW's publishing to synch up that status.  (Or just manually know which files have changed, and select those to publish.)

The question is: are the files the same, in the same locations: the files in your site root locally match the files that show when you first connect to your destination on the remote side: you don't have to go down a level on the remote side to see your files.  If so, you are connected to the correct directory on your host.

Answer 37

Kathy;

The files look the same.  They have the same number of files/html pages, etc.

Do you know how Scott was able to screen capture the diff. EW pages and copy them into this forum page?

Rick

Answer 38

Look at the menu at the top of  the "Reply" window of this forum.  Notice the "image" icon on the right?  Use it.   Clicking "upload" lets you browse your PC for an image to upload.   As to how you capture your image - that's up to you, and I certainly can't answer for Scott.

Answer 39

Hi, Rick. To get the screen grabs, I use a tool called Ashampoo Snap 5 ($19.99). I don't know if they're still offering this promotion, but you can go here and download a free copy of an earlier version (Snap 3) which should serve your purposes. Use the "Capture Free Rectangle Region" icon, like so...

to draw a square around the area you want to capture, then the "Save Capture in other Format or Location" option to rename it and save it where you want it. It also has drawing and highlighting tools for adding arrows, blurring text you don't want seen, etc.

As for adding the image to a post, the forum software allows that. When you are in Edit mode, there is an icon on the toolbar that will allow you to upload up to two images per post, seen here...

Just click that icon, then, in the dialog which appears, click "Upload," and browse to and select the saved image, click "Insert," and "Bob's yer uncle!" you're done. If you want more than two images per post, that's another discussion, but this'll get you started. Oh, and if that promotion is over, Ashampoo offers a free trial you can download here. BTW, after you've had Snap 3 for a while, Ashampoo will almost certainly send you an offer to upgrade to Snap 5 for $7.99 to $9.99, and it's well worth the deal. I use it all the time.  ;-)

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 40

To capture screen shots, Windows 7 comes with a small app called Snipping Tool that will do what you want; it can capture 4 different kinds (screen, windows, etc.). Or just press the PrtScr key (usually above Insert key) and then paste into a graphics program to crop the screen shot.

---

How many SEO experts does it take to change a lightbulb lightbulbs buy light bulbs neon lights sex porn.

Answer 41

Good point, Bill. I didn't mention that because he had specifically asked how I captured and posted those shots, but, yeah, the free Snipping Tool ("Start|Programs|Accessories|Snipping Tool") will get the job done for basic tasks. It is rather limited, however, and you can't capture open menus and other transients with it, nor videos (with sound), or entire scrolled Web pages, nor add annotations, highlighting, etc., so I would still recommend the really low-priced Snap tools from Ashampoo to anyone who asks. Much cheaper than, for example, SnagIt® (which I also have in an older version), and to my mind, just as capable.  ;-)

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 42

Scott;

Thanks for the info.  Did u get an opportunity to read the comments that Kathy and I have had regarding the conflict (approx 4 hrs + ago)?

I haven't gone any further than where we left off yesterday.

I wish we could talk....

Rick

I have having the darnest time trying to load in these images that I have cut and saved to my desktop.  It keeps asking for an html site and I can't drag them into this forum area....anyone have a clue?

Here is where we are having the conflict it would appear, but really of any concern according to an earlier post.  So naturally, I'm lost - which I guess everyone else knows that by now....

Answer 43

Bill

Thanks for the info.  Once you get it cut, how do you get it in the forum?

Rick

Answer 44

Rick,

What exactly, is your question there?  Once you have saved an image my earlier answer already told you how to get it into the forum from your PC.

Answer 45

Kathy;

I think I know how to get into the forum.  Since I started these questions many moons ago.

Please note the questions I asked Scott and Bill.  I have saved many images on my desktop but the forum wants and "http link".  It's on my "C".  I may be missing something really common to you brighter computer folks and that is why the questions...

Thanks for your help.

I answered this about three hours ago, but here ya go... ;-)

As for adding the image to a post, the forum software allows that. When you are in Edit mode, there is an icon on the toolbar that will allow you to upload up to two images per post, seen here...

Just click that icon, then, in the dialog which appears, click "Upload," and browse to and select the saved image, click "Insert," and "Bob's yer uncle!" you're done. If you want more than two images per post, that's another discussion, but this'll get you started.

Note that the "Insert Picture" icon shown above (red arrow) only appears when you are editing a message, NOT when viewing posted messages.

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 46

I didn't say "how to get into the forum".  I said "how to get it into the forum".  "It" - the image.  My earlier post explained it.

Answer 47

I finally tried something else that I hadn't done and it worked.  Thanks for everyone input.  Just be patient.  I have undergone Chemo treatment and now in the process of the healing my body.  Some things are a little slower than they were prior to all this...

I did the edit button on an earlier post (approx 1hr + ago) and you can see the conflict that I am having between desktop and server.

Someone suggested we run a Compatiablity check and see what the problem is.  Here is a snipit of that.

I don't understand the "p" issue, because those line items are in the DWT and have been there since day 1.  Again, this doesn't make sense.

Answer 48

Sorry for the misreading, again see my ealier post - somethings are still a little slow.

Answer 49

Gotcha. Well, it appears that you are connecting successfully, so that's one hurdle crossed. The compatibility issues are something else again; that's something to work on after we resolve your publishing issues.

OK, looking at the screenshot above, showing your connection at both ends, in order to run a publishing test, first click on a file on the left (local) side that also appears on the right (remote) side. When that file is highlighted, you should see that some of the blue arrows in the center bar, between the two file panes, are now lit. If so, click the right-pointing blue arrow to publish the currently highlighted file to the right side.

If the file published successfully, you should see that file's status change from "conflict" to "unchanged" on both sides of the display. Go ahead and try that now and let us know what happens.

Just so you know, if that works, what is probably happening with your images is just a pathing issue, something we run into all the time here. I'm going out for a few hours, but I'm sure that Kathy or someone can help you when you report back if I'm not back yet.

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 50

Compatibility check has nothing to do with publishing.  Publishing will let you publish a page with complete garbage in it, if for some reason you wanted to do that.  :)

Compatibility report is showing you errors, and it means exactly what it says: you can't have a paragraph inside of another paragraph, and apparently you do, or have coding errors (a missing closing tag, for example) that leads the parser to think that you do.  Go to the line numbers indicated and look.

As for the <embed> tag - it would be an <object> tag in XHTML (http://www.alistapart.com/articles/flashsatay), but depending on the context and browser support, you may also just keep using <embed>.  It won't validate, but if it's needed to work, you would ignore that.  (Check in *all* browsers to make sure what you are using works.)

Answer 51

What Kathy said. You say,

"I don't understand the "p" issue, because those line items are in the DWT and have been there since day 1.  Again, this doesn't make sense."

Which day one? Are you saying that this page has never been edited? No new text has been added, or paragraphs? It only takes one improperly closed <p> tag to affect every element that comes afterward. If you're supposed to have this...

<p>This is a paragraph marked up in HTML.</p>
<p>This is a paragraph marked up in HTML.</p>
<p>This is a paragraph marked up in HTML.</p>
<h1>This is a heading 1 marked up in HTML.</h1>

but instead you have this

<p>This is a paragraph marked up in HTML.</p>
<p>This is another paragraph marked up in HTML, but unclosed.
<p>This is a paragraph marked up in HTML.</p>
<h1>This is a heading 1 marked up in HTML.</h1>

Notice that the only difference between the two is that the second paragraph in the second example has no closing tag, no </p> to tell the browser, or the validator, that the paragraph has ended. As far as the code is written, whatever comes afterward is still a part of that open (not yet closed) paragraph.

One of the rules of the standard that the validator is using (XHTML 1.0 Transitional) says that a paragraph may not contain other block elements. Any block elements—paragraphs, divs, headings, lists, and many other elements are block elements—so every time one is declared in the code, until that paragraph is closed, it will generate another message like you see in that check.

The compatibility check is important, but using it to resolve issues requires some degree of understanding of HTML, and the ability to edit HTML in order to resolve the issues revealed by the check. The compatibility check is actually checking your code, your HTML markup, against the standard you currently have set in Page Editor Options. At some point you need to understand HTML enough to correct those validation errors, but that can come later. For now, let's concentrate on your publishing process. Have you tried the procedure suggested in my previous post? What happened?

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 52

Scott;

"If the file published successfully, you should see that file's status change from "conflict" to "unchanged" on both sides of the display. Go ahead and try that now and let us know what happens."  I don't how to make the colors, etc.  so bear with me...

Here is what happened:

I can't keep the failed tab at the bottom to stay open long enough to read it. How can I keep it open so that I can get a screen shot and let you guys know what happened?

Rick

Answer 53

Kathy;

Thanks for the comments.  I went back to the original data file that I had when we created the DWT and they are in there.  I didn't think it would work in EW 3 if things where wrong so as long as they went to the web and it was the way we wanted it - who cares?  Do you see our logic?

We thought if it went to the web - everything is ok.  I guess in EW 4, you can go any further until you fix those issues.

Since I was in the original file, I made the changes to the DWT and tried to save and again it failed because I don't have permission as has been discussed back on Friday, October 12th.  So I will attempt to change the BK up file, which is the file I removed the vti file I was told I didn't need.

Rick

Answer 54

Scott;

Thanks for the info, which is similiar to what Kathy said.  I responded back to her regarding the "p" issue.  I saw them in the DWT but didn't understand why it was working.

Very little has been changed on the DWT and again the techy person that we paid to do it...set it up (right or wrong) - it worked.  And we were happy.

Now that we are using EW 4 those issues have come to light and we are stuck trying to fix them...   Day one is referring to when we created our website with EW 3 and has been on the net for 3+ years now, if my memory serves me correctly.

I know some of the basics in HTML and knew that what has happened above wasn't suppose to be that way.  But again, I knew it was working, not knowing why, so I let it ride thinking that the person that created this knew a whole lot more than me.  Does that make sense?

I did try the publishing process as described and I responded to your post about 7-10 minutes ago, a couple of discussion panes above.  You should see the error msg I rec'd.

Rick

Answer 55

" I went back to the original data file that I had when we created the DWT and they are in there.  I didn't think it would work in EW 3 if things where wrong so as long as they went to the web and it was the way we wanted it - who cares?  Do you see our logic?"

No, I don't see your logic.  You are mixing things that have nothing to do with the other.  Compatibility reports, as I already explained, are not related to if the pages publish.  Or even if they work in a browser - browsers can forgive a lot, although you should fix the errors you can.  There is nothing different between EW3 and EW4 that has to do with publishing permissions, or local file permissions.  You have publishing issues, local file saving permission issues, and compatiblity error issues.  They are not all the same things, and compatibility errors have nothing at all to do with the others.

Fix the local file saving permission issue first.  If you don't have permission to save a modified DWT to your PC, something is hosed and there is no reasonable expectation that everything else will work.

Answer 56

Well it made sense to us.  If it worked and if you believed the person setting up the site was a lot more knowledgeable than me, then I would stay out of the way and not question.

You did hit the nail on the head when you said I have publishing issues, local file saving permission issues and compatibility error issues.

Again you are right in your analysis that I have to fix the local file saving permission issue first.  When I find the problems and can't save the file after I fixed the problem, how can I ever get this fixed?  Many of these fixed errors will solve the compatibility issues.

Your last sentence is what I was thinking all along....if it worked - what's the problem?  And believe it or not - the website works!  I test it almost daily, and trust me, I've been doing that multiple of times daily since this conversation started.

Hey I have another question for all you folks----

Transitional the tab "embed" is not permitted.   That is an issue I have.  We used this in EW 3 and it has worked up until now.  Do I just delete it or is another word more accepted in EW 4?

FYI to everyone - There is a ticket in with our Hosting Server folks.  They also recognize the "permission issue" and hope to have it resolved very soon.  Now maybe that problem will go away....we'll see.

Another question I have is "Transitional the attibute "align" is not permitted for the address tab.  Huh?  What does that mean?

Is there another word that we should use - again this was used in EW 3 and never had a problem that we were aware of.

Answer 57

Rick, seriously, please listen to me. Until you resolve your permissions issues, you are dead in the water, and compatibility issues do not matter! By continuing to bring those issues into the discussion, all you are accomplishing is to muddy the waters and dilute the focus on what you should be working on.

Until you can do normal file manipulation locally (opening, saving, transferring files), and successfully publish to your remote site, nothing that you do to resolve compatibility issues will be of any import, since any changes you make cannot be published.

Now, it sounds as if you have local and/or remote permissions issues to resolve. It is clear from that screen shot that you can successfully connect to the site. If your transmission failures, indicated by the error message you saw, are caused by permissions issues at the server, then there is absolutely nothing we can do here to resolve them. That is something that your provider must resolve.

If you are also having permissions errors locally, I have a suspicion that they may be because the site is on an external drive. There is a way to resolve that. Since you say that the online site is working fine, let's create a new, local site, on your internal hard drive, and publish the remote site down to it. That will give you a new, pristine site, and should eliminate local permissions from the issue.

To do this, create a folder on your hard drive and name it (without spaces) for your local site. Now, go to "Site|New Site...", select "Empty Site," then browse to the new folder you just created and select it. Check the "Add to Managed List" box, make sure the Name is what you want, then click OK. Now, once the new, empty site is open, click the Site View tab, then the Publishing tab, then "Add a publishing destination." Use the same information you used in the other site.

Once everything is ready to go, click the "Connect to the current publishing destination link." Once the connection is established, highlight everything on the right hand (remote) side, then click the right-to-left blue arrow to publish down to the new site, then report back.

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 58

"And believe it or not - the website works!  I test it almost daily,"

That has nothing to do with any of your questions.

"Transitional the tab "embed" is not permitted. "

I already answered that in an earlier post.  And it's not an important part of your issues.

Please start a new thread, completely separate, for questions about compatibility.  It is entirely unrelated to publishing and file permissions, and, frankly, should be the last thing you are focusing on if you can't make changes and can't publish.

Answer 59

Scott;

1)  "Until you resolve your permissions issues" - As stated, they are working on the permission issue.

2)  "compatibility issues do not matter"  - They may not matter at the moment due to the permission issue, but they should be important.  I have gone through all the pages that had issues and cleared the compatibility problem.  My number of issues has gone down from what it once was!

3)  "If you are also having permissions errors locally.."  -  I resolved the permission errors locally by deleting the "vti\pvt" file from the desktop bkup file as previously discussed.  After I did that I was able to make changes to the local desktop bkup website data file.  However I still was not able to publish.  Now it appears the permissions issue is being caused by the hosting site and they acknowledge that.  So I believe once they get that fixed I will be able to move the files to the server.  I had forgotten 2 weeks ago, they created/bought/built a new server.  Everytime they do something like that, it has always created a problem with something until we call and complain.

4)  "publish the remote site down to it" - Ahead of you.  I did that in the beginning when I couldn't load the files from the external hard drive.  That is what I am calling the bkup file.  That is the file I am using.   Since the vti file was deleted, I could make changes to the files.  What I was sure of was the vti file needed to publish and apparently not.  Again it appears the permission issue is holding up the process.

5)  "create a folder on your hard drive and name it" - I thought I would go ahead and try it using EW 4 (I did mine through CORE FTP) and see what would happen.

Here are the files from the server (what you can see that is):

I click the blue arrow to move all the files to the file folder on the desktop and here is what we got back:

Again, we have an issue with the "vti".

6)  This is why I was working on the things in my control, fixing the compatibilty issues, since apparently they were caused by things from the person that setup the site. That was the reason for my questions on the remaining issues. Once I get those fixed and they get the permissions issue fixed - I should be able to upload the data to the server. Isn't that a possibility?

Have a great afternoon!

Rick

Answer 60

You should not publish _vti folders or files down from the host, or, for that matter, the aspnet_client folder.  Or, unless you created it as part of your site, the Archive folder.

_vti_inf.html is a FrontPage Server Extension information file - do you have frontpage server extensions installed on the site?  (What is your site's URL?)

Answer 61

If you have any "_vti_xxx" files or folders on the remote server, and you are not using the FPSE for publishing, you can (and should) safely delete them from the server. Locally, they will be present if you are using metadata site management in EW, and if deleted, will be recreated by EW the next time the site is opened. Although they are used for site management by EW, they will not be displayed in EW (which treats them as hidden files), although they can be seen in Explorer or any other external file manager.

So, if I read your last post correctly, you are currently able to open locally and edit and preview any of your files locally, saving your changes. As far as publishing is concerned, your hosting provider has acknowledged that there are permissions issues, which they will resolve. It certainly sounds as though, once that is done, you should be able to publish.

So, as for your compatibility issues, your best advice is to work from the top (of your code) down. Again I will remind you that the compatibility check is checking your HTML markup, your source code, for compatibility with whichever standard you have selected in Page Editor Options. Therefore, to correct the errors, you must work in code view, and you must understand enough about HTML to know what the errors are telling you, and how to resolve them.

If you recall, having a single unclosed paragraph can cause a cascade of errors down the page, as every new block element created on that page generates a new error, since paragraphs cannot contain block elements. When you work from the top down, and close that first paragraph, you may find that dozens of other errors on the page suddenly vanish. So, always work top down. And keep us updated on your publishing status.

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 62

Scott;

The hosting people reported back that the permission issues are fixed.  So I went back to your post on 1/16/12 @ 11:20pm (that what shows on my screen, not sure if that is your time or my time) where you mentioned dragging a file from the local site (left side) to the remote side (right side) and I did that.

Notice that the words came back unchanged as you had indicated.  I went to the website and the name of the images where there but not the image.  I decided to upload the image file like I did the location file.  Checked the website and refreshed the page and everything was there.  Just like we had wanted.

Since then, I have made a change to another page and uploaded it.

It appears now I should address the compatibility issues.

I looked the 1st one as you stated and it deals with the on demand video page.  I tried the changes that Kathy had suggested (via an article by Drew McLellan).  When I got to thinking about these changes and I reflected on where they came from....I decided not to save them.  The people that host our video data provided that code for us to put in our website.  It has been working without any problems, so I think I will ignore the compatiability issue with that particular one.  I know I don't feel confident enough to make changes to this part of the website.

As for the "align" issues, they would appear to be relatively easy fixes.  If the word is not allowed for the address, then what word is allowed?  To me it seems like a simple substitution.  Am I wrong on this?

Answer 63

Scott;

The hosting people reported back that the permission issues are fixed.  So I went back to your post on 1/16/12 @ 11:20pm (that what shows on my screen, not sure if that is your time or my time) where you mentioned dragging a file from the local site (left side) to the remote side (right side) and I did that.

And...?

;-)

Was the transfer successful? Did the file's status change from "conflict" to "unchanged?" Did the action complete without generating an error dialog? How did it go?

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 64

Scott;

You only read the 1st paragraph.  Please look at the image inserted underneath the 1st paragraph and the following paragraphs under the image.  Hopefully, you can help me with my next issue.

Thanks for your help.

Rick

Answer 65

Actually, at the time I read that post, that first paragraph was all there was.  Note that I hit "Quote" and quoted the message as it existed then, which is why I responded as I did. I note that the post was later edited by you (40 minutes after my reply ;-), apparently adding the remainder of the information now showing. Tsk, tsk...  ;-)

Anyway, no biggie. That's great to hear, that you are now able to edit and publish your changes. And you are correct, now is the time to address your compatibility issues.

Now, as I have stated earlier, these are issues of code compatibility. That is, how compatible is your code, as written, your HTML markup, with the XHTML 1.0 Transitional standard that you have declared in your doctype statement. I went to where I think your site is, then used Firefox's Web Developer Toolbar to validate it, and it passed with flying colors, save for one BOM warning, which is nothing to worry about for a non-PHP site. See the validation report here.

Since the compatibility report checks all pages of the site, while the validator works with one page at a time, apparently you have markup on one of the other pages that is non-conforming. When you are looking at the report, note that it will tell you which page a given error occurs on, and, IIRC, double-clicking the error will take you to that page, with the error highlighted, so you can correct it.

As for "align," that is what is referred to as a presentational HTML property—it describes how the content is to be presented to the viewer. All such properties, save a very few that apply to images, have been deprecated for many years, ever since the adoption by all major browsers of support for CSS 2.x.

To resolve such issues, remove the property from the markup. If that affects the display, use appropriate CSS to achieve the same objective. For example, if the object being aligned is an inline element, such as an image, assign "style='text-align:left;" to its parent element (its container), which will achieve the same effect as "align=left" as an HTML property.

Read the compatibility messages that are presented to you, and correct them one by one, starting from the top down. As for "object" versus "embed" for active content, support among the various browsers has been all over the map, unfortunately inconsistent, so it is quite acceptable to ignore those warnings.

I have always said that validation is a goal, a troubleshooting tool, not a religion. Correct the easily corrected deprecated code errors, etc. And, you will often find that 3rd-party-supplied markup is invalid (for example, the BBB Online-supplied icon code doesn't validate ;-), so you will often just have to live with invalid markup from others. If your site looks OK anyway, don't sweat it.  ;-)

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 66

Scott;

Thanks for your help.  As you can see, I still don't have this forum stuff down either....LOL.

You were correct - that is our site!  And I did go to the validation report.  Don't know what a BOM found in UTF-8 file is, but like you said, "which is nothing to worry about for a non-PHP site."

I didn't know how to use the report and find the page that had the error.  Since it only runs one page at a time, do I open our site with one of the pages open and somehow tell this report program to validate????

Currently I think I only have 3 pages that have compatibility issues.  All but 1 revolves around the "align" issue.  One even says this:

To finish out what isn't readable, "Newer constructs are available."  Which is what I think you were trying to say with your comment, "which will achieve the same effect as "align=left" as an HTML property."

I will try that and see if it works.

Here is the coding so that you can see what the compatibility scan is picking up:

I deleted out the "img" before the word "align" and naturally all my images went away. So I quickly put the img back in place. Now I confused about what we need to correct...

Rick

Answer 67

Hmm, OK, see what you mean. First, a BOM is a Byte Order Mark, used when UTF-8 (double-byte) character codes are in use. The significance is that it can cause issues in PHP pages, but shouldn't be an issue for HTML, so nothing to worry about.

If you want a quick and dirty way to view each of your pages, then run a validation report on each, download and install the Firefox browser (which you should always test in anyway ;-). Then, using Firefox, go here and click "Add to Firefox." Restart Firefox.

Now you can browse to your site, and for each page, on the Web Developer Toolbar, click "Tools|Validate HTML," which will send that page to the validator. That will permit you to go through your site, page by page, and use the full, verbose, validation report to fix your issues, working with your local copy. When complete, publish the revised pages up to the server (now that you can edit and publish successfully ;-).

OTOH, EW's Compatibility Report has a number of things going for it, as well. For example, you can choose which parts of your site to work with. Note the choices in the opening dialog...

In "Check where:" you can choose from All, Current, Open, or Selected. So, you can first open only the pages you want to work with in that session, then choose "Open Pages." Or, in Site View or the Folder List, use Ctrl-click or Shift-click to select the files to work on, then use "Selected Pages," and so forth. You can limit or expand the scope to suit yourself, depending upon how granular or wide you want the scope to be.

Now, once the report is generated, EW offers other benefits. Note the following display...

Note the red arrow pointing to the first error in the report. When you double-click that error in the list, EW displays the part of design view where the element is displayed (green arrow pointing to the text color), and above that, EW highlights the actual HTML markup comprising the error (the blue arrow showing the highlighted color value "darkred").

(As an aside, I had to look through several pages to find an issue that would be reported, because I hand-code my own markup, and I write pretty tight, standards-compliant markup ;-)

Anyway, this allows you to step through each compatibility issue, one by one, and resolve, or ignore, them as you go. Why ignore? Well, as I've mentioned earlier, not every incompatibility is a problem. For example, in the illustration above, the "problem" is the property value assigned, darkred. Although this color name is one of the valid 147 HTML named colors, and is displayed correctly in all browsers, it is not one of the sixteen named standard colors (red, aqua, maroon, navy, etc.). To my mind, this is incorrectly flagged as an issue, and it does not affect page display in any way, so it may safely be ignored. (FWIW, expressing the color using its hex equivalent, #8B0000, would also eliminate the "error.")

Likewise, the only other "error" listed there is a complaint about the background color chosen for that text, pink, which, again, is not one of the "sanctified sixteen," but is one of the recognized 147, so I ignored that one, too. So, my code is essentially 100% compatible with XHTML 1.0 Transitional. Out of curiosity, I used the "Validate by Direct Input" method to copy that markup to http://validator.w3.org/#validate_by_input, and it found that "This document was successfully checked as XHTML 1.0 Transitional!" with zero errors.

So, EW's Compatibility Check may be slightly out of sync with the W3C validator, but it is very convenient, since you're working in EW the whole time, and can do everything in the same environment.

Finally, as for your "align" issue noted above, the thing to do when you have a deprecated HTML property (and "align" is definitely deprecated) is to remove the deprecated property, not the element it describes. So, in the markup "<img align='top'...", you would delete the "align='top'" part, not the img declaration. Frankly, it's been so many years (over a decade) since I've used HTML presentational properties that I had to look up the img align property. Here is what the w3schools has to say about it. I would suggest that you go ahead and remove it, then Preview in Browser to see the effect it has, and if necessary, apply CSS to achieve the desired effect.

Depending upon the number of issues you have, compatibility checking can take time. Or, more accurately, the check itself doesn't take much time, but resolving the issues can. And, since it is checking the actual code, you have to understand enough about HTML to be able to resolve those issues which need to be resolved, or to ignore those issues which can safely be discounted.  ;-)

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 68

Scott,

The words do flow from your finger tips. Good on ya!

Answer 69

Heh, heh... Thanks, TB. ;-)

Damn! Just noticed, This incredibly crappy forum software has shyte the bed again! Both of the images in that post have vanished. In Firefox, they just don't show at all. In Chrome and IE9, they show as the "x in a box" missing image icon. Sheesh!

Lovely. Guess I'll have to edit the damned post and use the tried and true method of referencing from a NON-Microsoft location...

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 70

Damn! Just noticed, This incredibly crappy forum software has shyte the bed again!

... a NON-Microsoft location...

cheers,
scott

---

FYI The members of this forum are NOT Microsoft employees.
You can rant as much as you like but we can’t do anything about this.
Etc. etc. etc.

This is the type of thing you say to others - how does it feel?  :¬P

#OwnMedicine

Answer 71

FYI The members of this forum are NOT Microsoft employees.
You can rant as much as you like but we can’t do anything about this.
Etc. etc. etc.

This is the type of thing you say to others - how does it feel?  :¬P

#OwnMedicine

Living up to your name again?

Answer 72

Badgerer,

Scott was explaining why his post initialy had "X" instead of pictures.  He was NOT asking us to do anything about it.  Do you really think he was?  Seriously?

Answer 73

Nah, he's just endeavoring to remain in character—a useless little twit who doesn't know enough to actually contribute anything to the forum, so he snipes at those who do.

Badgerer, you pusillanimous little worm, since you are obviously comprehension-challenged, I wasn't asking for anyone here to do a damned thing. I was complaining, as every regular contributor here has done since the establishment of the forum, about the shortcomings of this lousy, inadequate forum software, and explaining why viewers couldn't see my images, and ho I intended to rectify that.

At no point did I ever ask for technical support from the forum, nor say anything that even intimated that I thought anyone here was a Microsoft employee. Therefore, your terminally cute little jibe had no relationship whatsoever to reality, and your "tongue sticking out" emoticon just makes you look like the insipid, infantile little jerk that you are.

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 74

Common Scott, don't hold back. Tell us how you really feel.

Answer 75

Scott;

Not only could I not see the images that were behind the red X, I couldn't even reply nor ask further questions that I had.  I don't know what happened.

Will try this again.  Wow, this just updated within the last few minutes.  Now maybe I will be able to get on the same page as you.

I wasn't aware that you could double click the error and I sure didn't know that EW opened up to more info as you described.

FYI, I have eliminated most of the "align" issues I had.  I only have 19 more compatibility issues remaining, (4 of which I won't touch with a 10 foot pole).  Seven of the remaining issues evolve around a "calendar" that we also downloaded from the net and put it into our site.  This is also wording that they provided, very much like the previous problem and I'm questioning if I should change it....

And here is the Compatibility tracker comments:

I forgot to add arrows as you did, but I'm thinking that EW is telling me that the uppercase "M', "B", "A", etc must me in lowercase.  Is that correct?  Why would that make a difference?

Next it tells me for the same line (186) that the attribute values must be in quotation marks.

I double clicked the error and it highlighted the word "NAME" which I didn't have in the image above, but it is also in uppercase letters.  I started doing the double click issue and fixed the problems as I go.  Hopefully this will elimiate the final issues.

Rick

Answer 76

Ignore those errors.  Look at your source on the published page: those aren't styles for the page, or XHTML markup:  those are href's with query string values.

[In future, as is said in the Forum "Start Here" FAQ,  please provide a link to the page in question.]

This is in the page as sent to the browser

<td bgcolor="ccbbbb" align=center><a href="/sol_calendar/d01/02/2012?display=M&style=B&positioning=A"><font size=2 color="000000">Feb</a></font></td>

Remember, you need to validate what the browser actually sees, not what is in Code View, if the two are different.  They will be different if the page contains scripts that change the page, such as a script calling the calendar.  When in doubt, validate the actual page using online validation tools, not EW - EW can only validate Code View.

Answer 77

Right. As Kathy said, the compatibility checker in EW can only work with the markup as seen in code view. When the page is rendered in a browser, scripts such as 3rd-party features (your calendar) may generate code that is not seen in the unrendered markup that EW uses. Therefore, submitting the online page to the W3 validator may reveal issues not seen in EW, or resolve issues EW notes.

That is why I suggested earlier that you install Firefox and the Web Developer Toolbar. They're not absolutely necessary (you can go to the W3 validator and paste in your page's address), but they do make testing, validating, and troubleshooting much easier.

Finally, I noted earlier that validation is a tool, not a religion. Sometimes you will get markup from third parties that doesn't validate, or something may even be incorrectly marked as incompatible (like HTML named colors in EW). Compatibility checking and validation are tools to be used in resolving issues, not dogma that must be adhered to at all cost. If your page renders as expected, but something is marked incompatible or invalid, ignore it. You're the final arbiter.

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

Answer 78

Scott;

I forgot to mention in my earlier post that someone did showed me how to get into the Web Developer Tool, but I never used it probably I didn't understand it very much.  We used to see to how code was done for sites that we liked and wanted to learn what/how they did it.

That was a long time ago.  I used your links to download and restarted Firefox.  But I don't know how to get it up.

Rick

Answer 79

I thought you might be the sort that can dish it out better than they can take it! :P

Perhaps you will think a bit before being so rude to others.
Goodbye...

Answer 80

Scott;

I forgot to mention in my earlier post that someone did showed me how to get into the Web Developer Tool, but I never used it probably I didn't understand it very much.  We used to see to how code was done for sites that we liked and wanted to learn what/how they did it.

That was a long time ago.  I used your links to download and restarted Firefox.  But I don't know how to get it up.

Rick

Wow, that's just too wide open... Must...resist...temptation.

OK, now, let's see... It's possible that it's already "up"and you just don't know what to look for. I presume from the above that you got Firefox installed. If you also went here and clicked "Add to Firefox," then the WDT has been installed. After restart, you should see a new toolbar up in the browser chrome, below the menu bar, address bar, and favorites/bookmarks bar, like this...

Each of those choices invokes a menu of developer tools (hence the name ;-). For example, to validate one of your pages, browse to that page, then click "Tools" in the WDT, which will show this...

As you can see there, you have a number of choices. Selecting "Validate HTML" will send the current page to the W3C validator. You can also check other factors, such as accessibility, CSS, etc., if you wish. The other tools on that toolbar allow you to delve as deeply into the inner workings of the page as you care to, and even to edit the page and the CSS on-the-fly, to try to troubleshoot problems with the page.

Many of the tools available do require that you know and understand how HTML and CSS work. If you have the time and the desire to learn, there are many free training resources listed in the Learning Resources and Reference Sites section of the Forum FAQs and Guidelines - Start Here. In particular, the free, bite-sized lessons offered in HTML and CSS at http://w3schools.com/html/ and http://w3schools.com/css/ will provide you an excellent grounding in the principles underlying the Web, and will enable you to understand and use the tools in the WDT to analyze and troubleshoot issues with Web pages.

There are, IIRC, 150 short, focused lessons in each course, each with a "Try It Yourself!" little mini-exercise to illustrate and help learn each principle. And, they are self-paced—you can do as many, or as few, of them at a time as you like, in any order, or just use them as references whenever you need to. Your choice!  ;-)

Now, if the blasted forum software doesn't send those images off into never-never land again, that should help you find the WDT and try out some of its features. Give it a try and see what you think...

cheers,
scott

---

Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.