Community Forums

ATutor Bug Reports

Few bugs in

Page: 1

Avatar for IndieRect
Subject: Few bugs in this post in your reply
Hello. I've started translating and evaluating, and noticed a few bugs, the first of which is critical for us.

MC questions

* Answers to multiple-select multiple-choice questions are always incorrect.
Reason: In tools/take_test.php line 253, a hidden field is inserted, which later is treated as an incorrect answer (this line was added in 1.5.3).
Possible solutions: Remove that line, or, in case it's placed right, in line 78 initialize $num_answer_correct variable with 1, not 0.


* AT_language_pages: size of 'term' field should be increased to that of AT_language_text, since some variables have names longer than 30 chars (e. g. $enrolled_list_includes_assistants and $import_content_package_bottom_subcontent). That causes false entries to be shown in list of vars, which produce "not found" errors when clicked and effectively prevent from translating those vars.
* It seems that language variables, which are used only in included PHP files, are not recorded to the AT_language_pages table, making harder to find out the context they are used in.
* If a filter for New or Updated terms is applied, and any term is saved, that filter is active no more - all the lang vars are shown.

The latter 2 appear to be long-playing for many versions. Possibly that is because translating is not a job the end users do, and the bugs are quickly forgotten when translators get used to living with them smile, but I guess it might deviate some people just starting translating to a new language. Anyway, it seems that translating interface is the most outdated and inconvenient part of ATutor.

Default language

* There's no way to select the default language neither for an admin nor for a member.
The corresponding member tool is commented out. Is it for some reason or is it a forgotten debug-time issue?
Posted: 2006-08-09 04:40:16

Avatar for greg
Subject: Re: Few bugs in this post in your reply
We'll post a fix for the test issue shortly, and add the others to the bug tracker and look at them during the next development cycle.

There is no language default anymore. It defaults to the last language used.
Posted: 2006-08-09 09:01:13

Avatar for joel
Subject: Re: Few bugs in this post in your reply
The default language is found under admin -> System Preferences.
Posted: 2006-08-09 10:12:56

Avatar for IndieRect
Subject: Re: Few bugs in this post in your reply
Thanks for putting the bugs to the tracker.

About language:
Changing language automatically to the last one used was something I thought about at first. But as far as I tested, this works only for members, not admins. That made me state it's a bug.

System Preferences are system preferences, not profile's. There may be many admins, each speaking another language. Put it this way or another, it still doesn't work. In my case, I had to edit AT_admins to switch language for the administrator account.
Posted: 2006-08-09 10:28:27

