====== Angel Wiki Problems ====== ====== Bug #1: No Wiki Entries get saved ====== === Opening Up a New Wiki === The wiki comes with an invitation to edit the first page. {{blog:1.jpg?400}} === Edit Welcome page === So I edit it. {{blog:3.jpg?400}} === Save Welcome page === It looks like it is saved, doesn't it? {{blog:4.jpg?400}} === Return to Angel home page === Can't stay in the wiki forever. There are other things to do. {{blog:5.jpg?400}} === Return to the wiki === I'd like to add some other content there now. That's what wikis are for. {{blog:6.jpg?400}} === Changes lost! === Looks like we're back to where we started. {{blog:7.jpg?400}} I love the movie //[[:school:groundhog|Groundhog Day]]//. I enjoy watching it on TV. I don't like living through it. ====== Bug #2: Wiki comes and goes ====== After working with the wiki for a few weeks, suddenly everything vanishes and we're back to an empty, unedited wiki. {{blog:1.jpg?400}} ====== Bug #3: Other stuff disappears, too ====== 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? ====== Suggestions ====== **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 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 ====== Bug Blog ====== === Bug back (August 29, 2008) === * 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. === Overview: January 17, 2008 === * 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. === Last semester's reflections on the problem === ** --- //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: | {{blog:no_banner.jpg?400}} | When "no banner" is checked, no entries will show. === Angel Says They Will Fix it === --- 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.]// === Today's Theories 2007/09/05 === 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); } === Recent Untested Theories --- 2007/09/04 13:39 === == AutoSave not turned on == 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" ([[http://www.personal.psu.edu/ach12/tiddlywiki/#AutoSave|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? == Options not stored in cookies? == 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); ^Field^Initial condition for rm^After merging course info^ | filemode:|(window.location.protocol=="file:")?true:false| //{no change}//| | sectionId:| |'34221_RST354A_Fall2007'| | entryId:| |'52C8A5AE33A21EC759DBA3171D320000'| | userId:|'guest'|'moleski'| | fullName:|'Anonymous'|'Martin Moleski'| | firstName:|'Anonymous'|'Martin'| | lastName:| |'Moleski'| | enableRss:|true|false| | enableDownload:|true|false| | isAdmin:|true|true|| | isModerator:|false|false| | isReviewer:|false|false| | gateMode:|false|false| | wikiMode:|true|true| | allowCreate:|false|true| | allowEdit:|false|true| | allowDelete:|false|true| | allowComment:|false|true| | allowApprove:|false|true| | addingComment:|false| //{no change}//| | restrictedTags:| | | \\ That all seems pretty reasonable. == Ajax misconfigured? == 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; } ====== Failed solutions ====== **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. == Edit Welcome message, comment on it at 1:07 PM == {{blog:tw_prob_06.jpg?400}} == Clear the cache == {{blog:tw_prob_09.jpg?400}} == Edit Welcome message, comment on it at 1:16 PM == {{blog:tw_prob_11.jpg?400}} ====== Theories I cannot test ====== === Javascript/ActiveX permissions problem? === When I downloaded [[http://www.tiddlywiki.com/|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. == When first accessing TiddlyWiki == {{blog:tw_prob_02.jpg?400}} == After clicking on IE permissions bar == {{blog:tw_prob_01.jpg?400}} == ActiveX warning then appears == {{blog:tw_prob_03.jpg?400}} == Then the wiki modifies itself == {{blog:tw_prob_04.jpg?400}} == Access database permissions problem? == 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. {{blog:tw_prob_05.jpg?400}} 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.