Moodle

Related, files cannot be uploaded at the Attachments page either.

For after 1.9 Beta...

Martin did you mean that it was fixed in 1.9 beta already? Just double check

I tried this from 1.5.4+ to 1.9 beta, their behavior are all the same. There are at least three things need to be fixed:

Set up wiki in course with allow binary files set to yes:

1. If you upload an image file (within the file size limit), then it will give you a URL but wouldn't tell you any useful information that now the uploaded file is available in the "Attachment" tab in wiki. The text need to be changed to be more user-friendly. (see attachment)

2. If the file was uploaded successfully, somehow it would break our theme color (see attachment)

3. If the file was too big (exceed the file size limit, which is NOT configurable), then it would just throw out a blank screen

4. A help button next to the "Browse" "Upload" buttons probably would be a good idea, to specify what "binary" file types are supported, what are NOT, and what the upload file size limit is.

If Yu is busy working on something else I could volunteer to work on this ticket..

Wen, that would be terrific, thank you. Keep us up to date here.

I actually can't get it to work after a quick look.

Uploading from the Edit page makes the attachment go to the "main" section, and if you click on the attachment tab it's not visible unless you modify the URL to 'attachments/' manually

Uploading at the attachment page only works when I upload to "main", again. This results in the same problem. When trying to upload to this wiki section I get a [[uplrejsec]] error.

This bit of the code seems to fail ($data["content"] seems empty).

