The wiki comes with an invitation to edit the first page.

So I edit it.

It looks like it is saved, doesn't it?

Can't stay in the wiki forever. There are other things to do.

I'd like to add some other content there now. That's what wikis are for.

Looks like we're back to where we started.

I love the movie Groundhog Day. I enjoy watching it on TV. I don't like living through it.

After working with the wiki for a few weeks, suddenly everything vanishes and we're back to an empty, unedited wiki.

Gina Stephens wrote:

We are having tons of problems.  All assignments/quizzes seem to
disappear for no apparent reason and then magically reappear.  I am
frustrated.  Students are frustrated.  I am considering a life of
crime.  It is awful.

Eric Smith wrote:

Not that am glad you are all having problems, but I am 
relieved to see that we are not alone.  

We too were seeing this problem, first with the Wikis, then 
with assessments.  

Again, ANGEL Learning has not been able to duplicate, but 
they recommended the app pool recyle.  So whenever these 
started to occur, we would recycle the app pool, and like 
magic, everything works again.  But, if a kid is in an 
assessment during a recyle (or any content), their work is 
lost.  Obviously, this is not good.  But regardless, we have 
to do it.  

Upon further research, we now believe, that the backup is in 
the database, causing asp pages to hang.  This eventually 
needs to errors such as:  timeout, invalid sessionstate, 
expired session, page cannot be found, etc...  Most notably, 
the errors are notices most in Wikis, assessments, and 
trying to edit the RSS nugget on the portal page.  

After further discussions, we are curious as to whether or 
not our Stored Procedures are up to date, or even if they 
are all there.  We suspect that a previously update or 
upgrade may not have successfully completed, but we aren't 
positive.  

Another thing is that these really started to become 
prevelant almost immediately following the December 2007 
Service Pack was installed on our instance.  We are being 
told by ANGEL that we are the only ones with this problem 
and that it must be our configuration.  But after talking 
with some other people, I'm really starting to doubt.  

If you look in your error logs, are seeing any of these 
errors?  Most noticably any out of memory errors?  If so, do 
these errors tend to correspond with the times that your 
wiki's/assesments are broke?

1. Restart SQL database server.

This has happened with our Wiki and Blogs off and on. 
The solution that has worked for us is to restart the 
SQL database server. All blog and Wiki postings will 
return as if they never left. Somehow the Blogs and 
Wikis are losing their connection with the Database, 
but once the database is restarted, things seem fine. 

___________________________
Mike Wright
ANGEL LMS Administrator
TRECA

2. Recycle the app pool nightly.

Subject: Re: [ANGEL-L] Blogs in 7.2
Date: Thu, 27 Mar 2008 20:19:55 -0400
From: Justin St.
Reply-To: ANGEL User Group List <ANGEL-L@LISTSERV.IUPUI.EDU>
To: ANGEL-L@LISTSERV.IUPUI.EDU

I know the wiki entries are stored in mdb files on the web 
server...so I'm not sure that restarting your db server 
what is causing your wikis to re-appear.   I would guess 
that restarting your database server is causing the app 
pools to recycle which is actually what is fixing the 
issue.  
 
App pool recycles have always seemed to do the trick 
for us.   We do them nightly and don't see the issue 
much anymore.

3. Investigate .mdb

Jennifer Mullen wrote:

After making an entry, try going to 
Utilities/Associated File Manager. 

What's the timestamp on the wiki.mdb file? 

Does it match the time that you edited an entry? 

Download this file and open it up in Access. 

Look in the WikiEntries table. 

Does your entry appear there? 

What about the WikiHistory table?

4. Edit Welcome message in stages (Ron Blue).

• Edit the body only.
• Save.
• Edit the Title only.
• Save.

I checked this out again and had the same problem you 
are having then I had to discover again how I did it 
by chance.

Actually let me restate the process.

Create a new wiki

edit the welcome page text only, save the change.

edit the new welcome page, change the title, save the change.

problem fixed.

Why would this be true?  A file must exist to be 
accessed.  The command is to look for Welcome until 
changed. The default is Angel's Welcome.  Trying to 
change Angel's master is not allowed, pushing the system 
back to default.  Saving a Welcome page with changes 
is allowed because it is stored in the class.  A 
welcome page must exist in the class first.  Then the 
title can be changed to any name.

Ron Blue
LCCC

• Our Angel support guru wants to remove the wiki/blog option from “Add Content.” Angel can't replicate the problem, so they can't fix it. I'm not going to fight to keep Angel's wikis and blogs. I'll try something else for class updates.

• The wikis didn't work at first. Our ITS folks filed help tix.
• The wikis started working. I made notes on classes. Unclicking “no banner” made the wikis come and go (see below).
• The wikis stopped working. Data seemed to be lost. “No banner” was already unclicked. Clicking and unclicking “no banner” made no difference.
• The wikis started working. The data came back.

I'm convinced that Angel doesn't know what is causing the problem and that they do not have a solution for it.

