Moodle

MNET course names are not stored/displayed in correct UTF8

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.8, 1.9
  • Fix Version/s: 1.8.9, 1.9.5, 2.0
  • Component/s: MNet
  • Labels:
    None
  • Affected Branches:
    MOODLE_18_STABLE, MOODLE_19_STABLE
  • Fixed Branches:
    MOODLE_18_STABLE, MOODLE_19_STABLE, MOODLE_20_STABLE

Description

When testing Moodle Network features, I have been able to successfully connect two servers.
However, remote course names shown in My courses block are not displayed correctly if there are any non ascii characters. Local course are displayed correctly. See attached picture.

Activity

Hide
Valery Fremaux added a comment -

Issue is deep. Char miswrite are already present in the mnet_enrol_course table. It seems course textual description are not pulled out from remote host consistently when the user enrols in a remote course.

I don't know if it is a push or a pull, i.e. when a mnet transfered user is enrolling to a remote course, do the remote site push course description into outgoing peer or conversely.

I will continue dig in the code as we need this running correctly.

Cheers.

Show
Valery Fremaux added a comment - Issue is deep. Char miswrite are already present in the mnet_enrol_course table. It seems course textual description are not pulled out from remote host consistently when the user enrols in a remote course. I don't know if it is a push or a pull, i.e. when a mnet transfered user is enrolling to a remote course, do the remote site push course description into outgoing peer or conversely. I will continue dig in the code as we need this running correctly. Cheers.
Hide
Valery Fremaux added a comment -

Affects 1.9 either.

Show
Valery Fremaux added a comment - Affects 1.9 either.
Hide
Mathieu Petit-Clair added a comment -

Valery, I'm interested in fixing this one too... Any luck on your side?

Show
Mathieu Petit-Clair added a comment - Valery, I'm interested in fixing this one too... Any luck on your side?
Hide
Mathieu Petit-Clair added a comment -

This problem seems to be specific to MySQL 4.1. Upgrading to 5.0 could fix this, after applying the patch in patch-10935-mnet-utf8.txt

Needs testing...

Show
Mathieu Petit-Clair added a comment - This problem seems to be specific to MySQL 4.1. Upgrading to 5.0 could fix this, after applying the patch in patch-10935-mnet-utf8.txt Needs testing...
Hide
Mathieu Petit-Clair added a comment -

Ah, the patch was made five minutes ago against MOODLE_19_STABLE. It probably won't apply to 1.8.

Show
Mathieu Petit-Clair added a comment - Ah, the patch was made five minutes ago against MOODLE_19_STABLE. It probably won't apply to 1.8.
Hide
Eloy Lafuente (stronk7) added a comment -

Was this applied to 19_STABLE ? Or not ? Is it really a MySQL thing ?

Show
Eloy Lafuente (stronk7) added a comment - Was this applied to 19_STABLE ? Or not ? Is it really a MySQL thing ?
Hide
Mathieu Petit-Clair added a comment -

Somebody tested this back in May and said that upgrading to mysql 5 fixed the problem. I'm not sure this patch had anything to do with it.

Show
Mathieu Petit-Clair added a comment - Somebody tested this back in May and said that upgrading to mysql 5 fixed the problem. I'm not sure this patch had anything to do with it.
Hide
Kohlrusz Gabor added a comment -

I still have this problem with mySQL5 and patch applied.
Anyone has a fix for it?

Show
Kohlrusz Gabor added a comment - I still have this problem with mySQL5 and patch applied. Anyone has a fix for it?
Hide
Eloy Lafuente (stronk7) added a comment -

You said "morning" so assigning to Jerome... can you please check current behaviour between 2 connected servers under 19_STABLE ? Are utf-8 chars properly transmitted, stored and displayed?

Ciao

Show
Eloy Lafuente (stronk7) added a comment - You said "morning" so assigning to Jerome... can you please check current behaviour between 2 connected servers under 19_STABLE ? Are utf-8 chars properly transmitted, stored and displayed? Ciao
Hide
Jerome Mouneyrac added a comment -

I confirm that the bug still exists.

It first appears during the configuration:
As admin when you go to Networking > Enrolment > Select a peer
=> The courses are displayed with Unicode character
Then click on a course with unicode character
=> on the new displayed page, the unicode character are not well displayed.

I have a look to that...

Show
Jerome Mouneyrac added a comment - I confirm that the bug still exists. It first appears during the configuration: As admin when you go to Networking > Enrolment > Select a peer => The courses are displayed with Unicode character Then click on a course with unicode character => on the new displayed page, the unicode character are not well displayed. I have a look to that...
Hide
Jerome Mouneyrac added a comment - - edited

After deleting the record from mnet_enrol_course, and trying again, I can not reproduce... it works now. Note that I've been using Mysql5 and I didn't apply the patch.
I'll go through more investigation later.

