InContext Editing for Business Catalyst administrators

Additional Requirements

Business Catalyst extension for Dreamweaver

• Download

Business Catalyst free Partner account

• Learn more

In this article, you'll learn how to create new InContext Editing-enabled web pages and set them up to make it easier for your clients to edit their own site content—as well as steps to migrate an existing site that is enabled for InContext Editing to the Business Catalyst Platform. You'll also get information about the dependent files that are required to run InContext Editing and learn how to use the Admin Console to create roles, add users to roles, and set permissions to control precisely which page elements your clients (and their employees) can update. Once users log in to their site's Admin Console, the InContext Editing interface is very similar to using standard word processing software.

This article is divided into the following sections:

• Enabling InContext Editing
• Understanding InContext Editing roles
• Configuring pages to be enabled for InContext Editing with Dreamweaver
• Identifying the dependent files required for InContext Editing
• Hand-coding pages in a text editor to enable InContext Editing

Enabling InContext Editing

Adobe InContext Editing is a tool included with the hosted Business Catalyst Platform that enables you and your web clients to make simple content changes (update text, images, links and module content) within a web browser. To change a web page, your clients can log into their site's Admin Console, navigate to the page and then use InContext Editing to make any changes they want. The editing options are simple and elegant, and using them requires no knowledge of HTML code or other software, because the functionality is built into the online interface (see Figure 1).

Note: If you've used Business Catalyst in the past, you may be familiar with Sitewalk. InContext Editing replaces the Sitewalk functionality. At the time of this writing, you can still access it in the interface, but the Sitewalk feature is deprecated.

To create a new site from scratch, you need to enable InContext Editing and configure the pages using Dreamweaver (or a text editor). The Dreamweaver interface lets you enable InContext Editing on pages and specify which formatting features are available to users. Later in this article, you'll learn how to use Dreamweaver to define InContext Editing editable regions; you'll also learn how to hand-code editable regions with any text editor.

Note: Adobe AIR does not support Adobe InContext Editing. If you use the AIR Extension for Dreamweaver to export an application that contains InContext Editing regions, the InContext Editing functionality will not work.

Back to top

Understanding InContext Editing roles

InContext Editing is integrated tightly with the Business Catalyst roles. As a site administrator, you can add permissions to specific roles and then assign users to these roles. A single user can be assigned to multiple roles; a user can access features based on any permissions that are enabled for any of the roles to which they are assigned.

For example, you may choose to set up roles for the following sets of team members:

• Administrators: You and other trusted members of your web team that help develop the site
• Designers: Team members responsible for updating and maintaining site templates
• Content providers: Team members responsible for publishing new text and images
• Editors: Team members responsible for copyediting and fixing links
• Moderators: Team members responsible for approving submitted user-generated content

The list above is just a general list of roles—you are free to create any roles you desire, and name them whatever you'd like. It really just depends on the project. In smaller sites, perhaps only you and the business owner (your client) are allowed to update the site. In a larger project, you may have a large number of team members that focus on very specific areas of the site, or perform specific tasks. Business Catalyst offers precise control over who can edit, add, or delete content on the site—all based on how you set up the roles.

To create a new role, follow these steps:

1. Log into the site's Admin Console and choose Admin > Manage Roles (see Figure 2).

2. In the sidebar, choose the option to create a new role.
3. In the Role Details page that appears, enter the name of the role in the Role field (see Figure 3). Click Next.

4. In the next screen, select the desired user(s) in the left pane and click the right arrow to move them to the right pane to add them to the role (see Figure 4). Click Next.

5. In the Assign permissions screen, select the tasks available to users in this role by using the right arrow to move the tasks from the left pane to the right. Press and hold the Control key (Windows) or the Command key (Mac) to select multiple nonconsecutive items at once, or press and hold the Shift key to select a group of consecutive items in the list. After moving the desired tasks to the right pan, the role's permissions have been set.
6. If you like, you can now add other users to the system and assign them to the existing roles that you've already defined. To add new users, choose Admin > Manage Users. (The number of admin users you can add depends on the current hosting plan for the site).

As you can see from the steps above, you can separate tasks available to specific team members, based on the permissions that you grant to the roles they are assigned. Here's an example of how you could set the permissions:

• Administrators: All permissions are enabled by default (and should not be disabled)
• Designers: Add, delete, edit and view templates
• Content providers: Add, edit and view web pages; Add, edit and view photo galleries
• Editors: Delete, edit and view web pages; delete, edit and view photo galleries
• Moderators: Delete, edit and view blogs; delete, edit and view comments

