I went to http://<moodle url>/admin/repository.php?section=managerepositories&lang=en
and I have "Enable and visible" the following plugins: Server files, Recent files, Upload a file, and private files.
¿Is that what you meant?

If this helps:
In http://<moodle url>/admin/repository.php?action=edit&repos=local the "repository plugin name" is empty.

Pablo Niklas
added a comment - 16/Nov/10 7:17 PM Hi,
I went to http://<moodle url>/admin/repository.php?section=managerepositories&lang=en
and I have "Enable and visible" the following plugins: Server files, Recent files, Upload a file, and private files.
¿Is that what you meant?
If this helps:
In http://<moodle url>/admin/repository.php?action=edit&repos=local the "repository plugin name" is empty.
Thanks.

the $ext already contains the dot, have you made any change to lib/filestorage/file_types.mm? moodle will parse this file to get file extensions, if asterisk character added to this file, you may see this error.

Dongsheng Cai
added a comment - 12/Jan/11 4:48 PM Hi, Alan
the $ext already contains the dot, have you made any change to lib/filestorage/file_types.mm? moodle will parse this file to get file extensions, if asterisk character added to this file, you may see this error.

Steve Bond
added a comment - 07/Feb/11 8:09 PM Dear all,
It's not just an Opera bug, we get it here with IE8, Firefox (3.6.13) and Safari (Win 5.0.3), and on various different PCs (all Win XP).
Our Moode build is 20110125 (we're tracking HEAD).
Steps to reproduce (but it happens for all uses of the File Picker):
Add a resource > File
Insert name and description
Click Add...
The error popup either appears immediately, or else appears once you try to click one of the links on left ("Server files" etc.) It reappears each time you try to do anything in this popup.
File picker is completely unusable as a result.
Steve

I am testing the course restore process in Moodle 2.0. The error occurs when uploading the course backups via the file picker.

I have tested with multiple file sizes.
These all work 5,779KB, 8,820KB, 12,927KB, 20,927KB, 26,375KB, 28,785KB
These all fail 29,417KB, 30,404KB, 40,147KB.
-----------------------
Server Error404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
-----------------------

Trevor Johnson
added a comment - 24/Feb/11 10:45 AM Sorry missed part of the error message, the full message is...
-----------------------
ERROR: Invalid JSON string
Server Error404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
-----------------------

Looks like this issue is caused when you have HTTPS login enabled, but your WWWROOT set to "http://". It seems like the "require_login()" function is causing the problem on my end where it cannot detect the $USER object.

Jason Ilicic
added a comment - 04/Mar/11 7:43 AM Looks like this issue is caused when you have HTTPS login enabled, but your WWWROOT set to "http://". It seems like the "require_login()" function is causing the problem on my end where it cannot detect the $USER object.

When receiving the following error, you may have an IIS7/7.5 or older upload limit. This is set to 30MB. After searching the web I found the following http://www.webtrenches.com/post.cfm/iis7-file-upload-size-limits which informs you on how to adjust the settings so you no longer get the error message.
-----------------------
ERROR: Invalid JSON string

Server Error404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
-----------------------

To adjust the settings go to your web.config file (or create) in your moodle folder and add the below code

Please keep in mind that the maxAllowedContentLength is in bytes (the above example is 500 megabytes) so please adjust this accordingly.
Please also ensure that your php settings are adjusted accordingly as well.

Billy Keene
added a comment - 08/Jun/11 5:36 PM The below fix is only for IIS servers
When receiving the following error, you may have an IIS7/7.5 or older upload limit. This is set to 30MB. After searching the web I found the following http://www.webtrenches.com/post.cfm/iis7-file-upload-size-limits which informs you on how to adjust the settings so you no longer get the error message.
-----------------------
ERROR: Invalid JSON string
Server Error404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
-----------------------
To adjust the settings go to your web.config file (or create) in your moodle folder and add the below code
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="524288000"/>
</requestFiltering>
</security>
</system.webServer>
Please keep in mind that the maxAllowedContentLength is in bytes (the above example is 500 megabytes) so please adjust this accordingly.
Please also ensure that your php settings are adjusted accordingly as well.
PHP upload settings:
post_max_size = 500M
upload_max_size = 500M

Philipp Pavelka
added a comment - 29/Jul/11 6:24 AM - edited I'm also experiencing this problem with Opera and Moodle 2.1+.
It can be easily reproduced on http://demo.moodle.net/ .
I had the problem with IE9 too, but now it's working with IE, at least for me.

It seems like http://demo.moodle.net does not suffer from this bug anymore. I managed to successfully pick a file where. What version are they using now? 2.1? And did they need any additional tuning of the site in order to get rid of this bug?

Shevchenko Dmitry
added a comment - 31/Jul/11 2:41 PM It seems like http://demo.moodle.net does not suffer from this bug anymore. I managed to successfully pick a file where. What version are they using now? 2.1? And did they need any additional tuning of the site in order to get rid of this bug?

But moodle.org still suffers from it. Tried to upload a new avatar for my profile inside opera, and got the same error. So, the question is - what version is used on http://demo.moodle.net and what additional settings do we need to adjust in order to get rid of this error? Because it's really frustrating, and we have a lot of users working with Opera. They won't like the idea of having to swicht to Mozilla or Chrome.

Shevchenko Dmitry
added a comment - 31/Jul/11 2:46 PM But moodle.org still suffers from it. Tried to upload a new avatar for my profile inside opera, and got the same error. So, the question is - what version is used on http://demo.moodle.net and what additional settings do we need to adjust in order to get rid of this error? Because it's really frustrating, and we have a lot of users working with Opera. They won't like the idea of having to swicht to Mozilla or Chrome.

Philipp Pavelka
added a comment - 31/Jul/11 5:52 PM - edited http://demo.moodle.net and Opera still produces the same error for me.
Here is also a report on the Opera forums but no one replied yet.
I would like to know if this problem is maybe Opera's fault.

Using Opera 11.5, I just tested on my server, Centos 6 and Moodle 2.1+ and it works fine. I also went to http://demo.moodle.net and after setting up file repo, I was able to log in and use it as admin, manager, teacher, and student to upload, download, and view pictures. Opera 11.5 just came out a few days ago...maybe try that???

AL Rachels
added a comment - 01/Aug/11 6:42 AM Using Opera 11.5, I just tested on my server, Centos 6 and Moodle 2.1+ and it works fine. I also went to http://demo.moodle.net and after setting up file repo, I was able to log in and use it as admin, manager, teacher, and student to upload, download, and view pictures. Opera 11.5 just came out a few days ago...maybe try that???

Opera 11.5 just came out a few days ago
I don't think the problem is in Opera version, since I used an old version of Opera and it still worked fine. The problem is caused by Moodle, and it seems the very latest versions don't suffer from this problem. Will check on my test server today.

Philipp Pavelka: Opera still produce the same error for me
Where do you get this error? I just registered there and tested the usage of filepicker for uploading a profile picture, and it worked fine. What version of Opera are you using?

Shevchenko Dmitry
added a comment - 01/Aug/11 2:26 PM Opera 11.5 just came out a few days ago
I don't think the problem is in Opera version, since I used an old version of Opera and it still worked fine. The problem is caused by Moodle, and it seems the very latest versions don't suffer from this problem. Will check on my test server today.
Philipp Pavelka: Opera still produce the same error for me
Where do you get this error? I just registered there and tested the usage of filepicker for uploading a profile picture, and it worked fine. What version of Opera are you using?

Alex
added a comment - 01/Aug/11 2:30 PM - edited I have latest Opera 11.50 and it still throws JSON error... Here in Ukraine and Russia more than 40% of users use Opera so this bug is really frustrating...

Philipp Pavelka
added a comment - 01/Aug/11 4:45 PM - edited @Dmitry:
I can reproduce this error with Opera 12 build 1033 on Win7 x86, Opera 11.50 build 1074 on Win XP and Mac OS X 10.6.8.
What OS are you using with Opera?
Edit:
I can reproduce the error when I follow these steps:
http://my.opera.com/community/forums/topic.dml?id=1060732

Shevchenko Dmitry
added a comment - 01/Aug/11 8:06 PM I am using Opera 9 on my notebook inside Windows Vista. As soon as I get home, I'll test their latest release on my home test server, and we'll see, does it really work or not.

OK, so I tested it home. Deployed it on Apache 2.2.4 in Windows XP, PHP 5.3.6. In opera the latest stable release moodle 2.1 works fine, no error with file pickers.
The previous stable version I used (2.0.2) does not work in Opera, it gives this error with JSON string. So I guess the problem is finally resolved in 2.1.
@Philipp:
I am not sure, what's wrong with your environment, maybe nothing and maybe somethings in Opera cache, but you should be able to use filepicker (at least for loading profile picture) on http://demo.moodle.net. If you still cannot, please report.

Shevchenko Dmitry
added a comment - 02/Aug/11 3:40 PM - edited OK, so I tested it home. Deployed it on Apache 2.2.4 in Windows XP, PHP 5.3.6. In opera the latest stable release moodle 2.1 works fine, no error with file pickers.
The previous stable version I used (2.0.2) does not work in Opera, it gives this error with JSON string. So I guess the problem is finally resolved in 2.1.
@Philipp:
I am not sure, what's wrong with your environment, maybe nothing and maybe somethings in Opera cache, but you should be able to use filepicker (at least for loading profile picture) on http://demo.moodle.net . If you still cannot, please report.

Shevchenko Dmitry
added a comment - 02/Aug/11 8:53 PM @Cai
Not sure that empty response has something to do with it. Why would that happen only inside Opera? Besides, I guess that the users pick up some file, so the response should not be empty.

Dongsheng Cai
added a comment - 02/Aug/11 11:50 PM Shevchenko
I was debugging on repository/filepicker.js, line 135, I print
alert(o.responseText);
Chrome, safari, firefox even ie can display the content of moodle response, this could be a problem of YUI3 library.

Error thrown at line 23, column 4390 in A(R, S) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/queue-promote/queue-promote-min.js&3.2.0/build/datatype/datatype-xml-min.js&3.2.0/build/io/io-min.js&3.2.0/build/json/json-parse-min.js:

R.c.responseText=P?P.get("text"):O.get("text");

called from line 23, column 5307 in <anonymous function>() in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/queue-promote/queue-promote-min.js&3.2.0/build/datatype/datatype-xml-min.js&3.2.0/build/io/io-min.js&3.2.0/build/json/json-parse-min.js:

A(P,Q);

called from line 42, column 95 in <anonymous function: _notify>(J, H, I) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:

G=this.fn.apply(J,F);

called via Function.prototype.apply() from line 42, column 493 in <anonymous function: notify>(G, I) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:

F=this._notify(J,G,I);

called from line 41, column 8690 in <anonymous function: _notify>(I, H, F) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:

G=I.notify(H,this);

called from line 41, column 10229 in <anonymous function: _procSubs>(I, G, F) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:

if(false===this._notify(J,G,F))

called from line 41, column 9716 in <anonymous function: fireSimple>(F) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:

this._procSubs(G[0],F);

called from line 41, column 9317 in <anonymous function: fire>() in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:

return this.fireSimple(F);

called from line 51, column 7458 in <anonymous function: v.fn>(A) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:

Philipp Pavelka
added a comment - 04/Aug/11 7:27 AM This is what I get from Opera's Dragonfly.
Maybe it helps.
[04.08.2011 00:15:58] JavaScript - http://demo.moodle.net/user/edit.php?id=5&course=1
Event thread: load
Uncaught exception: TypeError: Cannot convert 'R.c' to object
Error thrown at line 23, column 4390 in A(R, S) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/queue-promote/queue-promote-min.js&3.2.0/build/datatype/datatype-xml-min.js&3.2.0/build/io/io-min.js&3.2.0/build/json/json-parse-min.js:
R.c.responseText=P?P.get("text"):O.get("text");
called from line 23, column 5307 in <anonymous function>() in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/queue-promote/queue-promote-min.js&3.2.0/build/datatype/datatype-xml-min.js&3.2.0/build/io/io-min.js&3.2.0/build/json/json-parse-min.js:
A(P,Q);
called from line 42, column 95 in <anonymous function: _notify>(J, H, I) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:
G=this.fn.apply(J,F);
called via Function.prototype.apply() from line 42, column 493 in <anonymous function: notify>(G, I) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:
F=this._notify(J,G,I);
called from line 41, column 8690 in <anonymous function: _notify>(I, H, F) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:
G=I.notify(H,this);
called from line 41, column 10229 in <anonymous function: _procSubs>(I, G, F) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:
if(false===this._notify(J,G,F))
called from line 41, column 9716 in <anonymous function: fireSimple>(F) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:
this._procSubs(G[0],F);
called from line 41, column 9317 in <anonymous function: fire>() in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:
return this.fireSimple(F);
called from line 51, column 7458 in <anonymous function: v.fn>(A) in http://demo.moodle.net/theme/yui_combo.php?3.2.0/build/yui/yui-base-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/yui/yui-later-min.js&3.2.0/build/event-custom/event-custom-base-min.js&3.2.0/build/event/event-base-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/event/event-delegate-min.js&3.2.0/build/node/node-min.js&3.2.0/build/yui/get-min.js&3.2.0/build/loader/loader-min.js:
v.fire(k.getEvent(A,y,(t||(false===w))));
called from unknown location in program code:
/* no source available */

I did a bit of debugging with Opera's Dragonfly.
Like Dongsheng said the filepicker makes use of YUI3. The problem is that with Opera the response (respsonseText) ist empty.
Apparently the problematic part in the code starts with the submit() function in the io scripts. In FF the script halts after the execution of submit() until the file is completely uploaded and proceeds afterwards.
In Opera submit() starts the upload process and immediately proceeds with the code.
This causes the empty response afterwards because the file isn't yet completely uploaded.

I wrote a little fix which works for me.
Unfortunately I don't know Javascript, hence the dirty solution.
I simply pause the execution of the code for 4 seconds right after the submit() function. This leaves enough time for uploading small files. For bigger files you can raise the duration.

Philipp Pavelka
added a comment - 04/Aug/11 10:30 PM I did a bit of debugging with Opera's Dragonfly.
Like Dongsheng said the filepicker makes use of YUI3. The problem is that with Opera the response (respsonseText) ist empty.
Apparently the problematic part in the code starts with the submit() function in the io scripts. In FF the script halts after the execution of submit() until the file is completely uploaded and proceeds afterwards.
In Opera submit() starts the upload process and immediately proceeds with the code.
This causes the empty response afterwards because the file isn't yet completely uploaded.
I wrote a little fix which works for me.
Unfortunately I don't know Javascript, hence the dirty solution.
I simply pause the execution of the code for 4 seconds right after the submit() function. This leaves enough time for uploading small files. For bigger files you can raise the duration.
Here is the code for the io-min.js in case someone wants to try it:
http://pastebin.com/zsck2yZg
Simply replace this code with the io-min.js in \lib\yui\3.2.0\build\io\ (assumed you have Debugging turned off).
Unfortunately I didn't find out how to check if the upload has successfully completed.
Sadly the submit() function doesn't return any status codes.

I have done some investigation with this problem. It turned out that some of our users can use the filepicker with opera, and some cannot. But it does not depend on the opera version! It depends on the network location of the user.

The user A (myself) tries to access the server using an USB modem for that - everything is fine. The opera console output is perfect, and the transaction response text is not empty.

The user B (one of our teachers) tries to access the server and that teacher is located at LAN of another district - he gets the error, and the console output shows that the response text is empty.

On my local server (then I use localhost) everything is fine with opera. So the question is - why the big difference.

I asked the teacher to use my USB modem on his comp for testing. Then he uses the USB modem, Opera works fine with filepickers, otherwise it throws an error!

@Philip: thanks for your debugging. I'll investigate your code and will try to merge it with our version to see if it works. Something's definitely wrong with opera handling the submit function. Since all other browsers are working fine with it, I can assume the function conforms to the standard, but the opera handling of submit (in some cases) does not.

Shevchenko Dmitry
added a comment - 12/Aug/11 3:17 PM - edited I have done some investigation with this problem. It turned out that some of our users can use the filepicker with opera, and some cannot. But it does not depend on the opera version! It depends on the network location of the user.
The user A (myself) tries to access the server using an USB modem for that - everything is fine. The opera console output is perfect, and the transaction response text is not empty.
The user B (one of our teachers) tries to access the server and that teacher is located at LAN of another district - he gets the error, and the console output shows that the response text is empty.
On my local server (then I use localhost) everything is fine with opera. So the question is - why the big difference.
I asked the teacher to use my USB modem on his comp for testing. Then he uses the USB modem, Opera works fine with filepickers, otherwise it throws an error!
@Philip: thanks for your debugging. I'll investigate your code and will try to merge it with our version to see if it works. Something's definitely wrong with opera handling the submit function. Since all other browsers are working fine with it, I can assume the function conforms to the standard, but the opera handling of submit (in some cases) does not.

Shevchenko Dmitry
added a comment - 12/Aug/11 3:18 PM This is the comparison of two different opera outputs that I have. The normal output is for USB modem (opera does not generate an error in that case), and the error output is for another LAN.

Ces Mo
added a comment - 17/Aug/11 2:00 AM Same problem for me for moodle 2.1 but not linked to opera, since it happened with any browser IE, firefox, chrome etc...
I have been testing the filepicker upload by 5 people located at 5 different places, 3 of them not working getting the Invalid JSON string, 2 of them working.
There is nothing on the log that gives us any clue of a solution

@Ces Mo
Great, but it gives us some statistics! Can you please tell what's the difference between all those locations? By the way, do you use an additional version of Moodle on 443 (for https) or not?

Can you please post the info about those 5 locations without going in details in actual info, i.e.
1. Is the person located in the same subnetwork with the server.
2. Is the person accessing the server via proxy.
3. Is there a firewall between them (or, if to be precisely, does the firewall on the server somehow filters and restricts the ip of this particular client).
4. Version of opera for each location.
5. Any additional info would be welcome.

Shevchenko Dmitry
added a comment - 24/Aug/11 8:16 PM - edited @Ces Mo
Great, but it gives us some statistics! Can you please tell what's the difference between all those locations? By the way, do you use an additional version of Moodle on 443 (for https) or not?
Can you please post the info about those 5 locations without going in details in actual info, i.e.
1. Is the person located in the same subnetwork with the server.
2. Is the person accessing the server via proxy.
3. Is there a firewall between them (or, if to be precisely, does the firewall on the server somehow filters and restricts the ip of this particular client).
4. Version of opera for each location.
5. Any additional info would be welcome.

Additional info. Just found out something interesting. It seems like this problem may rise due to the fact of moodle settings. Here is why:
1. On my local server, then I run the code with clear database (created by install in 2.0.2) opera does not throw an error.
2. Then I run the SAME code with database upgraded from 1.9.10 (just changed the config.php), opera does throw an error.
That means one of settings changed in the old database makes Opera act like that. In that case the raise of exception does not depend on the network location.
However with standard clear database it can still throw an error due to the network location as Ces Mo pointed out. Need further investigation.

Shevchenko Dmitry
added a comment - 24/Aug/11 9:39 PM Additional info. Just found out something interesting. It seems like this problem may rise due to the fact of moodle settings. Here is why:
1. On my local server, then I run the code with clear database (created by install in 2.0.2) opera does not throw an error.
2. Then I run the SAME code with database upgraded from 1.9.10 (just changed the config.php), opera does throw an error.
That means one of settings changed in the old database makes Opera act like that. In that case the raise of exception does not depend on the network location.
However with standard clear database it can still throw an error due to the network location as Ces Mo pointed out. Need further investigation.

Ces Mo
added a comment - 25/Aug/11 3:43 AM I m going to try to gives some details about the 5 users.
One thing i want to mention is my plateform was upgrade from 1.9 -> 2 -> 2.1
So this is not a clean new installation of moodle

That's weird.. Uploading in Moodle 2.1 suddenly started to work here in a virtual WinXP XAMPP machine.
So I decided to install another but a clean new Moodle instance on the same machine.
After restarting the Apache service Opera again throws the error in both instances

Edit:
Uploading small files did now work again. Anything bigger would throw an error after ~4 secs.
I cleared Opera's cache and cookies and it wouldn't let me upload even small files anymore.

Philipp Pavelka
added a comment - 25/Aug/11 6:07 AM - edited That's weird.. Uploading in Moodle 2.1 suddenly started to work here in a virtual WinXP XAMPP machine.
So I decided to install another but a clean new Moodle instance on the same machine.
After restarting the Apache service Opera again throws the error in both instances
Edit:
Uploading small files did now work again. Anything bigger would throw an error after ~4 secs.
I cleared Opera's cache and cookies and it wouldn't let me upload even small files anymore.

1. One is with databases upgraded from 1.9. Those databases can be (potentially) set up strangely, and some setting in them makes Opera act weird, even on the local test server.
2. Users connecting from strange locations. In that case even a clear instance won't work. I've set up on our university server two instances with the same code. Instance A is a clear one created from the scratch. Instance B is the upgraded one.
2.1. Instance A can be accessed from Opera without errors on the server itself, from my USB modem, but a guy trying to access it from another district lan gets an error (so he switches to Mozilla).
2.2. Instance B cannot be accessed from opera nowhere - not even on the server itself.

As for the point 1, I think I can solve it in few days by comparing the settings of the clear database and the upgraded one, hope I find the solution. As for the second one, it's hard to test. I would be very grateful, if Ces Mo would provide additional info about the network location of his users.

Shevchenko Dmitry
added a comment - 30/Aug/11 3:21 AM OK, there seems to be TWO problems inside this thing:
1. One is with databases upgraded from 1.9. Those databases can be (potentially) set up strangely, and some setting in them makes Opera act weird, even on the local test server.
2. Users connecting from strange locations. In that case even a clear instance won't work. I've set up on our university server two instances with the same code. Instance A is a clear one created from the scratch. Instance B is the upgraded one.
2.1. Instance A can be accessed from Opera without errors on the server itself, from my USB modem, but a guy trying to access it from another district lan gets an error (so he switches to Mozilla).
2.2. Instance B cannot be accessed from opera nowhere - not even on the server itself.
As for the point 1, I think I can solve it in few days by comparing the settings of the clear database and the upgraded one, hope I find the solution. As for the second one, it's hard to test. I would be very grateful, if Ces Mo would provide additional info about the network location of his users.

Please notice comment by Philipp Pavelka. I'm pretty sure, that network location and upgrade status DO NOT MATTER. Time does. Philipp has found the problem place. I can't upload nearly any file with opera, but I can upload very small file. this means that if upload is fast - it succeeds.
You have fast network access with low - you success. You have fast LAN but packets go around the Earth to reach nearest building - you fail.

Alexey Guseynov
added a comment - 04/Sep/11 11:57 PM Please notice comment by Philipp Pavelka. I'm pretty sure, that network location and upgrade status DO NOT MATTER. Time does. Philipp has found the problem place. I can't upload nearly any file with opera, but I can upload very small file. this means that if upload is fast - it succeeds.
You have fast network access with low - you success. You have fast LAN but packets go around the Earth to reach nearest building - you fail.

I played around again with Opera's debugger.
I'm starting to think it's an Opera bug.

Adding a breakpoint at a specific line with a condition that doesn't even fire surprisingly causes Opera to successfully upload any file although the script never halts.

Here's how to reproduce this behaviour:

Within Moodle disable YUI combo loading and probably also Cache Javascript under Site administration>Appearance>AJAX and Javascript

tidy up the node-min.js (in case Moodle debugging is disabled) in order to make the code better readable (I've use the JSMin plugin for Notepad++ to format the code)

open Opera's debugger

select the node-min.js script

add a breakpoint within the function "H.scrubVal = function (M, L)"

add a condition which doesn't fire

upload a file

The debugger doesn't halt the script execution and Opera doesn't throw an error and the files get successfully uploaded.
Disable the breakpoint -> Opera also doesn't halt the script but throws an error.

Adding a breakpoint with a condition that makes the execution halt at the point also doesn't throw an error. Interestingly in this case Opera waits until the file has been completely uploaded an then halts at the breakpoint.

I've observed this behaviour with Opera 12 and Opera 11.51 on Win7 x86.

Another thing here I've noticed:
Opera throws an JSON error here with the small file but apparently the file has been successfully uploaded because later on with the breakpoint set I get asked whether I want to overwrite or rename the file.

Edit:
I've just reproduced the same behaviour on Mac OS X and Opera 11.51.
I don't know why this is happening but I suppose it shouldn't be that way.

Edit2:
Apparently in the latest 2.2 builds YUI has been updated from 3.2.0 to 3.4.0. The problem still persists here and you can still reproduce this behaviour but instead of the node-min.js the node-core-min.js (lib\yui\3.4.0\build\node-core) is being loaded. Add the breakpoint here in the k.scrubVal method.

Philipp Pavelka
added a comment - 05/Sep/11 7:14 PM - edited I played around again with Opera's debugger.
I'm starting to think it's an Opera bug.
Adding a breakpoint at a specific line with a condition that doesn't even fire surprisingly causes Opera to successfully upload any file although the script never halts.
Here's how to reproduce this behaviour:
Within Moodle disable YUI combo loading and probably also Cache Javascript under Site administration>Appearance>AJAX and Javascript
tidy up the node-min.js (in case Moodle debugging is disabled) in order to make the code better readable (I've use the JSMin plugin for Notepad++ to format the code)
open Opera's debugger
select the node-min.js script
add a breakpoint within the function "H.scrubVal = function (M, L)"
add a condition which doesn't fire
upload a file
The debugger doesn't halt the script execution and Opera doesn't throw an error and the files get successfully uploaded.
Disable the breakpoint -> Opera also doesn't halt the script but throws an error.
Adding a breakpoint with a condition that makes the execution halt at the point also doesn't throw an error. Interestingly in this case Opera waits until the file has been completely uploaded an then halts at the breakpoint.
I've observed this behaviour with Opera 12 and Opera 11.51 on Win7 x86.
Because a video says more than a thousand words:
http://www.screencast.com/t/2nCYj8s9Kzr
Another thing here I've noticed:
Opera throws an JSON error here with the small file but apparently the file has been successfully uploaded because later on with the breakpoint set I get asked whether I want to overwrite or rename the file.
Edit:
I've just reproduced the same behaviour on Mac OS X and Opera 11.51.
I don't know why this is happening but I suppose it shouldn't be that way.
Edit2:
Apparently in the latest 2.2 builds YUI has been updated from 3.2.0 to 3.4.0. The problem still persists here and you can still reproduce this behaviour but instead of the node-min.js the node-core-min.js (lib\yui\3.4.0\build\node-core) is being loaded. Add the breakpoint here in the k.scrubVal method.

Mart Mangus
added a comment - 14/Nov/11 11:20 PM I tried this "breakpoint technique" with following code added to /lib/yui/3.4.1/build/node-core/node-core-min.js:
k.scrubVal=function(r,q){
if (notExistingVariable==1)
<breakpoint here> alert('opera test');
if(r){if(typeof r=="object"||typeof r=="function")
But couldn't still upload the file.
I could only crash Opera (Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.9.168 Version/11.52) multiple times during this test.
Philipp, what code did You use in Your testing and do You still think it can be a bug in Opera?

Mart did you actually add those lines within the node-core-min.js on the server?
What I've done was to add a breakpoint with a condition in Opera's debugging tool Dragonfly.

I've tried it again with Moodle 2.1.2+ (Build: 20111115) and Opera 12 (build 1155) on Win7 x64 and still could reproduce my described behaviour.
What's strange is that I need now to add at least two breakpoints with (non firing) conditions in order to successfully complete the upload process.
I've took /lib/yui/3.4.1/build/node-core/node-core-min.js, reformatted it with http://jsbeautifier.org/ and in Dragonfly I've added breakpoints to lines 82 and 83 with the condition 'r == "blah"' each.

Philipp Pavelka
added a comment - 17/Nov/11 7:27 AM Mart did you actually add those lines within the node-core-min.js on the server?
What I've done was to add a breakpoint with a condition in Opera's debugging tool Dragonfly.
I've tried it again with Moodle 2.1.2+ (Build: 20111115) and Opera 12 (build 1155) on Win7 x64 and still could reproduce my described behaviour.
What's strange is that I need now to add at least two breakpoints with (non firing) conditions in order to successfully complete the upload process.
I've took /lib/yui/3.4.1/build/node-core/node-core-min.js, reformatted it with http://jsbeautifier.org/ and in Dragonfly I've added breakpoints to lines 82 and 83 with the condition 'r == "blah"' each.
Yeah, I still think there's something buggy with Opera's Javascript engine.

Mart Mangus
added a comment - 17/Nov/11 9:55 AM - edited
Mart did you actually add those lines within the node-core-min.js on the server?
Yes.
Tried again with formatted node-core-min.js, but still could not upload the file like that.
Maybe it's because of different version of Opera (Windows vs Linux).
Has anyone else tested this "breakpoint technique" under any operating system?
With success?

Did you use Opera's Dragonfly to add the breakpoints as shown in my above screencast?

This is not a resolution for the JSON problem nor a workaround since I just want to show that Opera's JS engine is working somehow cheesy in that way that I can get Opera to successfully upload files each time with my described steps without problems.
Adding conditional breakpoints in the debugger which do not even halt weirdly solves the problem.

Keep in mind that my described workaround occurs only within the browser itself and serves primarily only a "proof of concept" to show that IMHO the bug is buried within Opera.

Philipp Pavelka
added a comment - 17/Nov/11 8:13 PM Did you use Opera's Dragonfly to add the breakpoints as shown in my above screencast ?
This is not a resolution for the JSON problem nor a workaround since I just want to show that Opera's JS engine is working somehow cheesy in that way that I can get Opera to successfully upload files each time with my described steps without problems.
Adding conditional breakpoints in the debugger which do not even halt weirdly solves the problem.
Keep in mind that my described workaround occurs only within the browser itself and serves primarily only a "proof of concept" to show that IMHO the bug is buried within Opera.
Anyway I'm also interested if anyone else can reproduce my experiences.
At least there's apparently someone from the Opera team looking into this issue.

Did you use Opera's Dragonfly to add the breakpoints as shown in my above screencast?

Oh, now i saw the screencast – i did not understand that You meant conditional breakpoint in Opera!
But even that did not make Opera file upload work on my Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.9.168 Version/11.52

Mart Mangus
added a comment - 20/Nov/11 8:05 AM
Did you use Opera's Dragonfly to add the breakpoints as shown in my above screencast?
Oh, now i saw the screencast – i did not understand that You meant conditional breakpoint in Opera!
But even that did not make Opera file upload work on my Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.9.168 Version/11.52

Vicente Jiménez Aguilar
added a comment - 11/Jan/12 5:24 AM I just wanted to inform that I resolved this issue after increasing the PHP memory limit to 512M.
I don't know if is possible to improve the memory usage, if this is a memory leak or this process really needs all that memory.
In my case, it was trying to list a very large course imported from version 1.9.
And I found that the wrong JSON was due to a empty string because the request get cancelled (Saw it in Firebug).
Maybe it is possible to catch that even (request cancellation) and print a more informative message like:
"Response canceled by server. Check PHP memory limit."
In my case, this error was due to a memory limit reached.
This same "invalid JSON" message could be due to a set of different problems.

Martin Samek
added a comment - 23/Feb/12 6:23 AM Negative, memory limit increase didn't make it. Tested on same system and connectivity. Chromium uploads file without any problem, at the same moment Opera fails with Invalid JSON string. Any idea?

Vadim Dvorovenko
added a comment - 10/May/12 3:31 PM The problem is in conflict in Opera and YUI 3.4.1, described here http://yuilibrary.com/projects/yui3/ticket/2531217
The solution is to upgrade from YUI 3.4.1 to 3.5.0 or later
Latest 2.3dev have yui 3.5.0 and this bug is fixed
Patch for 2.2.2 based on https://github.com/dpobel/yui3/commit/1a8b46c524b8ceb36f06d544c1c1c6f6436b3152 can be found here
https://github.com/vadimonus/moodle/commit/a63de07e297e355152acfa2befd54906a1bd1b25

If you didn't see it yet, there's also probably an internal fix in Opera's core. Hopefully it will be released to the public in the near future. The fix will be recognizable as CORE-44712 in the changelog.
(Reference)

Philipp Pavelka
added a comment - 17/May/12 10:22 PM If you didn't see it yet, there's also probably an internal fix in Opera's core. Hopefully it will be released to the public in the near future. The fix will be recognizable as CORE-44712 in the changelog.
( Reference )

I'm using latest stable Opera, but still can not upload files to moodle.org. In addition we should keep thinking about users that does not use latest opera, so solution with patching or updating YUI is preffered. As far as some percent of users uses opera I think we should patch all stable moodle versions, besides the patch is very simple.
patch for 2.1 here https://github.com/vadimonus/moodle/commit/97474c6fee120c4f921491572400ea132b125ca0

Vadim Dvorovenko
added a comment - 18/May/12 4:06 PM I'm using latest stable Opera, but still can not upload files to moodle.org. In addition we should keep thinking about users that does not use latest opera, so solution with patching or updating YUI is preffered. As far as some percent of users uses opera I think we should patch all stable moodle versions, besides the patch is very simple.
patch for 2.1 here https://github.com/vadimonus/moodle/commit/97474c6fee120c4f921491572400ea132b125ca0

I totally agree!
It's not clear how long it will take until Opera's fix will be integrated into a public build. It definitely will still take a while and it's not sure if the fix will really apply to this specific issue.

Philipp Pavelka
added a comment - 18/May/12 6:09 PM I totally agree!
It's not clear how long it will take until Opera's fix will be integrated into a public build. It definitely will still take a while and it's not sure if the fix will really apply to this specific issue.

I was in two minds about this originally but have swung around and do think this backport of a YUI issue is going to be the best solution.
Could you please add a note to lib/yui/readme_moodle.txt explaining we've backported a fix that will has been introduced in 3.5.0 and provide a link to the YUI issue.
Once done this can be put up for integration.

Sam Hemelryk
added a comment - 23/May/12 9:02 AM Hi Dongsheng,
I was in two minds about this originally but have swung around and do think this backport of a YUI issue is going to be the best solution.
Could you please add a note to lib/yui/readme_moodle.txt explaining we've backported a fix that will has been introduced in 3.5.0 and provide a link to the YUI issue.
Once done this can be put up for integration.
Cheers
Sam

I had thought about backporting YUI 3.5 to 2.2 and certainly it is one possibility.
However this is a pretty contained issue and I'm not familiar enough with what is changing with YUI to know about the consequences of such a backport.
I've added Petr as a watcher here as no doubt he will have a much better understanding than me (I've also added other integrators).
Presently I think we should be applying this patch and just noting the alteration in lib/yui/readme_moodle.txt

Sam Hemelryk
added a comment - 23/May/12 11:10 AM Hi Dongsheng,
I had thought about backporting YUI 3.5 to 2.2 and certainly it is one possibility.
However this is a pretty contained issue and I'm not familiar enough with what is changing with YUI to know about the consequences of such a backport.
I've added Petr as a watcher here as no doubt he will have a much better understanding than me (I've also added other integrators).
Presently I think we should be applying this patch and just noting the alteration in lib/yui/readme_moodle.txt
Petr + integrators what are your thoughts?
Cheers
Sam

Hmm, we did not modify yui before and I dod not think we should now because it does not work for sites using external YUI from CDN. Upgrading to 3.5.x seems scary to me, risking breakages for majority of people. Could there be a way to patch the YUI class on the fly in browser only? Are there any other places apart from File picker that are affected by this problem?

Petr Skoda
added a comment - 23/May/12 2:17 PM Hmm, we did not modify yui before and I dod not think we should now because it does not work for sites using external YUI from CDN. Upgrading to 3.5.x seems scary to me, risking breakages for majority of people. Could there be a way to patch the YUI class on the fly in browser only? Are there any other places apart from File picker that are affected by this problem?

if its the yui modification - my -1 for stability is compromised in too many places, if we're talking about the backport of the better yui version, i think +1 as long as the yui we're backporting has been tested in some release already.

Aparup Banerjee
added a comment - 23/May/12 4:31 PM if its the yui modification - my -1 for stability is compromised in too many places, if we're talking about the backport of the better yui version, i think +1 as long as the yui we're backporting has been tested in some release already.

Petr Skoda
added a comment - 23/May/12 5:47 PM - edited YUI 3.5.x is not compatible with moodle 2.2.x, we had to tweak loaders in master, but it is still not fully tested there and the codebase diverged enough to require separate testing in 2.2.x.

Derek Chirnside
added a comment - 30/May/12 12:09 PM This is the screenshot I got. 20120525, 2.2.3+ Debian
Tried to upload a zip file 65Meg (Hung) then with some smaller files (eg 1.6Meg) got this. Also with 1.6Meg JPG, 3Meg PDF, but Not a tiny JPG.

[OK, the JIRA database refreshed mid post] see the screenshot above, I have not seen the detail of the message like tyhis before, usually I only get a small message, and usually, up until now this has been completely unpredicatable. Now it is consistent.

Derek Chirnside
added a comment - 30/May/12 12:17 PM [OK, the JIRA database refreshed mid post] see the screenshot above, I have not seen the detail of the message like tyhis before, usually I only get a small message, and usually, up until now this has been completely unpredicatable. Now it is consistent.
-Derek

Dan, I had the "Invalid JSON string" error a few of weeks back in FF 12(Win) and IE 8, but I don't get the message with those browsers and the most recent Moodle 2.3+. Seems to be fixed from my point of view.

Gordon Bateson
added a comment - 19/Jun/12 1:15 PM Dan, I had the "Invalid JSON string" error a few of weeks back in FF 12(Win) and IE 8, but I don't get the message with those browsers and the most recent Moodle 2.3+. Seems to be fixed from my point of view.

I'm also getting this for the very first time, in stable 2.3 (20120625). This morning, I was getting it on any repository I clicked on from the left hand menu. However, now I can only trigger it by clicking the tree-view display on Server Files, and only as a teacher role (not as an admin).

Michael Woods
added a comment - 27/Jun/12 10:35 AM - edited I'm also getting this for the very first time, in stable 2.3 (20120625). This morning, I was getting it on any repository I clicked on from the left hand menu. However, now I can only trigger it by clicking the tree-view display on Server Files, and only as a teacher role (not as an admin).
I'm using Google Chrome on a Win7 machine.
Has something changed in recent builds?

If you see this error, please can you check the error console if in file manager, the error should be output there.

If in filepicker the actual error should be in the filepicker window behind the error message.

Note that unfortunately this 'invalid JSON string' is a generic 'there was a problem' error so there could be many different things going on here, so if you can get the actual error then that is important.

Dan Poltawski
added a comment - 27/Jun/12 10:55 AM Hi,
If you see this error, please can you check the error console if in file manager, the error should be output there.
If in filepicker the actual error should be in the filepicker window behind the error message.
Note that unfortunately this 'invalid JSON string' is a generic 'there was a problem' error so there could be many different things going on here, so if you can get the actual error then that is important.

Dan Poltawski
added a comment - 27/Jun/12 1:06 PM Thanks Michael, your bug has been reported and is waiting for integraiton review in MDL-33857 , it'd be great if you are able to try that patch out to see if it fixes your problem too.

Testing instructions.
Setup lates moodle 2.2.
Download some old opera from http://arc.opera.com/pub/opera/win/
Install it in usb flash mode if you have other opera installed
Create new file resourse, try to upload file, get error.
Apply patch.Check for normal behaviour.

Vadim Dvorovenko
added a comment - 29/Jun/12 4:10 AM - edited The problem caused by opera is not actual since Opera 12 in 2.2, and it's not actual for 2.3 at all.
I've recently found solution, that causes normal upload behaviour.
Unfortunately, i've found it only now, when solution is not so actual as one year ago. But i think we should update moodle 2.2 for users that still uses old opera.
https://github.com/vadimonus/moodle/commit/bef899b1208f943b5e1cd083f924c98fecdd730a
Testing instructions.
Setup lates moodle 2.2.
Download some old opera from http://arc.opera.com/pub/opera/win/
Install it in usb flash mode if you have other opera installed
Create new file resourse, try to upload file, get error.
Apply patch.Check for normal behaviour.

Carola Brunnbauer
added a comment - 04/Jul/12 8:54 PM Unfortunately in our case the update to 2.3 only solved the problem by using the drag&drop-upload. With the filepicker some useres still get the error message (latest FF).

Aparup Banerjee
added a comment - 05/Jul/12 3:27 PM i think i've seen this happen to me too. not sure who's really working on this but i'm dragging this into the next planned sprint now and grabbing this.

Susan Mangan
added a comment - 12/Jul/12 6:21 AM I just upgraded our development server to 2.3.1 and this is the first I've seen of this error since we've been running 2x. We were running v2.2 since January and didn't see it once.
I now get this error when I go into the filepicker and click on Server Files using FF and IE.
Debugging msg: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 60775 bytes) in /var/www/moodle/lib/dml/mysqli_native_moodle_database.php on line 868

I have come across this and found it to be the HTTPS logins enabled also as Jason has said:

"Looks like this issue is caused when you have HTTPS login enabled, but your WWWROOT set to "http://". It seems like the "require_login()" function is causing the problem on my end where it cannot detect the $USER object."

Any ideas how to resolve this? I have tested with https logins switched off and it works fine so this is definitely the issue.. for me in this instance anyway

Andrea Gregory (Gordon)
added a comment - 17/Aug/12 8:44 PM Hi All
I have come across this and found it to be the HTTPS logins enabled also as Jason has said:
"Looks like this issue is caused when you have HTTPS login enabled, but your WWWROOT set to "http://". It seems like the "require_login()" function is causing the problem on my end where it cannot detect the $USER object."
Any ideas how to resolve this? I have tested with https logins switched off and it works fine so this is definitely the issue.. for me in this instance anyway
Thank you!
Andrea

I have been trying to reproduce this error without luck. As suggested by Dan (above), Jason string is a generic error. It can happen because of few reasons. If you are still seeing this issue, then please check console and report exact error message.

Rajesh Taneja
added a comment - 20/Aug/12 12:09 PM I have been trying to reproduce this error without luck. As suggested by Dan (above), Jason string is a generic error. It can happen because of few reasons. If you are still seeing this issue, then please check console and report exact error message.
I think Vadim patch ( https://github.com/vadimonus/moodle/commit/bef899b1208f943b5e1cd083f924c98fecdd730a ) make sense. But unfortunately, I can't get to reproduce the original problem.
@Philipp: Can you please try Vadim's patch and confirm if this resolves issue on opera < v12
@Mary: Can you please confirm if this problem is still visible with 2.3
@Andrea: Can you please put more information about this error ( http://tracker.moodle.org/browse/MDL-25190?focusedCommentId=165852&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-165852 ). I checked secure login and couldn't replicate this issue on 2.2 (2011120504.08) and master

Rajesh Taneja
added a comment - 23/Aug/12 10:29 AM It will be helpful, if you can please provide some feedback on this issue.
I can't replicate this issue at my end, seems this has been resolved in 2.2+

Sorry for the late reply.
I can't reproduce this problem any more.
I've tried Opera 11.64 and an old Opera 12 beta version on the demo Moodle site which holds the version 2.2.3 (Build: 20120514). I've also installed the LastPass extension which also added its part to the JSON error as mentioned on the Opera forums but I could make the error appear.

Philipp Pavelka
added a comment - 27/Aug/12 12:38 AM Sorry for the late reply.
I can't reproduce this problem any more.
I've tried Opera 11.64 and an old Opera 12 beta version on the demo Moodle site which holds the version 2.2.3 (Build: 20120514). I've also installed the LastPass extension which also added its part to the JSON error as mentioned on the Opera forums but I could make the error appear.
So the bug seems to be fixed, at least for me.

Closing this issue as "Not a bug", and if anyone feels otherwise then please feel free to comment. It will be helpful if you provide proper debug information, as "Invalid JSON string" is a generic message and it's very difficult to get exact cause of problem.

Rajesh Taneja
added a comment - 27/Aug/12 9:43 AM Thanks for the response Philipp,
Closing this issue as "Not a bug", and if anyone feels otherwise then please feel free to comment. It will be helpful if you provide proper debug information, as "Invalid JSON string" is a generic message and it's very difficult to get exact cause of problem.

I just ran into this problem, and it matches Alan Whittamore's comment from 06/Dec/10. I made the change he suggested and it worked fine to prevent the PHP warning regarding preg_match (which in turn makes the ajax response not valid json).

Jay Knight
added a comment - 07/Sep/12 1:19 AM I just ran into this problem, and it matches Alan Whittamore's comment from 06/Dec/10 . I made the change he suggested and it worked fine to prevent the PHP warning regarding preg_match (which in turn makes the ajax response not valid json).
This was in FF 15, Moodle 2.2.4+ (Build: 20120823), PHP 5.3.3 (debian)
The problem doesn't happen on our production server, where php warnings are not printed to the browser.

Andrea Gregory (Gordon)
added a comment - 04/Oct/12 12:19 AM @Rajesh - Moodle version is 2.2.4+ (Build: 20120712).
These settings are set in the config file:
$CFG->sslproxy=true;
$CFG->loginhttps = '1';
If I take these out uploading a profile image works fine. With them in I get the json error.
Does this help in any way?
I tried the preg_match change but it hasn't taken the error away.
Thanks
Andrea

Michael de Raadt
added a comment - 19/Oct/12 8:55 PM Thanks for providing more information, Andrea.
I'll ask Raj to have a look at this soon. It might not be for a week or so as we are heading off for the Hackfest.

1. Creating a new user from Administration. Since there is a filepicker, it finally shows the JSON error message. Or,
2. Opening the filepicker popup with all repositories. Clicking on any respository, shows the JSON error message. And if debug messages are enabled, a message is shown in addition using javascript' alert(): "Error updating user preference 'filepicker_recentrepository' using ajax. Clicking this link will repeat the Ajax call that failed so you can see the error:" with the "Ok" button and nothing more.

Jordi Pujol-Ahulló
added a comment - 15/Nov/12 6:34 PM - edited Hi,
The same patterns occurs from http://tracker.moodle.org/browse/MDL-25190?focusedCommentId=105585&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-105585 in our installation with Moodle 2.3.3 (upgraded yesterday from M2.1):
When disabled loginhttps, filepickers work successfully.
When enabled loginhttps, a popup with the generic JSON error message appears.
What we could make to help?
Edited:
The Apache error log shows lines like these:
Default exception handler: Ha finalitzat l'execuci\xc3\xb3 de l'script perqu\xc3\xa8 s'ha detectat un redireccionament sense suport. Debug: \nError code: redirecterrordetected\n* line 2375 of /lib/weblib.php: moodle_exception thrown\n* line 2826 of /lib/moodlelib.php: call to redirect()\n* line 55 of /repository/repository_ajax.php: call to require_login()\n
Default exception handler: Aqu\xc3\xad no hi ha cap visitant Debug: \nError code: noguest\n* line 467 of /lib/setuplib.php: moodle_exception thrown\n* line 36 of /repository/draftfiles_ajax.php: call to print_error()\n
You can try to reproduce the error following any of these points:
1. Creating a new user from Administration. Since there is a filepicker, it finally shows the JSON error message. Or,
2. Opening the filepicker popup with all repositories. Clicking on any respository, shows the JSON error message. And if debug messages are enabled, a message is shown in addition using javascript' alert(): "Error updating user preference 'filepicker_recentrepository' using ajax. Clicking this link will repeat the Ajax call that failed so you can see the error:" with the "Ok" button and nothing more.

Rajesh Taneja
added a comment - 05/Apr/13 6:21 AM Hello Andrea and Luciano,
I was looking at related issue ( MDL-34182 ) and seems this is still an issue.
Can you please confirm few things for me:
Do you have $CFG->sslproxy=true; and/or $CFG->loginhttps = '1'; in your config
If above, are they defined after require_once(dirname(_ FILE _) . '/lib/setup.php'); ?
Does your $CFG->wwwroot has 'https://MOODLESITE' or 'http://MOODLESITE'
I managed to reproduce this problem, and it happens only if sslproxy and loginhttps configurations are not set after setup.php is included and wwwroot is http not https.
If above is not the case then please add more information about your setup and error msg, as with above information it's not easy to detect the cause of problem.

comment 1
"Open IIS 7 SnapIn
Select the website you want enable to accept large file uploads.
In the main window double click 'Request filtering'
once the window is opened you may see on top a list of tabs eg: file name extensions, rules, hidden segments and so on...
regardless the tab you select, in the main window rightclick and select "Edit Feature Settings" and modify the "Maximum allowed content length (bytes)"

Rafi Eliasaf
added a comment - 04/Jun/13 10:34 AM Easy way to set IIS7 File Upload Size Limits
see http://www.webtrenches.com/post.cfm/iis7-file-upload-size-limits
comment 1
"Open IIS 7 SnapIn
Select the website you want enable to accept large file uploads.
In the main window double click 'Request filtering'
once the window is opened you may see on top a list of tabs eg: file name extensions, rules, hidden segments and so on...
regardless the tab you select, in the main window rightclick and select "Edit Feature Settings" and modify the "Maximum allowed content length (bytes)"