Forum OpenACS Development: xoWiki and images

Collapse
Posted by Stan Kaufman on
Seems like this should be an easy config, but I can't figure it out. How do you you tell xinha in an xowiki instance which file-storage instance it uses for image uploads?

What I'm trying to do is set up a file-storage instance for each xowiki instance both for the main site as well as for a number of subsites -- ie each subsite has its independent xowiki/file-storage combo so they can be maintained completely separately.

However, what is happening is that the same subsite's file-storage instance is being used by xinha in every xowiki instance. The subsite appears to have been randomly chosen somehow, but the choice persists between server restarts so somehow this file-storage package_id is getting stored somewhere I guess.

The code in /packages/xowiki/www/xinha/file-selector.tcl and insert-image.tcl appear to look for the main site file-storage instance, but it also appears that a different package_id can be passed in somehow. In my case, for whatever reason the main site file-storage instance isn't getting used by any of the xowiki instances.

So how do I specify where xinha/xowiki goes for images?

Also, xinha inserts images using img tags, but this is a security hole that is closed by default. Is there a better way to place images in xowiki pages than this?

Collapse
2: Re: xoWiki and images (response to 1)
Posted by Gustaf Neumann on
I'll try to sum things up.
Firstly, the general part, not specific to xowiki:

file-selector.tcl accepts as optional parameter
- the package id of the file storage fs_package_id, and
- folder_id
it is possible to provide either of these. If non of these are provided, file-selector gets the id from the sitenode (key file-storage)

file-selector is called via insert-image and insert-ilink,
which are called by the OacsFS plugin of xinha. The plugin is configured via the widget spec of the rich text widget (see https://openacs.org/api-doc/proc-view?proc=template%3a%3awidget%3a%3arichtext)

specific for xowiki:

since it is not so easy, the get the braces for the nested lists of the widget spec right, one can use the "folderspec" parameter of the form for editing the xowiki page. See edit.tcl

xowiki first tries to get the shared community folder of the dotlrn community, or it is using the defaults.

actually, i don't see, where one gets a random behavior, but certainly, it is possible to define your own policy in edit.tcl.

Concerning the dangers of the IMG tag: there are three approaches to this: a) restrict in xinha and/or htmlarea tag check, that only local images are used (no external urls); editing the HTML-source in xinha must be disabled.
b) provide an adp-include for images.
c) restrict the users/sites that are allowed to insert images.

hope, this helps.

Collapse
3: Re: Re: xoWiki and images (response to 2)
Posted by Stan Kaufman on
The behavior I noted indeed isn't "random" though it appeared that at first. What's going on is that when there are multiple instances of file-storage in various subsites and the main site, the file-selector.tcl code grabs the first one it finds (because apm_version_id_from_package_key will return all the instances, and then site_node::get_children uses the first one it gets):

if {![info exists fs_package_id]} {
  # we have not filestore package_id. This must be the first call.
  if {[info exists folder_id]} {
    # get package_id from folder_id
    foreach {fs_package_id root_folder_id} \
	[fs::get_folder_package_and_root $folder_id] break
  } else {
    # get package_id from package name
    set key file-storage
    set id [apm_version_id_from_package_key $key]
    set mount_url [site_node::get_children -all -package_key $key -node_id $id]
    array set site_node [site_node::get -url $mount_url]
    set fs_package_id $site_node(package_id)
  }
}

Changing this default behavior could be done in file-selector.tcl, or else one could edit insert-image.tcl to find the subsite's file-storage instance and then pass that into file-selector.tcl -- which is what I decided to do. The following tries to set fs_package_id using a file-storage instance in a subsite, or the file-storage instance in the main site if there's none in the subsite. Here's a cvs diff:

Index: xowiki/www/xinha/insert-image.tcl
===================================================================
RCS file: /cvsroot/openacs-4/packages/xowiki/www/xinha/insert-image.tcl,v
retrieving revision 1.3
diff -u -r1.3 insert-image.tcl
--- xowiki/www/xinha/insert-image.tcl   30 Dec 2005 00:09:58 -0000      1.3
+++ xowiki/www/xinha/insert-image.tcl   30 Jun 2006 19:28:36 -0000
@@ -7,7 +7,19 @@
   {fs_package_id:integer,optional}
   {folder_id:integer,optional}
 }
