OIT Tech 32px
pagemasters toolbox -- classic commonspot

Introduction to Classic CommonSpot Authoring


Table of Contents






The focus of these materials is what you need to know to maintain an existing site in CommonSpot.

The intended audience includes two groups of people:

  • those who are already maintaining a Web site in some other server environment; and

  • those who have studied the New Pagemasters material, linked from the Full Contents in the secondary navigation block to the left.

As such, this user guide does not include extended discussions of the trade-offs involved in page and site design, nor extended discussions of the range of information gathering and work approval processes that may be appropriate for new or radically re-designed sites.

These user guides will not cover everything there is to know about using CommonSpot. What we do aim to do is to bring you up to a reasonable level of comfort with the essentials, and to expose you to a wide enough range of CommonSpot features that you can develop a useful level of intuition as to how the authors of this software approach the whole Web site content management business. That will serve as a foundation for your own exploration, which will be aided by these on-line tutorials.

Features of CommonSpot


For many people, we believe that one or more of the following areas will prove to be attractive features of CommonSpot:

  • Pagemasters and content contributors can create pages and update content without directly confronting the HTML.

  • CommonSpot includes workflow features to address situations where multiple people should approve any changes before they are public.

  • CommonSpot pages are built on templates. Templates make it easier to build and update a site with consistent page design while avoiding repetitious work when creating multiple pages that share design features. When revising those shared features at a later date, a change in a template immediately propagates to all pages built upon it.

  • Pagemasters can create their own templates, by adding page elements either to one of the system base templates or to a derived template built upon a base template by themselves or others.


Limitations of CommonSpot


The current version of CommonSpot is designed to create pages that can be viewed with a wide range of modern graphical browsers, on Windows, Macintosh, and other platforms. Viewing the sites with text-based or older graphical browsers is likely to have some problems.

Site creation and updating require the use of one of a restricted set of browsers. For the past several years, CommonSpot authoring has routinely worked with recent prior versions of Microsoft Internet Explorer on Windows and of Firefox on Windows, Macintosh, or Linux, but has often not worked with the latest versions of those browsers. For current details, follow the "Authoring Browsers" link in the secondary navigation block at the left.

In all cases, CommonSpot authoring works only with with cookies and scripting enabled (this includes de-activating any pop-up-window blockers). To reduce the risk of compromising your personal computer's security that would result from having cookies and scripting generally enabled in order to work with CommonSpot, we suggest that you follow the separate instructions for configuring Internet Explorer, or for configuring Firefox. If you have a pop-up blocker that can be configured to trust certain servers, then the list of servers that the pop-up blocker must trust is the same as that given for IE or Firefox to trust in the above-linked pages.

The current version of the Rich Text Editor is not able to preserve some common HTML constructs, even if you enter them correctly by hand in the HTML view. For example:

  • A "Definition List" structure (involving the tags, <DL>, <DT>, <DD>, and </DL>) will not survive the Rich Text Editor if the <DT> parts have header tags (e.g., <DT><H2>text</H2>).

  • A <UL> ... </UL> structure, used without <LI> tags for the list items, in order to create an indented section, will be transformed into MARGIN commands that only some graphical browsers will honor.

CommonSpot cannot be used to create pages using HTML <FRAME> tags. Because it is impossible to refer someone to a particular resource in a framed environment, except by providing the frame home page, and then a sequence of clicks to bring up the particular information, this is no great loss. Most of the advantages of frames (e.g., having one file to update for a uniform set of navigational links) are achieved in CommonSpot by using templates.

CommonSpot uses the browser to do a significant part of the work while you are creating or revising page content, mostly through Javascripting, while the server interacts with the "back-end" database of elements and uploaded documents. Frequently, the visible response is assembled in a window that is located off-screen until it is ready; in such cases, the only evidence of activity will be the creation of that window's segment of the task bar. As a result, you will at times see little or no visible result from clicking on a button. Do not re-click; instead wait for the system to catch up with you. Be especially cautious about this at first, while you are developing your intuition for CommonSpot's reaction-time. There are some situations where a second click will create problems that can require systems staff to resolve.

There is a maximum size of somewhat less than 100 MBytes for uploaded files, including graphic images and binary documents such as Word's ".doc" and Acrobat's ".pdf" files. It is rarely humane treatment of your audience to include such large files!


The Front Door Servers


