text:
Type: Bug
Status: Closed
Priority: Critical
Resolution: Not a bug
Affects Version/s: 2.0, 2.1.6, 2.2.3, 2.3
Fix Version/s: None
Component/s: Filepicker
Environment:Any, moodle.org for example
Affected Branches:MOODLE_20_STABLE, MOODLE_21_STABLE, MOODLE_22_STABLE, MOODLE_23_STABLE
Pull from Repository:email@example.com:vadimonus/moodle.git
Every time I tried to pick a file and the filepicker window appeared, it gave me the error: "Invalid JSON string", and I couldn't use it.
The problem's described and solved here http://yuilibrary.com/projects/yui3/ticket/2531217
Gliffy Diagrams
Issue Links
- has a non-specific relationship to
MDL-34182 Invalid JSON output on filepicker when repository plugins output invalid content
- Closed
MDL-33857 Server files repository runs out of memory on big site
- Closed
- is duplicated by
MDLSITE-1198 Problem uploading files from Opera
- Closed
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Hi, Pablo
Which repository plugin were you using when you got the error?
can you please try to select one from the left side, to see if you got the same error?
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.
I still get this for the 'Recent files' section on build 20101125. Details are:
ERROR: Invalid JSON string
Warning: preg_match(): Compilation failed: nothing to repeat at offset 0 in /var/www/moodle2/repository/lib.php on line 1382
Call Stack:
0.0023 426940 1.
() /var/www/moodle2/repository/repository_ajax.php:0
0.2195 12796224 2. repository_recent->get_listing() /var/www/moodle2/repository/repository_ajax.php:134
0.2249 12832120 3. array_filter() /var/www/moodle2/repository/recent/lib.php:113
0.2249 12832240 4. repository->filter() /var/www/moodle2/repository/lib.php:0
0.2264 12847552 5. preg_match() /var/www/moodle2/repository/lib.php:1382
I changed line 1382 in /repository/lib.php
from if (preg_match('#'.$ext.'$#', $value['title'])) {
to if (preg_match('#.'.$ext.'$#', $value['title'])) {
(only the dot added after the first #) and that works fine!
Hope this throws some light on the problem.
What browser do you use? Invalid JSON string is some kind of Opera bug.
Reopening for further investigation after further reports suggesting that the problem occurs when using Opera.
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.
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.
Hi Everyone
Have the same issue, but only files larger than around 28MB.
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.
Get the same result using IE8 and Firefox.
Our build is:
Moodle 2.0.2 (Build: 20110221)
PHP upload settings
post_max_size = 2000M
upload_max_filesize = 2000M
Moodle upload setting
Moodle course Maximum upload size = 2GB
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.
I had this issue also. I found that the issue was the proxy host setting was wrong.
I'm getting this error with IE8/IE9/Chrome/Firefox/Safari on a Windows 7 machine.
Build settings:
Moodle 2.0.1
Windows 2008 R2 SP1
SQL Server 2008
PHP upload settings:
post_max_size = 256M
upload_max_size = 256M
Hmm, I thought I attached my patch but I guess I didn't. This is only a temporary fix, not really something that should go in to core, but it works
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
<requestLimits maxAllowedContentLength="524288000"/>
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
Hi! Both on local server (WinXP, Apache, PHP 5.3.3) and on web-hosting the same error in Opera (Latest Moodle 2.0.3+).
I've tried 20110317-Fix_AJAX_WWWROOT.patch: just changed in "lib/outputrequirementslib.php" "$CFG->httpswwwroot" to "$CFG->wwwroot", cleared cache via Moodle Development->ClearCache and tried again to upload something in Private area - again: "ERROR: Invalid JSON string". Please, anyone can solve it?...
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?
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.
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???
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?
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...
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?
I can reproduce the error when I follow these steps:
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.
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.
Still no chance here ;(
I've just additionally tried to upload a profile picture on demo.moodle.net with a clean installation of Opera 11.50 on Debian 6.
I get the same error message.
Maybe I'm doing something wrong
I perform the following steps to upload a profile pictue:
1. login with a demo account
2. go to My profile settings > Edit profile & under User picture select "Choose a file..."
3. select "Upload a file"
Hello guys
filepicker uses YUI3 IO component to handle file uploading, the problem is filepicker get empty response, and failed to parse it, please see: http://yuilibrary.com/projects/yui3/ticket/2528752
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.
I was debugging on repository/filepicker.js, line 135, I print
Chrome, safari, firefox even ie can display the content of moodle response, this could be a problem of YUI3 library.
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:
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:
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:
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:
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:
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:
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:
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:
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.
Here is the code for the io-min.js in case someone wants to try it:
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.
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.
That's a really weird behavior having different results with only a different access to the Internet
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.
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.
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
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.
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.
It would be nice to know how big the size of the successfully uploaded files was.
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:
- 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:
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.
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.
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.
I tried this "breakpoint technique" with following code added to /lib/yui/3.4.1/build/node-core/node-core-min.js:
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.
Yeah, I still think there's something buggy with Opera's Javascript engine.
Mart did you actually add those lines within the node-core-min.js on the server?
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.
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
Reproduced on http://demo.moodle.net/user/filesedit.php using:
Version 11.60
Build 1185
Platform Linux
System x86_64, 2.6.32-35-generic
Browser identification Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.10.229 Version/11.60
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.
Thanks for your insights!
Unfortunately increasing the memory limit didn't help in my case.
PHP memory limit increase to 512M did not make the file upload to work in Opera in our case also.
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?
I'm also seeing this issue with Opera 11.62 and Moodle 2.2.2+ (Build: 20120329).
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
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.
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.
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.
Hi Sam
Are you going to apply Vadim or backport YUI3.5 to moodle 2.2?
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?
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.
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.
The "Invalid JSON string" error still persists in latest Moodle 2.3dev (Build: 20120522) when trying to upload a file with file picker. YUI version seems to be 3.5.1.
Server: Win2003, PHP 5.3.2, MySQL 5.1.48
Browsers tested: FF(Win) 12.0 and IE 8.0
This is no error using same browsers to upload files to latest Moodle 2.2.3+ (Build: 20120519) on same server. Moodle 2.2.3+ seems to be using YUI 3.4.1
Today's Opera's build mentions the bug fix CORE-44712 in its changelog but unfortunately it doesn't fix this problem as hoped.
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.
Seems like there's an Opera fix on the way:
The problem is now fixed for me with the latest Opera 12 final version.
Maybe someone can confirm.
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.
We have two different cases with FF (starting with 12.0) in Moodle 2.2.2+ , at the moment only concerning pdf.
I'm getting the error with IE 9, uploading videos over 30 meg, Moodle 2.2.3, W2008 + IIS 7.5. I'm off to see if IIS size/timeout settings help.
If you're running Moodle on Win2008 and IIS 7x, you need to add this to your web.config file to prevent the Invalid JSON string on filepicker message from showing up.
<requestLimits maxAllowedContentLength="262144000" />
I have just come across this problem for the very first time ever!
Moodle Version: $release = '2.3rc1 (Build: 20120624)
Theme: Rocket(latest version)
Browser: FireFox 13.0.1
OS: Win7
Localhost: WAMPServer2.1 (PHP 5.3.4; MySQL 5.1.53; Apache 2.2.17)
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.
Hi Dan,
I'm getting the error message below. So is it a server configuration issue (lack of memory)?
Invalid JSON string
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 143493 bytes) in /mnt/moodle/moodle2b/lib/dml/mysqli_native_moodle_database.php on line 868
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.
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.
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.
I am also experiencing this issue with Moodle 2.2.3 using IIS 7.5 and MySQL and Server 2008 R2.
I'm seeing this error in FF 13.0.1 and IE9.
I have modified the max file size etc in PHP and increased content length in IIS.
Going to upgrade to latest 2.3 +
HI All,
I have now upgraded to 2.3 + and it has solved the error.
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).
In 2.3 I like Mary get the error using Rocket as a theme - but with other themes no error.
Browser makes no difference. IIS7.5 PostgreSQL db.
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.
Hi Everyone, have you checked your web server configuration? Upload limit conflicts with Moodle/web server can cause this problem.
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
Aparup is now working on another project.
Hopefully we will be able to complete what he started in an upcoming sprint.
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!
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
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.
So the bug seems to be fixed, at least for me.
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).
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.
Thanks Jay,
Can you please provide me with replication steps. This will help me to pin-point the exact cause of issue.
@Rajesh - Moodle version is 2.2.4+ (Build: 20120712).
These settings are set in the config file:
$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 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.
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?
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,
This problem keeps the same on version 2.3+. We had to apply the patchs to solve the problem.
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.
1.sslproxy=false and loginhttps = false
2./lib/setup.php last lines of config.php
3.wwwroot has http://MOODLESITE
Thanks for the reply Luciano,
Can you please confirm which patch your are applying to solve this problem? Is it 20110317-Fix_AJAX_WWWROOT.patch ?
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)"


