Category Archives: Uncategorized

Pasting in Chrome and Safari


As you may know, the new version of CommonSpot now supports authoring in Safari and Chrome.  But pasting into a Text-block element in these browsers is a little different than what you are used to.


To paste in Safari, you have to right-click and pick paste from the popup submenu or you can use the appropriate keyboard shortcut.


To paste in Chrome, you first have to download a Chrome extension.

  1. Go to and save the extension to your desktop.
  2. When the download is finshed, drag the file to Chrome to install it.  A warning will appear in the bottom left of the window.  Click “Continue”.
  3. Click Add when the next window appears.
  4. A confirmation that the installation succeeded will appear.

After you have installed the plugin, you will be able to paste with Chrome.  To do this, you have to use the paste button that is on the RTE toolbar (Control + V and the right click context menu do not work in Chrome).

Redirects: A Graceful Way to Retire Pages


Last week, the update project took me into the main website folder where I scrutinized about 100 pages. Here’s what I found:

  1. Most pages were fine and needed no updates
  2. Some were test pages or experiments
  3. Some sported outdated content
  4. A few repeated information maintained in other sections of ITCS
  5. Four or five needed to be moved to other subsites with like content
  6. And—I hate to admit this—one page had a duplicate twin in another subsite. Exact information, two different names. Hum.

So once I had an idea of the content and navigation for the web folder, I came up with a refresh plan:

  1. Contact the owners of any experiment/test pages for permission to delete
  2. Charge student workers, Becky and Liz, with updating obsolete content
  3. Move content or entire pages to the appropriate web folder and create a REDIRECT (more on that in a bit)
  4. A REDIRECT was definitely in order for the “twins” (No. 6 above).

If you have a bit of clean up in your own website, here’s what you need to know about URL redirects.

URL (page) to URL (page)

This is appropriate if you need to delete a single page but don’t want users to get the dreaded 404 page. To do this, choose a different page as the target and then submit an IT service request that says:  “Please redirect URL [page to be deleted] to URL” [different page].  Therefore, when someone navigates to the old URL, their browser automatically travels to the new page.

After the redirect is completed, the original page may be deleted.

URL (Folder) to URL (Folder)

This situation is not a page-to-page redirect but rather an entire web folder-to-web folder switch. For example, you may have decided to create a “development subsite” to contain all your new 960-wide pages.

First, send an IT Help Desk request to create the new subsite folder. Once you’ve recreated all you pages within the new subsite, send a second IT service request to have the new subsite replace the old subsite. Keep in mind that this may be a good time to retire old pages by simply taking them out of the new navigation scheme.

For a video tutorial on copying and pasting elements between pages, see the Tutorials page.

Long URL to Short URL

Some circumstances require that a subsite URL be shortened to make it easier for users to remember it. For example, The Help Desk website URL is really But the URL has been shortened (and redirected) to


When deciding if you need a redirect, remember that judicious use of the three options is a must—too many redirects are just as bad as the 404 page!

And while we’d all like for our sites to be finished once they’re created, the truth is they require frequent updating. A redirect is just one of the ways we keep our content refreshed and users happy.

Previous Versions


The ability to view previous versions of a page and the associated chance to revert pages to those previous versions seems to be one of the lesser known and understood features of CommonSpot. Until very recently, I actually thought that it wasn’t working, because I misunderstood how the process worked. So let’s look at some of what you can do and some of what you cannot.

CommonSpot, by default, stores all previous versions of all pages for 30 days. A new version of the page is made when you change the content of the page and submit the page or the element. Since some changes (e.g. changes to custom elements, changes to custom metadata, adding or removing style sheets) do not require a submission to become active, these do not create new versions. While 30 days is the default, upon request, we can change the settings for a subsite to 90 days. The settings for individual pages can also be changed via “Document Information” under “Tools & Information” on the menu bar (if in author mode).

All the saved versions of the page can be seen by choosing “Version History…” under “Page View”. A new window will appear listing all the saved versions. You can see any previous version by clicking on the hyperlink with the date and time of when the version was saved, or you can check two versions and compare them by then clicking on the “Visual Difference” button at the top.