Note: Only add the bare minimum permissions to each role that enable the users assigned to that role to complete the work they need to accomplish. Always err on the side of not providing enough permissions, rather than granting too many. Restrict access to tasks that could allow your clients or their employees to accidentally delete or disable site features.

For more information on setting up roles, see Creating roles and assigning them to users to add permissions.

Back to top

Configuring pages to be enabled for InContext Editing with Dreamweaver

When you use Dreamweaver to create a site, the InContext Editing features are built into the interface. In this section, you'll learn how to work with Dreamweaver to create InContext Editing-enabled pages and templates. If you prefer to hand-code the pages instead (using a text editor), skip this section and jump to Identifying the dependent files required for InContext Editing.

To create a new page enabled for InContext Editing, follow these steps:

1. In Dreamweaver, choose File > New. The New File dialog box appears.
2. Click Blank Page. In the Page Type section, choose HTML, then select one of the included CSS layouts. As you click each layout name, the preview area displays an example of the page layout (see Figure 5).

3. In the bottom right corner, select the option Enable InContext Editing (see Figure 6).

4. The new page appears. Always save a new page as soon as it is created. Choose File > Save, enter a name for the page, and navigate to the location in the local root folder where you want to save it. Upon saving the file, Dreamweaver displays the Copy Dependent Files dialog box (see Figure 7). Click OK.

5. Edit the page as you like, replacing the default text in the CSS starter layout with your own site content. Add images and other rich media to design the page. If you'd like, you can move the CSS rules from this page to a separate, external CSS file. To do this, select all of the rules listed in the CSS Styles panel (hold down Shift while selecting the entire list). Then, right-click (or Control-click) the selected rules and choose the option Move CSS rules from the context menu that appears (see Figure 8).

6. In the dialog box that appears, choose whether to move the rules to an existing style sheet or create a new CSS style sheet. Click OK.
7. Choose Site > Put to upload the new page to the remote server. The first time you upload the files, upload the dependent files (to upload the CSS file, the InContext files, and any other image or media files inserted on the page). Be sure to view the live site to check your work.

Using the default editable regions

If you do not specify editable regions on a web page or template, the InContext Editing feature in the Admin Console parses the code to identify the default editable areas of each page or template based on the layout and the elements that exist on the page. When editable regions are discovered, the interface identifies these elements by giving them dashed line borders (see Figure 9).

Identifying the different types of tags for enabling InContext Editing

HTML tags in the code of the page can be categorized into three types:

Type 1: Tags that can be set as editable regions

By default, the CSS starter layouts in Dreamweaver have the content <div> tag (the main content area of the page) set as the only editable region when you enable InContext Editing.

If you view the source code, you'll see the following syntax on the opening <div> tag for the Content area:

While it is convenient to use the default editable region set by Dreamweaver, you are not limited to only setting that area of the page for InContext Editing. Any of the following tags can be specified as editable: <div>, <td> and <th>.

To specify one of these tags as an editable region in Dreamweaver, use the tag selector at the bottom of the Document window to select the desired tag (one of the three tags listed above) or select the tag in either Design view or Code view. While it is selected, do one of the following:

• Choose Insert > InContext Editing > Create Editable Region.
• In the Insert panel, choose the InContext Editing category, and then click Create Editable Region.
• In Code View, edit the tag to add the following syntax right before the closing greater than symbol: ice:editable="*">

Save the page and then choose Site > Put to upload the file. Once you've inserted or hand-coded the editable region, your clients who access the InContext Editing tool from within the Admin Console will see the dashed border around this element, and they can use the interface to edit and format text, images and links.

Type 2: Tags that are not directly editable, but can be placed inside <div>, <td> and <th> tags

The following tags cannot be set as editable (either using the Dreamweaver interface or by hand-coding the ice:editable="*" parameter): <p>, <span>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <ul>, <ol>, <li>, <dl>, <dt>, and <dd>.

However, you can make these areas editable by placing them inside a <div>, <td> and <th> tag that has been set as editable. This strategy effectively enables the elements for InContext Editing, so that your web client can make changes as desired.

Type 3: Tags that cannot be set as editable regions, regardless of their parent tags

The following list of tags (also known as forbidden tags) cannot be edited with InContext Editing, even if they are placed inside <div>, <td> and <th> tags that are enabled as editable: <iframe>, <frame>, <noframe>, <script>, <map>, <area>, <object>, <embed>, <video>, <audio>, <noscript>, <style>, <applet>, <form>, <input>, <hr>, <select>, and <textarea>.

Defining custom editable regions

When your client edits a page using InContext Editing, the feature automatically defines editable areas and elements of the page that don't contain forbidden tags or Business Catalyst modules. These selections will be marked as editable regions.