Since the introduction of CommonSpot in mid-July, 2003, the Ohio University Front Door has been a combination of a "Static-Page" server (using the raw HTML and graphics files model of site preparation) and a CommonSpot server (using a content management system model of site preparation). With some exceptions, the pages, images, and documents in each subsite or sub-subsite are served from the same server. There are a number of subsites that have some sub-subsites served by the Static-Page Front Door server and also some sub-subsites served by the CommonSpot Front Door server.

At this time, only a few new subsites are being created in CommonSpot, pending implementation of the successor content management system. Once the new CMS is in place, no new subsites will be created in CommonSpot. During the migration of the existing CommonSpot subsites into the new CMS, both will be serving pages that appear to the world with URLs that start "https://www.ohio.edu/" (along with pages served by the static page server and the personal pages server).

The authoring server, "author.oit.ohio.edu," is a separate server from the ("read-only") public server, which serves pages within "www.ohio.edu"; the pages viewed from the two CommonSpot servers will be identical, because both the authoring and the public server use the same "back-end" database.

You work on subsites in CommonSpot by accessing the pages with URLs that look like:


Once you are live and in production as http://www.ohio.edu/subsite/, you will continue to access your subsite for revision using the "author.oit.ohio.edu" URL. Once you are satisfied with a new page, or with a change to an existing page, you will instruct CommonSpot to "publish" that update, and it will be visible from both domain names.




Many terms will be introduced as they are used, but there are a few that should be presented right away (some of which we have already been using). We will try to be consistent throughout this guide in using these words as described here:


  • site refers to the entire collection of pages found on a single server; for example, the Front Door site is all those pages whose URLs start with "https://www.ohio.edu/" and the online catalogs site is all those pages whose URLs start with "http://catalogs.ohio.edu/".

  • subsite refers to all those pages that share a first-level URL within a site; for example, the first subsite to be published from the CommonSpot server was the bicentennial subsite, all of the pages whose URLs start with "http://www.ohio.edu/bicentennial/".

  • sub-subsite refers to a group of pages within a subsite whose URLs all match through at least one more "extra" slash (a sub-subsite is achieved on most servers by placing those files into their own folder or subdirectory); for example,




    are both part of the "webservices" sub-subsite of the "oit" subsite. Subsite pagemasters are responsible for creating sub-subsites. Some CommonSpot screens refer to sub-subsites as "child subsites."

  • page element refers to an item within a page that has its own access controls, identifying the people and groups who are allowed to create, read, revise, or remove that item. This may be a single graphic image, a paragraph, or the entire main section of a page. Page elements can be shared among more than one page, with updates done once and being reflected immediately on all pages where the shared element appears.

  • content contributors are people who are responsible for one or more parts of a subsite. Their responsibility may extend to one or more entire pages, or may be restricted to a single page element that appears on one page.

  • subsite pagemasters are people who are responsible, as individuals or as a group, for an entire subsite. Often the "subsite" prefix will be left off, and "pagemaster" by itself will be used with this meaning. Some of the CommonSpot screens and documentation use the phrase "subsite administrator" with this meaning. Subsite pagemasters can do everything that a content contributor can do, and more besides.

  • templates are the starting point for constructing pages in CommonSpot. The two types of templates are "base templates" (which are hand-coded by programming staff) and "derived templates" (which any CommonSpot subsite pagemaster can create by adding elements to an existing base template or derived template). Unlike some other Web publishing tools, CommonSpot templates include only items that will be identical on all pages derived from that template; they also include content-free placeholders where page-specific content will be built.

  • inheritance is the mechanism by which updates to a template are propagated into the templates and pages built on (or "derived from") that template. Some revisions to a page can break the inheritance, so that updates to the underlying template may no longer be propagated to the page, or so that updates to the underlying template will destroy page content when they do propagate to the page. The current version of CommonSpot provides no warning dialog when a page or template revision would break inheritance from an underlying template. Fortunately, it is possible to set "inheritance security" while working on the template so as to prevent breaking inheritance, but that will also prevent some kinds of revisions to the pages and templates built on the template. These topics are discussed in more detail elsewhere.

  • refresh directive refers to an HTML construct, within a META tag inside the HEAD section of an HTML file, that instructs the browser, after a controlled delay, to jump to a different, specified URL. The page containing this refresh will be, briefly, visible on the browser's display, until the specified delay time has elapsed and the browser jumps to the new URL. With most browsers, the refresh page will also be visible, briefly, if the user later clicks on the browser's "back" tool repeatedly to return through that page to the prior one; see, for example, the page


    If you do choose to use a page with a refresh directive (e.g., on your old site, after you have migrated into CommonSpot), be sure to avoid using a zero-second delay: that would be user-hostile, because, with most browsers, it would prevent your reader from using the browser's "back" button to return to the page that brought them to your site.

  • redirect refers to an HTTP protocol level interaction in which the server responds to a request for a page, not by sending an HTML file, but by sending a small data "packet" to inform the browser that it should instead be asking for a different URL. This is established by appropriate configuration of the server. Because no HTML page is transferred from the server, no intervening page is displayed by the browser when the user follows the link to the re-directed page, nor later if the user clicks on the browser's "back" tool to return to the prior page; see, for example, the result of clicking on the page