text:
Creative Construction and Design (CCD )34 Feedback reviews, 94% positive
Hi my name is Christopher Shaw I have been in the building trade for about thirty years ,Damp is Rated my no 1 specialty it's a pleasure to make so many people happy, I am based in Norwich,having all the tools and specialized equipment this manages to keep the cost down for...
Latest Damp Proofing feedback review:
By simcou on 19th Feb, 2017
L J BRICKLEY ROOFING2 Feedback reviews, 100% positive
Hi! I specialise in roofing and I have been in the trade for 17years.I have an NVQ2 DIPLOMA IN SLATE + TILING ,I specialise in all types of roofs.flat roofs, coldsystems and hotsystems.I also specialise in pitched roofs. strip and retile, newroofs , leadwork, veluxs,...
Latest Roofing feedback review:
By jamie_816 on 31st Jul, 2016
SWEEPOUT7 Feedback reviews, 100% positive
Solid fuel heating specialist, HETAS registered . Chimney builds and repairs . One stop shop . Many years experience all chimneys sorted.listed buildings etc. Lime mortar buiders. Flue liner installers. All fencing and paving. Garden maintenance small building work....
Latest Chimneys & Fireplaces feedback review:
By bridgeneil on 11th Jul, 2016
Stovesman Building Contractors13 Feedback reviews, 100% positive
We are HETAS registered installers of Wood burning and Multi-fuel stoves. We also cover all aspects of building, roofing, and chimney works. Our reputation goes before us, this has been built up of old school standards of which enables us to meet your exact requirements with...
Latest Chimneys & Fireplaces feedback review:
By duggan_81 on 20th Nov, 2016
K Greenlees Pointing Contractor88 Feedback reviews, 100% positive
I have been repointing all types of brickwork and historic buildings since 1976. also chimney stacks,internal fireplaces and roofwork
Latest Chimneys & Fireplaces feedback review:
By ksevern on 6th Feb, 2017
Cambridge Stove Installations Ltd58 Feedback reviews, 100% positive
We are Cambridgeshire premier Stove installation company, we guarantee to beat any like for like quote within 10 miles of Cambridge. We offer a full installation service, from free initial site survey to completion & can also offer a full aftercare package, something none...
Latest Chimneys & Fireplaces feedback review:
By lhasa63 on 23rd Feb, 2017
Heatsafe installations ltd56 Feedback reviews, 100% positive
Heatsafe installations is a family run business with over 25 years experience. We deal in all aspects of fireplace fitting , flues , wood burning stoves , gas fires, chimney reconstruction or building a new chimney. We pride ourselves on being specialists in the bespoke...
Latest Chimneys & Fireplaces feedback review:
By minnow_97 on 30th Jan, 2017
All Way Chimney Services1 Feedback review, 100% positive
All Way Chimney Services is a member of the National Association of Chimney Sweeps. As well as sweeping chimneys to the highest standard, I also inspect, repair and rebuild after poor maintenance and events such as a chimney fire. Always here for all your chimney troubles!
Latest Chimneys & Fireplaces feedback review:
By les_173 on 23rd Jun, 2016
mik993 Feedback reviews, 100% positive
Hi, my name is Michael Toland I am a time served Bricklayer. I have worked in the construction industry since 1981 soley as a bricklayer. I have worked on a variety of projects in this time including ,housing,commercial and private sector i.e extensions,porches that...
Latest Bricklaying feedback review:
By myjobs_93 on 6th Jun, 2016
Andy Tyrrell Ltd16 Feedback reviews, 100% positive
We are a family run roofing and solar installer working though out Essex for private and building companies for the last 30 years. All our work is guaranteed and we are fully insured and our aim is to give customer satisfaction on every job.
Latest Chimneys & Fireplaces feedback review:
By anardledesmagmailcom on 24th Jan, 2016
Pinnacle Building Maintenance Ltd.41 Feedback reviews, 100% positive
We are an exterior building maintenance company specialising in lime mortar pointing, chimney repairs/rebuilds, roof & gutter repairs/replacements, and brick or stone restoration. We are comfortable working on both period and modern properties. We know the right...
Latest Chimneys & Fireplaces feedback review:
By rosalind656 on 22nd Feb, 2016
LN Gas Solutions25 Feedback reviews, 100% positive
A friendly company owned and run by Mr Liam Norfolk based in Great Cornard (Suffolk). The company specialises in fitting fireplaces, fires and cookers for both Natural Gas and LPG. LN Gas Solutions are fully qualified and Gas Safe Registered offering a professional and high...
Latest Chimneys & Fireplaces feedback review:
By cambridgeblue on 3rd Jun, 2016
Stag Building Co3 Feedback reviews, 100% positive
We are a Lowestoft based company who has 10 years experience within the building industry, we cover all aspects of building work and complete to the highest possible standard.
Latest Bricklaying feedback review:
By mr_m_petersen on 26th Feb, 2017
WJP Plumbing & Heating Limited7 Feedback reviews, 100% positive
Both domestic and commercial plumbing & heating work undertaken. A professional, reliable & cost effective service provided throughout all projects. Unrivalled advice given.
Latest Chimneys & Fireplaces feedback review:
By deanjohnston02 on 24th Nov, 2015
Suffolk Premier Roofing16 Feedback reviews, 100% positive
We are prompt and reliable, always aiming to keep costs low and quality high. With all aspects of roofing undertaken there isn't job we can't tackle.
Latest Chimneys & Fireplaces feedback review:
By richard_s_43 on 27th Oct, 2015
Need a tradesman?
Post a job on MyBuilder to find a quality, local tradesperson.
How MyBuilder works
1. Post a job
First, create a job listing for your chimneys & fireplaces project. It's quick, easy and free - the first step to finding recommended chimney & fireplace specialists in NR6, Norwich.
2. Hire a tradesman
Having met our recommended chimney & fireplace specialists in NR6, Norwich and read customer reviews, you're ready to decide which chimney & fireplace specialists to hire.
3. Leave feedback
After your project is successfully completed, you can leave a review for your chimney & fireplace specialists. This review helps you and future MyBuilder users.
What our customers say
- "This website helps people struggling to find builders - it has been so easy to use and clever in its conception."
- Barbara Young
Tradesmen in NR6, Norwich
- Architectural Designers
- Bathroom Fitters
- Bricklayers
- Carpenters & Joiners
- Carpet Fitters
- Chimney & Fireplace Specialists
- Conservatory Installers
- Conversion Specialists
- Damp Proofing Specialists
- Demolition Contractors
- Driveway Pavers
- Electricians
- Extension Builders
- Fascias, Soffits and Guttering Specialists
- Fencers
- Flooring Fitters
- Gas Engineers
- Groundworkers
- Handymen
- Heating Engineers
- Insulation Installers
- Kitchen Fitters
- Landscape Gardeners
- Locksmiths
- Loft Conversion Specialists
- New Home Builders
- Painters & Decorators
- Plasterers
- Plumbers
- Restoration & Refurb Specialists
- Roofers
- Security System Installers
- Stonemasons
- Tilers
- Tree Surgeons
- Window Fitters
- All Tradesmen

