written by David Anglin

Troubleshooting In Context Editing

In this article, you'll learn methods to solve the most common issues that may arise when using InContext Editing. The first part describes issues that may occur for users who are editing the site within the InContext Editing interface in the Admin Console. The later sections focus on issues that site administrators may encounter when setting up InContext Editing functionality for a site.

Issues using the editor

In this section you'll find suggestions to resolve issues that occur when using the InContext Editing interface to update a site.
Note: If you'd like to review the detailed instructions on how to use InContext Editing to update page content, see Using the InContext Editor.

Attempts to access the InContext Editing feature are unsuccessful

This system includes a convention known as permissions, which are applied to the roles that assigned to each user of the Admin Console. If you are not the site's administrator (the person who set up the site originally), it may be that your user account does not currently include the permissions necessary to access this area of the site.
InContext editing is accessed by clicking the Edit tab from within the Admin Console.

If you do not see this menu item in the Website tab, or if you try to launch InContext Editing, but cannot invoke it, it means that your user account does not currently have the necessary permissions to use it.
If you do not have administrative privileges, contact your site's administrator to ask if you can be granted the permissions (understanding that the ability to update the site comes with a great deal of responsibility). You may need to participate in training sessions first, to ensure that you understand how to use the InContext Editing interface to update the site.

Unable to edit certain content or apply formatting using the InContext Editing page

There are many ways that InContext Editing functionality can be configured by web designers. For example, text formatting features, (such as the ability to set text as bold or underlined) may optionally be disabled by site administrators as they prepare the web pages for publication. These types of restrictions are usually applied to help maintain site consistency across all pages--to ensure that the site displays a similar look and follows a standard design aesthetic as visitor navigate between pages.
It is also possible for web professionals to disable specific portions of each page to prevent them from being edited. The area may contain complex code or features that may be accidentally broken if they are edited. Other times, the area may contain sensitive material that a department has approved (such as legal notices, and End User License Agreements, among others) that should not be changed.
If you are able to log into the InContext Editing area through the Admin Console, but cannot update certain content or access specific formatting options, it is likely that you are simply encountering areas of the site (or features within the interface), which have been made unavailable. If you feel you should be able to access specific formatting features or edit a particular area of the page that is not currently editable, contact your site's administrator to see if the page configuration can be updated to enable the content or features. Alternatively, ask the site's administrator to update the content for you.

Difficulties navigating to the page you want to edit

Normally, browsing through the pages in the site while in the InContext Editing interface is fairly straightforward. When you log into the InContext Editing interface and begin the editing session, you are presented with the site's home page. If you want to edit a different page of the site, you can navigate through the site to edit linked pages. For example, the navigation menu items respond the same way as they do on the live site, so you can click them to quickly locate the page you want to edit.

To edit a page using InContext Editing that is not linked from the home page, you can enter the page's name in the address field of the browser while ICE is enabled:
For example, this is the URLthat displays when editing the home page with InContext Editing:

Edit the URL (after the equal sign) to access the Contact page:



Siteadministrator issues

In this section you'll find suggestions to resolve issues that occur when configuring the site to customize the editability of specific page regions and control how the InContext Editing interface works:

Restricting editing capabilities on specific pages

Generally speaking, you do not need to edit the HTML pages in a site to turn on InContext Editing. It is enabled by default for <div>, <td> and <th> containers. If the user has the necessary permissions, they can log into their site and edit the content that they have the ability to access.
For example, you may set the user's role to enable the editing of web pages, but not template files. Without making any changes to the page or template code, users will not be able to edit template content--although if you log into the InContext Editing interface with full permissions, you'll be able to edit both pages and templates. Since templates comprise so much of the displayed content in a site, and a single change could affect an entire site's appearance, it is recommended to not grant permissions to edit templates to users.
However, you may encounter situations where you want users to edit most of the web pages in a site, except for a few. In these cases, it is important to understand how to set specific pages as uneditable.
InContext Editing follows these rules:
  • If the page contains <div>, <td> or <th> tag containers, these areas are marked as editable by default.
  • However, if you specifically set at least one of these containers as an InContext Editing editable region, then all other <div> tag containers on the page are set as uneditable automatically.
So, while it may seem counterintuitive, the way to make a page non-editable in InContext Editing is to define a single editable region on that page. For example, you could create a <div> tag in the footer, or some other inconspicuous area that does not contain any text or image content, and then set that section as editable (using Dreamweaver or by hand-coding the tag). Ensure that at least one opening <div> tag has the following syntax:
<div ice:editable="html">
If you want to restrict the formatting abilities even further, use this syntax for the opening <div> tag:
<div ice:editable="html" ice:options="bold">
Publish the page, and log into the InContext Editing interface. Navigate to the page and test the editing accessiblity to confirm that the desired content is no longer editable.
Repeat this step for any pages that you want to specifically control the content, to maintain exclusive ownership of the page and protect sensitive content from changing. You may also want to let users know that you've disabled the editability of these areas, so that they understand why they are not able to update the content when they use InContext Editing.


Information from Adobe Business Catalyst Website



comments powered by Disqus