04 April 2014, 3:36

Mahara users at my institution were getting into a tangle trying to embed images into forum posts, by copying image urls into the tinymce editor's image dialogue. This seems to go wrong as often as not for someone without any tech expertise, and it means that the image has to be up on the web somewhere already.

I also found that the option to embed an attached image, as implemented in blog posts, was not intuitive to users at all.

After some hair-tearing I managed to add a 'Browse' option to the tinymce image dialogue which allows users to select images from their Mahara file area, or upload an image to embed. Here's an example, from the editing of a forum post:

I set blog posts to work in the same way instead of using attached images.

One problem is that with this approach you can end up with a stack of popups. For example, if embedding an image in a text box in a Page, you will have 3 popups on top of each other - the text editor popup, the tinymce image dialogue, and the custom imagebrowser dialogue.

Any other suggestions how this should work? Any feedback welcome before I roll this out to users here.

I think it is really useful functionality in any case - makes the forums and blogs much more useable and makes it possible to have text wrapping round images in pages.

04 April 2014, 4:04

Hi Mike,

You're not the first to work on the image selection in the tinymce editor. You should have a look at https://bugs.launchpad.net/mahara/+bug/1235569 

There was also an update on the tinymce editor that's going to get merged into version 1.10 (also linked from the patch, that's referenced in the bug report): 

https://reviews.mahara.org/#/c/3030/

Cheers

Tobias

04 April 2014, 5:57

Hi Tobias, thanks, I'll look into that. At first glance it looks like the approach is to have the 'embed attached image' feature available throughout Mahara? I was looking for an alternative approach as that doesn't seem to be intuitive enough for our users.

Perhaps the new version of tinymce will also bring new options.

Mike

04 April 2014, 11:04

Also have a look at https://bugs.launchpad.net/mahara/+bug/1038580

This issue was brought up by me at the last developer meeting. The core developer team agreed they'll look into it by nex developer meeting which is scheduled at 1 May 2014. Please see Developer Meetings info (Agenda of 31st meeting and exact date and time of the 32nd meeting): https://wiki.mahara.org/index.php/Developer_Area/Developer_Meetings

HTH, G

04 April 2014, 23:36

OK - if I have a feasible looking solution before then I will upload it to the review site so that it can be included as an option in the discussion on the 1st May.

Best wishes,

Mike

04 April 2014, 9:07

Thinking about this, it would probably be improved by just opening the custom image browser directly when clicking on the image icon, instead of having the initial tinymce image popup...
It could have the tinymce fields like alignment, width, etc. at the top of the image browser.

04 April 2014, 11:53

Yeah, that would probably be the way to do it.

You also need to take into account permissions. An image is not currently viewable on its own unless it's embedded in a Page that the user has access to see. (On mahara.org when I want to put an image in the forums, I put it into a special "Files for sharing" public page of mine.)

One of the things the Totara Social guys are trying to upstream for Mahara 1.10 is artefact-level permissions, to let artefacts be shared on their own, so that's one possible fix. I guess another way to go, would be something like you keep track, in the database, of which forum posts have which images in them, and then when you call the PHP script that loads up the image, you include the postid as part of the request.

Cheers,

Aaron

04 April 2014, 23:33

Aha, permissions - thanks for pointing that out Aaron.
Back to the drawing board I reckon.

Best wishes,

Mike

07 April 2014, 9:56

Yeah, I think the permissions are the reason why blog posts have the weird "attachments" system they currently have. The idea is that when you set up the attachment, it then stores the images as a "child artefact" of the blog post. And then when we're trying to decide whether a particular user can view that image or not, we check whether the image or any of its parent artefacts, is in a Page that user can view.

So you could do something similar for forum posts. Like, when you're saving the forum post, you scan it to see which images are present, and then you store those in a new table (forum_post_attachments ?). And then to artefact/file/download.php, you add an option for a "forumpost" parameter, which indicates which forum post the artefact is being viewed as part of. If that's present, you check whether the user can view that forum post, and you check whether the image artefact is "attached" to the forum post.

I probably would not go the route of making all embedded images also show up as "attachments" listed below the forum post, like we do for blog posts. (Though there is a wishlist option for forum attachments, since other forum softwares allow you to attach files.)

Cheers,

Aaron

08 April 2014, 23:40

I just looked into this, and while I was able to open a custom image browser directly from clicking on the image icon in the tinymce editor, there were some issues to resolve around the json-type forms used by the Mahara file browser, because tinymce 3.x puts the popup window into an iframe. (If you use the tinymce API, that is. This could just be bypassed, I guess...) This introduces various problems with javascript scope.

This changes with tinymce 4.x, which creates a div element instead of an iframe for poupups.

With tinymce 4.x it should be easier to reuse existing Mahara file browser methods for a custom popup. It should be pretty quick to deploy the code I've already put together in fact. If an update to tinymce 4 is imminent then there is no point in trying to get this working with tinymce 3.x. (Though I might try to just bypass the tinymce 3.x API in the meantime. If I do that I will also explore the permissions issue.)

Bw,

Mike