subset: commoncrawl


text:
IAG Cargo posted revenues of 1.02 billion euros for 2016, a 6.6 percent drop from 2015.
The Georgia Ports Authority handled 3 million tons of cargo in January, with bulk cargo at the Port of Brunswick more than doubling January 2016 figures.
The Agriculture Transportation Coalition, National Industrial Transportation League and National Retail Federation expressed concerns over a threatened work stoppage at East and Gulf Coast ports by members of the International Longshoremen's Association.
Registration takes less than 1 minute.
Forwarders and NVOs are accustomed to adapting to complex markets and new competitors, but is this time different?
The chief and second engineers of the Top Ship cargo vessel were sentenced Thursday to jail for their role in obstructing a U.S. Coast Guard inspection in July 2015 on board the ship in North Carolina's Port of Wilmington.
The United States Maritime Alliance, the employer group that negotiates the master contract with the International Longshoremen's Association, called the ILA's planned work stoppage threat "disturbing."


text:
Littlefinger poses!
August 22, 2012 17:07:36 Posted at August 22, 2012 17:07:36 Photos:
And a now moment to geek out over Game Of Thrones....
Littlefinger - aka Aidan Gillen - was at the Irish premiere of Shadow Dancer. Yes he's Irish. Which means Duana likes him even more now. I like him even more because he can work a red carpet. Look at our Littlefinger with his head tilted just so, lowered for the most flattering angle, and one foot slightly ahead of the other.
God do we really have to wait another 8 months for the new season?