- 
+# get file-storage instance from this subsite
+set subsite_node [subsite::get_element -element node_id]
+set mount_url [site_node::get_children -package_key file-storage -node_id $subsite_node]
+if { $mount_url eq "" } {
+    # no file-storage instance at this subsite so look to main site
+    set subsite_node [subsite::get_element -subsite_id [subsite::main_site_id] -element node_id]
+    set mount_url [site_node::get_children -package_key file-storage -node_id $subsite_node]
+}
+if { $mount_url ne "" } {
+    # file-storage instance IS at main site
+    array set site_node [site_node::get -url $mount_url]
+    set fs_package_id $site_node(package_id)
+}
 set selector_type "image"
 set file_selector_link [export_vars -base file-selector \
                            {fs_package_id folder_id selector_type}]

If there is no file-storage instance in the main site either, then the default code in file-selector.tcl will use the first one it finds -- or generate a server error if there is no file-storage mounted at all, but presumably this shouldn't happen in a real site.

I can commit this if you approve, Gustaf, or if there's a better way, I'd like to see it.

Thanks for your help with your brilliant package, Gustaf!

Collapse
Posted by Gustaf Neumann on
Stan, the same problem with images and subsites happens with link to files. therefore it is better to put this code into the file-selector. secondly, if someone passes explicit a folder_id or a fs_package_id, the search is not needed and is actually wrong since it can overwrite the specified value. I would put the your added code to file-selector in the section called now "get package_id from package name".

Do you see arguments against this?
-gustaf

Collapse
Posted by Stan Kaufman on
Gustaf, excellent point; I hadn't checked how file linking works. What do you think of this:

Index: xowiki/www/xinha/file-selector.tcl
===================================================================
RCS file: /cvsroot/openacs-4/packages/xowiki/www/xinha/file-selector.tcl,v
retrieving revision 1.3
diff -u -r1.3 file-selector.tcl
--- xowiki/www/xinha/file-selector.tcl  30 Dec 2005 00:09:58 -0000      1.3
+++ xowiki/www/xinha/file-selector.tcl  30 Jun 2006 22:45:48 -0000
@@ -20,10 +20,26 @@
   } else {
     # get package_id from package name
     set key file-storage
-    set id [apm_version_id_from_package_key $key]
-    set mount_url [site_node::get_children -all -package_key $key -node_id $id]
-    array set site_node [site_node::get -url $mount_url]
-    set fs_package_id $site_node(package_id)
+    # get file-storage instance from this subsite
+    set subsite_node [subsite::get_element -element node_id]
+    set mount_url [site_node::get_children -package_key $key -node_id $subsite_node]
+    if { $mount_url eq "" } {
+        # no file-storage instance at this subsite so look to main site
+        set subsite_node [subsite::get_element -subsite_id [subsite::main_site_id] -element node_id]
+        set mount_url [site_node::get_children -package_key file-storage -node_id $subsite_node]
+    }
+    if { $mount_url ne "" } {
+        # file-storage instance IS at main site
+        array set site_node [site_node::get -url $mount_url]
+        set fs_package_id $site_node(package_id)
+    } else {
+        # look for any file-storage instance
+        # probably not what user wants; could return error instead
+        set id [apm_version_id_from_package_key $key]
+        set mount_url [site_node::get_children -all -package_key $key -node_id $id]
+        array set site_node [site_node::get -url $mount_url]
+        set fs_package_id $site_node(package_id)
+    }
   }
 }

If that looks OK, let me know and I can commit it. Thanks again!

Collapse
6: Re: xoWiki and images (response to 1)
Posted by Gustaf Neumann on
Looks good! thanks as well, and please commit it.
-gustaf
Collapse
7: Re: Re: xoWiki and images (response to 6)
Posted by Stan Kaufman on
Gustaf, I've committed it. I also added xoWiki to the list of packages.
Collapse
8: Re: xoWiki and images (response to 1)
Posted by Deds Castillo on
Solution Grove provides subsites for clients on http://www.solutiongrove.com and we needed to tie up with a per client instance as well. The thing is that we do not use xinha exclusively for xowiki and also use it for say forums, etc.

What I ended up doing on SG site is to pass in source_package_id as a xinha_option in richtext-procs.tcl and use that in OacsFs.js so that its propagated up to the point of file-selector.tcl in xowiki. That in turn would allow to query for a parameter, say FSPackageID specific to each package as we have the source_package_id on where xinha is being called.

In file-selector.tcl, That has priority over all fs instances assuming none was passed. We are also able to add in more package parameters like in most of SG clients's cases, UseLRNFs or UseFOLIOFs if .lrn or dotfolio is installed respectively.

It's generic enough for Solution Grove's roster of clients but I don't know if it will be generic enough for everyone else. Just posting here so that one would know where to get the code if one needs the same functionality.

Collapse
9: Re: Re: xoWiki and images (response to 8)
Posted by Orzenil Silva Junior on
Hi,

Deds, could SG share this code? We have a similar scenario here: people would like to use OacsFS xinha plugin in the dotlrn forums and access shared community folder from wyswyg editor.

Thank you.

Collapse
Posted by Deds Castillo on
Orzenil, sure. I'll create a diff of the affected files, tar it up and post it on a publicly accessible page in SG. I'll post here again on the location when I'm done.
Collapse
Posted by Orzenil Silva Junior on
Hi Deds,

Thank you for share. I followed up instructions you pointed and everything works well.

I think SG approach in this topic was very good providing several options to use xinha OacsFs plugin. We choose add XinhaFileStoragePackageID to forum package so we could now set the community/class file-storage package intance for store files/images and referring them inside forums. Great! A very attractive way to replace attachments package in forums.

Collapse
Posted by Gustaf Neumann on
I am not to happy with this patch. do i see correctly, that it requires package ids to be specified as parameters? There must be better ways to do this. the resolver logic is way to complex for me and has hard coded names in it. There must be better ways for achieving this. The current implementation allows a per-form configuration of folders (not only package ids). The widget code should be able to derive the folder id from parameters and default values and pass it around. If the folder is specified via parameter, it should be specified via the URL such a user can do a cut&paste...
Collapse
Posted by Deds Castillo on
Gustaf, this is just one way I scratched the itch and I'm not happy with it as well from a generic reusable kind of way that's why I mentioned I did it internally for SG and just have the code lying around if someone needs the same. 😊

I do admit it's not pretty at this point but we just needed something real quick that deviates from the default implementation. It just attempts to do more on the resolver but the code is backwards compatible with current implementation such that everything can still be passed by URL and folder ids are still supported. The package ids are not required to be specified as parameter but just an option that I check precedence-wise.

We also have several clients who use .lrn and .folio and we needed to support both with a single patch that's why the resolver looks complex. The only actual hard code on the resolver in the strict sense is the check on a mounted /xowiki which is already being mounted on install.

If you have implementations that achieve similar functionality lying around feel free to commit 😉 and we're sure to pull it. 😊

Collapse
15: Re: xoWiki and images (response to 1)
Posted by Dave Bauer on
The best option and simplest to implement, is to allow upload of an image and to associate the image directly to the object being edited.

The way I have been doing this lately is to add the image to the content repository and then set the parent_id of the cr_item for the image to the object being edited.

This is much simpler than trying to guess which file storage instance to use. I guess the only issue would be defining a URL for this type of image. We could use the /o/ object redirector for this.

Collapse
Posted by Gustaf Neumann on
i was considering something like this for xowiki itself, to allow e.g. wikipdeia style names withing the wiki folders (like image:dave.png). From the datamodel is see that parent_ids of item_ids are just acs_objects, therefore, also a forum message should be fine. in some cases it is useful to associate an image (file) with an object, in some cases it is useful to associate it with a folder (in the xowiki case: one might like to use the image in multiple pages, or not to erase it, when the page containing it is removed)... the file selector will only be used when a folder is specified, otherwise the uploaded content could be directly associated with the object_id.... this is certainly interesting to think about this in more detail.