if (strlen($sect = $_REQUEST["section"])) {
if ($ewiki_upload_sections[$sect]

stack trace of this call is

Array
(
[0] => Array
(
[file] => /var/www/18stable/mod/wiki/ewiki/ewiki.php
[line] => 582
[function] => ewiki_action_attachments
[args] => Array
(
[0] => dsf
[1] => Array
(
[id] => dsf
[version] =>
)

[2] => attachments
)

)

[1] => Array
(
[file] => /var/www/18stable/mod/wiki/view.php
[line] => 247
[function] => ewiki_page
[args] => Array
(
[0] => attachments/dsf
)

)

)

I didn't get much further than this.

Wen, were you going to work on this?

Wen, do you have time?

Hi Martin, as much as I really want to help with this but this is currently not our priority now. Our priority now is to make sure course-level backup/restore really works for LARGE COURSES for archive purposes (the backup need to include GBPv2 graded events, etc.)... If you or Yu could help with this one that would be great! Thanks!

Hi: When this issue is revisited, one thing to make sure is that the image ALT tag remains available for the blind. Currently, in order to insert an image in a wiki page, you need to enclose the full URL in brackets like this:

http://path/in/moodle/to/image.jpg

While this convention will display an image, it does not allow for ALT tags.

Hi: If this would help to explain the issue, we have posted a video on the process of adding images to wiki pages:

http://ccle.ucla.edu/mod/resource/view.php?id=18280

Hi James, I went through the video and followed through step-by-step and tested it on both PC and Mac using moodle 1.8.2, 1.8.4+, and 1.9, but I couldn't reproduce the exact same behavior that you were experiencing. I believe that UCLA is using 1.8.2, correct? Are you still experiencing the problem that you recorded in the video?

For this ticket, Ray Lawrence was actually describing another issue, which happen only when you enable the "Allow binary files" option. So if you are still experiencing the image problem you might want to check the permission setting on your server or create another ticket as this should be separate issues. Thanks!

Hi Wen Hao,

You are correct, and I knew that I was cheating and my "tack-on" was an entirely different issue. Do you have any tips on finding existing Tracker tickets for such broad terms as "image, URL" etc? It's maddening trying to pre-filter your Tracker searches to make sure you're not duplicating someone else's ticket.

But thanks; I'll open a different ticket and see if I can find a clearer way of presenting the issue.

Best regards,

Jim

OK, I spent couple of hours to really dig into this issue, I think I found the source of this problem.

The key really is in ewiki, when you try to create or update a wiki page and click on the "Show Advanced" button, then you are given the option of "Allow binary files." The default is "No" but if you set it to "Yes" and then click on "Save and display" button (see Fig1), then you will be giving TWO options to upload such "binary files" (see Fig2). The problem lie on the (2) "Browse" "Upload" GUI. For me the "Attachments" tab works fine, I could upload image files, .zip files, .ppt files as attachment to the wiki without any problem. However, if I use the "Browse" "Upload" GUI to upload stuff, big problems! The upload file size limit is about 70K (the limit is probably hard-coded somewhere as I can't change that through GUI), anything above that file size limit you will get a blank screen (see Fig4). EVEN if your file size is below file size limit, ewiki will display a really ugly dark-red color page (color was hard-coded) showing you (see Fig5) no matter what theme you are using:

Your uploaded file was saved as
[internal://xxxx.png].

So here is what I would propose:

1. I will attach a temporary fix for the Fig5, at least make the message more user-friendly and users would know how to use this [internal://xxxxx.xxx] thing.

2. I would also suggest to hide the "Browse" "Upload" GUI. For me, I think if you want to insert pictures embedded with text page you could use the HTML editor to do so (see Jim's video mentioned above). And for "other" type of binary files that would be served as "attachment", the "Attachment" tab seems to be sufficient. I don't think the "Browse" "Upload" GUI is really necessary here (especially that there is no help button about this regarding file size limit and you can't change the file size limit, and the fixed file size limit is only around 50K or so). What do people think?

If people agree I could go ahead to propose 2nd patch later which will hide the "Browse" "Upload" GUI. Let me know what you think. Thanks!

temporary fix (to make it more usable)?

I am using Moodle 1.9 and am experiencing the same problems.
I set the wiki to be able to upload binay files and here's what happens:
1) uploading a 62 KB jpeg. file it shows a pop up screen with the internal path, but when I go to the Attachments tab, I get the message that no files were uploaded yet;
2) uploading a hotpotatoes quiz (7 KB) from the attachments tab, sometimes (same file, same page) it works, and sometimes it shows a reject error in brackets;
3) after uploading the attachments correctly, I still get the message that no files were attached to the page!

I checked and all the attachments are saved on the course files folder.

It would appear that using method 2 (see figure 2 above) does not upload to the attachments page, but rather makes the file available to insert on an edited page via the [internal://file_name_here.ext] mechanism. It would be helpful if this was documented better.

What I found that may be helpful to some:
in mod/wiki/ewiki/ewiki.php

• the constant EWIKI_ACCEPT_BINARY needs to be set to 1 if you want to be able to upload anything other than jpg, png, gif and flash
• by default the max binary file size is 64k you can adjust this by editing the constant EWIKI_IMAGE_MAXSIZE, just change the 64 to some larger value i set my to 2 Mb define("EWIKI_IMAGE_MAXSIZE", 2048 *1024);
• the constant EWIKI_IMAGE_ACCEPT contains the type of files that are acceptable as images, BUT, that value is only used for generating the html <input type= file> tag.
• in the function ewiki_binary_save_image() the acceptable mime types are redefined and the constant is not used, you however cant just edit this list to add additional mime types because ewiki tries to determine mimetype by a call to the php function getimagesize(). Since getimagesize() can only work on images, it will not get a mime type for any other file type. This in turn causes an if statement on line 2727 to fail because the mime type cannot be determined.

To summarize:
if you want to allow files other than image files to be uploadable by method 2
define("EWIKI_IMAGE_MAXSIZE", 2048 *1024);
define("EWIKI_ACCEPT_BINARY", 1);

Brandon thanks for the info confirm this resolved the issue for us. However, when I debugged I wondered why these are being set here at all? The hard coded constants in /mod/wiki/ewiki/ewiki.php are setting or resetting constants that should probably be usefully set in /mod/wiki/view/php in the Binary Handling section starting at #181

I would prefer not to have to hard code constants and use Moodle's configuration values where possible.

So I am currently tryingg the following modifications:

1. In the binary handler in /mod/wiki/view.php the constant for Binary Handling look to be incorrect. Here they are EWIKI_ALLOW_BINARY in /mod/wiki/ewiki/ewiki.php they are EWIKI_ACCEPT_BINARY. I changed /mod/wiki/view.php to use EWIKI_ACCEPT_BINARY instead

2. Because EWIKI_ACCEPT_BINARY is in /mod/wiki/ewiki/ewiki.php it then resets the constant to this hard coded value regardless of how the binary handler has set it. So I commented out line #143 in /mod/wiki/ewiki/ewiki.php to allow the binary handler to set this constant.

3. Ewiki seems to use EWIKI_IMAGE_MAXSIZE for every type of file not just images. So #183 in /mod/wiki/view.php define("EWIKI_UPLOAD_MAXSIZE", get_max_upload_file_size()); doesn't seem to help, hence why the hard coded value in /mod/wiki/ewiki/ewiki.php is being used instead. So I added define("EWIKI_UPLOAD_MAXSIZE", get_max_upload_file_size()); to the binary handler in view.php and commented out the hard coded constant in ewiki.php on line #136

This now looks to be correctly allowing the Moodle binary handler to check the wiki setting to determine whether to allow binary files at all, and the Moodle site/course max file upload setting to determine how big the file can be. Also an oversize error message now displays on our setup not just a blank screen (albeit not a very user friendly one). Caveat is I've only tried this on a development install at the moment but am about to move to our test server for further testing.

Hi Alison, your solution make sense and I have tried it but was getting some error messages "Headers already sent" after I login as a instructor and create a wiki page. Have you tested out your solution a little bit more? Do you have a working patch that you could post here for more testing? Thanks!

Wow by the way I just noticed that the wiki 2.x is still not implemented in Moodle 2.0 dev (head)? Seems like 2.0 dev is still using the old ewiki for now? I changed the "Affects versions" to include 2.0 too..

I just encountered this problem in Moodle 1.9.x. While the workaround fixes the immediate issue, and I know ewiki's going away in Moodle 2.0, I think this issue could use some more love. It's a cryptic error based on a hardcoded setting that the end-user has no control over and it's likely that folks are encountering it but never figuring out what the actual problem is.

I also like Alison's new text explaining what to do with the resulting wiki code; it may not be pretty, but it works.

Alison's solution and patch worked fine in my dev instance. Any chance we can get this revisited for the next 1.9 point release?