text:
Lack of monitoring and emphasis can easily waste hundreds of dollars per head.
by Dennis Halladay, Hoard's Dairyman Western Editor
Every dairy conference has a presentation that unexpectedly makes you sit up straighter, listen closer and think harder. The one at the 7th annual Dairy Cattle Reproduction Council annual meeting in Sacramento, Calif., November 8 and 9 that met that description was John Lee's talk on the financial opportunities that are lost when raising heifers.
Lee (pictured) is managing veterinarian for Dairy Technical Services at Pfizer Animal Health. His talk was utterly compelling. His message is that money is lost when producers raise heifers using old assumptions and low priorities that ignore heifers' vital role in the success of the business. His conservative estimate: every heifer that calves at more than 22 months of age costs $100 per head per month in the form of unnecessary extra days on feed before they begin milking.
Saving those costs starts at birth - keeping calves alive, getting them started right, and feeding them aggressively to promote rapid frame size growth and vigor. But weaning isn't the end goal, it's just a beginning. Building upon this foundation in the growing heifer phase, via continued excellent nutrition and health care, is also only a step.
Getting them to breeding size early isn't the finish line, either. Nor is catching them in heat or getting them bred. Not moving heifers into the A.I. pen frequently enough (he recommends every two weeks at least) is a common mistake, as is not making age at first service a priority. Getting heifers pregnant puts producers into the home stretch, but the ultimate measure of success is when heifers calve and enter the milking string.
"My key take home message is, lower age at first calving is the single most important benchmark for achieving the highest economic return from a heifer replacement program," said Lee.
Hoard's Dairyman will broadcast a webinar presentation of Lee's DCRC talk on November 19. The time it takes to watch will be well worth it - literally. A link to register for the webinar appears below.
Want to make an extra $60 per heifer? In this webinar, John Lee, D.V.M., Pfizer Animal Health, leads an interactive discussion on getting more out of your heifer investment. With high input costs there is less room for error when breeding replacement heifers. Lee shares his thoughts on the best metrics to use when evaluating a heifer reproduction program. While common measurements are conception rate and percentage of heifers pregnant within three services, he will tell you about measurements that give you a better idea of what's really going on with your heifer reproduction program. Learn about efficiencies in heifer reproduction from a Hoard's Dairyman webinar, "Shrinking the freshening window for replacement heifers," live on Monday, November 19, 2012, at noon (Central time).
This is a special reproduction webinar, so those wishing to participate, must register at Go To Meeting. Registration in the monthly Hoard's Dairyman webinars will not automatically carry over to this special webinar.
Click the icon to subscribe to HD Notebook and get the blog sent to you.


