Delayed Updates Fixed
- The problem that PaperThin staff had identified a problem that intermittently obstructs the transfer of updates from the authoring server to the public server was resolved by the V5 upgrade over Labor Day Weekend. Once obstructed, all updates were stalled until we intervened manually. The system did not notify us automatically that updates are blocked, but we did have a tool that permitted us to confirm such obstructions.
Therefore, if you submitted a change, or an entire page, for publication on the authoring server, and your change was visible in Read mode on the authoring server, but the old version continued to be displayed unchanged for more than five minutes on the public server, we needed you to let us know right away by one of the following two methods:
- Phone the OIT Service Desk staff at 593-1222
- E-mail the OIT Service Desk staff at servicedesk@ohio.edu
Authoring Freeze Thursday night, September 25, 2008
- The authoring freeze will start at 9:55 pm and conclude Friday morning, likely before 7 am. The planned work is to take a complete copy of the disk files and the database, so that we can re-establish the development and test environment for further improvements to V5.
Authoring Freeze Sunday, September 7, 2008
- The authoring freeze will start at 5 am and conclude when the work is finished, likely around 10 am. The planned work is the installation of patches to fix the "tiny-font" problem that has affected parts of a large number of pages since the upgrade to V5.
Authoring Freezes Wednesday Morning, August 27, and Labor Day Weekend
- The Wednesday morning freeze will start shortly before midnight, Tuesday night, and conclude before 7 am on Wednesday morning. This freeze is for network changes in the Computer Services Center machine room. (All Front Door pages, and many other services, will be completely unavailable for a short period of time after midnight.)
The Labor Day Weekend freeze started at 5 pm on Friday, August 29, and concluded when the work is finished, around noon on Tuesday, September 2.
You will find that the login process is different, and, once logged in, that the tool icons and page layout also look different. The logic is the same, and most of the menu choices are in the same place, but the icons and the names of some choices have changed.
We expect that learning to use the new version won't be trivial, but it should be reasonably easy.
If part of your page's content is missing or ugly because the background color is not what it should be, you can fix that yourself (we did our best over Labor Day weekend to identify and fix such problems on each CommonSpot subsite's home page, but we may well not have found all such problems). If you cannot fix it, please do use the e-mail link, above, to let us know the URL of the page or pages.
Authoring Freezes Friday and Saturday Mornings, August 15 and 16
- The Friday morning freeze will start at 5 am and conclude when the work is finished, probably before 7 am. This is the first freeze for the CommonSpot Overhaul project described in the next section.
The Saturday morning freeze will start at 1 am and conclude when the work is finished, probably before 8 am. This is the routine monthly installation of Microsoft patches.
July 28, 2008
- We are sorry for the problems that have disrupted authoring this morning. They appear to be resolved, but authoring may well be slow for a while.
May 16, 2008
- There will be an authoring freeze early Saturday morning, May 17, 2008. The freeze will start just before 1 am and conclude as soon as the work is completed, likely by 9:00 am. The CommonSpot Front Door servers, both authoring and read-only, may be completely offline for software service for part of the time between 6 am and 8 am. As soon as normal operation is restored, authoring will be re-enabled.
May 7, 2008
- The process of copying updated files from the authoring server to www.ohio.edu has been obstructed since shrtly before 5 pm on May 6. Now that someone has brought this problem to our attention, we will remove the problem item, but it will take a while for the systems to catch up on the backlog. No further action by page authors is required, just time for the automatic processes to complete.
May 5, 2008
- There will be an emergency authoring freeze Monday afternoon, May 5, 2008. The freeze will start at 3:07 pm and conclude as soon as the work is completed. This directly affects only the CommonSpot authoring server, but the reason it is necessary is that the public, read-only server (www.ohio.edu) is offline and being repaired. As soon as normal operation is restored, authoring will be re-enabled.
June 1, 2007
- There will be an authoring freeze early Saturday morning, June 2, 2007. The freeze will start at 5:00 am and conclude as soon as the work is completed, likely around 8:00 am. The CommonSpot Front Door servers, both authoring and read-only, are scheduled to be completely offline for software service for about an hour between 6 am and 8 am. As soon as normal operation is restored, authoring will be re-enabled.
May 15, 2007
- The development and test environment work is progressing, so that the domain names for those servers are now established, and so the instructions for configuring Internet Explorer and FireFox have been updated accordingly. If you have been using a CommonSpot feature that is not documented in the Intermediate Pagemasters or Advanced Pagemasters materials, please update your browser configuration, so that you will be able to participate in future testing, to ensure that the features you are using continue to work as expected.
March 2, 2007
- There will be an authoring freeze starting shortly before midnight on Saturday, March 3, and lasting until around 8 am. The CommonSpot Front Door servers, both authoring and read-only, are scheduled to be completely offline for software service for about an hour between 6 am and 8 am. As soon as normal operation is restored, authoring will be re-enabled.
The authoring freeze is extended in order to permit creating coordinated backup copies of the server disk files and the backend database, so that we will be able to bring up our development and test environment in preparation for installation of the latest service pack from PaperThin, which should resolve a number of outstanding issues. More news on that will be posted here as it becomes available.
January 19, 2007
- PaperThin technical support staff have identified a bug in Internet Explorer 6 that interferes with pop-up menus. The bug is not observed in IE7, but at this time about twice as much of our traffic is with IE6 as is with IE7. Therefore, it is appropriate to implement the work-around that is documented now in steps 10 and 11 of the instructions for managing pop-up menus; if this is the only thing you need to do, then perform steps 1, 2, 10, 11, 13, and 14.
Windows Internet Explorer 7
- Microsoft has now included the major update of IE, from 6 to 7, as a high priority update for those with automatic updates or who do it manually. The software appears to work well with CommonSpot, with the following exceptions:
- In the Rich Text Editor (for working with Formatted Text Blocks), the tool button for Table Functions (which you use to insert a new table, and to control an existing table inside the Formatted Text Block), although present, accomplishes nothing.
- For at least some people who had working configurations with IE 6, the upgrade process changes some critical settings.
If you encounter any problems, please go through all of the updated Internet Explorer configuration steps. These do now include the additional step required to permit use of the Table functions within the Rich Text Editor when using IE 7.
Delayed Updates
- PaperThin staff have identified a problem that intermittently obstructs the transfer of updates from the authoring server to the public server. Once obstructed, all updates are stalled until we intervene manually. The system does not notify us automatically that updates are blocked.
Therefore, if you submit a change, or an entire page, for publication on the authoring server, and your change is visible in Read mode on the authoring server, but the old version continues to be displayed unchanged for more than five minutes on the public server, please let us know right away by one of the following two methods:
Other Problems
- If you encounter other problems with page authoring or access in CommonSpot, please report them promptly, so that we can work with you to resolve them.
- Urgent problems should be reported to the OIT Service Desk staff (593-1222 or servicedesk@ohio.edu).
- Less urgent issues can be reported to webteam@ohio.edu, or by phone to 593-1017 or 593-1016.
Form Issues
- Please be aware that the "simple forms" features built in to CommonSpot do provide for the transfer of information from the reader of your page to you by e-mail, but that transfer is not secure. Therefore, never collect sensitive information, such as Social Security or credit card numbers using such forms.
If you use an HTML fragment to create a form on your CommonSpot page using either of the generic scripts documented at http://www.ohiou.edu/pagemasters/memo85/append5.html, please be aware that the same statement applies, because the e-mails they send are also not encrypted.
Change Your OAK Password
- We have found and fixed a one-character-typo in our custom code for CommonSpot user authentication that prevented your OAK password from being encrypted when it was submitted through the network each time you logged into CommonSpot from November 16, 2005 (when we upgraded to CommonSpot V4.5 ), through the morning of June 1, 2006. Windows Internet Explorer did not complain about the problem, but fortunately FireFox did, which directed our attention to it. This un-encrypted transmission created a tiny but not-quite-zero possibility that someone eavesdropping on the network traffic between your computer and the CommonSpot server might have learned your OAK password, and therefore be able to pretend to be you for any service requiring OAK authentication. The risk was less for those who used wired connections, but more for those who used wireless connections. The risk was less for those who logged in rarely, but greater for those who logged in to CommonSpot many times during that interval.
The risk applies to all CommonSpot Subsite Pagemasters and Content Contributors who logged in during the time indicated above; those people are being notified by e-mail. The risk also applies to anyone who provided his or her OAK login ID and password in order to read a protected page on the CommonSpot Front Door (www.ohio.edu); if access was granted on the basis of membership in a particular defined group of people (e.g., prepublication versions of VisionOHIO planning documents were visible to the members of the committee preparing them), then CommonSpot recorded the activity; those people are also being notified by e-mail. CommonSpot keeps no record of people who gained access simply because they have an OAK login, so we cannot notify them personally.
It has always been a good idea, as a routine precaution, to form the habit of changing your OAK password on a regular basis (perhaps once a month or once a quarter). In light of the exposure we have just fixed, we urge that you promptly change your OAK password, which can be done online by taking the appropriate link from
http://technology.ohio.edu/myaccount/
Rich Text Editor Problems
- The Rich Text Editor ("RTE"), which CommonSpot uses to update Formatted Text Blocks, is implemented using programming interfaces provided by Internet Explorer and by FireFox. As such, the RTE will behave somewhat differently on one browser than it does on the other. Also, the RTE is vulnerable to updates for those browsers as well as to changes created by PaperThin. At any given time, you may find that one browser or the other provides a more satisfactory tool for the work you need to do.
For example, one of the April, 2006, patches from Microsoft made a change to IE on some versions of Windows that broke the RTE. A future version of CommonSpot should fix that problem. In the meantime, you can either use FireFox on Windows, or you can back-out that one change, using the Microsoft-provided tool.
You may well also want to install FireFox, and configure it for authoring, so that you will have both browsers and therefore will be able to work productively even when one browser or the other is affected by an incompatibility between CommonSpot and the latest version of that browser.
CommonSpot V4.6.1
- This update has been in production, using a dual-server configuration, since April 19, 2006: the authoring server is "author.admsrv.ohio.edu" and the public -- read-only -- server is "www.ohio.edu".
You will see that the three primary CommonSpot tool icons, which used to live at the bottom-center of the page are now at the top-center.
It will normally take a few minutes for new pages and changes to existing pages to appear on the read-only, public server, "www.ohio.edu," after you have published them on the authoring server. Therefore, do not add links in existing pages leading to new pages until you have seen the new page on the public server (i.e., using the "www.ohio.edu" URL). The delay should be less than three minutes, but, as described above, we have seen longer delays. We are working with PaperThin to minimize the delay and to make it as consistent and predictable as possible.
If you cannot find the template you want to use in the Template Gallery while creating a new page, please navigate to that template, go to Author mode, and confirm that the Page Properties and Template Security are set as documented in steps 17 through 24 of the template creation process. If the template still is not available in the Template Gallery, please contact the Web Team by e-mail (webteam@ohio.edu) or by phone (593-1016 or 593-1017).
Permanent Change of Authoring Server
- Instead of starting your CommonSpot authoring session by going to
- http://pages.ohio.edu/secure.cfm
you will now start your session by going to the new authoring server, at
- http://author.admsrv.ohio.edu/secure.cfm
This is a permanent change; if you have any bookmarks for "pages.ohio.edu", please update them to use "author.admsrv.ohio.edu" instead of "pages.ohio.edu". We have at least temporary automatic re-routing if you use a stale bookmark, but please do update your bookmarks now.
You will also need to configure your browser to trust "author.admsrv.ohio.edu" so that it can work as the authoring server. Details for Windows and Macintosh FireFox and for Windows Internet Explorer are linked from the "Practice and Experimentation" section of http://www.ohiou.edu/pagemasters/commonspot/pageint/conclude.html.
Deleting Temporary Internet Files
- If you are having problems authoring in CommonSpot, you may well find, as several of us have, that it helps to clear out your browser's temporary internet files:
- Take the "Internet Options" choice from the "Tools" menu.
- Select the "General" tab if it is not already selected.
- Click on the three buttons: "Delete Cookies," "Delete Files," and "Clear History," confirming each action.
- Click on the "OK" button to dismiss the Internet Options dialog window.
CommonSpot V4.5
- CommonSpot V4.5 was in use from November 16, 2005, through April 18, 2006. For more information, please see
CommonSpot V4.5 Differences