There are some considerations that affect how complete the previous version are. As noted above, changes to custom elements are not saved, so when you view a previous version, any custom elements will have the same content as the current version. Also, any element that you delete is deleted from previous versions as well. So, for example, if you delete an entire Formatted Text Element, using the previous version option will not let you see the content of that element. Instead, the area where that text was will appear blank.

Elements that have remained on the page and only changed their content can be reverted back to their previous state. When looking at a previous version in author mode, these elements will have a grey arrow pointing to the left that will let you revert the content or compare it to the current version.

CommonSpot Corner: Preview Mode


After yesterday’s Users Group meeting, I was chatting with a couple of the attendees, and a complaint came up that I bet many people have had. As everyone knows, when you are in author mode, the page does not render exactly as it does in read mode, so when you are making changes, it is not unusual for the page to look fine when you make the change in author mode, but then when you submit the change and go to read mode, it changes, and so you have to go to author mode, edit, submit, go to read mode, repeat, until you get it right.

But there is a simpler way. After you have made your change but before you submit it, you can see how the page will look in Read Mode by picking “Preview” under the Page View menu.

New CommonSpot Templates



Starting Monday, 25 October, we changed the base template that all CommonSpot pages are built from.  The biggest aspect of this change is that all new pages will no longer use a table as the layout framework.  Instead the pages are using CSS to determine the display.  This will give us all much more flexibility and control over the appearance of our pages.

This change will not require any changes to any current pages or templates or any pages you make from current templates.  The only problem that should occur when you are making pages is that now when you specify a width for the left column, any images that are wider than column will be truncated, like this:


The basic layout of the page is divided into divs, most of which have ids that you can use in styling your pages.  This is a rundown of the divs.  In each image, the div under consideration has been given a red border to show its location.

1. #contentArea

This is the div in which all the other page content that you control goes into.

2.  #topRow

This is the area that the header images usually go into.

3. #barDiv

This contains the two bars after the header image.

4. #printerFriendly

This contains the printer friendly link

5. #bottomRow

This contains everything else above the footer.  No content goes directly into this div, but into the one or two child divs that it contains.  It will always contain at least one div within it (#bottomRight, more on it in a minute).  If the Full Body option isn’t checked in the Custom Metadata, will also contain a #bottomLeft  div as well.

6.  #bottomLeft

This div has the width that is specified in the left column specification in the Custom Metadata.

7. #bottomRight

This div has a width of 770 – the width of the left column.

An interactive demo of these divs can be seen at  When you mouse over each of the three main divs, you will see the background change and the id of the div will appear at the top.

Inaugural Edition – Remote Script Tutorial


Every Tuesday, I will post a new tutorial that I hope will help you get more out of CommonSpot.

Remote Script

We have created a new Custom Element called Remote Script.  The element lets you do two things:

  1. Upload your own CFM files without having to wait for ITCS to approve them and move them to the live server.
  2. Upload raw HTML snippet files and have them imported directly into a CommonSpot page.

Let me explain case #2 first:

CommonSpot has always had a built in element for including HTML.  However, maintaining these elements has been somewhat difficult for many users.  With this new element, the process is simplified, and updating the file is easier than ever.

First, create your HTML snippet in DreamWeaver, Microsoft Expression Web (free for download at the Download Center for all faculty and staff), or your favorite editor.  Since this snippet will end up in a larger HTML file, do not include the html, head, body or other like tags.  Then upload your document via your tools file.  The URL, which you will need in a later step, will be[site]/[subsite]/customcf/[filename.html].  Go ahead and open it to make sure that it works and everything looks ok.

Then add a Remote Script element (listed under Custom Elements) to the CommonSpot page.  Then paste the URL, except for the “http://”, in the Remote URL text box.  Click Finish, and you are done.

Anytime you want to update your file, just overwrite the existing HTML file and the CommonSpot page will change automatically.

Uploading your own ColdFusion scripts

If you want to upload CFM files, first you need to send an email to hallwa at so that we grant you the file permissions that you will need.  The place where you will load the files is actually on a different web server than the CommonSpot server.  You would then be allowed to freely upload CFM files, and then you can use the Remote Script element, in the same way as above, to import the output of those files into your CommonSpot site.

If you have any questions or comments about this element or any elements that you would like to see developed in the future, please leave a comment.