text:
Blanche Wheeler Lee
Blanche Wheeler Lee, beloved mother, grandmother, great grandmother, great, great grandmother, and friend passed away peacefully at the Vista Grande Inn nursing home on June 12, 2014. She was born November 4, 1920 in Redmesa, Colo. to Veda Slade and Joseph LeRoy Wheeler.
She was raised in Redmesa and graduated from Farmington High School in 1938. She attended Phoenix School of Cosmetology in Phoenix, Ariz. Blanche married Robert E. Lee on November 12, 1943 in the LDS Mesa Arizona Temple, and together they had 5 children.
Blanche was a faithful member of the Church of Jesus Christ of Latter Day Saints and served in many positions. Her life was a life of giving and serving others. She was an avid knitter and shared her creations with many. She enjoyed making a variety of candy to share with friends and family. To most who knew her, she was Aunt Blanche or Grandma. She leaves a legacy of love, devotion and service.
Blance is survived by her children, Robert (Nancy) Lee of Peoria, Ariz., Linda (Dave) Colson of Aledo, Texas, Annette (Danny) Decker of Cortez, Colo. and Sheila (Lonni) Lee of Lubbock, Tex.; 15 grandchildren, 46 great grandchildren, and 1 great, great grandchild. She was preceded in death by her husband Robert; son Alan; her parents; 3 sisters and 2 brothers.
Funeral services will be held under the direction of Bishop Merle Whittaker at 10:00 a.m. on June 28, 2104 at the Redmesa LDS Church in Redmesa CO., with a viewing held prior to the service from 9:00-9:30 a.m. Burial will immediately follow the service at the Redmesa Cemetery.
Services are under the direction of Ertel Funeral Home. For further information or to send condolences, log on to www.ertelfuneralhome.com and click on the obituary section.


