Persistent Data was not able to be stored

Huh. I was able to add a tag to this thread, "cookies".

Trivantis: should I, a non-moderator non-threadstarter, be able to change the tags on threads by replying to them?

So that message is sent by JavaScript in Trivantis' included file trivantis-cookie.js. I haven't gone through that file in detail but from the name, I'm guessing the course is trying to set a cookie and the browser is set to not allow that.

OK, on a quick glance, this seems to relate to "suspend" which in this context means saving the user's progress so he/she can return to the last visited page. You can test this by republishing with that feature turned off and seeing if that removes the error.

It's a bug that's been in Lectora for years. Lectora encodes data and then compares the length of unencoded data to the encoded data and throws up the error when it doesn't match.

undefined

The fix is to either

1. edit the js to compare like with like or
2. to not title any pages with characters that change when they get encoded (eg ",6," will become "%2C6%2C" and thus fail the comparison test).

For 1, in trivanits-cookie.js find the section that reads SetSuspendData(newData); (around line 875) and change

if( chkdata.length undefined

}

}

This is an inconsistency with the way data is stored and returned by an LMS. This check was put in for LMS containers that used parameters on a url to send data. Once the limit was reached in various browsers data would be lost. We started checking to make sure what we saved is what we received back. Some LMSs had problems storing data and this was a sanity check.

We removed this in Lectora Online since it rarely a problem anymore.

undefined

In Lectora Desktop you can modify the support file trivantis.js to disable this error (see attached image). Set bDisplayError to false instead of true. This is the easiest way to disable this sanity check. The real underlying problem is that what we save to the LMS and what we receive back are not the same length. This may be because of some differing encoding being used but is is not the same issue where we would lose half of the data in the old days.

We will set the default for this to false in v18 since this is producing so many false positive error reports.

undefined

I know that LMS used to store relatively small amounts of data and it was easily possible to go over the limit but the Lectora error arises not only when you exceed some LMS limit but when you include text that Lectora necessarily needs to encode but then wrongly compares the encoded text to the original (unencoded) text.

Your fix is simpler than mine but mine leaves the possibility of catching a real LMS error.

Has a release date been set for Lectora 18?

Joe, I think you're mistaken about why the false positive error occurs.

At any rate why would hiding 'real' errors be a good thing? Surely users, at least I would, want to know.

undefined