Moodle

I do find it frustrating when adding files that it previews them all the time. With 99% of the documents I upload being my own work, I am well aware of the content and know that they will display within a browser. Heres hoping! Cheers.

When someone is uploading big pdf file, the file after upload is opening in a browser which is very annoying!

Comming up again:
http://moodle.org/mod/forum/discuss.php?d=71101

Having demonstrated my first Moodle to a teacher today, he felt that the preview feature was very confusing and unnecessary.

This auto-previewing has made me suicidal at times... (Especially when putting loads of resources on in one go....)

I have a sort of workaround in that one can make the resources open in a new window and then turn on ones popup blocker but naturally this will not work when the resource is to open in the same window.

When I click 'Save Changes' after choosing a file to link to, I want to be returned to the course page - not stay on the editing page. This behaviour is very confusing for staff learning Moodle because it is not consistent with the behaviour of other 'Save Changes'-type buttons in Moodle. It is also a big time-waster.

This issue is not "minor". Instructors are VERYconfused by the forced preview and end up adding the same resources repeatedly as there is no indication that the resource has been added.

Just adding noice: I too find that I always have to explain what happens after the Save button in the resource uploading process.

This is actually on the top 5 list of things I have to hack for my school. Teachers get completely lost and confused by this process. All of the sudden moodle disappears and their window becomes the resource. They go back and reload the same resource. Overall it is a disaster. This behaviour should be modified.

I have never seen an issue that has received so many votes! Why can't someone take ownership of these issues?

The fix is easy (I did it years ago)!

What is the fix?

Well, it depends. It could be a seperate button at the bottom of the page 'Save Changes' and 'Save Changes and Preview', or it could be an administrative option in the module config page.

I could probably post a patch if I get some time, but prob not til after the Moot at Open U next week

It's more of an issue now with 1.8.2 (and perhaps 1.8.3; I haven't tried the update yet) because frames are disabled by default. The old behavior was to redirect the user to framed resource, which was confusing enough. Now, if you upload a file – e.g. a Word document or Excel file – the user is redirected to the file. This has the effect of causing the file to immediately be downloaded to their computer, while leaving them stuck at the Resource screen with no obvious way to know if a) the file was uploaded or b) how to get back to the course page itself.

This behavior caused havoc among our users, and I was forced to turn frames back on to get around it in the short term.

The default preview is indeed an extremely confusing element to the uploading and assigning of resources. Further I can think of no possible reason any instructor would want to "preview" a document AFTER they have posted it as a resource. The "Files" area already allows instructors to open a document (without assigning it to a resource) by clicking on the file name if they wish to preview the document BEFORE assigning it to a resource area. The fact that they click on "Choose" (instead of the file name itself) logically assumes that they know which document they are adding.

We mitigated this problem by changing the default from "same window" to "new window". This does not solve the problem but makes it more manageable as users are at least able to continue to navigate the site.

Nicolas, can you please implement a new button on the form for adding/editing a resource so that there are two options:

[Save and return to course] [Save and display]

I've actually traced this back quite a few levels in the code and it would require some modification going up into the moodle code, not just in the resource module.

The only way I know of to have 2 submit buttons that do different things it to compare the value in the returned by the button, but I was curious if this would be cross language reliable. IE:

In mod/resource/mod_form.php, just before $this->add_action_buttons(); you could add:
$mform->addElement('submit', 'submitbutton', get_string(savechangesandreturn));

The problem later on is you have to do:

if ($fromform->submitbutton == get_string(savechanges)) {
//save changes and preview
} else {
//save changes and return to course.
}

The question is, can you reliably compare the submitted value for the button against the string in get_string. I know it should work for latin languages, but I'm not clear if it will work in other languages reliably.

