I have a case of the File picker never loading. See attachment.
The Moodle runs on a cheap shared host. I know, shared hosting is too weak. But what is exactly the component which is insufficient?
The site is very responsive otherwise. I can back up this 100 MB course in seconds - as fast as the VPS before. I transferred the course taking a course backup (with users) from the VPS and restored it in the shared host. All went without a hitch. But I can not attach files to a forum post, because the File picker never gets loaded.
For comparison:
- Previous setup: low-end VPS (1 vCPU, 2 GB RAM), Debian 8 (PHP 5.6), Moodle 2.7, "Clean" theme.
- New setup: shared host ("one-click" installation), PHP 7.1.10, Moodle 3.4.1, "Boost" theme.
I have both sites running. There were no problems in the VPS. The same course transferred to the shared host, to the latest software, does not load the File picker. Any insight in to this?

Hi Visvanath,
it's not a matter of resources IMHO but of a broken JSON response for "some reasons" for sure related to the new env (regardless its sizing at first).
Please, open the Dev Tools of your browser (<F12> in Windows, e.g. CR) and inspect all the network requests coming from AJAX context (xhr usually): for each of them, explode the response to look for a real JSON response body and not e.g. an HTML page explaining something - and if you'll find an HTML page, you'll get some good investigation points towards finding the actual culprit.
HTH,
Matteo
Sounds convincing. Only thing, I don't know how accurately I can debug, I am not a web developer!
Anyway, I looked at a "Write new post" page http://example.com/mod/forum/post.php?forum=1 with the developer tools. There are only three xhr lines:
1) ./lib/ajax/service.php?sesskey=bSVV34QpkV&info=core_message_get_unread_conversations_count
2) ./lib/ajax/service.php?sesskey=bSVV34QpkV&info=message_popup_get_unread_popup_notification_count
3) ./lib/ajax/service.php?sesskey=bSVV34QpkV&info=core_fetch_notifications
4) Immediately below 3) there is a ./lib/javascript.php/1519504683/repository/filepicker.js followed by
5) a series of
./theme/yui_combo.php?3.17.2/event-simulate/event-simulate-min.js&3.17.2/async-queue/async-queue-min.js&3.17.2/gesture-simulate/gesture-simulate-min.js&3.17.2/node-event-simulate/node-event-simulate-min.js&3.17.2/json-stringify/json-stringify-min.js&3.17.2/io-upload-iframe/io-upload-iframe-min.js&3.17.2/io-form/io-form-min.js&2in3/2.9.0/build/yui2-treeview/yui2-treeview-min.js&3.17.2/cookie/cookie-min.js&3.17.2/array-extras/array-extras-min.js&3.17.2/array-invoke/array-invoke-min.js&3.17.2/arraylist/arraylist-min.js&3.17.2/model/model-min.js&3.17.2/model-list/model-list-min.js&3.17.2/datatable-core/datatable-core-min.js&3.17.2/view/view-min.js&3.17.2/datatable-head/datatable-head-min.js&3.17.2/datatable-body/datatable-body-min.js&3.17.2/datatable-table/datatable-table-min.js&3.17.2/datatable-base/datatable-base-min.js&3.17.2/datatable-column-widths/datatable-column-widths-min.js&3.17.2/datatable-message/lang/datatable-message_en.js&3.17.2/datatable-message/datatable-message-min.js
Those were the headers. The Response in 5) are all CSS. The response to 4) begins with
YUI.add('moodle-core_filepicker',function(Y){Y.Note.prototype.getStyleand ends with
if(this.options.repositories[repository_id]{this.list{'repo_id':repository_id})}}.get_preference:...=new FilePickerHelper(options)}
(Manually entered. Didn't find how to copy-and-paste.)
Is this the right track?
Hi Visvanath,
yes&no: it is related but to load the required JavaScript code for "running" the file picker.
You need to focus only on "xhr" connections, precisely (e.g.) https://moodle.org/repository/draftfiles_ajax.php?action=list.
The URL in the example is the one called to populate the file picker when replying to your post here and you can find below its JSON payload:
"path": [
{
"name": "Files",
"path": "/",
"icon": "https://moodle.org/theme/image.php/moodleorgcleaned_moodleorg/core/NNNN/f/folder-MM"
}
],
"itemid": LLLL,
"list": [],
"filecount": 0,
"filesize": 0,
"tree": {
"children": []
}
}
/lib/ajax/service.phps are AJAX calls, still with a JSON payload: (2) and (3) responses are required for the callouts near the profile name&picture at your top-left corner in the browser display.
HTH,
Matteo
You are slowly but steadily losing me! (The Ajax I know perished in the Trojan war.
;)
I am giving a try, in case it helps to debug Moodle. For me, giving up the exercise and going back to my VPS and 3.1 LTS is the most sensible thing.
I am back on a page ./mod/forum/post.php?forum=11. There are only three Calls=xhr, all have Type=json:
1) ./lib/ajax/service.php?sesskey=2dQ730VVX5&info=core_message_get_unread_conversations_count
2) ./lib/ajax/service.php?sesskey=2dQ730VVX5&info=message_popup_get_unread_popup_notification_count
3) ./lib/ajax/service.php?sesskey=2dQ730VVX5&info=core_fetch_notifications
1) and 2) have empty response (0 object, error false, data 0)
3) has data Array. But can not expand it.
None of them building the widget, I believe. There is a whole series of ./theme/yui_combo.php?... exchanges, as far as I can see, they are CSS. I an diverging, I'm afraid.
Don't really have an answer, but questions ... that might lead somewhere ...
Shared hosting and one click installer ...
Saw a provider that had inode restrictions on customer accounts - shared hosting ... they too had a 'one click' installer'. In forums of that provider a discussion about the issue and Moodle. Tech support response was an eye opener ... their one click, stripped out from moodle code things meant for development use thus reducing the number of files and getting under inode limit. Upgrades ... no manual for sure. They had to provide.
Combo loading ... YUI ibraries (which are no longer getting fixes, etc. but are available) ... does combo loading mean ... use locally cached js files first and if they cannot be found reach out to a Yahoo URL to re-aquire the .js files? Or does it mean acquire a .js file that then, itself, brings in/loads 3 other .js files?
Anyhoo ... those files are in a Moodle cache somewhere .... don't re-call exactly which one ... but was able to 'solve' the issue by changing into that cache area and used wget to re-acquire the .js files from Yahoo. Manually removing cache, of course, meant re-acquiring all over again ... built a bash shell script, however, that did that.
Don't re-call the URL, unfortunately. :\
Mind sharing the provider? If they have FAQ's or Customer forums opened to the public, don't mind chasin' this rabbit a little for ya from a different angle!
'spirit of sharing', Ken
Thanks for all the pointers! This seems to be an issue local to the laptop! With Matteo I localized the problem to the Browser, the Firefox 52.6 ESR 64 bit Linux, which I use. Right now, I am on Firefox 52.6 ESR on a different 64 bit Linux, and have no problems. So it must be a plug-in or something else in my regular laptop.
Right now, I am not following up, this particular combination is not so important. Want to come back though, I am curious to know whether the sudden surge of file picker issues are related:
- https://moodle.org/mod/forum/discuss.php?d=350083
- https://moodle.org/mod/forum/discuss.php?d=366687
- https://moodle.org/mod/forum/discuss.php?d=362093
P.S. I didn't mention the (shared) hosting provider, since the problem is on the client side.
Yes, 'shared host ("one-click" installation), PHP 7.1.10, Moodle 3.4.1, "Boost" theme'.
The issue is with the browser, Firefox 52.6 ESR, in one laptop running 64 bit Linux. The same browser in a different laptop, also 64 bit Linux, has no problems.
But I am not following it up right now.
This is ridiculous. The browser caches and does not look back? For over a week? I thought, time stamps control the life time of a cache.
Whatever, learned a lesson. This was a small headache, but could have been otherwise. Many thanks!
Hello Everyone,
Moodle makes uses of the local browser cache - which is another thing among the other ones listed above, which run at server side - through some HTTP Headers describing the caching mechanisms to be applied (or not) on the local browser (FYI Pragma and Cache-Control): depending on the version, it is quite aggressive and it could be e.g 3 months which means that given the SAME URL the browser will never contact the server up to that time range.
That's why usually purging all caches in Moodle purges this local browser cache too since the URL of javascript and other themes related files will change, being in the URL serving the file, a time-based "patch", here are some examples in moodle.org:
- JS, time based: https://moodle.org/lib/javascript.php/1519094525/blocks/spam_deletion/module.js
- CSS, time based: https://moodle.org/theme/styles.php/moodleorgcleaned_moodleorg/1519094525_1516101571/all
- CSS, vendor version based: https://moodle.org/theme/yui_combo.php?3.17.2/cssbutton/cssbutton-min.css
The strange thing here is why purging the Moodle (themes) caches, which changes the time based URLs to force the download of the "new" files from Moodle, didn't work here: guessing something in the middle (an extension) or some plug-ins in Moodle not following its APIs or some external iframes badly interacting with the code or... an obscure Moodle bug.
HTH,
Matteo
Thanks for all the background information! I just want to add that Firefox (at least on Debian) is very reluctant to release its cache. I had a case of changing the IP address of a domain in DNS having no effect for days.
Again the same story: Noticed that Chromium visits the new IP. Waited another day. Firefox still visits the old IP. Deleted its cache. Firefox immediately jumped to the new IP! So the problem is not with Moodle, at least aggravated by Firefox.
Hi Visvanath,
let me add a note about "my" vs "your" caching .
My last post describes content/resource caching whilst in your last post you're talking about DNS caching which cannot be controlled via HTTP Headers, being something depending on some local settings of your web browser.
Open a new tab in Firefox and write about:config, search for dnsCache, then you'll find three items:
- network.dnsCacheEntries
- network.dnsCacheExpiration
- network.dnsCacheExpirationGracePeriod
those values will rule the local DNS cache of your Firefox application (in my 59.0.2 64bit running on Win 10 the values are 400/60/60 respectively).
Even the OS has its own DNS client cache, if you have tried to resolve the name using ping <hostname> from a terminal: for example in Windows you can flush it via ipconfig /flushdns, https://support.apple.com/en-us/HT202516 for OSX and in Linux it depends on the distro and user tuning e.g. by means of dnsmaq.
HTH,
Matteo
The same problem happened recently on our 3.3.4+ server in a single specific course. Trying to add a file resource failed.
Tracked it down to a browser console error visible in your browser (ctrl+shift+J in chrome or firefox):
TypeError: Y.one(...) is null
view.php?id=478:319 Uncaught TypeError: Cannot read property 'detach' of null
at YUI.<anonymous> (view.php?id=478:319)
at e.Subscriber._notify (yui_combo.php?rollup/3.17.2/yui-moodlesimple-min.js:40)
at e.Subscriber.notify (yui_combo.php?rollup/3.17.2/yui-moodlesimple-min.js:40)
at e.CustomEvent._notify (yui_combo.php?rollup/3.17.2/yui-moodlesimple-min.js:39)
...(there is YUI_combo.php again)
Workaround: created a new course and imported the buggy one into the new. Strange but it helped.
Although yours got the same symptom, I don't think it has the same cause as https://moodle.org/mod/forum/discuss.php?d=366360. See its cause https://moodle.org/mod/forum/discuss.php?d=366360#p1479457.