Make ImageManager backend configurable through javascript.

[gogo]

The ImageManager (amongst others) backend requires editing a configuration file contained in the IM plugin itself. This is an inconvenient situation which should be remedied so that the backend may be (securely) configured by passing values to the xinha_config javascript object so that modification to the config.inc.php is no longer required.

[niko]

I could imagine doing this using $_SESSION-variables.

in php:

$_SESSION['xinha']['ImageManager']['myconfig']['base_url'] = ...
$_SESSION['xinha']['ImageManager']['myconfig']['otherconfigvar'] = ...

xinha-configuration:

config.ImageManager.useConfig = "myconfig";

..and in config.inc.php we read $_SESSIONxinha?ImageManagermyconfig?

[gogo]

:) I've already done it, was just documenting ;) Will be committing this and some other stuff for ImageManager soon. This is how I did it.

       <?php
        $IMConfig = array();
        $IMConfig['images_dir'] = '/path/to/xinha-trunk/examples/images/';
        $IMConfig['images_url'] = '/xinha-trunk/examples/images/';
        $IMConfig = serialize($IMConfig);
        if(!isset($_SESSION['Xinha:ImageManager'])) 
        {
          $_SESSION['Xinha:ImageManager'] = uniqid('secret_');
        }
        $secret = $_SESSION['Xinha:ImageManager'];
       ?>
       xinha_config.ImageManager.images_url          = '/xinha-trunk/examples/images';
       xinha_config.ImageManager.backend_config      = '<?php echo jsaddslashes($IMConfig)?>';
       xinha_config.ImageManager.backend_config_hash = '<?php echo sha1($IMConfig . $secret)?>';
       xinha_config.ImageManager.backend_config_secret_key_location = 'Xinha:ImageManager';

(where jsaddslashes is just a function to escape special characters for javascript strings).

[gogo]

As I said there are a few extra things I'll be checking in soon for ImageManager, I'll just add them as a little "rider" to this ticket ;)

1. When you save an image after editing it, the editor doesn't close, nor the image browser refresh or select the image you just saved. This will be fixed.
2. when you change the dimensions of an image in the browser and click OK, it uses the full-size image as the src and just changes width/height. This will be changed so that the image is first resized (and saved to a new filename in a special directory in the same way as thumbs) and that is used as the src.
3. When you open the image browser after selecting an already inserted image the image manager does not change to the directory containing that image automatically. This will be fixed.
4. There is no indication in the image browser "filmstrip" of which (if any) image is currently selected. This will be fixed.

I'm also considering changing the filmstrip (horizontal scroll) view into a normal vertical scrolling view (with 4 thumbs/icons per row). The reasons I think this would be better are two-fold

• a horizontal scroll is fairly unusual in interfaces, and may be unfamiliar
• mouse wheels don't scroll horizontally (well, most)

comments on that last one are invited :)

[niko]

nice features :D

about the vertical scroll: yes, much better! the ExtendedFileManager (EFM) by Afru has this allready implemented! (among many other features)

He actually sent me a recent version of efm some time ago but told me to keep it private. (that was two month ago) He wanted to fix some bugs and then upload it into the plublic. But since that i only heard from him that he will get married :D. I allready sent him some patches - no rensponse.

[gogo]

I've commited these changes (finally) in changeset:256 also included in this commit is a new color picker which is being used by the image manager dialog, it's a fancy little (even if I do say so myself) HSV style color map which will appear in a layer when you click the button. I think this would work well as the main color picker interface for Xinha rather than the present popup window.

[ray]

The tranfer of the image folders does not work if some special character, like umlauts, are contained in the the path. The data should be urldecoded when transmitted through an url

[Kim Steinhaug]

I guess I did some of this already in my patch file in ticket #546. I didnt commit it as noted, if Niko or Gogo wants this to be apart of the ImageManager I could commit it and look over it again.

Again I dont see any reasons for having special characters in the URL anyways since it's bad practise and always ends with problems. (Point is, even if spaces in the URL usually translates to %20 and still works, it's wrong and it doesnt make it a good idea)

[ray]

Kim, you are right, for spaces anyway. But just in case the developer has chosen to use e.g. umlauts in urls (like i did and i admit i've got loads of problems with it), it would be a rather painless modification to use rawurldecode() in php or escape in js, respectively

[ray]

p.s.: I was inspired for my decision by the german wikipedia which replaces spaces by _ but leaves/encodes umlauts

[gogo]

In javascript, you should use EncodeURIComponent - particularly when dealing with PHP on the other end of the connection, escape encodes most unicode characters incompatably from php. From PHP, feeding data to Javascript in Xinha then you should probably use UTF-8, and ensure that your web server is serving it as UTF-8 (with a Content-Type header).

urlencode()'ing UTF-8 encoded characters above 127 should produce the individual bytes url-encoded, as should EncodeURIComponent() when run over a UNICODE character above 127 in javascript (remember strings in Javascript are raw UNICODE once read in, EncodeURIComponent effectly converts the UNICODE to UTF-8 encoded UNICODE and from that to a URL-Encoded string).

If that ENcodeURICOmponent'd url is given to PHP then PHP will be giving you the UTF-8 string (from urledecode), so if you're not expecting UTF-8 then you might be in trouble there.

In short, UTF-8 or don't use special characters is my advice :-)

Kim - if your patch fixes stuff, by all means, commit, as a non-english speaker you know more on this stuff than me I'm sure :)

[gogo]

I think this can be closed now.

[Rick Schippers <rick@…>]

Then how is it configurable through javascript now? I still see the same php config script inside the plugin directory. Is there a way to pass the image dir and image url through javascript now? If so how??

[Rick Schippers <rick@…>]

Nevermind, I found it out. Maybe you should update the example here http://xinha.python-hosting.com/wiki/ImageManager.