If you'd prefer to enable specific areas of a page that your client can edit (besides the default editable regions that are pre-set in the CSS starter layouts), or if you want more control over which sections of the page or template are editable, you can choose to define your own editable regions. You can also specify which typography tools are available to use in each region.

Note that InContext Editing does not include an interface option or code that blocks an entire page from editing. If you want to prevent a page from being edited by your clients, the method involves defining one area that is editable (such as a strategically placed <div> tag in the footer area). If you add at least one editable region to a page (and remove the ice:editable="*" code from the content <div> tag, as desired), then the other areas of the page are automatically set as non-editable.

By default, when no region has been defined, InContext Editing uses an algorithm that parses the page and determines which areas of the page are editable, based on the page layout and page elements. Although it may seem counterintuitive, you must assign at least one custom editable region in order to prevent the default editable region (or supported tags) from being enabled.

Defining editable regions with Dreamweaver

To define editable regions in Dreamweaver, follow these steps:

1. Use the Business Catalyst panel (which is activated upon installation of the Business Catalyst extension for Dreamweaver) to connect to your Business Catalyst site through Dreamweaver. Enter your username and password in the Login area of the panel to start the connection (see Figure 10).

2. Choose the name of your site from the site list to select it. The first time you connect, the Quick Start Setup Wizard will appear; the wizard defines the site for you, directs you to select a local root folder, and facilitates the process of downloading the remote files to your local machine (see Figure 11).

Note: If you need to extend the duration of an expired trial site, log into the Admin Console, access the Partner Portal, and select the Clients tab. Click the name of the expired site to see its details, and in the page that appears, click the button to Extend Expiry (see Figure 12).

3. Once you have successfully logged into your site and defined it in Dreamweaver, create a new file, as described previously, or open an existing file.
4. Select a <div> tag (or a <th> or <td> tag) that you want to set as an editable region. Either choose Insert > InContext Editing > Editable Region from the menu, or use the Insert panel to select the InContext Editing category and then click the Create Editable Region option (see Figure 13).

5. Open the page in Design View and select an area that you want to make editable; then, click the Create Editable Region command. As mentioned previously, only specific tags can be directly set as editable regions: <div>, <td> and <th>. If the area you select to set as editable is one of the following tags: <p>, <span>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <ul>, <ol>, <li>, <dl>, <dt>, or <dd>, create a <div> tag or a table that surrounds the element, and then set the parent container of the element as an editable region.
6. The Create Editable Region dialog box appears, prompting you to choose between two options (see Figure 14):

If you select the first option, a new <div> tag will be added to the page, surrounding just the selected element. This offers more precise control.