Page Security


The owner of each page, and the administrator of each subsite, can control who has the ability to modify each page, or each page element. In order to simplify the transitions between people in various jobs, and to more easily maintain the subsite during vacations or illness of the primary people, we urge you to take advantage of CommonSpot's "Group" capabilities. Access to the page or page element should usually be granted to the appropriate group, not to individuals, even if there is only one person in the group. Then, individuals can be added to or removed from the group, as their temporary or permanent responsibilities change, without each and every page and page element needing to have its security re-set.


Creating groups and changing their membership is one of the functions of the CommonSpot application administrators. The owner of each page can then grant access at the appropriate level to each group.

In addition to the controls for permission to modify pages and page elements, CommonSpot pages can be visible to the world at large, or they can be restricted to be visible only to the specific individuals and groups you authorize. This guide includes instructions for creating subsites that are visible to the world. The Advanced Pagemasters guide includes instructions for restricting browsing access to specific individuals and groups. If you need to have an entire subsite or sub-subsite password-protected, so that it will not be included in any public search engines, for example, but do want to have all of the pages be visible to all Ohio University users, then use the techniques documented as part of the Advanced Pagemasters guide. If you need to restrict access to part of a sub-subite, e.g., to restrict access to a particular page, please contact OIT by E-mail to servicedesk@ohio.edu for instructions.


The Approval Process


New pages and changes to page elements are not visible to anyone except the page author until they are approved. That approval process can be a single step taken by the page author ("submit for publication"), or it can involve an entire workflow sequence of approvals initiated by the page author.

If you have an immediate requirement to have someone else approve your work before it is visible to the public, please contact OIT (by E-mail to servicedesk@ohio.edu, or by phone to 593-1222).


Jumping In




Explore your CommonSpot Site


  1. Go to http://author.oit.ohio.edu/secure.cfm.

  2. Enter your own personal Ohio login ID and password.

  3. Navigate to your subsite's home page and observe the pencil icon at the top right. In the next section we will begin our exploration of the tools available through this icon for modifying this page or creating a new one.

  4. If, during your session, your authentication expires (most likely as a result of what appears to CommonSpot to be inactivity), then some or all of the various shortcut icons will disappear and their tools will not be available. If you then attempt to access


    your browser will automatically re-submit your password on your behalf, and when you return to the page you were working on, and re-load it, the shortcut icons will be re-displayed.



Investigate the CommonSpot Dashboard


Click on the pencil icon at the top right; observe the menu of choices. To take a choice, move the mouse (keeping it within the menu box) until it is over that choice, then click as usual. If you move the mouse outside of the gray menu box so that it leaves through the bottom boundary, or if you leave by the left side but try to come back in through the bottom, the menu will collapse with no choice being made.

Pencil Icon placement


  1. Choosing "View Page in CommonSpot" will bring up the page inside the CommonSpot Dashboard.

  2. Choosing "Work on this Page" will bring up the page inside the CommonSpot Dashboard, showing you work-in-progress that you started.

  3. Choosing "Work on this Page (All Changes)" -- if that choice is present -- will bring up the page inside the CommonSpot Dashboard, showing you work-in-progress that anyone started.

  4. After you select "View Page in CommonSpot," "Work on this page," or "Work on this page (All Changes)," the page will be re-displayed within the "CommonSpot Dashboard," as shown here (for this graphic, we have added a blue overlay on the full-width toolbar, and a red overlay on the content-spanning toolbar):

    CommonSpot Authoring User Interface

    (click on the image to see it full size).


Modifying CommonSpot Pages


