Hello,
I am having a problem when I try to add a file to my course. Here is a scenario of my use:
- in the course I turn editing on
- i select in in the "Add a resource"- combobox "Link to a file or website"
- the ''Adding a new resource to week X"-window opens
- I fill something in at the title
- I click on the "Choose or upload a file"-button.
- Then I select a file and click "Choose", which inserts the object in the form.
- I click at the bottom on the "Save changes"-button
- A red box with an error is shown, that says: "A required parameter (type) was missing"
I experimented with this both in Safari and in Firefox (both on Mac and on Windows). It only occurs in Safari. I am using Moodle 1.8.4+. Does anyone has an idea what can be done to fix this? Or why this occurs?
Thank you for your help and time,
Sten Govaerts
I use Safari all day every day with no problems. Is this on a Mac or on a PC? How big is the file? Is it anywhere near the maximum upload size?
The last try was with an excel-file of 53 KB. I suppose this can not be a problem.
And on the other hand I can upload the file to Moodle Files, but I cannot insert it into a course.
Yes, this is on both a mac and a PC running Windows. I even tried it on 3 different machines...
The maximum file size of PHP is set to 20MB in php.ini, so this should also suffice.
-Sten
And on the other hand I can upload the file to Moodle Files, but I cannot insert it into a course.
Yes, this is on both a mac and a PC running Windows. I even tried it on 3 different machines...
The maximum file size of PHP is set to 20MB in php.ini, so this should also suffice.
-Sten
I just checked the maximum file size in the Moodle settings. It is set to 18 megabyte. The course settings are also set to 18 megabyte.
What does the type-parameter in the error message refer too?
-Sten
What does the type-parameter in the error message refer too?
-Sten
Sten,
Is Safari set to update itself as necessary?
Try a much simpler file type as your File Resourse; a .gif or .jpg file that has to be supported in every browser! Does that work?
If not, try it without using the Add a resource drop-down at all.
Just click on the Edit Summary button (pen-in-hand) on any empty week...
Click the Insert Image button (picture frame)...
Click once on a jpg or gif already in the file browser, (or, click browse pick up such a file and click upload, then click once on the filename)...
Fill in the Alternative text... click OK
Is the picture immediately visible in the edit box? It should be.
Save changes.
Does the picture appear in the course? It should.
Regards,
John
Is Safari set to update itself as necessary?
Try a much simpler file type as your File Resourse; a .gif or .jpg file that has to be supported in every browser! Does that work?
If not, try it without using the Add a resource drop-down at all.
Just click on the Edit Summary button (pen-in-hand) on any empty week...
Click the Insert Image button (picture frame)...
Click once on a jpg or gif already in the file browser, (or, click browse pick up such a file and click upload, then click once on the filename)...
Fill in the Alternative text... click OK
Is the picture immediately visible in the edit box? It should be.
Save changes.
Does the picture appear in the course? It should.
Regards,
John
Hi John,
Thanks for the reply! I tried it with a simpler file type (a jpeg) as you proposed, but it gives the same error. After that I tried to add a jpeg to a Summary, but that is pretty hard to do in Safari since the rich text editor isn't really browser independent. In firefox I get a nice editor with different buttons and features, in Safari it doesn't exist (see the attachment, I could not add it into the text since I'm typing this in Safari).
My guess is that the problem of the error is related to the fast Javascript engine of Safari. The page where the "type" parameter is used, uses quite a bit of javascript. It could be that the value for the hidden inputfield with name "type" is not known yet to Safari because of the faster execution of Javascript then when executed with Firefox or IE.
Does anyone have the same problem when adding resources with Safari (both on Windows and mac)?
-Sten
Thanks for the reply! I tried it with a simpler file type (a jpeg) as you proposed, but it gives the same error. After that I tried to add a jpeg to a Summary, but that is pretty hard to do in Safari since the rich text editor isn't really browser independent. In firefox I get a nice editor with different buttons and features, in Safari it doesn't exist (see the attachment, I could not add it into the text since I'm typing this in Safari).
My guess is that the problem of the error is related to the fast Javascript engine of Safari. The page where the "type" parameter is used, uses quite a bit of javascript. It could be that the value for the hidden inputfield with name "type" is not known yet to Safari because of the faster execution of Javascript then when executed with Firefox or IE.
Does anyone have the same problem when adding resources with Safari (both on Windows and mac)?
-Sten
Sten,
Now that is really interesting!
Because I'm seeing exactly the same problem in Safari 3, as far as the Editor is concerned!
I've just checked that for both Moodle 1.9+ and 1.9.1, neither show the editor in Safari 3 for Mac OS X Tiger,
but it works fine on Firefox 2 for Mac, and Firefox2 (PC), and IE7 (PC).
I've just downloaded Safari 3.1.1 ("the world's best browser"... it says), to test on that
- and the Editor still doesn't appear!!!
But I have never experienced the problem you started with - very odd.
I presume that if you add your file link - or my suggested summary picture - in Firefox,
then the content is displayed correctly when you refresh in Safari.
Is this correct?
I'm wondering if the Editor problem is a bug in Moodle specific to Safari,
or a setting in Safari.
But your original problem may not be connected to the Editor issue??
I have noticed another thread that has some relevance, I might try a test or two.
Regards,
John
http://moodle.org/mod/forum/discuss.php?d=84293
Now that is really interesting!
Because I'm seeing exactly the same problem in Safari 3, as far as the Editor is concerned!
I've just checked that for both Moodle 1.9+ and 1.9.1, neither show the editor in Safari 3 for Mac OS X Tiger,
but it works fine on Firefox 2 for Mac, and Firefox2 (PC), and IE7 (PC).
I've just downloaded Safari 3.1.1 ("the world's best browser"... it says), to test on that
- and the Editor still doesn't appear!!!
But I have never experienced the problem you started with - very odd.
I presume that if you add your file link - or my suggested summary picture - in Firefox,
then the content is displayed correctly when you refresh in Safari.
Is this correct?
I'm wondering if the Editor problem is a bug in Moodle specific to Safari,
or a setting in Safari.
But your original problem may not be connected to the Editor issue??
I have noticed another thread that has some relevance, I might try a test or two.
Regards,
John
http://moodle.org/mod/forum/discuss.php?d=84293
Hi Sten,
Okay. On the subject of the Editor, the reason why Safari is behaving differently is that historically the HTMLarea editor did not work in Safari and so it was treated as a special case.
It is supposed to use the TinyMCE editor, but in our setups it is failing to load that!
I read that it may be a version issue, so I downloaded the latest from http://tinymce.moxiecode.com and it still didn't work!
I re-read the forum thread I referred to and tried a couple of changes to the php as mentioned, but those didn't work either!
So next I'll post a message to that forum thread and see if this behaviour is recognised.
Regards,
John
Okay. On the subject of the Editor, the reason why Safari is behaving differently is that historically the HTMLarea editor did not work in Safari and so it was treated as a special case.
It is supposed to use the TinyMCE editor, but in our setups it is failing to load that!
I read that it may be a version issue, so I downloaded the latest from http://tinymce.moxiecode.com and it still didn't work!
I re-read the forum thread I referred to and tried a couple of changes to the php as mentioned, but those didn't work either!
So next I'll post a message to that forum thread and see if this behaviour is recognised.
Regards,
John
TinyMCE needs also correct init code and a proper integration if you want to use it. Did you try my moodle 1.9 editor test package or was it some other integration? Safari does not render default editor htmlarea in any current versions of moodle.
You could also test if your Safari works for example in http://wiki.moxiecode.com/examples/tinymce/installation_example_04.php
Yes, that moxiecode-link shows a proper rich text editor, with all the blows and whistles.
I am running moodle 1.8 on which I am dependent because of a plugin only available in 1.8.
-Sten
I am running moodle 1.8 on which I am dependent because of a plugin only available in 1.8.
-Sten
Sten,
your case could be related to some settings of your Safari (something disabled) or some files of your local install (some odd characters breaking javascript code in Safari) or some server settings but you could also test if my xinha package works on your site. It replaces htmlarea and does not change any system files so you can easily recover old htmlarea by renaming folders before and after testing. Check http://korpelainen.net/xinhatest/
As with Sten, the TinyMCE example runs fine in Safari.
J.
J.
Mauno,
I have bitten the bullet and upgraded my Local 1.9+ installation to the Weekly1.9.zip that you show above (1.9.1+ Build: 20080528).
All went really well, and the site is working fine. The HTMLarea Editor works in Firefox as before, however there is a fault in TinyMCE editor in Safari as it throws up the message box shown below and only shows text editing as you click through.
I think this might be because I had already taken Safari up to 3.1.1 before the Moodle upgrade. Is that possible?
Does Moodle editor not know about 3.1.1, or have I not enabled TinyMCE???
Regards,
John
I have bitten the bullet and upgraded my Local 1.9+ installation to the Weekly1.9.zip that you show above (1.9.1+ Build: 20080528).
All went really well, and the site is working fine. The HTMLarea Editor works in Firefox as before, however there is a fault in TinyMCE editor in Safari as it throws up the message box shown below and only shows text editing as you click through.
I think this might be because I had already taken Safari up to 3.1.1 before the Moodle upgrade. Is that possible?
Does Moodle editor not know about 3.1.1, or have I not enabled TinyMCE???
Regards,
John
There are two level checks - first function can_use_html_editor() in moodlelib.php checks what browser you have (or what does the browser tell itself to be - sometimes browsers can mask themeselves to be something else they usually are). Then editors have tests of their own - each editor has some lines that test browser and tell if they support that browser or not.
Files may be in cache so clearing cache and page history might help. This looks like the old browser check. Did you select the editor from user profile (default is htmlarea) and did you try fckeditor or xinha?
Ah - this is the message from htmlarea http://moodle.org/mod/forum/discuss.php?d=84293
Because htmlarea is the default browser of moodle Safari shows this message that comes from htmlarea.php
If you select another editor from your user profile everything should be ok.
I could update the package to use tinymce as a default editor or update htmlarea to leave this message away (it still shows only the textarea with or without this message)
Thanks for your note!
Mauno,
Okay I've got the editor running, but you really do need to change the default editor!
Otherwise I have to go through every user and change their editor, just in case one of them uses Safari!
But surely this is an interim position - do you really intend to have users all using different editors?
That looks whimsical to me, and would add one extra complication to any training sessions on how to use the editor.
Why not put the choices on Site Administration only - which is where I went looking!
TinyMCE works on Firefox & Sarafi (both a MAMP installation on Mac).
I'll report back some more in a day or two.
In the meantime, does any of this make Sten's original issue go away?
Regards,
John
Okay I've got the editor running, but you really do need to change the default editor!
Otherwise I have to go through every user and change their editor, just in case one of them uses Safari!
But surely this is an interim position - do you really intend to have users all using different editors?
That looks whimsical to me, and would add one extra complication to any training sessions on how to use the editor.
Why not put the choices on Site Administration only - which is where I went looking!
TinyMCE works on Firefox & Sarafi (both a MAMP installation on Mac).
I'll report back some more in a day or two.
In the meantime, does any of this make Sten's original issue go away?
Regards,
John
Well, my tests started from the idea to get different editors for kids, different editors for university professors, different editors for people who need some special plugins...and I started to plan user based, role based, course based etc editors like we have different themes for different people.
It might be a good idea to test a same kind of multi level selection system for editors as we have for themes so that administrator could force or allow site editor (default editor from administration menu), course editor (from course settings), role based editor (from role settings) or user editor (if allowed)
There is already a process going on for changing default editor for moodle (2.0) - http://tracker.moodle.org/browse/MDL-11113
I can change the default editor easily by editing files in folders lib/editor/1-5
I left htmlarea to default editor for historical reasons but could change it to tinymce any time. It takes only a couple of minutes to edit the package or to create a smaller package from files in folder 1-5. In future settings and configuration will probably change a lot more flexible - this is more or less a one-man-project that I have been doing out of pure interest.
On the other hand it is also easy to set moodle to have only one editor by changing first the default editor to tinymce or fckeditor and then taking away options 2-5 from user/editlib.php - it is still possible to create any kind of selection systems for editors, editor themes, skins and skin variants for each editor from various selection lists, from editor itself etc.
Thanks Mauno,
I'll make TinyMCE my default following your instructions.
BTW: Editor choice by course, with the course default an administrative setting and the administrator able to force an all courses settings (i.e no choice) sounds eminently more practical.
See this thread on what administrators might think of young users being able to change things much!...
http://moodle.org/mod/forum/discuss.php?d=97620
Regards,
John
I'll make TinyMCE my default following your instructions.
BTW: Editor choice by course, with the course default an administrative setting and the administrator able to force an all courses settings (i.e no choice) sounds eminently more practical.
See this thread on what administrators might think of young users being able to change things much!...
http://moodle.org/mod/forum/discuss.php?d=97620
Regards,
John
Thank you for the link. They describe a hack, which I am for the moment going to leave as it is. The users can type, but they cannot upload any files...
I can of course add a picture to the summary by referring to an online picture in the HTML img-tag and moodle shows it correctly (there shouldn't be any sane reason why Safari can't display an img-tag anymore
. So that is not the problem. The problem is that I can not add documents to moodle when using Safari...
I will try some debugging tomorrow...
-Sten
I can of course add a picture to the summary by referring to an online picture in the HTML img-tag and moodle shows it correctly (there shouldn't be any sane reason why Safari can't display an img-tag anymore
I will try some debugging tomorrow...
-Sten
Hi Sten,
I don't have Safari here (at work) to be able to test it but any javascript error may cause problems like this. Very often this kind of strange problems are caused by some edited file (config.php, theme config.php or some lib file) so the reason for failure can be for example white space or empty row before or after php code. I will be at home after 3 hours - if you can send some link to your site it would be easier to check source code and to find possible reason...
Mauno,
I have noticed that the upload tool used by Moodle in Safari does not appear the same (or at least does not look the same) as the one used in other browsers!
But I have only just spotted the difference!
If the tool is conditional on the browser, could it suffer from much the same sort of problem as the Editor tool?
Thanks for posting up the information on editors in the Developers forum.
John
I have noticed that the upload tool used by Moodle in Safari does not appear the same (or at least does not look the same) as the one used in other browsers!
But I have only just spotted the difference!
If the tool is conditional on the browser, could it suffer from much the same sort of problem as the Editor tool?
Thanks for posting up the information on editors in the Developers forum.
John
Do you have any screenshot about the difference - any buttons missing or something like that...
Yes - this is normal Safari 
The file will be visible on the right side of Choose file button when it have been chosen.
Bear in mind that I don't see the file upload fault Sten does, but I do see this marginal difference in the upload tool between browsers.
The IE7 (on PC) view is exactly like Firefox.
John
The IE7 (on PC) view is exactly like Firefox.
John
This just started happening with me (Safari 3.2.1). The work around is to change the User Agent in Safari (advise me if you don't know how to do that) to something other than Safari. I tried switching it to Internet Explorer 7 and the uploads work as they are supposed to. This tells me Moodle isn't recognizing the latest Safari as an acceptable browser, as only changing the User Agent makes it work...