Avatar for joel
Subject: Re: Few bugs in this post in your reply
to fix the test bug
replace line 77 in tools/take_test.php with:
highlight_code('if (is_array($_POST['answers'][$row['question_id']]) && count($_POST['answers'][$row['question_id']]) > 1) {
if ($_POST['answers'][$row['question_id']][0] == -1) {
// place holder was added in 1.5.3 in case a multi-choice multi-select is left blank.
Posted: 2006-08-09 11:07:39

Avatar for IndieRect

Attachment: ukr_numbers.php
Subject: Bugs in this post in your reply
Here's the list of bugs and errorsI found in ATutor Their number is quite large despite the fact that I didn't search for them. I was just translating, and roamed the pages for catching context. The result of the latter one will see in my translation, and here's what I caught besides that main task.

== Errors and Bugs ==

1. MS MC questions

1.1. Continuing the above discussion.
To start with, I'd say that your fix, Joel, doesn't work well. Now in historical order.
Since the time the feature of MS MC (multi-select multi-choice) questions was added, line 77 of tools/take_test.php contained a logically incorrect condition, which caused line 95 (below) to NEVER execute.
$_POST['answers'][$row['question_id']] = '-1'; // left blank')
Even when the file was reviewed for 1.5.3, this remained overlooked. Now, after you fixed the bug caused by 1.5.3 "fixing" and changed the condition, execution does come to that line 95 (or whichever number it has now).
But the line is also incorrect by itself - the following implode(), to which this variable is passed, appears to require an array as its parameter. As a result, the DB is updated using an empty answer string.
Effectively, the fix was rolled back to 1.5.2, but now the bug is harder to notice and track.

To ultimately fix this issue, at the same time being careful about possible hidden field's moving or other inattentive code changes (and eliminating the assumption made in rev6563), I've slightly modified Joel's code, and suggest the following:

Replace lines 77 to 97 of tools/take_test.php (

if (is_array($_POST['answers'][$row['question_id']]) && count($_POST['answers'][$row['question_id']]) > 1) {
if (($i = array_search('-1', $_POST['answers'][$row['question_id']])) !== FALSE) {
$num_answer_correct = 0;
foreach ($_POST['answers'][$row['question_id']] as $answer) {
if ($row['answer_' . $answer]) {
// correct answer
} else {
// wrong answer
if ($num_answer_correct == $num_correct) {
$score = $row['weight'];
} else {
$score = 0;
$_POST['answers'][$row['question_id']] = implode('|', $_POST['answers'][$row['question_id']]);
} else {
// no answer given
$_POST['answers'][$row['question_id']] = '-1'; // left blank
$score = 0;

1.2. There are also problems with computing statistics for MS MC questions. I briefly examined the operation of lines added to tools/tests/results_all_quest.php in 1.5.2, and came to conclusion that you didn't go over the impact that would adding this feature have on the script operation. Please have a look at it.

2. Reading list

2.1. reading_list/edit_reading_file.php shows a blank page because of a misspelled 'echo' on line 114.
2.2. When editing resource, clearing one of the required fields and trying to submit, the same page with an error message reappears, but the page title states "Add Resource ...". If then those fields are filled and the form is submitted again, the resource is added as a new one, not edited.
2.3. Additionally, in 2.2 after the first erroneous submission, if a language is switched, all fields go blank.
2.4. Additionally, if resource in 2.2 is a URL, after the first erroneous submission URL field goes blank.
2.5. In reading_list/index_instructor.php, when any of the readings is edited, a feedback message says that the reading was successfully ADDED.
2.6. A two-step resource addition process is hardly understandable. More specifically, the steps themselves, button captions and feedback messages are not self-explaining enough. I believe this process should be slightly redesigned, to become clear without the necessity to read the handbook.
2.7. Files are not split into student's and instructor's sections (reading_list/* and tools/reading_list/*), like in other similar tools.

3. Links

3.1. Links are no more accessible from Manage tab, only from student's Home tab. This breaks a clear distinction that we used to present to our instructors: "Everything you use to control the course is on the Manage tab. Nobody except you and those you gave such privileges can access it. Everything located elsewhere students can use just like you do".
What was the reason for doing so?

== Language Errors ==

4. Hard-coded English
4.1. "Or, Groups:" in tools/course_email.php.

5. Improper i18n, resulting in linguistically incorrect phrases

I believe that the principle which would lead to a good i18n sounds like: do not assume any particular order of words in sentence, as well as any way of word combining.
I am thankful for your efforts that almost eliminated such issues from normal full sentences.
But, as I can see, a new kind of this problem appears in ATutor code, the so-called "# of" bug. It's when a number and a unit are combined right in PHP code, like $num . ' ' . _AT('files'). Or, I saw another variant: if there's one item, you use AT_('item'), otherwise AT_('items').
To illustrate that it can be not as simple in other languages, I attach here a script that shows how such a distinction would look like in Ukrainian.
Basically, this script shows that for my language, not 2, but 3 variables should have been used, and the rules for their usage may look weird for you (of course, if you aren't familiar with any of Cyrillic languages). I want to say, that the best thing you can do is defining 1 variable looking like "%s Items", and then each translator would make it fit his own language.

For the following text, I continue using the scheme $var_name to indicate language variables.

5.1. "# of" bug: $groups, $members in tools/groups/index.php.
5.2. "# of" bug: $submissions and $unmarked in tools/tests/index.php.
5.3. "# of" bug: $search_results in search.php.
5.4. "# of" bug: $comments in file_storage/comments.php; meanwhile, at least 2 vars exist serving the same purpose: $comments_num and $fs_comments.
5.5. "# of" bug: using either $fs_comment or $fs_comments in file_storage/index.php depending on a number of comments. Besides, in this case there's no need in using any words in cells - just numbers.
5.6. "# of" bug: the same with $fs_revision and $fs_revisions.
5.7. "# of" bug: the same with $mark and $marks in tools/take_test.php (multiple times).
5.8. Concatenation of $total and $results in tools/tests/results_all_quest.php instead of declaring a separate variable.
5.9. Administrator should be able to change the order of names in full name. It shouldn't be a hard-coded concatenation like in directory.php.

6. Language variables with outdated or otherwise incorrect content
$AT_FEEDBACK_RL_RESOURCE_DELETED (resource, not reading)
$AT_INFOS_ASSIGNMENT_FS_SUBMISSIONS in assignments/index_instructor.php - back to pre-1.5 guidelines style.

7. Duplicated variables
$or and $rl_or
$reading_list and $rl_reading_list
$category and $rl_category
$start_date and $rl_start_date
$end_date and $rl_end_date
$file and $rl_file
$optional and $rl_optional
$url and $rl_url
$comments_num and $fs_comments
$auto_install_languages_cron and $mail_queue_cron

8. Misspelled variables (in DB)
$editor_properties_insturctions_related (in code too)

9. Unused variables (exist in DB, not get used in PHP code)
I believe you'll be able to find some more with a simple grep-based script.

10. Other
Variable $glossary_term_limit (content editor) states that glossary term limit is 60 chars. But Unicode strings of >30 chars will fail length checking, and this message will appear, causing users' misunderstanding.

About Reading List in #7 and #9.
It's a good idea that a separate module has its own variables and own prefix. It simplifies translation and maintaining. But I believe it should use as much common language vars as possible. In other case, there's a perspective that vars bred in this way will dominate in a new language added between versions.
Also I consider such a list of unused variables to be too long for a module which is included for the first time,
And I would like to note that new messages, added in file storage and reading list, are often too brief and are much harder to understand than earlier terms.
Altogether with numerous minor and clearly noticeable bugs it gives that RL module is too raw and should have been tested for some more time before releasing.
Posted: 2006-08-11 04:20:59

Avatar for joel
Subject: Re: Bugs in this post in your reply
Thank-you for your detailed bug report. The lack of proper testing of 1.5.3 is visible by the need to release two and possibly three bug fix releases. Recently, it has become our policy to have the community test beta and release candidates before their release.

Now on to your issues:

1. MS MC questions

You are correct with your changes and have been fixed.

2. Reading list

This new module is the result of a new team member who was asked to create it as a side project. It probably should not have been included into the final release as it was not looked over enough. There are many other bugs we have identified that will require some considerable work to fix.

3. Links

I agree with the confusion over where to manage links.

5. i18n

This has been an on going issue that we've been trying to deal with since the beginging.

7. Duplicated variables

Largely due to the RL.

9. Unused variables

We do have a script that detects unused language. We just have to run it more often.

10. Other

Converting atutor to correctly use unicode will require a lot of work and make the requirements to install atutor more strict. Our plan is to move completely to utf-8 by 1.6.

We're still investigating ways to keep module language seprate and better ways of managing the language as a whole. It's just a matter of priorities.
Posted: 2006-08-11 10:42:38

Avatar for IndieRect
Subject: Re: Bugs in this post in your reply
Thank you, joel. I see you're aware of these issues. Hope our correlated efforts will make ATutor still better.
Posted: 2006-08-14 04:22:31

Avatar for IndieRect
Subject: Re: Bugs in this post in your reply
Here are some more bugs.

File Manager
* In tools/filemanager/preview.php, base64_encode() is used to generate file names. If AT_FORCE_GET_FILE == FALSE, the system probes for a file with the encoded name directly in content/, and, of course, shows Error 404.
* When a file upload starts, a progress window (tools/prog.php) opens. If the upload finishes before that window is completely loaded (it happens very often in our LAN), the progress window doesn't close automatically, likely because of session_write_close(). It's a long-existing bug (1.5.1 min).

Reading List (reading_list/reading_details.php)
* BR tag misspelled in line 66.
* Lang var $rl_id (line 78) absent in AT_language_text.

get_login() and $_SESSION['login'] now return a full name. I have some notes on this:
* Bug: The variable is not updated when the profile settings change.
* In the function it is hard-coded as 1st Name + 2nd Name + Last Name. It constitutes an i18n bug.
* Some our scripts use the var exactly as a login. Now we have to edit them and add an extra SQL request. However, once we noticed this, it's not a problem any more, but it can make problems for other users.
* Last but not least. It's strange to see a function and variable called 'login' containing a full name. I think this surrogate was the faster way you chose, but it creates a confusion and has a large bug potential.
Posted: 2006-08-19 04:25:50
Subject: Re: Bugs in this post in your reply
Hi, could anyone help me on this error at login.php?

Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in E:\xampp\htdocs\ATutor\include\classes\Module\Module.class.php on line 57

Things to describe:
operating system - win XP
version of ATutor -
versions of php - 5.0.4
version of mysq l - 4.1.12
webserver & version - apache
copies of error messages - as above
changes to default settings - none; fresh installation with default settings
web browser being used - firefox 1.5

Really appreciate your help.
thank you,
Posted: 2006-09-04 04:39:11

Avatar for greg
Subject: Re: Bugs in this post in your reply
Make sure sessions are enabled in php.ini

session.use_cookies = 1

Also make sure mysql is running properly. See if you can access it from the command line, or through some othert application that uses mysql, such as the xamp control panel.

In reply to:
Hi, could anyone help me on this error at login.php?

Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in E:\xampp\htdocs\ATutor\include\classes\Module\M...

Posted: 2006-09-04 09:42:20
Subject: Re: Bugs in this post in your reply
Ithanks for your help, greg.
Posted: 2006-09-05 04:57:29
Page: 1

You must be signed-in to post.

Related Articles