While you are modifying a page, CommonSpot will routinely create one or more "lightboxes" to function as dialog boxes and forms to obtain your input. There may be a period of time with minimal or no visible result from your actions.


  1. Return to your subsite's home page, if you are not still there. While viewing the page as published, you are seeing only those changes that have been completed and published.

  2. Click on the "View" button in the content-spanning toolbar, and select "Work on this Page (My Changes)" or "Work on this Page (All Changes)." In the former case, you will see the completed and published version that was visible, as modified by any changes that are your own work-in-progress. In the latter case, you will be able to see and work with not only your own work-in-progress, but also work-in-progress by all other CommonSpot pagemasters or content contributors who have been authorized to work on that page.

  3. After the page has been re-drawn, observe that your page now includes various small CommonSpot tool icons. Clicking on these icons will bring out menus of various actions. Each CommonSpot element will have at least one tool icon, a gear wheel at its top-left corner: element properties tool icon

  4. Clicking on that icon will evoke a menu; the choice closest to where the gear wheel was will usually be the primary content-modification tool -- for example, the Rich Text Editor for Formatted Text Block elements. The only common exception has a choice of "New Data" closest to the gear wheel location, and a choice of "Edit Data" next to that; in such cases, the "Edit Data" choice is used far more commonly than "New Data."

  5. When you make changes, there will typically be a "Save" button to store them as work-in-progress.

  6. The changed elements will have a yellow "work-in-progress" icon in place of the gear wheel, which should look similar to one of the following:

    WIP 3, WIP 2, or WIP 1. The symbol within the icon may indicate initial creation of a new item, modification of an existing item, re-positioning of an existing item to a different location on the page, etc.

    Such changed or new material is visible only when working on the page (and to those who are part of the formal approval process for that change, if there is one).
    "Preview" mode displays the page as your audience would see it if all work-in-progress items were submitted for publication in their current state.

  7. When you click on the yellow work-in-progress icon and select "Submit page...", be very careful to avoid selecting "Discard Change," which is adjacent on the menu!

    If you had multiple page elements with changes that were still work-in-progress, you could choose to submit any one element's changes for publication at any time, by clicking on the appropriate yellow work-in-progress icon, and choosing "Submit Change..." from the menu. That will leave the other elements' changes still as work-in-progress, visible only while working on the page. If you have only one change to submit, the system is likely to be quicker in responding to the "Submit Change..." choice than it can be for the "Submit page..." choice. If CommonSpot has gotten confused about some aspect of the page, it is more likely to recover during a "Submit page..." procedure than during a "Submit Change..." procedure.

    While you are first building your subsite, it is appropriate to activate new pages, and to publish changes in revised pages, as you go along. Once your subsite is in production, however, you may well choose to get a new page entirely ready before activating it, or choose to complete an entire set of revisions to the content of an existing page before publishing them all together.

  8. In the resulting publication dialog box, you will find the opportunity to provide comments. Please make a habit of doing so -- they will prove quite useful when you need to use the Version History feature, among other times. Do consider that the times when you need to use Version History are times when the world is already seeing something that is wrong, so any help that will speed your selection of the correct prior version is a very good thing!

  9. In the publication dialog box you will also find a check-box, immediately after the comment section, to display the page as published after publishing the changes. Often it is best to check that box, for immediate proofreading. If you don't check it, the page will be displayed with tool icons for you to continue authoring activities.

The key things to remember about changing a CommonSpot page are that you will typically go to the page in question, scroll up to the top, and select "Work on this Page" or "Work on this Page (All Changes)," and then either

  • add something, by clicking on "Click to insert new element" or

  • change something that is already there, by clicking on the gear-wheel icon at its upper-left corner.


Planning a New Site or Migration of an Existing Site

These issues will no longer arise in the context of classic or traditional CommonSpot tools. For the last six years, all new sites in CommonSpot have been built using the "managed" tools. Planning for the last few such migrations before we shift over to the new CMS will be done through direct consultation between OIT's Web Services and the site owners. You can get that started by submitting a web project request through the form on https://www.ohio.edu/web/help/

CommonSpot Infrastructure


A final complication that is better addressed during planning: you cannot use file or sub-subsite name that collide with any of the various files and folders that CommonSpot creates on the server "behind the scenes," on your behalf. The list of files and folders that CommonSpot will create as part of its infrastructure includes:

  • template-*.cfm for your local templates (the * will be replaced by the name you specify for the template)

  • the following folders will be created in each subsite and sub-subsite:

    • cachecustomcf (not in V6 or later, but may be left over from pre-V6)

    • customcf (new in V6 or later)

    • images

    • menuoverride

    • pageindex (not in V6 or later, but may be left over from pre-V6)

    • presentation

    • templates

    • upload

  • files with the following names, with one ending or another, will be created in each subsite and sub-subsite:

    • admin

    • application

    • createpage

    • default

    • force-login (not in V6 or later, but may be left over from pre-V6)

    • index

    • loader

    • login

    • logout

    • override-getfile-error

    • override-search-text

    • restricted (not in V6 or later, but may be left over from pre-V6)

    • upload

