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

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

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).replaceWith('[['+wiki_link+']]');
    }

This is in:

richtext::ckeditor instproc js_image_helper

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

Regards
Richard

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:

3042/my_image_ext

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.

Use-case:

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?

Regards
Richard