- IDs & Accounts
- Networks / Telephones
- Academic Services
- Information Security
- Web Services
- Bobcat Depot
- OIT Projects
- About OIT
We will keep the most recent few items here, currently active and newest first. As problems are resolved, or other problems are detected, we will let you know by updating this page. Older items are available from our archive page.
We will not normally list authoring freezes here that are planned for our standard maintenance windows of 1 to 7 am. They rarely take the full time during that window, and most often occur on Saturday mornings, when traffic is lowest.
During extended authoring freezes, especially any that take place during business hours, we will maintain updated information on http://www.ohio.edu/outage/commonspot/ (which can be revised during authoring freezes because it is served by the static-page Front Door server).
The freeze will start at 9 pm Tuesday, October 17, and continue until the work has been completed. We expect that to be before 11 pm.
The work in question is replacement of RAM in the back-end database servers. Failing over to the standby database will permit the ROPS to function normally (so our public will notice no change in the publicFront Door pages, at www.ohio.edu), but it will not support continued authoring.
The freeze will start at 8 pm Tuesday, September 17, and continue until the work has been completed. We expect that to be before 7 am on Wednesday, September 18.
The public pages, at www.ohio.edu, will continue to be available throughout the process, although page display may be delayed, at times.
Saturday morning, August 10, we plan to upgrade CommonSpot from V 7.0.0 to V 8.0.2; to upgrade to more recent and more secure versions of other server software; and to shift the servers to faster hardware with more memory. We expect that the hardware upgrade will improve performance, and that the software update will provide support for authoring with more recent browsers, other new features, and enhanced reliability.
The authoring freeze will start promptly after midnight, and extend until the work is completed, likely by 10 am.
Our testing has confirmed that, despite the jump in version number, there are very few author- or reader-visible changes to existing features; you will be able to continue to do your authoring work as you have been. If you do encounter any discrepancies, please let us know right away, so that we can update our online user guides.
During the part of the work while the read-only public servers are offline, anyone attempting to reach any CommonSpot page will be redirected to the outage page
That page is served from the static-page Front Door server, so it will remain online throughout the work. Please inspect that page now, and let us know of any modifications you care to suggest.
As of February 7, 2013, we have received additional patches from PaperThin (the vendor of CommonSpot) that we will install Saturday morning, February 9. There will be an authoring freeze during our normal maintenance window (currently planned for 5:00 to 6:30 am) during the work, but www.ohio.edu should be available throughout. These patches should resolve the problems that we had been experiencing with excessive delays in propagating changes from the authoring server to www.ohio.edu, and issues where the changes were propagated to only one or two of the three read-only public servers ("ROPS") that the world sees as www.ohio.edu.
Updates may properly take up to five minutes to propagate from the authoring server to the ROPS, but once seen on the ROPS, should be seen by all browsers from then on.
If you notice any discrepancies with your own pages (either longer delays or old content being displayed after the new content has been seen), please clear your browser's cache ("delete temporary internet files") and reload the page; if the problem persists, please use the OIT Customer Service portal, at http://www.ohio.edu/oitech/, to submit a ticket, letting us know the details: which page, where on the page to look for the discrepancy, and whether, on the one hand, the particular outdated content is a minor item that can be left in place while we and PaperThin work to figure out the cause, or, on the other hand, it is a critical change that should be forced through immediately.
PaperThin has released and we have now installed the "Winter 2012" Service Pack for CommonSpot. Please let us know if you encounter any problems.
We will update the following list as our understanding, or the facts, change:
With some browsers, the Rich Text Editor ("RTE" -- used for creating and updating Formatted Text Blocks) will not display the cursor, so you cannot readily tell where the changes you make will happen.
The work-around is to click first in the gray boundary area, within the lightbox for the RTE, but outside of the content display area; then click in the content display area, and you should see the cursor.
Updates to content may not be visible when viewing a page as published on the authoring server (author.oit.ohio.edu), or when looking at the page on the read-only server (www.ohio.edu).
The work-around is to clear and update the server's cache for that page: go to the page on the authoring server, reload it to confirm that the updates are not visible; if the problem persists, click on the pencil at the upper-right to View the Page in CommonSpot; click on the "Actions" button on the content-spanning toolbar; and choose "Clear and Update Cache..." (at the end of the menu).
Adding images in the RTE may fail, with an error message indicating that you "no longer have a lock on the requested item/resource." If you encounter this problem, please let us know immediately, because we believe that this issue has been resolved.
The referring pages list is sometimes falsely empty, or incomplete.
The work-around for now in situations where you are replacing a page is to use the Standard Properties "expired content" redirect. Later, when the referring pages lists are reliable, you can use them to mend any links that would be broken by deleting the retired page, and then remove it.
We have seen some situations where only some of the sub-subsites of a subsite are visible while building a link to a CommonSpot page with the "Choose..." button. If you know a sub-subsite exists, but you don't see it, please let us know the details, so that we can provide PaperThin with more examples.
We have seen some situations where content pasted from Microsoft Word (especially into the Rich Text Editor) does not display properly. In the RTE, the upper-right quadrant of the toolbar includes an icon with a "W" superimposed on an eraser; you can use that to clean up your content. Please let us know about any problems that persist after doing that.
You can still force a login by going to your subsite's admin.cfm page; however, in V6 the result is to display the CommonSpot dashboard page in its subsite administration mode, for your subsite. We suggest that you should generally start your authoring sessions by going to http://author.oit.ohio.edu/secure.cfm (e.g., by following the "CommonSpot Authors' Login" link in the secondary navigation block at the upper-left of this page). Please let us know if you encounter any problems logging in.
If you start working in CommonSpot, and then do other things for so long that your session expires (typically 20 minutes of inactivity), it may display a generic, non-Ohio University login dialog that you cannot use:
We believe this issue has been resolved, so if you encounter it, please let us know immediately. In the meantime, if you do get the above login lightbox (without the red editorial comment, of course), there are two ways to work around this problem: you may either quit the browser and start over, or manually go to http://author.oit.ohio.edu/secure.cfm (where your browser will automatically renew your session) -- either by typing the URL into the address box, or by using a bookmark -- and then manually return to the page you were working on, and reload it. As with V5.1 in such a situation, un-saved work in progress (e.g., within the Rich Text Editor) is likely to be lost.
Image Grid elements may well not work: existing image grids continue to function, and changes may be possible through FireFox. This issue has been reported to the vendor.
Global Edit Text Fields do not work. This issue has been reported to the vendor.
Changing ownership of a page or template may generate an error message, but it works. This issue has been reported to the vendor.
Changing the subsitewide default value of the number of days of version history to display may generate an error message, but it works. This issue has been reported to the vendor.
Don't try to use the "Quick Find" feature (located in the top-center of the full-width menus; it does not work. If you try to use it, you will not be able to do anything until it times out, after 120 seconds, and then you must use the browser's reload or refresh before you can do anything else (and that will destroy un-saved work-in-progress). This issue has been reported to the vendor.
Our apologies for the inconveniences today. We used the two emergency authoring freezes this morning to install patches from PaperThin that do appear to have addressed the performance problems we saw earlier in the day. We used the mid-afternoon authoring freeze to install patches from PaperThin to address further performance issues. There may be another authoring freeze this afternoon to address other issues. Please do let us know if you encounter any problems, so that we can work to resolve them.
The upgrade to CommonSpot V6.2 is complete, and authoring will be restored this afternoon. Shortly after it is restored, we will send an e-mail to all content contributors. Please let us know if you encounter any problems.
We will update these pages to include any items that we think might affect others:
Content that was originally copied and pasted from Microsoft Word may require manual editing to repair the text -- in particular, ampersand codes may show up visibly there they are not wanted.
You may well have to clear your browser's cache (delete temporary internet file) before CommonSpot will work correctly.
We are currently planning the CommonSpot V5.1 to V6.2 upgrade to begin at 12:01 am on Monday morning, December 12. We expect to complete the work during the afternoon of Tuesday, December 13. Authoring will be frozen throughout that process, and the authoring server (author.oit.ohio.edu) will be offline for much of that time.
The public servers (www.ohio.edu) will be offline for several hours, starting at 12:01 am on Tuesday morning, December 13. While the public servers are offline, no CommonSpot page, image, or uploaded document will be available. During that time, a temporary page will be displayed from the static-page Front Door server, so that your audience understands that the situation is a temporary outage during planned server work. The temporary page will include links to services that people routinely access by following links from CommonSpot pages (e.g., the My OHIO portal).
We may be able to provide one last opportunity for all CommonSpot authors to experiment with V6.2 before the upgrade; if so, the details will be available here.
Authoring was restored Wednesday morning, 11/29, around 7:30 am.
We continue to prepare to re-try the V6 upgrade again in mid-December. The next step requires that CommonSpot authoring will be disabled Wednesday morning, November 30, starting at 4 am. We will re-enable authoring as soon as the work is complete, probably mid-morning.
CommonSpot authoring was broken Monday morning, October 17, from about 9 am until about 9:45 am. The issue appears to be resolved, now.
The V6 upgrade that started Friday morning, August 19, has been rolled back; we are still running V5.1.1; authoring has now been re-enabled.
We will update this page with information about the next attempt to upgrade to V6.2.
At this time, we anticipate that all three of the regular servers will continue to serve the www.ohio.edu pages throughout the day and evening of the upgrade, while the authoring server and database are upgraded (that will prevent performance problems). Shortly after midnight, all three will be taken offline to complete their upgrade. While the three are offline, any attempt to get a CommonSpot page from www.ohio.edu will be redirected to the outage page. Normal service for www.ohio.edu will be restored as soon as all three are upgraded (we anticipate that will be before 3 am). The authoring freeze will continue while other tasks are completed. We anticipate that the authoring freeze will end by 6 pm of the second day.
We plan to update the header section of the "official_pages1" template in the middle of September. Most classic CommonSpot pages for official subsites have been built directly or indirectly on that template, so the changes will affect many pages. However, we do not believe that you will have to do anything beyond inspecting your pages on the test server, to confirm that there are no unintended side-effects of the changes. An initial version of the revised code is already in place on the test server, so take a look whenever it is convenient.
What will not change:
The width of your page (whether 100% of the window, 672 pixels, or 760 pixels).
The content of your page.
Any customization you have made to the page footer.
What will change:
If you now have the pale-green sitewide navigation bar between the header and your page content, it will be removed.
The new, thinner, dark-green sitewide navigation bar will appear at the top of the page, whether or not you now have the old sitewide navigation bar in place.
The section in the middle of the header (with "you@Ohio" and "Apply Online") will be replaced by "My OHIO," linked to the new portal.
The search box at the upper-right will have a solid white background, instead of the multi-colored, "Google."
The logo graphic in the upper-left will be shorter.
In summary, the header will look very similar to this page, and therefore to the university's home page and to many other more recent pages. If you do have the old sitewide navigation bar in place now, then the new header will be more than 25 pixels shorter than the old header; if you don't have it in place now, then the new header will be more than five pixels shorter. Either way, more of your page content will be visible without scrolling.
The CommonSpot upgrade to Version 6.2 is scheduled for this coming Monday and Tuesday, August 15 and 16. See the V6 differences and V6 FAQ links in the secondary navigation block to the left to learn about the new version.
The upgrade process requires several authoring freezes, some of which have already happened, some of which may be outside the normal maintenance windows, and some of which may be scheduled with limited prior notice. During the upgrade itself, we anticipate an extended authoring freeze of perhaps two days' duration. We do not anticipate any outages of pages on http://www.ohio.edu/ (although it may at times run more slowly than usual).
The test servers are now available for you to experiment with the new version, before we install it on the production authoring server and ROPS. Please try to take advantage of that opportunity: this is a major release (we are currently running V. 5.1); there are significant changes in the authoring user interface. We have documented the changes, but it will be to your advantage to have experimented with the new version ahead of time, for yourself.