A strange learning path bug… fixed

See update below for the fix

I’m trying to get my head around a super-tricky bug since last Friday. Basically, the bug happens only on one portal and with a specific learning path imported by Oogie.

The bug appears due to a loss of session before the generation of the table of contents.

Something like this appears:

Fatal error: Call to a member function get_theme() on a non-object in /var/www/yourportal/main/newscorm/lp_toc.php on line 39

The bug is not in the Oogie conversion (no strange characters) as the same content works on another portal on the same server.

The bug is not a PHP configuration problem either, as again, another portal on the same server, with the same PHP configuration, works perfectly.

The problem seems to reside in the time the newscorm tool needs to generate some of the frames. Apparently, one of the frames loads before the others, and looses the session data, but only on this portal.

I’m not out of things to try out, but this one is really a painful one.

2008-07-04 Update

After a long week of interrupted searches, I realised (mostly thanks to a conversation with Arnaud) that the bug was caused by an overflow in the session size capacity.

Now most of you PHP developers will think “mmmmh, is there actually a way to limit sessions file size on disk?”. Well, the answer is “no”, not in the predefined PHP5 options, anyway. However, there is kind of a special condition here: the portal on which this error occured had the setting configured to save the sessions inside the database, using the dokeos_main.php_session table.

The thing is, inside this table, we defined the field to store the session as a “text”-type field (or blog, which is the same for MySQL 5). However, I did an enormous mistake in thinking that a “text”-type field could actually store up to 4MB. It can’t. It just stores a maximum of 16KB.

This size should be enough, in most situations… yes, but not in the learning path object situation. Learning paths are very large objects with a structure set to limit the number of queries made on the database. Even then, however, it coped nicely with *most* learning paths, until this 56-pages learning path appeared. Apparently, the structure was too large and went over the 16KB limit, making it unproper to serialization into the database field.

So basically, turning the field to a MEDIUMTEXT field fixed the problem:

ALTER TABLE php_session CHANGE session_value session_value MEDIUMTEXT NOT NULL;

To make things clear, the problem appeared to be a loss of session, somewhere between the script where the learning path object is built and the first script using it straight from the session.

Debugging the second script showed that the session was recovered (or rebuilt), but without that large element, which just couldn’t be stored in the database. This made it really difficult to track down, as nothing is telling you anywhere (even with full debugging on) that the problem comes from the session size and the database field limit…

Of course, this has all been fixed in the Dokeos code for the next version of Dokeos, so you don’t have to worry too much about it, it will just get updated automatically.


  • krizanke1
    1 July, 2008 at 6:56 pm  - 

    Well there is another bug that bugs us. Making links doesn’t work with Firefox 3. See video: http://sodelovanje.com/dokeos.swf

    When you click “ok” to save the page the “link” window pops up again and the link becomes some non-working javascript..

  • ywarnier
    1 July, 2008 at 7:16 pm  - 

    Yep, we’ve been reported this. Considering the stable release of Firefox 3 and the stable release of Dokeos 1.8.5 were at about the same time (I think we released a few days before Firefox 3), we would have had a hard time finding out in time (although it could be argued that, with the beta of FF3…).
    Anyway, the bug is related to FCKEditor and we have been made aware of it already. Seeing how things are going now, it is *possible* that we will release a 1.8.6 version earlier than planned. It’s not that 1.8.5 is unstable, but rather that it is so stable that people actually report minor bugs like this one (which kind of never happened before).
    We haven’t got our heads around it yet (because there are other pressing matters for us as a company and community) but we would love to see a contribution from anyone to fix it. Beware that FCKEditor has been considerably modified to integrate perfectly in Dokeos, so it’s not just a matter of putting the latest version of FCKEditor (which reportedly fixes the problem) into Dokeos.

  • I think this should do the trick to get links on FF3.

    Replace maininclibfckeditoreditordialogfck_linkfck_link.js with this version:


    Look at lines 486-500 to see the changes.

  • ywarnier
    2 July, 2008 at 4:01 pm  - 

    As posted in our BTS (link above), the patch has been checked by Julio and commited to the Dokeos SVN (will be there for 1.8.6).
    Thanks for the contribution.

Comments are closed.