Santa Clara University

When uploading an image file to Commonspot, try to avoid file names that include characters such as accents, apostrophe, and commas.  Commonspot won't provide a warning about the file name (that should be fixed in the next release), but it will cause problems in the replication process.  If you rename the file on your local system prior to uploading it, removing any non-standard characters, that will avoid the replication problems.

The formatted text editor in Commonspot isn't fully functional in Firefox 3.6. If you've recently upgraded Firefox, you might encounter problems adding links or viewing the HTML source in Commonspot. Paperthin has released a patch for this, and we plan to install that tomorrow morning, 2/17/10. Update - 2/17 8am: the patch has been applied, and appears to have corrected this issue.

Following the upgrade to Commonspot 5.1, we're seeing an error when attempting to copy an existing page - the error reported is "error while generating a unique ID".  You can create a new page from a template, but will likely see this error if attempting to copy a page.  The bug has been reported to the vendor this afternoon.

UPDATE: This issue has been resolved; the copy-page action works now.

Following the Commonspot 5 upgrade, we're seeing an issue with the Template Gallery listing; some user's templates are not listed in the gallery.  If you're creating a new Commonspot page and don't see the template you need in the Gallery, the work-around is to copy an existing page that's based on the template you want, and save that as your new page.  We hope to have the Template Gallery issue resolved fairly soon.

Commonspot users frequently encounter problems with access to element icons in pages that have content "below the fold" - content that is not visible when the page content is scrolled to the top of the window.  Clicking on an element icon can cause the page view to "hop" to the top of the page, and you then lose access to the element's menu options.

A work-around for this problem is to press the CTRL key (Windows) or Command key (Mac) when clicking the element icon.  That should prevent the view from resetting to the top of the page.

Credit for this useful tip goes to OMC student assistant Chris.

A recent Commonspot patch has introduced a minor bug in the rich text editor element. Any text edits will generate an HTML cleanup warning message. Paperthin is working on a remedy for this problem, which should be applied in the next couple of days. In the meantime, just click the "continue" button to bypass the warning message.

Following last month's upgrade to Commonspot 4.6sp3, a bug was observed with Commonspot's rendering of special text characters.

A recent update to Windows XP has introduced a conflict with Commonspot's rich text editor. The Windows XP update released in April includes a change to the ActiveX control - you will now see a message every time you used the rich text editor in Internet Explorer instructing you to hit the spacebar or enter key to activate the control. Updated 4/21/2006: Paperthin has released a patch that corrects this behavior in Commonspot. The patch has been installed on the cms server.

Commonspot's internal process for validating external links to secure (SSL-enabled, beginning with https://) Web sites has changed. Rather than categorizing the link as invalid, Commonpot will validate the link syntax but skip the process that actually checks to see if the link can be reached. If you've checked to make sure that you've entered the link correctly, you can check the link in Commonspot's link validation form, telling Commonspot that the link is in fact valid.

Commonspot creates a cache file copy of a page the first time it is requested from the www.scu.edu server, following the creation of the page or any update to the page on the cms server. This helps Commonspot deliver pages on the www.scu.edu servers more rapidly; the system doesn't need to get updated data from the database every time the page is requested - it just builds a copy of the page following a change published from the cms server. Sometimes a previously-created cache file isn't cleared from the www servers when you update a page and publish the change in Commonspot; you'll notice this if a published change appears to revert back to an older version on www.scu.edu (when one of the www servers hasn't updated the cache file), or a change published in Commonspot isn't displayed on www after several hours have elapsed. The Web Publishing site includes a step-by-step guide for handling these Commonspot cache issues.