If you select the second option, InContext Editing parses the code and finds the <div> container for the selected element, and converts that <div> tag to an editable region (which may also allow other elements on the page to become editable.

Be sure not to select the following tags when setting an editable region: <iframe>, <frame>, <noframe>, <script>, <map>, <area>, <object>, <embed>, <video>, <audio>, <noscript>, <style>, <applet>, <form>, <input>, <hr>, <select>, and <textarea>. These tags cannot be set as editable. If you attempt to set them as an editable region, an error message appears (see Figure 15).

You'll also see the following error message if you attempt to set an editable region inside another editable region (see Figure 16).

Defining the formatting options enabled for InContext Editing

In the previous section, you learned how to set an editable region for InContext Editing on the page. The syntax added by the Dreamweaver menu commands (or hand-coding) specifies that an area is editable like this:

The code above literally means: enable the content <div> tag for InContext Editing with all of the formatting options available to the editor when using the browser interface.

The asterisk (*) is a wildcard symbol; by default, the formatting options are all turned on.

However, you have complete control over precisely which tools your clients can access. This is helpful when you want to constrain their editing capabilities to maintain a consistent appearance across the site.

You can specify which formatting options are enabled in Dreamweaver. Follow these steps:

1. If it is not displayed, enable the Property inspector (Window > Properties).
2. Do one of the following:
   • In Design View, select the blue border of the editable region.
   • In Code View, click inside the <div> tag that contains the ice:editable code attribute.
3. After selecting the editable region, the Property inspector updates to show the entire list of formatting options (see Figure 17).

Deselect the options you do not want to be available in the InContext Editing interface. The formatting option descriptions are listed below (reading from left to right in the Property inspector):

• bold
• italic
• underline
• align options (left, right, center and justify)
• font formatting (the user can apply a font to a text element from a pre-defined list of fonts)
• font size
• indent/outdent
• bulleted and ordered lists
• paragraph and headings formatting (the user can set text elements as paragraphs or headings)
• background color
• font color
• Applying CSS styles (the user can apply a rule to a page element from a pre-defined list of rules)
• insert and edit image functionality
• insert and edit link functionality

4. After deselecting the desired options, look at the ice:editable attribute for the <div> tag in Code View. Since some of the options are now set as unavailable, the syntax has been updated. Instead of the asterisk (*) wildcard syntax, the names of the available formatting tools are spelled out explicitly. For example, if you deselect all of the options except bold, italic, and underline, the edited code looks like this:

The corresponding settings in the Property inspector are shown in Figure 18.

Inserting editable regions in templates (DWT files)

You can edit template files in Dreamweaver to add editable regions using the same syntax described above for web pages. You can set the same types of tags (or their parent <div> containers) and you can also specify which formatting options will be enabled when your clients access InContext Editing through their site's Admin Console. However, there are some minor differences when preparing templates for InContext Editing. Consider the following when editing DWT files for use with the browser-based InContext Editing interface:

When you create a new template file (File > New > Blank Template > HTML), you'll notice that the option to Enable InContext Editing cannot be selected (see Figure 19).

This occurs because you must follow a specific order of operations:

1. Create a new DWT file.
2. Insert one Business Catalyst editable region (Insert > Template Objects > Business Catalyst Editable Region).
3. Save the DWT file (it is automatically saved in the Templates folder at the root level of your site).
4. Insert the InContext Editing editable region (by selecting the entire Business Catalyst editable region, or a <div> container that exists inside the Business Catalyst editable region.
5. Edit the template as desired, and then save the DWT file again.

If you attempt to insert an InContext Editing editable region outside the Business Catalyst editable region of the template (or you've not yet defined the Business Catalyst editable region for the template), an error message is displayed (see Figure 20).

Updating roles to enable or disable access to editing template files

As mentioned in the section "Understanding InContext Editing roles," you can create a role, add users to that role, and then define the permissions granted to the users who are assigned to the role. This is an important consideration when it comes to working with template files.

If you do not want your client and their employees to edit the templates that define the appearance of a site, then create a new role, and make sure that the following permissions to edit templates are disabled in the Admin Console:

• Add Template
• Delete Template
• Edit Template
• View Template

By setting the user's permissions, you can ensure that they will not accidentally change the templates themselves, only the unique page content on each page. Remember, any tasks that are in the left pane are disabled and cannot be accessed by the user of that role (see Figure 21).

Always restrict the permissions you grant to users, and err on the side of not enough rather than too much access. If you do want your clients to edit the templates, you can grant them the necessary permissions and then specify exactly which areas of the templates are editable and which tools they can use when editing.

It is a common practice to disable permissions for editing and deleting templates, because changes to a template are propagated across an entire site (and affect any page that uses that template). Since templates are so powerful, you may decide to reserve the editing of templates for only yourself, or a trusted member of your web team. Remember that changes made to a single template file can significantly change the appearance of an entire site. Proceed with caution.

Back to top

Identifying the dependent files required for InContext Editing

The InContext Editing feature requires three include files in order to work correctly. If the files do not exist, if they are renamed, or if they are moved to a different folder on the site, the browser-based InContext Editing interface will not function as expected.

The following files must be located in the includes/ice folder structure at the root level of the site:

• includes/ice/ice.conf.js
• includes/ice/ice.js
• includes/ice/ide.html

If you are using Dreamweaver to create InContext Editing-enabled pages and templates, these files will be automatically added to the site structure the first time you save a file that uses InContext Editing (see Figure 22).

When you choose File > Put to upload the new file, be sure to upload the dependent files (the inserted images, rich media, CSS style sheets, and includes that are linked to the file) the first time you upload it to the remote server.

If you previously used the InContext Editing service and Dreamweaver to create non-Business Catalyst sites, you can import the site into the Online Business Builder to migrate the site to the Business Catalyst Platform.

You'll also need to update the older ice.js file to use the newer version.

To learn more about moving an InContext Editing-enabled non-Business Catalyst site to the Business Catalyst Platform, see Migrating an existing site with InContext Editing to the Business Catalyst Platform for more information.

Back to top

Hand-coding pages in a text editor to enable InContext Editing

In addition to using Dreamweaver, you can insert InContext Editing editable regions by hand-coding them using any HTML or text editor. Just add the syntax ice:editable as an attribute to a <div>, <td> and <th> tag to define an editable region, as in this example:

If you need to make another page element editable, place it inside one of these container tags, and then set its container as editable.

In some projects, you may not need to hand-code the pages. For example, the InContext Editing feature contains an algorithm that scans Business Catalyst sites to see if your pages contain the following tags: <div>, <td> and <th>. If these page elements exist, (even if no editable regions have defined), the algorithm parses the page and sets these containers as editable by default.

Note: Currently, there isn't a tag that you can type (or an option you can choose in Dreamweaver) that sets a page region as non-editable. If you want to prevent your clients from editing a specific page, add an empty <div> tag in an unobtrusive area (such as the footer) and set that one <div> tag as editable. If you define even one editable region on a page, the other areas (defined by the default supported tags of <div>, <td> and <th>) are automatically set as non-editable.

Defining the formatting options enabled for InContext Editing

Remember that when you add the asterisk (*) to the ice:editable attribute, you are enabling all of the formatting options so that your client can access all of the available tools when editing this area of a page. However, you can also set specific tools to be available for an editable region in the page. If you'd prefer to restrict access to some of the formatting options, you can individually itemize them (separated by commas), as the value for the ice:editable attribute, instead of using the asterisk. You can choose any of these options:

• bold
• italic
• underline
• align_justify
• align_right
• align_center
• align_left
• font_face
• font_size
• indent
• outdent
• ordered_list
• unordered_list
• paragraph_styles
• background_color
• font_color
• css_styles
• media
• hyperlink

Here's how the syntax looks when you specify these individual editing features:

Most of the formatting options are self-explanatory. The following descriptions illustrate the behavior in the online editor when some of the less obvious formatting options are enabled:

• font_face: Allows your client to apply a font (from a pre-set list of available fonts, not any font) to text.
• paragraph_styles: Allows your client to apply a paragraph or header style (such as <p>, <h1>, <h2>, and the other header styles).
• css_styles: Allows your client to apply a rule (from a pre-set list of available rules) to page elements.
• media: Allows your client to insert, edit, and format images (including uploading new images to the site).

If you want to prevent your client from making specific changes to their site, ensure that the formatting option is not included in the list of enabled values. Removing the option (such as bold) means that the ability to set text as bold is not available for the defined editable region. You have complete control and flexibility to enable specific tools for specific regions of the page.

Adding editable regions to Business Catalyst templates

As described above, you can hand-code editable regions to a template page to enable your clients to edit a specific area of a template. However, you must consider the following:

In the Admin Console, the user must be assigned to a role that includes permissions to edit templates. Even if the template itself contains InContext Editing editable regions, the content cannot be edited if the user that is currently logged into the Admin Console does not have the permission to edit templates.

Additionally, since templates are comprised of both editable and non-editable regions (and Business Catalyst templates only ever have one such region applied per template), the InContext Editing region that you define must be placed inside the template's editable region for the area to be editable.

For example, to define the template's editable region for Business Catalyst, the following code must be present:

This tag specifies that the container it is inside will display the unique page content when the template is applied to a page.

Inside this parent container (the Business Catalyst editable region for the template) you can set any number of <div>, <td> and <th> tags as editable using InContext Editing. For example, the syntax might look like this:

In the code example above, the unique page content will display in the <div> tag with the class set to main, but the client will only be able to edit the first table cell's contents. Even though the entire table is inside the template's editable region, the second <td> tag is not enabled for InContext Editing, so that content cannot be changed in the InContext Editing interface.

You can also choose to set the entire editable region of the template as enabled for InContext Editing. But any areas outside the template's editable region are locked by default. Therefore you cannot "unlock" these areas by applying InContext Editing code.

Be extremely cautious when setting editable regions (and granting permissions) to allow your clients to edit the content of templates. If they delete or change an area of the template and publish it, the changes will affect all of the other pages in the site that are linked to that template. A single update could potentially cause display problems across the entire site. Unless you feel confident that your clients will understand this responsibility, you should restrict them from editing the template files at all.

Back to top

Where to go from here

InContext Editing is a helpful tool that adds intuitive editing capabilities to the Admin Console, making it easier than ever before to train your clients to edit their own site content. By leveraging roles, assigning permissions, setting editable regions, and defining the specific toolset available, you can precisely control (and guard) the site to ensure the critical functionality and continuity of appearance are not compromised.

And best of all, the InContext Editing is included automatically with all of the Business Catalyst sites you create. There are no additional fees to use it or limitations to the number of sites that can take advantage of this functionality. (Trial and paid sites do have restrictions on the number of administrators allowed to access the Admin Console. Visit BusinessCatalyst.com for more details on the terms of each plan.)

To help you train your clients on how to use the InContext Editing interface, read the article, Using InContext Editing to update sites for content providers (coming soon).

Also watch the instructional video geared towards business owners who are learning to work with InContext Editing to update their sites: Updating sites with InContext Editing (coming soon).