This content has been marked as final. Show 17 replies
It sounds like you're experiencing the same issue discussed in the Error Editing Page topic...
Please take a look at the following Tech Note which discusses the issue:
Error: "The operation could not be performed because a problem occurred while attempting to connect to the server" when trying to edit a page using Adobe InContext Editing
After successful login in InContext Editing or when navigating to a page in your website while the InContext Editing toolbar is displayed, you receive the error "404 File or Directory Not Found", or, depending on the server configuration, a custom error page is displayed instead.
If you try to edit the page you will receive the following error message: "The operation could not be performed because a problem occurred while attempting to connect to the server. Please check your Internet connection and try again. For more details, please visit the InContext Editing Support Center".
InContext Editing requires the HEAD HTTP request method to be enabled and functioning properly for a registered web site. InContext Editing will not function properly if the HEAD HTTP request method is disabled or if it does not function properly.
InContext Editing is using HEAD requests to check the existence of the draft and published versions of the current page. If those calls do not work as expected (the HEAD should return status code 200/304 if the checked page exists, 404 otherwise) then you will experience this behavior. In most cases the problem appears on web servers running IIS 6 or 7 with PHP installed as CGI, but this problem may occur with other server configurations as well.
Contact your web hosting provider for assistance. This may require changes in web server configuration.
Thanks for your directions and apologies for the spelling errors on my first contact.
The diagnosis that it is a web hosting provider issue can be rejected in this case because the successful edit and publication of the demo "news-start.html" was provided by the same web hosting server so that is not the issue - in this case anyway.
On considering the importance of <HEAD> to InContext Editing, I realise that the pages that were failing were all ones whose <HEAD> was fully 'immersed' in the Dreamweaver Template for the site. On copying the page and removing it from the template, I could add it to the demo site and could then successfully access, edit and publish it without the ERROR 404.
So the problem is in relation to Dreamweaver Templates which may need adjustment to accommodate individual page <HEAD>. I need to find the support documents on using InContext Editing with Dreamweaver templates to get round this problem, I think.
Any suggestions or new directions greatly appreciated.
I think there has been a misunderstanding – the technote refers on the HEAD HTTP request, not to the head tag in the html page.
The problem is that when InContext Editing makes a HEAD http request to your server (to check if the your-page_draft.htm exists), the server responds with 200 OK response code. This should mean that the page exists, so InContext Editing proceeds with loading it. However, the page does not exist on the server, so the “page not found” error page is displayed.
From this reply: "..successful edit and publication of the demo "news-start.html" was provided by the same web hosting server so that is not the issue..." I understand that you have (or had) a page working, that was not showing this problem. Can you give us an URL to a page on the same server, that does not show this behavior?
Thanks you for your help and clarification.
I successfully loaded the (non-template) version of the page to:
and successfully edited, saved and published.
Sorry, perhaps I was not clear before. I was under the impression that you have (or had) a page working on the http://www.andrewleestrust.org site.
On this new URL- http://www.sitepreviewer.co.uk/FOUR/links.htm - it works properly because the server throws a correct error code (404 not found) when the InContext Editing service checks for the existing of the draft page.
Thank you Florin.
I have contacted support for the hosting service that hosts all my websites across about 12 servers. I asked if HEAD HTTP was enabled on the Andrew Lees Trust server and their reply was:
"Thanks for contacting us.
It is enabled across all our servers which you can verify by simply accessing your web logs or perhaps even performing a telnet to the website. All our servers are LINUX based and we do have PHP installed as CGI.
Hope that helps. "
I have successfully created, edited, saved and published changes for 3 separate websites each hosted on 3 separate servers at my hosting provider service, some old and some brand new.
One of these successes is hosted on the same server as the unsuccessful www.andrewleestrust.org.
None of the successes were websites featuring a Dreamweaver template.
Next I will create a new site based on a Dreamweaver template and load it to a 'proven successful' server. I will let you know the result.
I have this problem as well. When I try and edit a page (testincontext.html) using Cmd-E in Firefox on a Mac I get the custom 404 page for my site. This is a simple html page with one editable region, no includes, no server-side code.
I did manage to successfully edit by manually creating a testincontext_draft.html file on the server and then ctrl-E did allow me to edit the draft page and publish it. Once the draft page has gone however it reverts to the 404 behaviour.
Any ideas? Maybe it's something to do with the way the draft page is being checked for?
I have had success with templated sites, editable region sites and plain html pages on a variety of servers and am generally getting on well with the InContext Editing and its functionality.
However there is still this one website (the one that really needs it) that keeps throwing up the Error 404. I've tried changing the location of the CSS so it is not within the template but still get the Error. I've detached the page from the Template and had success with the editing. I continue to try and identify the problem and will post a message if I ever solve the problem. I don't think it is Florin's suggestion that it is a server setting issue.
Meanwhile are you setting the CSS to be used on the editable page before uploading the includes? ( INSERT> InContext Editing > Manage Available CSS Classes).
I have now identified the cause of the Error 404 for this one problem website. A CGI script called "404/500 Error Page" (Version 1.1) providing customised Error pages was in place on this website's server. Once the CGI is removed from server the CTRL+E allows access to edit,save and publish changes successfully.
Good to have finally identified that problem
I switched off custom error pages on my web server and now I can edit the html file using InContext editing. I'm still getting an error when trying to edit asp pages though. Can asp pages be edited using InContext or is it just for plain html pages? The asp page in question has plain html blocks and the editable region is in one of those blocks.
Good to hear you also have identified Custom Error 404 as the issue.
I'm afraid I can't help with the asp issue. Perhaps Corey or Florin have some ideas.
Good to know you're making progress too.
Originally posted by: pluckerster
I'm still getting an error when trying to edit asp pages though. Can asp pages be edited using InContext or is it just for plain html pages? The asp page in question has plain html blocks and the editable region is in one of those blocks.
I did a simple experiment with an asp page and incontext, and here is what I found:
The plain html on an asp page is updated without a problem, but because asp returns html when the page is displayed, if you update the html that the asp code returns, then it turns the asp programming part into html, with no asp left in it. Basically, if you make a change to the end result, you lose your programming.
I'm not an Adobe representative or anything like that, but I wanted to check things out for myself. I think I may have a reason that you can't update asp in this:
To me, (and this is just my opinion) this seems like something that Adobe developed for the non-programmer. Personally, I would never give any of my clients access to some of the programming that is "behind the scene" of their website. It's not that I care if they know the programming or not, I just wouldn't want them to mess it up and have to go back into it and fix it over and over again (This has been a problem in the past for me).
I guess what I'm trying to say is that when I look at this, it appears that they made it for a "non programmer" to simplify things for our clients, therefore, they shouldn't have access to the programming part.
This is just my opinion without knowing what your situation is.
I'm not an Adobe representative or anything like that
Thanks for that, I was thinking it would be odd to allow asp edits, but as the service accesses the server via ftp and only allows editing of editable regions I don't see why incontext editing can't be applied to static html parts of an asp page which can then be saved back with the code intact. It should be able to get the .asp file as source and only allow editing of the editable regions of the page which providing they don't contain any code should be fine. Hopefully an Adobe representative can advise on this soon.
What you say makes sense to me too, who knows, maybe they will update it.
Even if you can't update asp code, this is still a great service that Adobe is offering.
Pluckerster and Magikmarc,
Draw your attention to the "Known Limitations and Issues" list Corey has put up:
On the Pages section it says: "InContext Editing can edit only static content from inside dynamic pages. If dynamic content exists inside an editable region (or repeating group), it will be lost. "
Do try and start a New Topic next time so others following on can quickly identify with your ASP issue.
"InContext Editing can edit only static content from inside dynamic pages. If dynamic content exists inside an editable region (or repeating group), it will be lost. "
I did read that information and was expecting a static editable region in an ASP page to be editable but it doesn't work.
I also did start a new topic here http://tinyurl.com/854d8q