Search · Index

Site Wide Image Upload Widget

MGH and Solution Grove are collaborating on a new image upload widget that will hopefully be easier to use and more easily integrated into any Xinha text element. 

Here is how it will work. The user will be editing the content of an object using a rich text editor (XINHA). If they decide an image or reference to a file is needed in the content, they can click the attach-file or attach-image icon.  A popup window appears allowing the user to choose a file to upload. The file is uploaded and stored in the content repository. If it is an image a thumbnail will be generated and linked to the full size image. When the content of the object is saved, the content is scanned for references to files or images, and a link is stored in the database that the particular object is "using" a file or image. This is the simplest case. Some more complex cases include allowing the user to search or browse images they have previously uploaded in a popup window to choose and image to insert.
  Insert_Image.jpg

The use case we are trying to solve:

  • In assessment, right now an admin can associate one file or image with a question. The admin can already enter HTML for the question description. We need to allow image upload from Xinha so the admin can add an arbitraty number of images to one question description. We need this functionality in any richtext widget within the assessment creation process. 

 Requirements:

  • upload image without thinking about where it will go, just entry optional title, description and choose a file from your Desktop
  • image will have parent_id=package_id where its created.   if an object is used in multiple pages, we will keep track of that and let the owner see where it is used. We'll need to write a parser to extract /image/ url links. (DONE uses application_data_link feature from acs-tcl)
  • image will inherit permissions depedning on the setting of the user. In general it'll inherit from the package_id or the subsite where its created.
    • To avoid namespace conflicts we can do someting like this for the cr_items.name
        • cr_items.name = '{$item_id} {$filename}' or automatically rename the item filename(1) (2)...  (DONE, we strip the item id on display)
    • Image may be "private" which means it does not inherit permissions from any other object. This means the only person who can see it is the owner. If the image is uploaded within the context of another object, ie Xowiki page, a link is created between the page and the image. If someone has permission to view he page, they can also see the image. We make this work by creating a special URL /image/${image_id}/private/${xowiki_page_id}/${filename} This generated a unique URL that includes the "viewing context". When this URL is accessed 1) the system is checked to make sure a data link exists, that is, that the image is used "in" the viewing context object, and that the viewing user has permission to see the viewing context object.

  • User uploading image will be granted direct "admin" permission over the image  DONE
  • images will have a centralized URL for delivery, ie: an acs-subsite/www/images.vuh similar to o.vuh so urls will appear to be /images/${item_id}/image-filename.jpg (for example)  (Thanks to gustaf to notice the obvious namespace conflict with just using filename)  DONE
  • images are stored as image type in the content repository (stored with "file" storage type) DONE
  • thumbnails will be generated (propose to use the image-magick package, I have some code to contribute that will process an image upload and generate a thumbnail (this will be disabled if image-magick package is not installed) 
    • A new image thumbnail API is DONE

Once we have this in place, we have a simple, site-wide solution to upload image attachments to any object. This can be used in places like forums etc, and solves the problem of figuring out how to configure each Xinha widget in every package to find a place to store images.  By attaching the image directly to the object we solve the issue of finding a place to store images.


Future Ideas

These ideas are not planned for an initial implementation, but definitely are on our TODO list

  • Add a UI to browse images you uploaded
  • Add a UI to allow users to browse any images they can read?
  • Add a way to search metadata on images when choosing an image so when you choose the add image button in Xinha, it will allow you to search existing images you have uploaded
  • Add a recently viewed/uploaded feature to the image picker, so you can choose an image you recently viewed or uploaded without searching for it
    • Here is an example of what that could look like (actual working code exists for this now)

  • Add a clipboard feature to the image picker, so you can use the optional clipboard package to mark an image in your clipboard while viewing it, then choose it from the clipboard to insert a link into another object. 

 




 

previous October 2017
Sun Mon Tue Wed Thu Fri Sat
1 (1) 2 3 4 (1) 5 6 7
8 9 10 (1) 11 12 13 14
15 16 (1) 17 18 (3) 19 (2) 20 21
22 23 24 25 26 27 28
29 30 31 1 2 3 4

Popular tags

17 , 5.9.0 , 5.9.1 , ad_form , ADP , ajax , aolserver , asynchronous , bgdelivery , bootstrap , bugtracker , CentOS , COMET , CSP , CSRF , cvs , debian , emacs , engineering-standards , fedora , FreeBSD , guidelines , host-node-map , hstore , includelets , install , installation , installers , install-ns , javascript
No registered users in community xowiki
in last 30 minutes
Contributors

OpenACS.org