Do not attempt to create pages using any of the above listed file names, except index, nor to create sub-subsites using any of the above listed folder names!

If you are migrating an existing site that uses any of the folder names or file names that are listed above (including any files of the same name with any ending), please contact the Web Team (by E-mail to servicedesk@ohio.edu or by phone to 593-1222) early in the planning process, before you start creating any pages or sub-subsites in CommonSpot.



Create Sub-Subsites


Using sub-subsites to organize your Web pages can help your reader to understand and remember the URL, because it can be parsed out into smaller pieces. There is no requirement that your sub-subsite organization correspond exactly to the navigational sequence of links that you expect people to follow to get from your subsite home page to the specific content pages, but that often provides a good basis for choosing a sub-subsite organization.


Sub-subsites must be created before any pages can be placed into them. Only subsite pagemasters are permitted to create sub-subsites. Other content contributors may be permitted to create new pages within a sub-subsite that the subsite administrator has already created.

It is possible to configure our CommonSpot server so that your subsite is live and visible as http://www.ohio.edu/subsite/, but one or more sub-subsites are still being redirected to your old server, while you complete those sub-subsites, accessing the pages through http://author.oit.ohio.edu/subsite/sub-subsite/. If you want to bring your subsite live in stages this way, please contact OIT (by E-mail to servicedesk@ohio.edu or by phone to 593-1222).

In the following example we write "subsite" where it is the label that CommonSpot uses in the forms and dialog boxes for your new sub-subsite.

  1. Go to your subsite's admin page: login and navigate to any CommonSpot page; click on the pencil; choose, "View Page in CommonSpot"; click on the "Admin" button in the full-width toolbar, and select "Subsite Administration..."; choose your subsite; click on the "Next" button.

  2. Click on "New Subsite" at the lower right, and observe the Create Subsite lightbox.

  3. Fill in the subsite name, description, and display name; choose a name that consists of letters, digits, hyphens, and underscores, but no spaces or other punctuation marks. Click the "Save" button at the lower right.

    If an error message is displayed (e.g., about the request timing out or providing an empty response), close the error message's lightbox(es) and then close the subsite-creation lightbox. Click on the browser's "refresh" or "reload" button to re-display the CommonSpot Dashboard with the subsite administration page. The new subsite should be listed. If not, please contact OIT (by E-mail to servicedesk@ohio.edu or by phone to 593-1222).

  4. Click on the new subsite's name in the list of child subsites, at the lower left of the subsite administration page.

  5. Click on "Create New Page" at the top of the block of text links on the right side, in the "Subsite Statistics" section in the middle of the page. A more-detailed, general description of the process for creating a new page on an existing template is included elsewhere; steps 6 through 10, immediately below, provide a quick summary.

  6. Select a template from the Template Gallery: choose a category and then click on the "Next" button at the lower right; then click on the template name to highlight it (observe that the templates are listed in case-sensitive order, with the uppercase letters preceding the lowercase letters). For example, you might choose category, "Ohio University Templates," and then the "official_pages1" or "unofficial_pages1" template, as appropriate for your subsite. Once a template is highlighted, click on the "Next" button at the lower right.

  7. Complete the "Create New Page" form:

    • Give the first page in the sub-subsite a name of "index" (without the quotes), even if you are replacing an existing site that used "welcome," "default," or "homepage" for its default home page.

    • Be sure that the title you specify is different from any other CommonSpot page's title -- include the subsite in the title, either as it shows in the URL or by a conventional name, and then make sure it is distinguishable from any of your other pages.

    • You can use either of the orange circle with the black down-arrow to propagate that field's text to later fields.

    • Specify a category of "Ohio University Website," or "Unofficial Ohio University page," as appropriate.

    • You will be able to revise your entries later: the name, by choosing "Rename Page..." from the "Actions" menu; the others, by choosing "Standard..." from the "Properties" menu.

  8. Click on the "Next" button.

  9. Decide whether or not to activate the sub-subsite home page immediately. If your entire subsite, or this particular sub-subsite, is still being redirected to the old server, you should activate the page right away, since it will not be visible on www.ohio.edu anyway.

  10. Select "View page as published" before leaving the page.

  11. Sub-subsite security settings may need to be adjusted if you are going to have others work on those pages, or if you want to restrict access when reading the pages. That can be done later, and is a separate topic.