Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#343 closed enhancement (fixed)

Make ImageManager backend configurable through javascript.

Reported by: gogo Owned by: gogo
Priority: highest Milestone: Version 1.0
Component: Plugin_ImageManager Version: trunk
Severity: normal Keywords:
Cc:

Description

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.

Change History (14)

comment:1 Changed 14 years ago by 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?ImageManager?myconfig?

comment:2 Changed 14 years ago by 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).

comment:3 Changed 14 years ago by 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 :)

comment:4 Changed 14 years ago by 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.

comment:5 Changed 14 years ago by gogo

  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:6 Changed 14 years ago by ray

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

comment:7 Changed 14 years ago by 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)

comment:8 Changed 14 years ago by 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

comment:9 Changed 14 years ago by ray

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

comment:10 Changed 14 years ago by 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 :)

comment:11 Changed 14 years ago by anonymous

  • Priority changed from normal to highest

comment:12 Changed 14 years ago by gogo

  • Resolution set to fixed
  • Status changed from reopened to closed

I think this can be closed now.

comment:13 Changed 14 years ago by 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??

comment:14 Changed 14 years ago by Rick Schippers <rick@…>

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

Note: See TracTickets for help on using tickets.