Nevertheless, I used the blogs successfully during the semester.

I like wikis.

Current theory: the wiki/blog pages are losing contact with the Access database in which the entries are stored. This is not a programming error, per se, but something in the environment that gets knocked askew from time to time in particular setups. It is a systemwide bug because it affects all wikis and blogs in the system, not just mine. There really isn't anything I can do about it from my end.

— PROBLEM BACK! 2007/10/15 12:46

Canisius applied the September updates from Angel.

The bug is back, as described below.

The trick of not checking “no banner” does not work any more.

Groundhog Day!

— Update 2007/09/05 09:08

I've heard that Angel Learning has been able to replicate the problem and am assured that the help ticket has been escalated. The bug should be fixed Any Day Now.

— Problem fixed 2007/09/06 17:00

Dunno who fixed what, but both the blog and the wiki tools are up and running now.

— Possible fix noted 2007/09/07 12:04

The problem can be caused by checking the “no banner” option in the settings for a wiki or a blog:

When “no banner” is checked, no entries will show.

— Update 2007/09/05 09:08

I've heard that Angel Learning has been able to replicate the problem and am assured that the help ticket has been escalated. The bug should be fixed Any Day Now.

— Problem fixed 2007/09/06 17:00

Dunno who fixed what, but both the blog and the wiki tools are up and running now. [Vain hope. The fix didn't last.]

The following code shows that security privileges are required in order to save the file. Are the security settings on our server blocking this action?

// Returns null if it can't do it, false if there's an error, true if it saved OK
function mozillaSaveFile(filePath, content)
{
	if(window.Components)
		try
			{
			netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
			var file = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
			file.initWithPath(filePath);
			if (!file.exists())
				file.create(0, 0664);
			var out = Components.classes["@mozilla.org/network/file-output-stream;1"].createInstance(Components.interfaces.nsIFileOutputStream);
			out.init(file, 0x20 | 0x02, 00004,null);
			out.write(content, content.length);
			out.flush();
			out.close();
			return(true);
			}
		catch(e)
			{
			//alert("Exception while attempting to save\n\n" + e);
			return(false);
			}
	return(null);
}

My latest theory is that AutoSave has not been turned on by the person or persons who configured Angel on our system. Here is what AutoSave is supposed to do:

“The addition of AutoSave to the InterfaceOptions causes TiddlyWiki to automatically perform a SaveChanges each time you edit a tiddler, making it a good deal harder to accidentally lose information” (QWikiWeb).

The configuration of TiddlyWiki in Angel requires that AutoSave be on because there is no separate option to save the wiki as a whole. The only “save” option is for each entry (tiddler).

The code in the init.htm page looks to see whether this flag is set:

if(config.options.chkAutoSave)
saveChanges();

Now the question is: where in the Angel setup is the AutoSave option to be found? Where would a helpful ITS person go looking to see whether that AutoSave is turned on for our system?

TiddlyWiki stores all user options in cookies–lose your cookies and you lose your options (I think).

Is the Angel wiki similarly using cookies to store user options? That seems inconceivable to me. The options should be stored in the Access database.

function saveOptionCookie(name)
{
	if(safeMode)
		return;
	var c = name + "=";
	switch(name.substr(0,3))
		{
		case "txt":
			c += escape(config.options[name].toString());
			break;
		case "chk":
			c += config.options[name] ? "true" : "false";
			break;
		}
	c += "; expires=Fri, 1 Jan 2038 12:00:00 UTC; path=/";
	document.cookie = c;
}

The default options seem to be written to an init file when the wiki is created:

merge(rm, {
 sectionId:'34221_RST354A_Fall2007',
 entryId:'52C8A5AE33A21EC759DBA3171D320000',
 userId:'moleski',
 fullName:'Martin Moleski',
 firstName:'Martin',
 lastName:'Moleski',
 enableRss:false,
 enableDownload:false,
 isModerator:false,
 isReviewer:false,
 gateMode:false,
 wikiMode:true,
 isAdmin:true,
 allowCreate:true,
 allowEdit:true,
 allowDelete:true,
 allowComment:true,
 allowApprove:true,
 restrictedTags:''
 }, false);

merge(config.options, {
 chkRegExpSearch:false,
 chkCaseSensitiveSearch:false,

 chkAnimate:true,
 txtUserName:'Martin Moleski',
 chkSaveBackups:false,
 chkAutoSave:false,
 chkGenerateAnRssFeed:false,
 chkSaveEmptyTemplate:false,
 chkOpenInNewWindow:true,
 chkToggleLinks:false,
 chkHttpReadOnly:false,
 chkForceMinorUpdate:false,
 chkConfirmDelete:true,
 txtBackupFolder:"",
 txtMaxEditRows:"18"
 }, false);

rm seems to be a record kept by the Rights Manager:

/***
!Rights Manager
***/
//{{{
if (!window.rm)
    window.rm = {};
    
merge(rm, {
    filemode:(window.location.protocol=="file:")?true:false,
    sectionId:'',
    entryId:'',
    userId:'guest',
    fullName:'Anonymous',
    firstName:'Anonymous',
    lastName:'',
    enableRss:true,
    enableDownload:true,
    isAdmin:true,
    isModerator:false,
    isReviewer:false,
    gateMode:false,
    wikiMode:true,
    allowCreate:false,
    allowEdit:false,
    allowDelete:false,
    allowComment:false,
    allowApprove:false,
    addingComment:false,
    restrictedTags:'',
    ERR:{}
}, true);

That all seems pretty reasonable.

The code to save a tiddler (entry) checks to make sure that Ajax is not in filemode (whatever that may be). This code almost certainly is working because the page does get refreshed with edits as they are saved. The stuff written on the refreshed page has to come from the database–there isn't anywhere else for it to be.

/***

!Ajax Method Overrides

***/

//{{{

store.saveTiddler_orig_ajax = store.saveTiddler;

store.saveTiddler = function(title,newTitle,newBody,modifier,modified,tags) {

    //make sure there are no special win1252 characters

    newTitle = newTitle.escWin1252();

    newBody = newBody.escWin1252();

    tags = tags.escWin1252();

    modifier = modifier.escWin1252();

    var bRtn = false;

    var exists = store.tiddlerExists(title);

    var newExists = store.tiddlerExists(newTitle);

    var nErr = rm.ERR.NONE;

    if (exists && newExists && title!=newTitle)

        nErr = rm.ERR.ENTRY_EXISTS;

    else if (ajax.enabled && !ajax.filemode)

        nErr=ajax.doSave(title,newTitle,newBody,modifier,modified,tags);

    if (nErr==0)

    {

        bRtn = this.saveTiddler_orig_ajax(title,newTitle,newBody,modifier,modified,tags);

		var t = this.fetchTiddler(newTitle);

        t.userid = rm.userId;

        t.guid = 'unknown';

        t = null;

    }

    else

        alert(rm.errorText(nErr));

    ajax.refreshAllVisible();

    return bRtn;

}

These differences make no difference:

• Creating the wiki in my repository or in a course.

• Publishing the wiki from my repository to a course.

• Publishing by copying vs. publishing by linking.

• Assigning start and end dates for the wiki.

• Reserve edit permission to author only.

• Working from my home (Windows XP, Firefox 2.x, IE6) or my office (linux, Firefox 1.5). It doesn't matter whether I create or edit the wiki with Firefox or IE. No joy either way.

• Creating a blog instead of a wiki. It has the same interface and the same problem.

• Clearing my browser cache before and after editing the wiki.

• Creating a new entry, delete Welcome entry.

• Matching tags for the entry with keywords for the course.

• Changing link target to new window.

• Creating an agent to track wiki submissions.

• Opening the wiki frame in a new window (right-click in Firefox, select This Frame/Open frame in new window). The cool thing about this approach is that the page can be reloaded (ctrl-R), which shows the bug more quickly than navigating elsewhere and coming back. I edit the Welcome entry, save it, admire it, reload the page, and am back at the unedited entry in no time.

When I downloaded TiddlyWiki and installed it on my desktop computer, I got a security warning message when I tried to save the wiki. TiddlyWiki wants to make a backup of the original page, then save the new version. Some part of the security system notices the self-modifying nature of the code and objects to it.

TiddlyWiki is distributed in one html file. Each time the wiki is modified … back in a second … need to do some testing …

OK: each time the wiki is modified, the original file is copied as a backup and then the file is overwritten by the new version. In the image below, tidwink.html is the most recent version of the file; the other three files are earlier editions.

Now the big question is: How did Angel Learning modify this behavior?

• Do they also keep the wiki in one file?
• No. “ANGEL actually uses an ajax extension to store updated posts in the Access DB back on the server as they are added. From the discussion on the listserv it sounds as if this is functioning as expected.” So the question raised by this information is: Does Canisius have Ajax correctly configured?

• Is the wiki still driven by Javascript and ActiveX?
  • Yes. View the page source for an Angel wiki page and it reveals that it is TiddlyWiki 2.1.0.

<!--
TiddlyWiki 2.1.0 by Jeremy Ruston, (jeremy [at] osmosoft [dot] com)

Copyright (c) Osmosoft Limited 2004-2006

There are two steps in working with TiddlyWiki that you have to take to modify the wiki: first you edit a tiddler and save that particular edit; then you save the whole wiki as described above.

Angel Learning does allow you to save a tiddler but it does not offer a prompt to save the wiki. I can generate the same problem with TiddlyWiki that I have with Angel Learning by creating any number of edits on old or new tiddlers then leaving the page without saving. When I come back, all the changes I made have been lost (not surprisingly).

The correct records may be in the database. They sure do seem to be there so long as I stay on the wiki itself. It is when I leave and come back that the problem shows itself. How does Angel note that the wiki has been modified?