Is there some other way of doing this (that doesn't completely rely on javascript) that Im missing?

This would actually be easier to add for ALL activity modules at the same time.

I think we could extend add_action_buttons in moodleform_mod in course/moodleform_mod.php to add that extra submit button.

$mform->addElement('submit', 'submitbutton2', get_string(savechangesandreturn));

Note the different element name (submitbutton2). IIRC only the value for the submit button you clicked gets sent (ie submitbutton OR submitbutton2)

And then in modedit.php where it has

redirect("$CFG->wwwroot/mod/$module->name/view.php?id=$fromform->coursemodule");

make it check for the two different submit values and if !empty(submitbutton2) go to the course page instead.

Something like that. Go Nicolas.

I'm not sure why this has been upgraded to a blocker, but anyway it's fixed now

Because it has 33 votes.

Looks great. Nice job Nicolas!

Thanks for the fix, this will be a huge usability improvement for our faculty!

Will this be back-ported to the 1.8.x tree?

I'll second that request for a backport to 1.8.x.; this issue causes no end to confusion among faculty. We worked around it by turning frames support back on, but that's not an ideal solution.

Fix back-ported to 1.8.5!

Tested on 1.9beta4. Verified, closing.

Very useful. Many thanks for the fix.

In Moodle1.8.4+ (2008/02/02), this function does not run normally. After pushing "submitbutton", "submitbutton2", the web page become blank page.

In course/modedit.php (Moodle1.8.4+), Line15, 16,
$submitbutton = optional_param('submitbutton', null, PARAM_ALPHANUM);
$submitbutton2 = optional_param('submitbutton2', null, PARAM_ALPHANUM);
These variables are going to return null, since "method" of <FORM> is POST.

Please try following codes;

// if ($submitbutton) {
if (!empty($fromform->submitbutton)) { redirect("$CFG->wwwroot/mod/$module->name/view.php?id=$fromform->coursemodule"); // } elseif ($submitbutton2) {
} elseif (!empty($fromform->submitbutton2)) { redirect("$CFG->wwwroot/course/view.php?id=$course->id"); // }
} else redirect("$CFG->wwwroot/course/view.php?id=$course->id"); // (ADD)
exit;

Reopening per last comment.

Here are the buttons with and without the word changes

I like this new feature, but because of the size of the buttons, it causes the buttons to go on two lines (see top of screenshot) and it appears sloppy. I have removed the word "changes :from the two buttons and I don't think that it causes any problem with understanding but keeps them on one line. Hopefully other translations would be similar. I would recommend this change.

Removed "changes" from the 2 buttons, and applied the patch

I am not sure I agree with the latest change suggested by Tatsuya (and committed to CVS).

optional_param does accept input of type POST or GET.

This code would seem to mask a different problem and perhaps introduce new ones (like what happens when you go back in the browser). The existing code does work in other installations. And even if I am misunderstanding the issue, it can be simplified to just go to course/view.php if $fromform->submitbutton is not true.

I would suggest that this be kept open until there is consensus on this.

OK Gary, I will keep this open a while longer. Thanks for your feedback.

Thanks. I can only speculate as to why Tatsuya might have a blank screen issue, although I have seen this type of thing with php script caches are not working right, and perhaps code changes without restarting could cause this if he is used a cache.

Note the cleaning of optional_params does and that this is not happening in the proposed code.

Hi Gary!
I did not understand that optional_param() does accept input of type POST too. Now, I understand. Thanks!

But both of $submitbutton and $submitbutton2 are null in Japanese environment.
I guess why both variables become null, the cause of this is $submitbutton/2 are clean_param() by PARAM_ALPHANUM. In japanese environment, value of $_POST['submitbutton'] is "???????????"(Non ALPHANUM characters!). Then, all characters are cleaned up -> null.

Maybe, it will be ok, by changing 3rd parameter of optional_param(); PARAM_ALPHANUM to PARAM_RAW.

Now I'm in home. I can not try this.
Next morning I will try and report here.

Good morning!
I've confirmed that both buttons work normally in Japanese environment by changing PARAM_ALPHANUM to PARAM_MULTILANG and PARAM_RAW. After changing PARAM_ALPHANUM, a return value of $submitbutton and $$submitbutton2 becomes not null.
I think PARAM_MULTILANG is better than PARAM_RAW with an eye to the future.

if ($submitbutton) { redirect("$CFG->wwwroot/mod/$module->name/view.php?id=$fromform->coursemodule"); } elseif ($submitbutton2) { redirect("$CFG->wwwroot/course/view.php?id=$course->id"); // }
} else redirect("$CFG->wwwroot/course/view.php?id=$course->id"); // (ADD)
exit;

I think that if-elseif-"else" needs for safety, too.

Nicolas, currently the code is checking $fromform->submitbutton (which is part of the form and since a PARAM_TYPE is not specified it is using some default). BTW, I did quick clean up of the logic just now (removed the elseif).

Can you please:

1) Remove the optional_param stuff from the top of modedit.php for $submitbutton and $submitbutton2 because they are no longer used.
2) Explicitly set the PARAM types for the submit buttons to be PARAM_RAW to make it work consistently with all languages (it's safe since we aren't actually using the value, just checking for non-null).

Actually, why are we checking the contents of the buttons at all ... can't we just check for isset($fromform->submitbutton) ?

Removed the optional_param lines at the top, and set the submit buttons to PARAM_RAW. Also changed !empty() to isset();

Please confirm that the multilang issue is resolved.

Tatsuya, can you confirm that this works in japanese too?

Download latest Moodle1.8.4+ now, and confirm that it works fine in Japanese.
Thanks, nicolas!

Verified, closing. Thank to all.

Thanks for this fix - this is going to make life a LOT easier

I know its pedantic, but could the order of the buttons be reversed so that 'save and return to course' is the first one, i.e. the one on the left? For novice users, that is where they are most likely to click, not knowing the difference between them, and although I know the functions are written on them, I have also done a lot of training before and suspect that people will still do this.

Thanks for the suggestion Matt. It doesn't sound pedantic to me at all, however, I would prefer if some usability testing was the deciding factor on this small issue. The reason I am a bit reluctant is that the "Save and display" button has been the default behaviour since 1.7 (or maybe earlier). This was the main reason I put it first.

Hi, Nicolas and Matt.
I understand that "Save and Display" is a very good function!
Sometimes I use this, however most of the time I use "Save and return to course".

I propose two ideas;
(1) Save and [Display] [return to course] : not so good...
(2) [Save and return] [x] Display

In second idea, [x] means check box. In default this is unchecked.

I don't agree with the checkbox idea, sorry Tatsuya.

But I do agree with Matt that the course button should go on the left, it naturally fits with the idea of the breadcrumb navigation (and browser navigation) in that left is "go back" to the course and right is "go forward".

I've fixed this in 1.9.

Thanks Martin! No problem.
I also agree with Matt.
"go back" and "go forward" is a good reason.