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

When you use the xiwkiimage uploader to upload and then insert an image into an ::xowiki::formField of type editor=ckeditor, there is one Javascript function that creates an image tag to ensure that the image is displayed in the editor window, and another Javascript function that creates the "wiki link" to be stored in the database.

At the moment the "wiki link" generated for the db looks like this:

[[image:my_picture.jpg]]

...which is no good because the image is stored as a child of the page, and so the link should look like this:

[[my_page/image:my_picture.jpg]]

I can modify the Javascript and submit a patch, but I wanted to check first in case this work has already been done elsewhere, since it seems strange that this could evolve without anyone noticing.

Regards
Richard

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

Gustaf,

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:

en:my_page/my_image_ext

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

R.

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).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

....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.

Regards
Richard

Collapse
Posted by Richard Hamilton on
Gustaf,

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

First of all, the ckeditor plugin "xowikiimage" is not configured by default. One can only find it by reading through the source code. This plugin was developed in a different code-base, and never resolved the paths for standard xowiki correctly.

You are right in your diagnosis, hard-coding the name is no solution, entries might be renamed, etc. I'll look into the problem and provide a patch.

best regards
-gustaf neumann

Gustaf,

A couple of other points that might be helpful.

1) I wondered, if I used the definition code for en:photo_form as a boilerplate and added some other custom fields, perhaps the code you previously wrote to support photo carousels might be leveraged here to populate the image selection dialog?

2) CKEditor version 4 does not need the JQuery adapter. It has its own support for in-line (i.e. inplace=true) editing without depending on Jquery, and it has its own support for creating dialog boxes without requiring Jquery-UI. I was therefore going to have a bash at converting the xowikiimage plugin and related ajax code to run on the back of a native CKEditor v4 dialog.

I am more than happy to put time towards anything I can helpfully do.

Regards & thanks,
Richard

The new xowiki version in cvs head address these problems. In particular, xowiki supports now item-refs (references to other xowiki pages, written e.g. in the wiki links) which are able to address child-items of the current item. In particular, one can now refer to a child item via prefix ".SELF./" ("./" refers to the current directory, "../" to the parent directory, "SELF" alone could conflict with a page name, the leading "." reduces this likelihood). The plugin is adjusted accordingly.

Regarding carousel etc. as image selector: the used image selector allows upload and selection, while a typical carousel code does not provide this. So, in principle, the question boils down how to integrate this with a js selector. When just child-items are used, a carousel seems as a overhead. However, it would be nice to extend the xowikiimage to allow the configuration of other image directories.

all the best
-gustaf neumann

Gustaf,

I have done a clean install (everything HEAD) and tried it out.  That's absolutely fantastic.  How on earth do you do things like that so quickly?  Thank you very much indeed.

😊

I see what you mean about extending to allow configuration of other image directories.  Yes, this would be good, though certainly not a necessity.  In point of fact, I did not mean to suggest using a carousel as an image selector.  I was just thinking about which bits of existing code I might be able to re-factor or re-use to do what you have done today.  I think the existing selector is wonderful as it is!

A couple of bits of housekeeping info I uncovered along the way in case it helps anyone:

- I initially tried using the new HEAD co of xowiki with oacs5-7 Core and the absent parent_id error mentioned earlier was thrown by 'ckeditor-images/upload_image.tcl'.  Presumably this reflects a change in oacs-core (perhaps some change to ad_page_contract or something) since the solution is to use a head co of oacs-core.  I agree probably not worth trying to fix for oacs5.7.

- There are some ds-comment statements in the ckeditor-images tcl pages.  Developer support is not set as a dependency so this will throw errors intially.  The solution of course is to either co and install acs-developer-support, or comment out the ds_comment statements.

- I have noticed that the 'list' method of my demo xowiki::Form is creating some Javascript errors.  Probably just a missing ';' somewhere causing amongst other things, yui-dom-event.js not to load.  I will have a look for this and report back.

SEC7113: CSS was ignored due to mime type mismatch
reset-fonts-grids.css
SEC7113: CSS was ignored due to mime type mismatch
base.css
SEC7113: CSS was ignored due to mime type mismatch
container.css
SEC7113: CSS was ignored due to mime type mismatch
datatable.css
SEC7113: CSS was ignored due to mime type mismatch
button.css
SEC7113: CSS was ignored due to mime type mismatch
skin.css
SEC7113: CSS was ignored due to mime type mismatch
menu.css
SCRIPT1004: Expected ';'
yahoo-dom-event.js, line 1 character 6
SCRIPT1004: Expected ';'
utilities.js, line 1 character 6
SCRIPT1004: Expected ';'
container-min.js, line 1 character 6
SCRIPT1004: Expected ';'
treeview-min.js, line 1 character 6
SCRIPT1004: Expected ';'
button-min.js, line 1 character 6
SCRIPT1004: Expected ';'
menu-min.js, line 1 character 6
SCRIPT1004: Expected ';'
datasource-min.js, line 1 character 6
SCRIPT1004: Expected ';'
autocomplete-min.js, line 1 character 6
SCRIPT1004: Expected ';'
datatable-min.js, line 1 character 6
SCRIPT1004: Expected ';'
selector-min.js, line 1 character 6
SCRIPT5009: 'YAHOO' is undefined

This image selector and page orientated image storage is a really wonderful feature - thank you very much indeed.

I will finalise the v4 CKEditor stuff and send through.

Regards
Richard