text:
Welcome to the Water Planet
Paperworks by James Rosenquist
10 June – 12 September 2006
Home | Gallery | Interview with Kenneth Tyler
Interview with artist James Rosenquist and curator Jane Kinsman,
with Beverly Coe asking questions on her behalf. Aripeka, Florida May 2006
Q: Would you describe your early days as an artist in New York.
James Rosenquist: I was studying art at the University of Minnesota in the fifties with Cameron Booth, a wonderful teacher who was 10 years older than the year. He studied with Hans Hofmann in Munich after World War II. He said, 'Jim, there's nothing for you in Minneapolis, you should go to New York and study with Hans Hofmann. I was interested in composition. Hans quit teaching, moved to Provincetown, so I tried for an out of town scholarship with the Art Students League and I won it for a year's schooling. So I arrived in the autumn of 1955 with 350 bucks in my pocket and started at the Art Students League.
You have to remember, New York at the time was a very different place than it is today. New York City was almost empty because the war vets who lived in Manhattan originally, families, moved to Long Island or New Jersey, so rents were cheap. I had a room on West 57th Street for eight bucks a week. I had later on a five room apartment on the Upper East Side for 31 dollars a month. So it was a very, very inexpensive place to be and a wonderful thing to live in a cosmopolitan city with all the advantages and not have to worry about money too much. Although I did, I didn't have any money, so I was always a starving artist, as many artists are.
New York was a fascinating place. I had been painting outdoor signs in Minneapolis for General Auto Advertising and I transferred into the union in New York, the Sign Painters and Pictorial Painters Union Local 230, which was largely run by Italians, and they said there was no work for me. But I made a speech saying I respected the rights of all the older gentlemen in the union and I'm willing to take my turn and they went, 'Ha, ha, ha. Okay, bring your money around Thursday'.
So I joined the union, went to work in Brooklyn painting Schenley whiskey signs above practically every candy store in Brooklyn. I painted 145 of them. After about number 50 I got so tired of this that, so boring, that on the label instead of writing, 'This spirit is made from the finest grains' and so on, I wrote 'Mary had a little lamb, its fleece was white as snow'. I was totally bombarded by advertising, which I didn't care for but it was something I did. I think that is probably my relationship to what is now called Pop Art.
I was bombarded by advertising right in front of my nose. I graduated from Brooklyn to Times Square and I painted the Astor Victoria Theatre seven times, which was 395 feet (120 metres) wide and 58 feet (17 metres) high. I also painted everything good enough to sell. You had to paint beer shirts, movie stars, anything good enough to sell it, otherwise you'd be fired.
So New York was a much different place and a young artist would have time to gather steam in New York. I mean, the people that I knew, middle-aged people I knew, were commercial artists but their fine art was a private social club and there was no demand for it, fine art, these avant garde artists, so they would have cocktail parties and show their art to each other but not in galleries or anything until probably a few years passed.
So I think that's a great advantage of that era because now it's so expensive in New York that the young artist thinks he or she has to show their fine art immediately and the critics say they stink and they go, 'Oh, no, I really am bad? Oh, that's terrible', and then they have to work twice as hard to show the audience that they're actually pretty good.
Q: Your use of collage seems important in your working method. How did this style of using a collage develop when you began working as an artist? Why did it appeal in those early days?
James Rosenquist: Well, all that working in collage, it started for me … well, way back during World War II in a museum in Ohio I saw a show in a museum where right next to each other was a little painting, a flower, live flower and a shrunken head, and I wondered what the hell does that mean?
Then, you know, naturally Kurt Schwitters, he's allegedly responsible for contemporary collage, but my experience was going to work for Artkraft Strauss Company with a lot of dissimilar material sitting on a desk, I would have to scale a lot of this material into one sign. It was all different sizes and so I'd have to scale it up, scale it down, put it in place, and then they'd send me out to paint this big sign, whether it was for the movies or it was for the Castro Convertible (sofa beds) sign on 47th street or the DeMille (theatre) sign on 47th street.
So I learned how to square things up from any size to billboard, one foot squares or two foot squares on a big sign, and that probably started me thinking about collage. I would take disparate images, put them together and try to make another sense out of them. It was almost like the idea of listening to radio and thinking about something in the abstract.
Q: How did you use collage for your paper works you made with Ken Tyler?
James Rosenquist: Well, I knew Ken Tyler for a number of years but I never worked with him. He called me up and he said, 'Jim, I've got a new facility up in Mount Kisco New York, why don't you come out here and light the place up'.
So, okay. So I went to see him, and Ken had very small presses, I mean, the press beds were rather small, but we wanted to do prints 5 by 6 feet (1.5 by 1.8 metres), 6 by 7 feet (1.8 by 2.1 metres), 10 feet (3.0 metres) and so on. So what did we do? Well, anyway, I brought him one collage and he said, 'Is this all you've got?' I said, 'Okay, maybe I'll bring in another one'.
So we had enough trouble doing the first one. What we did was he ground up Chinese rag paper pulp into a big porridge like material and put it on a big piece of felt so it would look like a quarter inch thick rug made out of mush. Then I coloured this paper pulp for a background and then on top of this stuff, this paper pulp, I made lithographs on a regular small lithograph press and we adhered those to the paper pulp after it had been dried. So they really became like gigantic collages because Ken didn't have the presses large enough.
Q: When you made the paper works with Ken over the months from September 1988 to December 1989 and again in 1992 at the Mount Kisco workshop, how did your working methods change?
James Rosenquist: Well, the one thing was the colour that I would spray on to the paper pulp with a house ceiling spraying machine for paint. The colours in this water, this watercolour, was a completely different colour than what it would dry up to be, almost like scenic art paint.
So sometimes you would want a very, very faint blue-grey and it would look like just plain water, dish water. Other times you'd want a rich red and the richest red after it was dried and pressed would become pink. So you'd really have to test a lot of colours for spraying on these colour backgrounds.
Q: Did you like working in paper pulp?
James Rosenquist: Working in paper pulp for me, and Ken, was a great experiment. Ken really produced this situation and he was ingenious in producing this because he had a mill that ground up the paper and then these huge hydraulic presses that would press the water out of the paper pulp, so it was purely his invention and I think I've never seen it done anywhere else to this day. He was a great innovator.
Q: In the light of your express desire to be more spontaneous in a print workshop, did you succeed?
James Rosenquist: I don't know (laughs). I don't know if I succeeded or not. I know that financially it was a big success for Ken and myself, but I just worked like a worker, sort of blindly, being excited by this adventure and it all seemed to come out pretty well.
Q: How did this working method at Tyler Graphics contrast with your earlier ways of making prints?
James Rosenquist: Well, Ken Tyler is a great innovator so the difference between Ken Tyler and other print shops was that if you came with an idea for Ken that seemed extremely difficult, he'd sort of think it over, shake his head, and then he'd walk away. The next day he would come out with a great big welded aluminum extrusion, he'd spare no expense to have something made out of magnesium or aluminum or whatever merely as a template to do a work. If it worked, fine, if it didn't work he'd merely throw it in the parking lot. But he would do and try everything. He was a total enthusiast.
Q: Do you think that the experience that you had working with Ken at Mount Kisco subsequently affected your methods and painting?
James Rosenquist: Probably only in maybe terms of colour, because I was always making rather large paintings and to make a print that approached the size of a 6 by 6 foot (1.8 by 1.8 metres) painting or whatever seemed to be very huge
Initially when I started painting back in 1960, '61, I was trying to do a new kind of artwork where I tried to make a mysterious painting by painting fragments, very realistic fragments of realistic things, and the last one would be so huge that you couldn't quite identify it, although it seemed real or whatever, so I've tried to make a mysterious painting by the viewer identifying the pieces in the painting at a rate of speed. All I wanted to do was mysterious paintings.
Q: The Water Planet series and related works House of Fire and Space Dust were made in the late 1980s and early 1990s. What were the issues you were concerned with when you were making these works?
James Rosenquist: Well, first of all it's called Welcome to the Water Planet and I've always thought of aliens visiting us and wondering who we are or what we are and what do we do, so there really was a pun or a joke because Welcome to the Water Planet, what you see is what you get, or what you expect is pretty much what it is.
So ecologically our country has been going on a disastrous path towards oblivion with our government and just a handful of people recognise the ecology of our world, the oceans and so forth, and so these art works called Welcome to the Water Planet were comments on this delicacy of our ecology.
Q: What message do these works have for us today one or two decades later?
James Rosenquist: Well, unfortunately it's the same old story, that our government policies continue to sort of kill the ecology of the world.
Q: Any other thoughts?
James Rosenquist: Well, it was a great deal of work and fun to work with Ken Tyler and now his shop is no longer available. I believe he's raising thoroughbred cattle. Also in my life, outdoor pictorial sign painting no longer exists. That was a thing that happened once and I was very fortunate to be able to experience that. My goal in that was I wanted to learn how to paint the Sistine Chapel. Now, I could learn the mechanics, I don't have the content but I could paint practically anything huge if I had the idea. That's about it.