Show
Jerome Mouneyrac added a comment - - edited After deleting the record from mnet_enrol_course, and trying again, I can not reproduce... it works now. Note that I've been using Mysql5 and I didn't apply the patch. I'll go through more investigation later.
Hide
Miroslav Fikar added a comment -

I confirm that the original issue still exists. We use mysql 5.0 and did not apply the patch.

Show
Miroslav Fikar added a comment - I confirm that the original issue still exists. We use mysql 5.0 and did not apply the patch.
Hide
Jerome Mouneyrac added a comment -

Ok I succeed to reproduce at any time:
As administrator, I enroll a local user to a remote course (Networking > Enrolment )
Once the user is enrolled, the course name is correctly displayed into the local database (database table: mnet_enrol_course).
The first time the user tries to connect to the remote Moodle, the remote course get updated into the local database (mnet_enrol_course). It is at this moment that we lost unicode.
I tested the patch but it didn't fix this problem.
I'm looking at it...

Show
Jerome Mouneyrac added a comment - Ok I succeed to reproduce at any time: As administrator, I enroll a local user to a remote course (Networking > Enrolment ) Once the user is enrolled, the course name is correctly displayed into the local database (database table: mnet_enrol_course). The first time the user tries to connect to the remote Moodle, the remote course get updated into the local database (mnet_enrol_course). It is at this moment that we lost unicode. I tested the patch but it didn't fix this problem. I'm looking at it...
Hide
Eloy Lafuente (stronk7) added a comment -

Thanks Jerome! Gogogo!

Show
Eloy Lafuente (stronk7) added a comment - Thanks Jerome! Gogogo!
Hide
Jerome Mouneyrac added a comment -

ok I think the patch was on a good track (or maybe it fixes something else).

Here another patch:
/mnet/xmlrpc/client.php
Line 175: $this->requesttext = xmlrpc_encode_request($this->method, $this->params, array("encoding" => "utf-8", "escaping" => "markup"));

adding "escaping" => "markup" should fix the problem.

If some people can check that fix all their problems, it would be better before I commit. Thank you.

Show
Jerome Mouneyrac added a comment - ok I think the patch was on a good track (or maybe it fixes something else). Here another patch: /mnet/xmlrpc/client.php Line 175: $this->requesttext = xmlrpc_encode_request($this->method, $this->params, array("encoding" => "utf-8", "escaping" => "markup")); adding "escaping" => "markup" should fix the problem. If some people can check that fix all their problems, it would be better before I commit. Thank you.
Hide
Jerome Mouneyrac added a comment -

committed in 1.8, 1.9 and HEAD

Show
Jerome Mouneyrac added a comment - committed in 1.8, 1.9 and HEAD
Hide
Eloy Lafuente (stronk7) added a comment -

Wow, just read the comment at http://es.php.net/manual/es/function.xmlrpc-encode-request.php#80907

But looks really "fragile", isn't it? I don't understand why that fixes the problem, more if, after a quick search, other uses of xmlrpc_encode_request() and xmlrpc_decode_request() aren't using that "trick" at all.

In fact both functions are marked as experimental... uhm.. I'll try to perform some tests this weekend with utf-8 chars everywhere (courses, users...).

Ciao

Show
Eloy Lafuente (stronk7) added a comment - Wow, just read the comment at http://es.php.net/manual/es/function.xmlrpc-encode-request.php#80907 But looks really "fragile", isn't it? I don't understand why that fixes the problem, more if, after a quick search, other uses of xmlrpc_encode_request() and xmlrpc_decode_request() aren't using that "trick" at all. In fact both functions are marked as experimental... uhm.. I'll try to perform some tests this weekend with utf-8 chars everywhere (courses, users...). Ciao
Hide
Jerome Mouneyrac added a comment -

If you dont put "escaping" => "markup", the unicode special character will be send through the XML as &#XXX;&#XXX;
If you put it, they are sent as correct unicode character.

Show
Jerome Mouneyrac added a comment - If you dont put "escaping" => "markup", the unicode special character will be send through the XML as &#XXX;&#XXX; If you put it, they are sent as correct unicode character.
Hide
Eloy Lafuente (stronk7) added a comment -

Yup, yup. I understood that. But... what happen with other uses of the same function? I think I "grep-ed" it and found some more usages...

Ciao

Show
Eloy Lafuente (stronk7) added a comment - Yup, yup. I understood that. But... what happen with other uses of the same function? I think I "grep-ed" it and found some more usages... Ciao
Hide
Miroslav Fikar added a comment -

As original reporter I am very happy to confirm that the issue is fixed.

Show
Miroslav Fikar added a comment - As original reporter I am very happy to confirm that the issue is fixed.

Dates

  • Created:
    Updated:
    Resolved: