Forum OpenACS Development: Re: xowiki javascript "function calc_image_tags_to_wiki_image_links" doesn't do what you'd expect...

Hi Richard,

you are most likely referring to the xowikiimage plugin for ckeditor. Images are not necessarily stored as children of a page (this is the case e.g. for Photo.form) but in classical wiki-setup these are stored in the same directory as text pages, often, these are stored in a separate image folder. The most sensible change would be to provide a parameter for the parent-folder.

all the best
-gustaf neumann


In that case I am a little confused because the images I have uploaded using xowikiimage on a system with folder features switched off are appearing in ::xowiki::Files named like this:


....and they are not being correctly referenced by the inserted wiki link.


I have fixed the wiki_link references on my system so that they point to the images uploaded using xowikiimages by adding :

window.location.pathname.split('/').splice(-1) + '/' +

to the javascript function that generates the wiki_links as follows:

function calc_image_tags_to_wiki_image_links (form) {
    var calc = function() {
      var wiki_link = window.location.pathname.split('/').splice(-1) + '/' + $(this).attr('alt');

This is in:

richtext::ckeditor instproc js_image_helper

The image links now work and display the uploaded image when the page is viewed.


....and I have also had to modify the following lines of the calc_wiki_image_links_to_image_tags function that converts the [[my_page/image:my_photo_ext]] link back into an <img> tag so that the editor window can retrieve and display the image in WSIWYG fashion:

    var regex_wikilink = new RegExp('(\\[\\[.*/image:)(.*)(\\]\\])', 'g');
    data = data.replace(regex_wikilink,'<img src="'+pathname+'/file:$2?m=download"  alt="image:$2" type="wikilink"  />');

In context the complete function with adjusted lines is:

function calc_wiki_image_links_to_image_tags (data) {
    var pathname = window.location.pathname;
    pathname = pathname.substr(pathname.lastIndexOf("/")+1,pathname.length)
    console.log('pathname' + pathname);
    pathname = pathname.replace(/:/ig,"%3a");
    var regex_wikilink = new RegExp('(\\[\\[.*/image:)(.*)(\\]\\])', 'g');
    data = data.replace(regex_wikilink,'<img src="'+pathname+'/file:$2?m=download"  alt="image:$2" type="wikilink"  />');
    console.log('data' + data);
    return data

It was as if someone had modified the code to create filenames with the page name prefixed to them, but did not adjust the javascript helper functions to match.

It is certainly very helpful that the xowikiimage selector/uploader only displays images that have been uploaded for the specific page you are working on.  Otherwise the number of images in the selector would rapidly become unmanageable.  It may simply be that the Javascript functions were not updated after this refinement was added.


Posted by Richard Hamilton on

Even after my changes to the helper functions, there still seem to be some issues that arise with uploaded file naming using xowikiimage. The most obvious one is that if you create a new instance of a formPage, and immediately upload an image to it, the image is stored in xowiki::Files with the numeric instance id as part of its filename like this:


When you submit the form after completing the '_name' field, any image names will no longer reference the uploaded images, and so the links don't work.

If all images are placed in the xowiki instance root, then you have problems with file organisation and potential for naming collisions.


You want to create a record/info card for 1000 cities. Every city will have a consistent set of five image files. When editing a record card, you only want the image browser to offer you a selection of the images that were uploaded for that page/city. You don't want to have to think about where the images are stored. You don't want any chance of images for different cities to become mixed up, even if they have identical names.

The various solutions:

1) If you store the images loose in the root there are problems of organisation/access/naming.

2) If you create names that have the parent formpage '_name' field pre-pended (as currently), you have problems with broken references in the ckeditor box whenever the formpage _name is updated and on initial formpage creation.

3) If the images were to be stored in folders, you'd need to activate the folder procs, and create a folder. you'd still have the problem that if the parent formPage '_name' is changed, the folder name would then not match up, and the ckeditor box links would fail.

4) If the images could be stored as children of the formPage, then they would remain related to their page regardless of the contents of the '_name' field, they would not need a pre-prended parent name or id (which could change later) because the relationships would be structural and independent of data content. There would be no requirement for maintaining textual link integrity because the images could instead be retrieved based upon their parent-child connection with the formPage they belong to.

Is this a feasible modification? Could a mixin class be used to create formPages that had the properties of photo_form for this purpose?

If so, scenario four would seem to hint at a fantastically powerful means to store and organise enormous numbers of uploaded and included content in a way that would be very easy to use.

Any images that were for general use outside individual pages could still be uploaded in the normal way to xowiki::Files and referenced manually.

What do you think?