text:
Presentation @ CommunityOne
By bytor on May 05, 2008
It's been a while since blogging! A lot has changed since late 2007 :) I have moved to the Portal group, working on Sun's next generation portal technology, providing lightweight widget aggregation and presentation, multi-language widget communication, and a host of other enterprise features.
Today I am at CommunityOne, Sun's free-to-attend conference the day before JavaOne. I did a presentation at 11am on "Breaking Down Barriers: Widgets, Mashups, and WOA for the Enterprise" where I did a general overview of the technology used to create "Web 2.0" widgets using web APIs made available by the likes of Google, Amazon, Facebook, Flikr, and others. It was the first time doing this presentation, so there were the usual flubs, "uh's" and uncomfortable pauses but generally it went well, with some excellent post-preso questions from the audience. I'll post the video as soon as it hits the CommunityOne/JavaOne site. Thanks to all those who attended. I also showed a demo of Project WebSynergy, the moniker we've attached to the future of middleware widget aggregation platforms. Thanks to all who attended. There will be additional press releases on Wednesday associated with this new project. More to follow...


text:
Soft and chewy
Verified Purchase
Soft and chewy
It is good to eat between meals if you are in low calorie diet. It is healthy and not so sweet. I give it 4 star because it is not my favorite flavor.
The taste is just okay
Posted by australia on Jan 09, 2014
I had tried the chocolate variety of these bars and loved them so thought I'd give the peanut butter ones a go. They're okay, but the flavour is just not that nice, I'm not really sure what it is, but they just taste strange (not a bad taste though, just different). Won't be repurchasing.
great snacking
Posted by Reviewer1717014 on Mar 14, 2014
one of my favorite snacks, and a perfect energy bar, even if you're not a kid. As good as a cookie and pretty wholesome!
great for snacking
Posted by 4692393388491981279 on Jan 02, 2014
perfect on the go for a pick me up
Posted by Reviewer1702476 on Apr 25, 2011
The best healthy bars I`ve tasted... Not just for kids :-)
protein bars
Posted by Reviewer1233797 on Sep 21, 2011
These are a great after gym snack for the whole family.
Kids say they're yummy
Posted by Reviewer2823720 on Sep 26, 2011
I have barely opened my delivery and my boys are asking if they can have one - very yummy
Posted by Reviewer2071911 on Oct 13, 2011
This is yummy. I will buy this again.
My son still prefers these at age 17
Posted by 5705832463974180334 on Dec 23, 2012
We bought these from amazon til UPS broke a box & returned it before it ever got to me, and they refused to replace it. Fantastic quick snack to keep the brain cells firing. My son says regular Clif bars are too sweet for him, so now that he's in High School he uses 2 Z Bars. iHerb has the best price, and delivers to my door.
Can't believe they're healthy
Posted by ekstravirgin on Jun 30, 2013
'cause they taste like candy. A favourite hiking snack for me and my daughter!
My kids love this.
Posted by Reviewer1443928 on Nov 16, 2007
Great nutrition and great taste! and great price too, thanks to Iherb!